Subject: [Nea] Review of PT-TLS draft

From: Alexey Melnikov <[email-masked]>
Date: Wed, 23 Nov 2011 10:52:38 +0000

Hi,
I finished the review I've started during the Taipei IETF:

I think text about using tls-unique channel binding with capable SASL 
mechanisms is missing. Not entirely sure what is the best place for it yet.

3.1.1. Issues with Server Initiated PT-TLS Sessions

    Another issue with this scenario involves X.509 certificates.

I think RFC 5280 reference is missing here.

3.4.2. PT-TLS Message Exchange Phases

    The PT-TLS message exchange occurs in three distinct phases:
    o  TLS Setup (including TLS Handshake protocol)

    o  PT-TLS Negotiation

    o  PT-TLS Data Transport

    The TLS Setup phase is responsible for the establishment of the TCP
    connection and the TLS protections for the PT-TLS messages.  The TLS
    Setup phase normally starts with the establishment of a TCP
    connection between the Posture Transport Client and Posture Transport
    Server.  The new connection triggers the TLS Handshake protocol to
    establish the cryptographic protections for the TLS session.  The TLS
    Setup phase SHOULD NOT be repeated after the PT-TLS Data Transport
    phase has been reached unless a change of TLS cipher suite or keying
    material is required to properly protect the session.

The last quoted sentence: does this mean TLS renegotiation extension or 
something else?
I found this text to be unclear.

    This phase
    also enables the establishment of the tls-unique shared secret that
    can be used in a later phase to bind the posture sent with this TLS
    connection.

3.4.2.1. TLS Setup Phase

    During the TLS Setup phase of PT-TLS, the PT-TLS Initiator contacts
    the listening port of the PT-TLS Responder and performs a TLS
    handshake.  The PT-TLS Responder MUST possess a trustworthy X.509
    certificate used to authenticate to the TLS initiator and used to
    bootstrap the security protections of the TLS session.

I think this is lacking some details about what kind of X.509
certificate is Ok and what is to be verified in it. I think you should
use RFC 6125 here (at least for the case of NEA client talking to NEA 
server),
if you can, as RFC 5280 allows for too much flexibility.

    The PT-TLS
    Initiator MAY also use an X.509 certificate to authenticate to the
    PT-TLS Responder providing for a bi-directional authentication of the
    PT-TLS session.

In 3.4.2.2: first mention of SASL needs a reference.

3.4.3. TLS Requirements

    In order to ensure that strong security is always available for
    deployers and to improve interoperability, this section discusses
    some requirements on the underlying TLS transport used by PT-TLS.
    Implementations of PT-TLS MUST support use of TLS 1.1 [RFC4346] and
    SHOULD also include support for TLS 1.2 [RFC5246].

As per discussion diring the face-to-face meeting in Taipei:
all major TLS 1.1 implementations seem to also support 1.2,
so TLS 1.1 should be dropped and TLS 1.2 should be made a MUST.

In 3.6:

      9 (PT-TLS Error)            PT-TLS Error message as described in
                                  section 3.9.  This message type may be
                                  used during any PT-TLS phase.

The corresponding IANA registration (Section 6.2) says:
     0     11     PT-TLS Error             RFC # Assigned to this I-D

So one of these sections has an error.

      10+ (Reserved)              These values are reserved for future
                                  allocation following guidelines
                                  defined in the IANA Considerations
                                  section 6.1.  Recipients of messages
                                  of type 13 or higher that do not

Did you mean "10" here?

                                  support the PT-TLS Message Type Vendor
                                  ID and PT-TLS Message Type of a
                                  received PT-TLS message MUST respond
                                  with a Type Not Supported PT-TLS error
                                  code in a PT-TLS Error message.

3.8.2. SASL in PT-TLS Overview

    Mechanism negotiation is performed using the Request SASL Mechanisms
    and SASL Mechanisms TLVs.  The PT-TLS Initiator sends a Request SASL
    Mechanisms TLV to request a preference-ordered list of SASL

I think you should drop "preference-ordered" here: each SASL client 
should have
its own policy regarding preference order and such policy is likely to 
be different from
the server's policy. The client shouldn't be trusting server on this.

    mechanisms that the PT-TLS Responder is willing to use for this
    session.  The PT-TLS Initiator selects one SASL mechanism from the
    list and sends a SASL Mechanism Selection TLV completing the
    negotiation.  Subsequent challenges and responses are carried within
    the SASL Authentication Data TLV carrying the authentication data for
    the selected mechanism.  The authentication outcome is communicated
    in a SASL Result TLV containing a status code.  If additional
    authentications are required, the PT-TLS Responder could trigger the
    next authentication by sending another SASL Mechanisms TLV after
    sending the SASL Result TLV for the current authentication mechanism.

3.8.4. SASL Authentication Flow

    If an authentication is required by the PT-TLS Responder and
    not requested by the PT-TLS Initiator, the PT-TLS Responder
    (typically the NEA Server) SHOULD initiate the entity
    authentication exchange by sending a SASL Mechanisms TLV.  If
    the PT-TLS Responder receives a NEA assessment message before
    the completion of any required entity authentication, the PT-
    TLS Responder MUST send an Authentication Required PT-TLS Error
    indicating to the PT-TLS Initiator that an authentication
    exchange is required prior to entering the PT-TLS Data
    Transport phase.  The SASL Mechanisms TLV includes a
    preference-ordered list of the SASL mechanisms that the PT-TLS

As above: drop "preference-ordered".

    Responder is willing to use and allows for the selection of one
    by the PT-TLS Initiator for use with this session.

Your SASL profile doesn't seem to support  "additional data with success"
feature of SASL (which can save a round trip). I suggest you say so 
explicitly.
Or alternatively you can update the message reporting outcome of a SASL
authentication exchange to include this information.

3.8.6.3. SASL Security Layer

    The NEA PT-TLS protocol always runs under the protection of TLS.
    SASL security layers are not used.

Add "and thus MUST be negotiated off during SASL authentication" to
the end of this sentence. SASL security layers are negotiated during
authentication using SASL mechanisms that support security layers.

3.8.6.4. Multiple Authentications

    Only one SASL mechanism authentication may be in progress at any one
    time.  Once a SASL mechanism completes (successfully or
    unsuccessfully) a new authentication may be initiated.

I think you need to talk somewhere that this profile of SASL
doesn't support reauthentication (i.e. authentication as another user,
after an earlier successful authentication) like LDAP does.
Instead PT-TLS is supporting "multiple cumulative authentications"
(I needed to invent a new term).

3.8.10. SASL Authentication Data

    This TLV carries an opaque (to PT-TLS) blob of octets being exchanged
    between the PT-TLS Initiator and the PT-TLS Responder.  This TLV
    facilitates their communications without interpreting any of the
    bytes.  The SASL Authentication Data TLV MUST NOT be sent until a
    SASL mechanism has been established for a session.  The SASL
    Authentication Data TLV MUST NOT be sent after a SASL Result is sent
    with a Successful status.

The last MUST NOT seem to prevent multiple authentications, which
I don't think is the intent.

3.8.11. SASL Result

    This TLV is sent by the PT-TLS Responder at the conclusion of the
    SASL exchange to indicate the authentication result.  This TLV may
    also be sent by the PT-TLS Initiator to indicate a client side
    failure.  The PT-TLS Initiator MUST NOT send other Result-Code values
    besides Failure.  Upon reception of a SASL Result TLV indicating an
    Abort, the recipient MUST terminate the current authentication
    conversation.  The recipient may retry the authentication in the
    event of an authentication failure.  Similarly, the NEA Server may
    request additional SASL authentication(s) be performed after the
    completion of a SASL mechanism by sending another SASL Mechanisms
    TLV.

Can any such subsequent list include authentication mechanisms already
successfully used earlier in the same session?

3.8.11. SASL Result

        1 (Failure)               SASL authentication failed.  This
                                  might be caused by the entity
                                  providing an invalid user identity
                                  and/or credential pair.  Note that
                                  this is not a mechanism failure to
                                  process the authentication.

What is the meaning of the last sentence?

If you meant to say that that is different from 3:

        3 (Mechanism Failure)     SASL mechanism failure during the
                                  processing of the entity's
                                  authentication (not related to the
                                  user's input).

then you should say so above (maybe quote "Mechanism Failure"?)

s/user's input/authentication mechanism's input
(Not all of it is "user's input")

Additionally, it is not very clear whether this covers any errors other
than "unsupported SASL mechanism name".

And finally, can you just use "error message" (Section 3.9) for reporting
SASL authentication errors instead?

3.9. Error Message

        4 (Failed Authentication) The authentication of the identity of
                                  the client failed.  This could occur
                                  if the SASL mechanism was unable to
                                  authenticate the claimed identity of
                                  the PT-TLS Initiator.  This error
                                  message does not indicate a fatal
                                  error has occurred, so the
                                  authentication is allowed to be re-
                                  started.

I am confused, I thought this condition should have resulted in "SASL 
result"
with Fail status.

4.2.5. NEA Asokan Attacks

    Because lying endpoint attacks are much easier than Asokan attacks
    and the only known effective countermeasure against lying endpoint
    attacks is the use of an External Measurement Agent (EMA),
    countermeasures against an Asokan attack are not necessary unless an
    EMA is in use. However, PT-TLS implementers may not know whether an
    EMA will be used with their implementation.  Therefore, PT-TLS
    implementers SHOULD support the Asokan attack countermeasures by
    providing the value of the tls-unique channel binding to higher
    layers in the NEA reference model: Posture Broker Clients, Posture
    Broker Servers, Posture Collectors, and Posture Validators.

Mention SASL here as well (e.g. use of tls-unique with SASL mechanisms
that support channel bindings)?

6.1. Designated Expert Guidelines

    Instead, designated experts should focus on the following
    requirements.  All values in these IANA registries MUST be
    documented in a specification that is permanently and publicly
    available. IETF standard values MUST also be useful, not

For clarity I would replace "IETF standard values" with "Values
defined in Standards Track RFCs".

    harmful to the Internet, and defined in a manner that is clear
    and likely to ensure interoperability.