Subject: Re: [Nea] Review of PT-TLS draft

From: Joe Salowey <[email-masked]>
Date: Thu, 9 Feb 2012 20:45:35 -0800

> 
>>> 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.
>>> 
>> [Joe] How About
>> 
>> "This phase also includes the establishment of the tls-unique shared secret.  The tls-unique shared secret can later be used by PA to protect again some forms of man-in-the-middle attack."
> Ok. tls-unique is the channel binding data here, right?

[Joe]  yes.  
>> 
>>> 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.
>>> 
>> [Joe] The preference-ordered represents the preferences of the message sender.  The PTC may have policy the guides its selection of mechanism.  This section is likely to be re-written based on other comments
>> discussed at the IETF meeting.  Is there an issue with the PTS sending a list of SASL mechanisms ordered in the PTS's preferred order?
> It is dangerous on the client side. For example if the server lists less secure mechanisms first for some reason.
>>   The PTC is free to select the mechanism it finds acceptable based on its local policy. Ideally this would result in the PTC using the first acceptable SASL mechanism proposed by the PTS (but this is a policy issue).
> I think the client should disregard server preferences. If the server advertises multiple mechanisms, it should be prepared for the client to use any of them.

[Joe] Makes sense to me. 

>>>    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.
>>> 
>> [Joe] Not sure I follow.  We do support carrying "Optional Result Data" along with a successful SASL authentication in the SASL Result message.
> I probably didn't find it because it is named differently. Can you rename the field (to match SASL terminology) or just clarify that the field can be used for this purpose?

[Joe] Yes

>> 
>>> 
>>> 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.
>>> 
>> [Joe] OK
>> 
>>> 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).
>>> 
>> [Joe]  So in LDAP does it specify that a subsequent authentication replaces the state of the previous one?
> Yes. In other protocols this is just disallowed.

>> I think with NEA this may be up to server policy.
>> 

[Joe] I'd like to hear more from the working group on this.  We could add text that it is up to the server whether to completely reset the client state on a new authentication or not.  I deserves some thought to make sure we understand any risks we are introducing.  

>>> 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.
>>> 
>> [Joe] In order to start another authentication, one repeats the SASL mechanism selection messages (doesn't send another SASL Authentication Data TLV right away).  We will make this more clear.
>> 
>>> 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?
>>> 
>> [Joe] Yes if dictated by the NEA Server policy.  Is this a problem?
> No, but it would be worth spelling this out explicitly.
[Joe]  OK

>>> 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?
>>> 
>> [Joe] The last sentence separates authentication failures from mechanism internal logic failures.
> Ok. I don't think I've seen protocols doing that, but that is not a problem in itself.

[Joe] OK
>> 
>>> 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"?)
>>> 
>>> 
>> [Joe] Agree
>> 
>>> s/user's input/authentication mechanism's input
>>> (Not all of it is "user's input")
>>> 
>> [Joe] Will make it more clear that was an example
>> 
>>> 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.
>>> 
>> [Joe] This error specifically was intended to mean the authentication of the user failed due to the claimed identity and credential not be acceptable (incorrect pair or unauthorized) which is different from mechanism
>> internal logic failures.  We need to review that this value is needed in light of the other ways to report authentication status and will remove if it's a duplicate.
> Ok.
>>> 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)?
>>> 
>> [Joe]  I'll work on some text to address this.
>> 
>>> 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".
>> [Joe] OK
>> 
>>>    harmful to the Internet, and defined in a manner that is clear
>>>    and likely to ensure interoperability.
>>> 
>