From jsalowey@cisco.com Wed Jan 18 17:30:43 2012 Return-Path: X-Original-To: nea@ietfa.amsl.com Delivered-To: nea@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49A3011E80DA for ; Wed, 18 Jan 2012 17:30:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tm1rPepkYMTk for ; Wed, 18 Jan 2012 17:30:40 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id C10FE11E80C1 for ; Wed, 18 Jan 2012 17:30:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jsalowey@cisco.com; l=16846; q=dns/txt; s=iport; t=1326936640; x=1328146240; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=Q64483qxTI5v1gCuni/z/aaa5B0nxl89sb4cR60xfCs=; b=QhCS4/995fBClv69avyBEtELT+NXd3TM90XyEHQ759iXNFjpHBaqynip oFQ0pEeWzTi5NxPhDzEr8QD8HIKLeMOzDGQo+Jlocn/wC8K0AWXvu2a2k X+ZrM0gf3BbyU7IZnbasOrB428hncu3THiNzdFIGN4yZxTTw4EHN0qNzy Y=; X-IronPort-AV: E=Sophos;i="4.71,533,1320624000"; d="scan'208";a="24386380" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-1.cisco.com with ESMTP; 19 Jan 2012 01:30:40 +0000 Received: from [10.33.251.93] ([10.33.251.93]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q0J1UbjF009647; Thu, 19 Jan 2012 01:30:39 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Joe Salowey In-Reply-To: <4ECCD076.7080003@isode.com> Date: Wed, 18 Jan 2012 17:31:08 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4ECCD076.7080003@isode.com> To: Alexey Melnikov X-Mailer: Apple Mail (2.1084) Cc: nea@ietf.org Subject: Re: [Nea] Review of PT-TLS draft X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2012 01:30:43 -0000 Hi Alexey, Thanks for the review, comments inline below.=20 Cheers, Joe On Nov 23, 2011, at 2:52 AM, Alexey Melnikov wrote: > =20 > Hi, > I finished the review I've started during the Taipei IETF: >=20 >=20 > 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. >=20 >=20 [Joe] Here is some proposed text: I suggest we add a section "3.8.6.5 SASL Channel Bindings" "SASL channel bindings are used to bind the SASL authentication to the = outer TLS tunnel to ensure that the authenticating endpoints are the = same as the TLS endpoints. For SASL mechanisms that support channel = bindings the TLS-unique value defined in [RFC 5929] is carried by the = SASL Mechanism. For most mechanisms this means including the = tls-unique value with the appropriate prefix defined in [RFC5929] in the = application data portion of the SASL Mechanism channel binding data. If = the validation of the channel-binding fails then the connection MUST be = aborted." > 3.1.1. Issues with Server Initiated PT-TLS Sessions >=20 > Another issue with this scenario involves X.509 certificates. >=20 > I think RFC 5280 reference is missing here. >=20 >=20 [Joe] I agree. The validation of the identity in the cert will likely = be different than traditional validation based on domain name. We = probably should mention some minimum functionality here, such as the = server should be able to validate against the issuer and subject alt = names to determine if it is talking to the right host.=20 >=20 > 3.4.2. PT-TLS Message Exchange Phases >=20 > The PT-TLS message exchange occurs in three distinct phases: > o TLS Setup (including TLS Handshake protocol) >=20 > o PT-TLS Negotiation >=20 > o PT-TLS Data Transport >=20 > 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. >=20 > The last quoted sentence: does this mean TLS renegotiation extension = or something else? [Joe] Perhaps it would be better to replace the last sentence with: "Once the PT-TLS setup phase has completed, the TLS session MUST not be = renegotiated. TLS session renegotiation MAY be used before the PT-TLS = Set-up phase ends and the Negotiation phase begins. " > I found this text to be unclear. >=20 > 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. >=20 >=20 [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." >=20 > 3.4.2.1. TLS Setup Phase >=20 > 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. >=20 > 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. >=20 [Joe] I think we can use RFC 6125, for the opposite direction I think we = will need to something different as discussed above. =20 > 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. >=20 >=20 > In 3.4.2.2: first mention of SASL needs a reference. >=20 >=20 >=20 > 3.4.3. TLS Requirements >=20 > 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]. >=20 > 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. >=20 [Joe] I think we'll need to get feedback from the working group. I'd = like to go with 1.2, however there are some 1.1 libraries that do not = support 2.1, but I'm not sure they matter to the implementers.=20 > In 3.6: >=20 > 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. >=20 > The corresponding IANA registration (Section 6.2) says: > 0 11 PT-TLS Error RFC # Assigned to this I-D >=20 > So one of these sections has an error. >=20 [Joe] needs to be fixed.=20 >=20 > 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 >=20 > Did you mean "10" here? >=20 > 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. >=20 [Joe] yes, Needs to be fixed >=20 > 3.8.2. SASL in PT-TLS Overview >=20 > 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 >=20 > 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. >=20 [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? 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). > 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. >=20 >=20 > 3.8.4. SASL Authentication Flow >=20 > 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 >=20 > As above: drop "preference-ordered". >=20 > Responder is willing to use and allows for the selection of one > by the PT-TLS Initiator for use with this session. >=20 >=20 >=20 > 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. >=20 [Joe] Not sure I follow. We do support carrying "Optional Result Data" = along with a successful SASL authentication in the SASL Result message. >=20 >=20 > 3.8.6.3. SASL Security Layer >=20 > The NEA PT-TLS protocol always runs under the protection of TLS. > SASL security layers are not used. >=20 > 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. >=20 [Joe] OK >=20 > 3.8.6.4. Multiple Authentications >=20 > 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. >=20 > 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). >=20 [Joe] So in LDAP does it specify that a subsequent authentication = replaces the state of the previous one? I think with NEA this may be up = to server policy.=20 > 3.8.10. SASL Authentication Data >=20 > 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. >=20 > The last MUST NOT seem to prevent multiple authentications, which > I don't think is the intent. >=20 [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 >=20 > 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. >=20 > Can any such subsequent list include authentication mechanisms already > successfully used earlier in the same session? >=20 [Joe] Yes if dictated by the NEA Server policy. Is this a problem? >=20 > 3.8.11. SASL Result >=20 > 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. >=20 > What is the meaning of the last sentence? >=20 [Joe] The last sentence separates authentication failures from mechanism = internal logic failures. > If you meant to say that that is different from 3: >=20 > 3 (Mechanism Failure) SASL mechanism failure during the > processing of the entity's > authentication (not related to the > user's input). >=20 > then you should say so above (maybe quote "Mechanism Failure"?) >=20 >=20 [Joe] Agree > s/user's input/authentication mechanism's input > (Not all of it is "user's input") >=20 [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". >=20 > And finally, can you just use "error message" (Section 3.9) for = reporting > SASL authentication errors instead? >=20 >=20 >=20 > 3.9. Error Message >=20 > 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. >=20 > I am confused, I thought this condition should have resulted in "SASL = result" > with Fail status. >=20 [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. >=20 > 4.2.5. NEA Asokan Attacks >=20 > 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. >=20 > Mention SASL here as well (e.g. use of tls-unique with SASL mechanisms > that support channel bindings)? >=20 [Joe] I'll work on some text to address this. =20 > 6.1. Designated Expert Guidelines >=20 > 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 >=20 > 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. >=20 From alexey.melnikov@isode.com Thu Jan 19 05:28:52 2012 Return-Path: X-Original-To: nea@ietfa.amsl.com Delivered-To: nea@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63D0321F85A3 for ; Thu, 19 Jan 2012 05:28:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.16 X-Spam-Level: X-Spam-Status: No, score=-102.16 tagged_above=-999 required=5 tests=[AWL=0.439, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l5XDt1AEraj8 for ; Thu, 19 Jan 2012 05:28:51 -0800 (PST) Received: from rufus.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 4A30421F85B4 for ; Thu, 19 Jan 2012 05:28:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1326979729; d=isode.com; s=selector; i=@isode.com; bh=f74UgZx8mPh8aEV06Vpgvgl44vxzt4aqfqiJTg14aYg=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=MNTUTroUdKDUFh5jrbkyKhBgFbj8fy5weF417MHuMAFS2hIAfWP5GrOnWPk7K10t0A5kyt v6Dj1kl8UHscxRb2zosXEIg/26HyYRVaBIOfbSvFF5sWoMCU1RfZ4Gkb6zmA8DS2ujVPGp n0d1EE3zAnYtU/ufdgcUAsIanSrfBlI=; Received: from [188.28.157.129] (188.28.157.129.threembb.co.uk [188.28.157.129]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Thu, 19 Jan 2012 13:28:47 +0000 Message-ID: <4F181A8B.6000504@isode.com> Date: Thu, 19 Jan 2012 13:28:43 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 To: Joe Salowey References: <4ECCD076.7080003@isode.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 19 Jan 2012 05:35:39 -0800 Cc: nea@ietf.org Subject: Re: [Nea] Review of PT-TLS draft X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2012 13:28:52 -0000 On 19/01/2012 01:31, Joe Salowey wrote: > Hi Alexey, Hi Joe, > Thanks for the review, comments inline below. > > Cheers, > > Joe > On Nov 23, 2011, at 2:52 AM, Alexey Melnikov wrote: > >> >> 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. >> >> > [Joe] Here is some proposed text: > > I suggest we add a section "3.8.6.5 SASL Channel Bindings" > > "SASL channel bindings are used to bind the SASL authentication to the outer TLS tunnel to ensure that the authenticating endpoints are the same as the TLS endpoints. For SASL mechanisms that support channel bindings the TLS-unique value defined in [RFC 5929] is carried by the SASL Mechanism. For most mechanisms this means including the tls-unique value with the appropriate prefix defined in [RFC5929] in the application data portion of the SASL Mechanism channel binding data. If the validation of the channel-binding fails then the connection MUST be aborted." This looks good to me, thanks. >> 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. >> > [Joe] I agree. The validation of the identity in the cert will likely be different than traditional validation based on domain name. We probably should mention some minimum functionality here, such as the server should be able to validate against the issuer and subject alt names to determine if it is talking to the right host. Right. >> 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? > [Joe] Perhaps it would be better to replace the last sentence with: > > "Once the PT-TLS setup phase has completed, the TLS session MUST not be renegotiated. TLS session renegotiation MAY be used before the PT-TLS Set-up phase ends and the Negotiation phase begins." Looks good, thanks. >> 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? >> 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. > [Joe] I think we can use RFC 6125, for the opposite direction I think we will need to something different as discussed above. Agreed. >> 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. >> > [Joe] I think we'll need to get feedback from the working group. I'd like to go with 1.2, however there are some 1.1 libraries that do not support 2.1, but I'm not sure they matter to the implementers. Ok. > >> 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. >> > [Joe] needs to be fixed. > >> 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. >> > [Joe] yes, Needs to be fixed > >> 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. >> 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? > >> >> 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. > >> 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. >> 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. > >> 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. >> From sethomso@cisco.com Thu Jan 26 12:56:19 2012 Return-Path: X-Original-To: nea@ietfa.amsl.com Delivered-To: nea@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B545E21F86EA for ; Thu, 26 Jan 2012 12:56:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HXtYvKop6TaD for ; Thu, 26 Jan 2012 12:56:19 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 1BAE921F8666 for ; Thu, 26 Jan 2012 12:56:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sethomso@cisco.com; l=753; q=dns/txt; s=iport; t=1327611379; x=1328820979; h=date:subject:from:to:message-id:mime-version: content-transfer-encoding; bh=RkOu0L8BT58BmfrOZ8Ohrq0DjfOun2DYH+SuTRs2QCE=; b=Tj54UdEJETxabs6jjVY4OkHurT+x/SpX9oNpz6/fqPTzCpR3DcR0jpmM 2A9F4fBX7Qt9v6YnjpLBSmOIby2ZU+A/ChmZZYOkdz/PcRkYs1hNaOOgo 3uOUNBdZcjVdslDQVCYWWAyniW/mlEN5vDEC5qJjNuOUOd6YFppFe/UzZ 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAAS9IU+tJV2c/2dsb2JhbABCrk6BBYF0AQQSAQodAgExHQGBJgEENYdimCSBJwGeO4kZASQQAQgBBgQDAwQLAQIECQQDAQKEUQIXgxwEiD+MYJJv X-IronPort-AV: E=Sophos;i="4.71,575,1320624000"; d="scan'208";a="54159450" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-8.cisco.com with ESMTP; 26 Jan 2012 20:56:18 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id q0QKuIIZ006978 for ; Thu, 26 Jan 2012 20:56:18 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 26 Jan 2012 14:56:18 -0600 Received: from 10.116.64.103 ([10.116.64.103]) by XMB-RCD-111.cisco.com ([72.163.62.153]) with Microsoft Exchange Server HTTP-DAV ; Thu, 26 Jan 2012 20:56:18 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Thu, 26 Jan 2012 15:56:17 -0500 From: Susan Thomson To: Message-ID: Thread-Topic: NEA WG Next Steps: Call for Comments on PT-EAP I-D Thread-Index: AczcbPKAWeepQPA9LEOlh35T0/Oz3Q== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 26 Jan 2012 20:56:18.0647 (UTC) FILETIME=[F37BFE70:01CCDC6C] Subject: [Nea] NEA WG Next Steps: Call for Comments on PT-EAP I-D X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2012 20:56:19 -0000 Hi all There has been good feedback on the PT-TLS I-D - thank you! The plan is for the editors to update the I-D based on comments received and post the revision to the list within a few weeks. The goal is to do a 2nd WGLC prior to the next IETF. In contrast, we have not received much feedback on the PT-EAP I-D. Please review the document (http://tools.ietf.org/id/draft-ietf-nea-pt-eap-00.txt) and send your comments to the mailing list by Friday, February 10, 2012. This will allow time to revise the document and to issue a WGLC on the document prior to the next meeting. Thanks very much to those who have posted comments on the PT-TLS I-D, and we look forward to the same level of feedback on the PT-EAP I-D. Thanks Susan