From aland@deployingradius.com Wed Jun 6 06:09:46 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 7AC7D21F8870 for ; Wed, 6 Jun 2012 06:09:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.283 X-Spam-Level: X-Spam-Status: No, score=-102.283 tagged_above=-999 required=5 tests=[AWL=0.316, 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 KW-Ba1Iri341 for ; Wed, 6 Jun 2012 06:09:46 -0700 (PDT) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id DD6C021F8860 for ; Wed, 6 Jun 2012 06:09:45 -0700 (PDT) Message-ID: <4FCF567D.900@deployingradius.com> Date: Wed, 06 Jun 2012 15:09:17 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: nea@ietf.org X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Nea] Review of draft-ietf-nea-pt-eap-02.txt 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: Wed, 06 Jun 2012 13:09:46 -0000 Some minor notes: Section 1: The PT-EAP protocol must be protected by an outer EAP TLS-based tunnel to ensure the exchanged messages are protected from a variety of threats from hostile intermediaries. That should probably be MUST instead of "must". I also suggest adding text saying: The encapsulating EAP TLS-based tunnel MUST first authenticate the user prior to using PT-EAP. i.e. using EAP-TLS + PT-EAP might be OK. Using EAP-TTLS with *only* PT-EAP inside the TLS tunnel should be forbidden. Section 3.3: Type TBD Suggestion: add a discussion of what the type field means, and what it is likely to be used for. Data Variable length data. The length of the Data field in a particular PT-EAP message may be determined by subtracting the length of the PT-EAP header fields from the value of the two octet Length field. It's worth saying what the data is expected to be. Right now, transport of JPGs inside of PT-EAP seems to be allowed. Section 4.2.1: In order to protect against NEA assessment message theft, the EAP tunnel method carrying PT-EAP must provide strong cryptographic authentication, integrity and confidentiality protection. That should probably be MUST instead of "must". Section 4.2.3: The strong integrity protections (hashing) offered by EAP-TTLS allows the PT-EAP message recipients to detect message alterations by other types of network based adversaries. Is "hashing" a method of strong integrity protection? Or is it just using the TLS message integrity methods? Section 7: There is no IANA considerations for the "Type" field. Since it is being defined here, I presume there will be an IANA "PT-EAP Type" registry. It would be good to add a section (7.2) describing this registry. Alan DeKok. From dromasca@avaya.com Mon Jun 11 07:20:08 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 C7CC921F8599; Mon, 11 Jun 2012 07:20:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.399 X-Spam-Level: X-Spam-Status: No, score=-103.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 GiaqeBM-IjbH; Mon, 11 Jun 2012 07:20:08 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 176DA21F8596; Mon, 11 Jun 2012 07:20:07 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAJH91U/GmAcF/2dsb2JhbABFtROBB4IaAQEDEh4KMQ4SARUVBgwMB1cBBAEaGodpmzWcUYs4hHVgA5sTigaCYoFU X-IronPort-AV: E=Sophos;i="4.77,389,1336363200"; d="scan'208";a="352090165" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 11 Jun 2012 10:17:35 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by co300216-co-erhwest-out.avaya.com with ESMTP; 11 Jun 2012 10:18:32 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 x-cr-hashedpuzzle: FEjk KtXO LVkZ M27l OVeo cyry iNCV vWxq 4tDB AB4tVQ== AC3Khg== ADXRLA== AEASOA== AEhGbA== AFducQ== AFhsPQ==; 8; agBzAGEAbABvAHcAZQB5AEAAYwBpAHMAYwBvAC4AYwBvAG0AOwBuAGMAYQBtAHcAaQBuAGcAQABjAGkAcwBjAG8ALgBjAG8AbQA7AG4AZQBhAEAAaQBlAHQAZgAuAG8AcgBnADsAbwBwAHMALQBkAGkAcgBAAGkAZQB0AGYALgBvAHIAZwA7AHAAYQB1AGwAXwBzAGEAbgBnAHMAdABlAHIAQABzAHkAbQBhAG4AdABlAGMALgBjAG8AbQA7AHMAZQB0AGgAbwBtAHAAcwBvAEAAYwBpAHMAYwBvAC4AYwBvAG0AOwBzAGgAYQBuAG4AYQBAAGoAdQBuAGkAcABlAHIALgBuAGUAdAA7AHMAdABlAHAAaABlAG4ALgBmAGEAcgByAGUAbABsAEAAYwBzAC4AdABjAGQALgBpAGUA; Sosha1_v1; 7; {E765DEDE-8763-4EFD-9F34-04ACAA28BE4A}; ZAByAG8AbQBhAHMAYwBhAEAAYQB2AGEAeQBhAC4AYwBvAG0A; Mon, 11 Jun 2012 14:19:46 GMT; TwBwAGUAcgBhAHQAaQBvAG4AcwAgAEQAaQByAGUAYwB0AG8AcgBhAHQAZQAgAFIAZQB2AGkAZQB3ACAAbwBmACAAZAByAGEAZgB0AC0AaQBlAHQAZgAtAG4AZQBhAC0AcAB0AC0AdABsAHMALQAwADUA MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable x-cr-puzzleid: {E765DEDE-8763-4EFD-9F34-04ACAA28BE4A} Content-class: urn:content-classes:message Date: Mon, 11 Jun 2012 16:19:46 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Operations Directorate Review of draft-ietf-nea-pt-tls-05 Thread-Index: Ac1H3UDULckBLm7vQhq8Xci7wLPg+w== From: "Romascanu, Dan (Dan)" To: , , "Joe Salowey" X-Mailman-Approved-At: Mon, 11 Jun 2012 07:33:33 -0700 Cc: ops-dir@ietf.org, nea@ietf.org, sethompso@cisco.com Subject: [Nea] Operations Directorate Review of draft-ietf-nea-pt-tls-05 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: Mon, 11 Jun 2012 14:20:08 -0000 Hi,=20 This is an OPS-DIR review for draft-ietf-nea-pt-tls-05. Although this is not an easy reading for a non-expert, it's a well written specification, based upon wide field experience with proprietary protocols, and I do not expect major obstacles in operational deployment.=20 A few issues triggered by the checklist in RFC 5706:=20 1. 'Does the new protocol need supporting services (e.g., DNS or Authentication, Authorization, and Accounting - AAA) added to an existing network?' The protocol stacks atop of TLS. Section 3.4.3 (TLS requirements) includes a SHOULD requirement for TLS 1.2, but neither here nor in other parts of the document I could find a requirement that PT-TLS implementations MUST support TLS 1.0 and TLS 1.1. The authors may want to add this. I believe that mentioning the fact that the protocol is layered atop of TLS in the title and Abstract would make this key design issue more clear to the readers. 2. The protocol uses the Vendor PEN, but assumes it is limited to 24-bit.=20 In Section 3.5 - Message Vendor ID - . =20 Consistent with PA-TNC and PB- TNC, we depend on the PEN fitting in 24 bits, so if IANA were to register a wider PEN than that PEN could not be used with NEA. IETF namespace PT-TLS Message Types MUST use zero (0) in this field. =20 However, discussions triggered by draft-liang-iana-pen-00 may end by that document recommending that new protocols define at least 32-bit PEN fields. Is this impossible in this case? What are the 8 bits preceding the Message Type Vendor ID Reserved for? 3. 'Have suggestions for verifying correct operation been discussed?' Not really. How are assessment results communicated to the operators? Are they public? Maybe they MUST NOT be public (because of privacy concerns for example)? The document says nothing about this. Same question about errors, authentication failures, or other error counts. =20 4. 'Has management interoperability been discussed?' As with many other security-related protocols this document offers little to none information about manageability, so interoperable management does not seem to be an issue, or maybe these aspects are discussed in another document. In any case, this could be explained in text.=20 5. Editorial observation - Readability could be improved if acronyms like MITM (Man-in-the Middle) would be expanded at their first occurrence.=20 Regards, Dan From stephen.farrell@cs.tcd.ie Wed Jun 13 04:32:20 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 CAF4021F865B for ; Wed, 13 Jun 2012 04:32:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 DwjEjiT3IS3D for ; Wed, 13 Jun 2012 04:32:20 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id CCA8421F865C for ; Wed, 13 Jun 2012 04:32:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 12B781717FE for ; Wed, 13 Jun 2012 12:32:19 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1339587137; bh=dDhGAKAZXZfWCt M+YpckkW1ZZkxQKBUOC7P5N1KrWqo=; b=D58xEylCkcJWUq6l2BLUi79jqjtABr 9KjCXux7kFWK8CImR71X3mZUYdKxX0x8eWAwFFJD2Llo6ZY7d1bmepZI0Lp6swtC DA3au5gchY+gf8+rIOI5fVlQx6DFjicivW+RjtnDyblxD5NZyDBbechdTc37UyIL r0qNjPVX8jzK3bFK5eU3HB02+qxd55z+VIOI3bouOyZnYQFMAP1mUxu6Zp6DFdsB HQdzds6MWijDM2OBMDImN9pBxTUel8gwK8FbwDGJulRy8+NGW6VctBDrpe+mRvTe Jci9tzwPvpGc17LvWYw8+nRV7ZhpsfsEAel7OuYMqkDoA+GyrY7129Sg== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id fmmTNGth4ama for ; Wed, 13 Jun 2012 12:32:17 +0100 (IST) Received: from [IPv6:2001:770:10:203:353a:5c1f:6277:879a] (unknown [IPv6:2001:770:10:203:353a:5c1f:6277:879a]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 15AC61714DE for ; Wed, 13 Jun 2012 12:32:16 +0100 (IST) Message-ID: <4FD87A40.3070708@cs.tcd.ie> Date: Wed, 13 Jun 2012 12:32:16 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: "nea@ietf.org" References: <4FCD0614.5050902@isode.com> In-Reply-To: <4FCD0614.5050902@isode.com> X-Enigmail-Version: 1.4.2 X-Forwarded-Message-Id: <4FCD0614.5050902@isode.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Nea] Fwd: APPSDIR review of draft-ietf-nea-pt-tls-04 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: Wed, 13 Jun 2012 11:32:20 -0000 Forwarding to nea list. -------- Original Message -------- Subject: APPSDIR review of draft-ietf-nea-pt-tls-04 Date: Mon, 04 Jun 2012 20:01:40 +0100 From: Alexey Melnikov To: apps-discuss@ietf.org, draft-ietf-nea-pt-tls.all@tools.ietf.org CC: ietf@ietf.org I have been selected as the Applications Area Directorate reviewer for this draft (for background on APPSDIR, please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ). Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. The review is not copied to the IESG as the Last Call has not been announced yet. Document: draft-ietf-nea-pt-tls-04 Title: PT-TLS: A TCP-based Posture Transport (PT) Protocol Reviewer: Alexey Melnikov Review Date: June 4, 2012 Summary: This document is almost ready for publication as a Proposed Standard, although some [mostly] SASL related issues remain. This document specifies PT-TLS, a TCP-based Posture Transport (PT) protocol. The PT-TLS protocol carries the Network Endpoint Assessment (NEA) message exchange under the protection of a Transport Layer Security (TLS) secured tunnel. (Note, I've reviewed -04, but I think all of this still applies to -05.) Major: In 3.4.2.1: RFC 6125 use details are missing. You need to describe whether CN-IDs and SRV-IDs are allowed, whether wildcards are allowed, etc. I can suggest some details. Minor: In Section 3.2: This document is not yet Internet Standard, it will be Proposed Standard. Suggest saying "Publication on Standards Track" instead instead of "Internet Standard". The same issue in the IANA consideration section. In 3.8.1: I think one instance of "SASL authentication messages" --> "SASL authentication mechanisms". Otherwise this sentence is out of place, as you are not talking about SASL messages. In 3.8.4: in SASL the server doesn't return abort as an error code, it just fails the authentication exchange. I suggest removing it as a choice. In 3.8.7: you define the Reserved field which I assume is used for padding? If yes, then you will not get proper alignment for the next field, as SASL mechanism names are variable length. (If you intended that they are always sent as 20 bytes, then this is missing from the document.) In 3.8.10: The Abort choice is really not needed (as per above). Also, can you give me an example of when the Mechanism Failure will be returned instead of just Failure? In 3.9: Failed Authentication error code - how does this differ from SASL Authentication result with Failure code? In 4.1.2, second block, the first bullet: I think you meant "client" instead of the "server". Question (might not be an issue): In 6.2: is it possible to register a vendor specific value without a specification? The same question for 6.3. Nits: None From stephen.farrell@cs.tcd.ie Wed Jun 13 04:32:34 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 B40FD21F8522 for ; Wed, 13 Jun 2012 04:32:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 zq1bgsuh8ovF for ; Wed, 13 Jun 2012 04:32:34 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id DE66A21F84FC for ; Wed, 13 Jun 2012 04:32:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 4B2CE1717F3 for ; Wed, 13 Jun 2012 12:32:33 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1339587152; bh=JEawXPj87CtpbC lInseymZtvXfHQjHYTI0eKSgsHnfo=; b=LxaTc2oXtzRrA7IVGNOJ3s8UTVOJu5 1E4nsH5GW+CptBacpKrnhpaPkJLisKECFJzR1I4f9+CRWiatlKUvutRLuRHAqsnO /ALBkyJgRckxJd5DWgbKT8lRCSbkEMRMo9XSK6YcnvhrdnqFcpa+8GHGhz+fPAfo MHxRUKkgHiFvDYjhfsicYh92a6MAGSd2QeZKzCiZbfpXU6TlEom9DBYuzIbagESm 5i4Zvdc3Pk/N9EPXOz2rT7BLqK+/Y6cLAID0CvH/CWGDb90fQOa2hPDw+xiSJQRp CWeUZZtEe7r4RLQvuGft+n5fvehRu9IMdnSpy8jp8xx7wo9pvoYUQbdg== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id 4svDlIu9kShp for ; Wed, 13 Jun 2012 12:32:32 +0100 (IST) Received: from [IPv6:2001:770:10:203:353a:5c1f:6277:879a] (unknown [IPv6:2001:770:10:203:353a:5c1f:6277:879a]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id CA07B1714DE for ; Wed, 13 Jun 2012 12:32:32 +0100 (IST) Message-ID: <4FD87A51.4060403@cs.tcd.ie> Date: Wed, 13 Jun 2012 12:32:33 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: "nea@ietf.org" References: <4fcd272e.2968b40a.55d4.ffff9de3@mx.google.com> In-Reply-To: <4fcd272e.2968b40a.55d4.ffff9de3@mx.google.com> X-Enigmail-Version: 1.4.2 X-Forwarded-Message-Id: <4fcd272e.2968b40a.55d4.ffff9de3@mx.google.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Nea] Fwd: GenART LC review of draft-ietf-nea-pt-tls-05 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: Wed, 13 Jun 2012 11:32:34 -0000 Forwarding to nea list. -------- Original Message -------- Subject: GenART LC review of draft-ietf-nea-pt-tls-05 Date: Tue, 5 Jun 2012 00:20:26 +0300 From: Roni Even To: CC: gen-art@ietf.org, 'IETF' I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at . Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-nea-pt-tls-05 Reviewer: Roni Even Review Date:2012-6-4 IETF LC End Date: 2012-6-13 IESG Telechat date: Summary: This draft is almost ready for publication as a standard track RFC. Major issues: Minor issues: 1. In section 3.2 "Therefore, this specification requests the IANA reserve a TCP port number for use with the PT-TLS protocol upon publication of this specification as an Internet standard RFC." I think it will be better to have here the assigned port number and instruct the RFC editor to put the correct value. 2. In section 3.4.2.2 last paragraph you summarize the text from section 3.8 while in the paragraph above you provide the reference. Why do you need the last paragraph if 3.8 is referenced. 3. In various places you refer to SMI 0 as IETF SMI number while according to the table it is IANA SMI number. 4. I assume that all implementations MUST support message type vendor ID 0. Is this mentioned? 5. In section 3.5 and 6.1 you propose a policy of "Expert Review with Specification Required ". I think that according to RFC5226 expert review is implied if you select a specification required policy. 6. In section 3.6 on 9+ "Recipients of messages of type 9 or higher that do not 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." I think this is true only for Message Type Vendor ID 0. 7. In 3.7.1 for Max vers and prefs ver you say that they MUST be set to 1. I think it will be more correct here to say SHOULD since you explain afterwards that they may have other values. 8. In section 3.7.2 "the recipient SHOULD send". Why not make it a MUST here. 9. In section 3.7.2 "The version selected MUST be within the Min Vers to Max Vers inclusive range sent in the Version Request Message" I was expecting to see pref ver here. 10. In section 3.8.3 " The SASL client authentication starts when the NEA Server enters the PT-TLS Negotiation phase and its policy indicates that an authentication of the NEA Client is necessary but was not performed during the TLS handshake protocol " my read of section 3.8 second paragraph is that it can be done even if was done in the TLS handshake so the last part of the sentence is not correct, if there is a policy you do it anyhow. This comment is also for the third paragraph. 11. In section 3.9 I noticed that you propose to send the entire original message. Isn't it enough to send only the message identifier. This is based on the last sentence of this section. 12. Most of the text in section 6.1 repeats RFC5226 but in your words. Are you trying to change some of RFC5226 text if not why write it in different words? Nits/editorial comments: From stephen.farrell@cs.tcd.ie Wed Jun 13 04:36:44 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 65DEC21F8522 for ; Wed, 13 Jun 2012 04:36:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 33f77-0nBicL for ; Wed, 13 Jun 2012 04:36:43 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 8E81321F84FC for ; Wed, 13 Jun 2012 04:36:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 02AD91717FE for ; Wed, 13 Jun 2012 12:36:43 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1339587402; bh=FHEZgIUzrrnneK 5p3Q2SOImuS0W8fxbyJLwrtLSXs6U=; b=I91GjsfqhTSEvrDPB0TCA7NNF4a9u+ d+fkNbJqlHiD9n6NxG+DLUchBTlsJRzQlr2hIgTvH/dqzgz4w6wir2eAoqE3VUYP psxsyOnOhqv9pFiY7mrVgfsI4k78yzknRure0ody3IRwfP2jsVxNaiT2ieGs1Ikz fQG00MORfG4aTnWcUKRhf1fqXKIEfFnxPT/0pqGehtSfwqT4BqH2q/JkV3ccpF/7 BEqNd7BlxUockE0NtrIdEIVqvcVqi6drna1P9ySMZ64dP7gmURN9Q5y50rNbiVaa 62kbN+yr+nBIBHvXKLNDH4od44QGpqqq87ag2npZgXcxmTy+Bahke8uA== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id zw7orG+9In04 for ; Wed, 13 Jun 2012 12:36:42 +0100 (IST) Received: from [IPv6:2001:770:10:203:353a:5c1f:6277:879a] (unknown [IPv6:2001:770:10:203:353a:5c1f:6277:879a]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 4C0DC1714DE for ; Wed, 13 Jun 2012 12:36:42 +0100 (IST) Message-ID: <4FD87B4A.4080104@cs.tcd.ie> Date: Wed, 13 Jun 2012 12:36:42 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: nea@ietf.org References: <20120530141633.22553.12004.idtracker@ietfa.amsl.com> In-Reply-To: <20120530141633.22553.12004.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Nea] Last Call: (PT-TLS: A TCP-based Posture Transport (PT) Protocol) to Proposed Standard 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: Wed, 13 Jun 2012 11:36:44 -0000 Hi all, IETF LC has now finished for this draft. We have comments from the ops, apps and gen-art reviews. I've not seen follow-up discussions on those, which should happen. I've forwarded the apps and gen-art reviews to the nea list in case some folks aren't subscribed to ietf@ietf.org. Follow up discussion should really be on ietf@ietf.org if its more than just "sure, we'll do that." Any substantive changes agreed should also of course be cc'd to the nea list. The ball is in the shepherd/authors court for that now, so please try get to that as soon as you can. I'm guessing that a revised I-D will be needed before we should put this on an IESG agenda so I've marked it as revised I-D needed. As soon as we get those reviews handled then I can put this on a telechat agenda, Thanks, Stephen. On 05/30/2012 03:16 PM, The IESG wrote: > > The IESG has received a request from the Network Endpoint Assessment WG > (nea) to consider the following document: > - 'PT-TLS: A TCP-based Posture Transport (PT) Protocol' > as Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2012-06-13. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > Abstract > > > This document specifies PT-TLS, a TCP-based Posture Transport (PT) > protocol. The PT-TLS protocol carries the Network Endpoint > Assessment (NEA) message exchange under the protection of a Transport > Layer Security (TLS) secured tunnel. > > > > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-nea-pt-tls/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-nea-pt-tls/ballot/ > > > No IPR declarations have been submitted directly on this I-D. > > > From Paul_Sangster@symantec.com Wed Jun 13 09:53:57 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 56E3521F8539; Wed, 13 Jun 2012 09:53:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 V+rP1tMCVig4; Wed, 13 Jun 2012 09:53:53 -0700 (PDT) Received: from ecl1mtaoutpex02.symantec.com (ecl1mtaoutpex02.symantec.com [166.98.1.210]) by ietfa.amsl.com (Postfix) with ESMTP id CA19421F858A; Wed, 13 Jun 2012 09:53:50 -0700 (PDT) X-AuditID: a66201d2-b7f6b6d000005fd4-11-4fd8c599508c Received: from ecl1mtahubpin02.ges.symantec.com (ECL1MTAHUBPIN02.ges.symantec.com [10.48.69.202]) by ecl1mtaoutpex02.symantec.com (Symantec Messaging Gateway) with SMTP id 76.B9.24532.995C8DF4; Wed, 13 Jun 2012 16:53:45 +0000 (GMT) Received: from [155.64.220.139] (helo=TUS1XCHHUBPIN03.SYMC.SYMANTEC.COM) by ecl1mtahubpin02.ges.symantec.com with esmtp (Exim 4.76) (envelope-from ) id 1SeqpF-0000L1-7p; Wed, 13 Jun 2012 16:53:45 +0000 Received: from TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM ([155.64.220.150]) by TUS1XCHHUBPIN03.SYMC.SYMANTEC.COM ([155.64.220.139]) with mapi; Wed, 13 Jun 2012 09:53:44 -0700 From: Paul Sangster To: Roni Even , "draft-ietf-nea-pt-tls.all@tools.ietf.org" Date: Wed, 13 Jun 2012 09:55:55 -0700 Thread-Topic: GenART LC review of draft-ietf-nea-pt-tls-05 Thread-Index: Ac1Cl9xExNAkih6WSYeHA9SkXDOg7gG388dg Message-ID: <6E79D623502C70419A9EAB18E4D274252B8B06102F@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> References: <4fcd272e.2968b40a.55d4.ffff9de3@mx.google.com> In-Reply-To: <4fcd272e.2968b40a.55d4.ffff9de3@mx.google.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_6E79D623502C70419A9EAB18E4D274252B8B06102FTUS1XCHEVSPIN_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrKIsWRmVeSWpSXmKPExsXCZeB6Snfm0Rv+BofWaFjMvTiB3eLqq88s Fs82zmex+Py2wuJvO7MDq8fOWXfZPZYs+cnk8eXyZ7YA5igum5TUnMyy1CJ9uwSujOtPlQom vGCsWPL+InsD4/vTjF2MHBwSAiYSjbequxg5gUwxiQv31rN1MXJxCAm8ZJSYvH4FM0hCSOA1 o8SanekQiVWMEp+2zmUESbAJGEjsPHKKHSQhItDIKPF1yRywDmaBJInjMzawgNgsAqoSV483 sYPYwgKWElO+TwKLiwhYSSz9MJEJwjaSaL73EizOKxAl0f1rJyvEZmuJ/ZeWgi3jFLCR2Hfl OFicEejU76fWMEHsEpe49WQ+E8QLAhJL9pxnhrBFJV4+/gdVLypxp3092MfMAvkSU85aQqwS lDg58wnLBEaxWUgmzUKomoWkCqJER2LB7k9sELa2xLKFr5lh7DMHHjMhiy9gZF/FKJOanGOY W5KYX1pSkFphYKRXXJmbCIzaZL3k/NxNjMDIXZbEeGkH4/3DuocYBTgYlXh42ffd8BdiTSwD qjzEKMHBrCTCu3olUIg3JbGyKrUoP76oNCe1+BCjNAeLkjjvhV1b/YUE0hNLUrNTUwtSi2Cy TBycUg2M2aFnX/Mf7DSawXywW6Zo0ZxzPLenH77Ad0BTKyv6wv4NaWs6zktHSFusELd6Pkd2 XSlbpnqYynnXP/1eVf32k39oZxeuflK9d3vastca5gl3n81o+yyyT2+FRHbNz+r1psmyK9KW rMnTUWc69eWVVIeOswBX4xTe7s+rOphNbugp5BlKLL6pxFKckWioxVxUnAgAH0ARXtgCAAA= Cc: "gen-art@ietf.org" , "nea@ietf.org" , 'IETF' Subject: Re: [Nea] GenART LC review of draft-ietf-nea-pt-tls-05 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: Wed, 13 Jun 2012 16:53:57 -0000 --_000_6E79D623502C70419A9EAB18E4D274252B8B06102FTUS1XCHEVSPIN_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks for the detailed review, comments are in-lined... From: Roni Even [mailto:ron.even.tlv@gmail.com] Sent: Monday, June 04, 2012 2:20 PM To: draft-ietf-nea-pt-tls.all@tools.ietf.org Cc: 'IETF'; gen-art@ietf.org Subject: GenART LC review of draft-ietf-nea-pt-tls-05 I am the assigned Gen-ART reviewer for this draft. For background on Gen-AR= T, please see the FAQ at . Please resolve these comments along with any other Last Call comments you m= ay receive. Document: draft-ietf-nea-pt-tls-05 Reviewer: Roni Even Review Date:2012-6-4 IETF LC End Date: 2012-6-13 IESG Telechat date: Summary: This draft is almost ready for publication as a standard track RFC= . Major issues: Minor issues: 1. In section 3.2 "Therefore, this specification requests the IANA re= serve a TCP port number for use with the PT-TLS protocol upon publication o= f this specification as an Internet standard RFC." I think it will be bett= er to have here the assigned port number and instruct the RFC editor to put= the correct value. [PS:] Ok, we can reword this in hopes of getting a particular value (race c= ondition with other upcoming RFCs). 2. In section 3.4.2.2 last paragraph you summarize the text from sect= ion 3.8 while in the paragraph above you provide the reference. Why do you = need the last paragraph if 3.8 is referenced. [PS:] The goal of this section is to introduce and summarize the different = phases of PT-TLS. We felt a brief discussion of the general message flow w= as helpful to the reader to understand what occurs during this phase (simil= ar to what we did in the other sub-sections). Your correct that this infor= mation is covered later in more detail. 3. In various places you refer to SMI 0 as IETF SMI number while acco= rding to the table it is IANA SMI number. [PS:] I presume this is about the PEN 0 being for the IETF. Correct, it's = the IETF's name space that administered by the IANA. What text would you l= ike to see to make this more clear? Can we do it in one place, for example= stating that the IETF name space is administered by the IANA? 4. I assume that all implementations MUST support message type vendor= ID 0. Is this mentioned? [PS:] The purpose of this section was just to summarize and enumerate the m= essage types for vendor id 0. I don't think it's a general rule that any = message type defined in the IETF (IANA :)) name space must (or should be) s= upported by all implementations. It will vary depending on the purpose of = the message so that normative language is included in the descriptions of t= he message. 5. In section 3.5 and 6.1 you propose a policy of "Expert Review with= Specification Required ". I think that according to RFC5226 expert review = is implied if you select a specification required policy. [PS:] I agree, it says "Specification Required also implies use of a Design= ated Expert". The policy is just "Specification Required" so we could remo= ve the "Expert Review with" and make it clear it's the Specification Requir= ed IANA policy. 6. In section 3.6 on 9+ "Recipients of messages of type 9 or higher= that do not support the PT-TLS Message Type Vendor ID and PT-TLS Message T= ype of a received PT-TLS message MUST respond with a Type Not Supported PT-= TLS error code in a PT-TLS Error message." I think this is true only for Me= ssage Type Vendor ID 0. [PS:] Thanks will reword this section to make it more clear. 7. In 3.7.1 for Max vers and prefs ver you say that they MUST be set = to 1. I think it will be more correct here to say SHOULD since you explain = afterwards that they may have other values. [PS:] I think this is a MUST. The next sentence just points out that this = normative text might change in a future revision (which is not currently pl= anned). 8. In section 3.7.2 "the recipient SHOULD send". Why not make it a MU= ST here. [PS:] I ok with making this change, let's see what others think ... 9. In section 3.7.2 "The version selected MUST be within the Min Vers= to Max Vers inclusive range sent in the Version Request Message" I was e= xpecting to see pref ver here. [PS:] Perf is just an informational (hint) preference. 10. In section 3.8.3 " The SASL client authentication starts when the NEA= Server enters the PT-TLS Negotiation phase and its policy indicates that= an authentication of the NEA Client is necessary but was not performed dur= ing the TLS handshake protocol " my read of section 3.8 second paragraph i= s that it can be done even if was done in the TLS handshake so the last par= t of the sentence is not correct, if there is a policy you do it anyhow. Th= is comment is also for the third paragraph. [PS:] Thanks, this was supposed to be an example. Will fix these. 11. In section 3.9 I noticed that you propose to send the entire original= message. Isn't it enough to send only the message identifier. This is base= d on the last sentence of this section. [PS:] Not "the entire original message" as its at most the first 1024 bytes= of the offending message. This allows the recipient to either caches rece= ntly sent messages and/or message identifiers when determining what caused = the error. We thought this flexibility was useful and had very little cost= . 12. Most of the text in section 6.1 repeats RFC5226 but in your words. Ar= e you trying to change some of RFC5226 text if not why write it in differen= t words? [PS:] We were hoping to emphasize the aspects of 5226 that are most importa= nt to this specification. We weren't trying to change how the IANA policy = was interpreted. Did you think we did so? Is there a portion of this text= that is most troubling or was this just a question? Nits/editorial comments: --_000_6E79D623502C70419A9EAB18E4D274252B8B06102FTUS1XCHEVSPIN_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks for the detailed review, comments are in-lined…<= o:p>

 

From: Roni Even = [mailto:ron.even.tlv@gmail.com]
Sent: Monday, June 04, 2012 2:20= PM
To: draft-ietf-nea-pt-tls.all@tools.ietf.org
Cc: 'I= ETF'; gen-art@ietf.org
Subject: GenART LC review of draft-ietf-ne= a-pt-tls-05

&nbs= p;

I am the assigned Gen-ART reviewer for thi= s draft. For background on Gen-ART, please see the FAQ at <ht= tp://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

 

Please res= olve these comments along with any other Last Call comments you may receive= .

 

Document: draft-ietf-nea-pt-tls-05

Reviewer: Roni Even

Review Date:2012= –6–4

IETF LC End Date: = 2012–6–13

IESG Telechat d= ate:

 

Summary: This draft is almost ready for publication as a stand= ard track RFC.

 

Major issues:

=  

Minor issues:

1.     &nb= sp; In section 3.2 “Therefore, this specifica= tion requests the IANA reserve a TCP port number for use with the PT-TLS pr= otocol upon publication of this specification as an Internet standard RFC.&= #8221; I think it will  be better to have here the assigned port numbe= r and instruct the RFC editor to put the correct value.

 

[PS:] Ok, we can reword this in hopes of getting a p= articular value (race condition with other upcoming RFCs).

 

2.       In section 3.4.2.2 last paragraph you summarize the tex= t from section 3.8 while in the paragraph above you provide the reference. = Why do you need the last paragraph if 3.8 is referenced.<= /p>

 

[PS:] The goal of this section is to introduce and = summarize the different phases of PT-TLS.  We felt a brief discussion = of the general message flow was helpful to the reader to understand what oc= curs during this phase (similar to what we did in the other sub-sections).&= nbsp; Your correct that this information is covered later in more detail.

 

3.    &n= bsp;  In various places you refer to SMI 0 as = IETF SMI number while according to the table it is IANA SMI number.

 

[PS:] I presume this is about the PEN 0 = being for the IETF.  Correct, it’s the IETF’s name space t= hat administered by the IANA.  What text would you like to see to make= this more clear?  Can we do it in one place, for example stating that= the IETF name space is administered by the IANA?=

 

4.       I assume that all implementations MUST support message type vend= or ID 0. Is this mentioned?

 

[PS:= ] The purpose of this section was just to summarize and enumerate the messa= ge types for vendor id 0.   I don’t think it’s a gene= ral rule that any message type defined in the IETF (IANA = J) name space must (or should be) supported by all= implementations.  It will vary depending on the purpose of the messag= e so that normative language is included in the descriptions of the message= .

 

5.    = ;   In section 3.5 and 6.1 you propose a = policy of “Expert Review with Specification Required “. I think= that according to RFC5226 expert review is implied if you select a specifi= cation required policy.

 

[PS:] I a= gree, it says “Specification Required also implies use of a Designate= d Expert”.  The policy is just “Specification RequiredR= 21; so we could remove the “Expert Review with” and make it cle= ar it’s the Specification Required IANA policy.

=  

6.&n= bsp;      In section 3.6 o= n 9+ “Recipients of messages   of type 9 or higher that do = not 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.” I think this is true only for Messa= ge Type Vendor ID 0.

 

[PS:] Thanks= will reword this section to make it more clear.<= /p>

 

7.       = In 3.7.1 for Max vers and prefs ver you say that they MUST be set= to 1. I think it will be more correct here to say SHOULD since you explain= afterwards that they may have other values.

 

= [PS:] I think this is a MUST.  The next sentence just poi= nts out that this normative text might change in a future revision (which i= s not currently planned).

 

8.       In section 3.= 7.2 “the recipient SHOULD send”. Why not make it a MUST here.

 =

[PS:] I ok with making this change= , let’s see what others think …

 

9.       In section 3.7.2 “The version selected MUST be within the Min Ve= rs to Max Vers inclusive range sent in the Version Request   Mess= age” I was expecting to see pref ver here.

 

[PS:] Perf is just an informational (hint) preference.=

 

1= 0.   <= /span>In section 3.8.3 “ The SASL client authentication starts whe= n the NEA Server  enters the PT-TLS Negotiation phase and its policy i= ndicates  that an authentication of the NEA Client is necessary but wa= s not performed during the TLS handshake protocol “ my read of  = section 3.8 second paragraph is that it can be done even if was done in the= TLS handshake so the last part of the sentence is not correct, if there is= a policy you do it anyhow. This comment is also for the third paragraph.

 =

[PS:] Thanks, this was supposed to= be an example.  Will fix these.

 

11.   In section 3.9 I noticed= that you propose to send the entire original message. Isn’t it enoug= h to send only the message identifier. This is based on the last sentence o= f this section.

&n= bsp;

[PS:] Not “= the entire original message” as its at most the first 1024 bytes of t= he offending message.  This allows the recipient to either caches rece= ntly sent messages and/or message identifiers when determining what caused = the error.  We thought this flexibility was useful and had very little= cost.

&nb= sp;

12.   Most of the text in section 6.1 repeats RFC5226 but in = your words. Are you trying to change some of RFC5226 text if not why write = it in different words?

=  

[PS:] We w= ere hoping to emphasize the aspects of 5226 that are most important to this= specification.  We weren’t trying to change how the IANA policy= was interpreted.  Did you think we did so?  Is there a portion o= f this text that is most troubling or was this just a question?<= /span>

 

 

 =

 

Nits/editorial comments:

 

= --_000_6E79D623502C70419A9EAB18E4D274252B8B06102FTUS1XCHEVSPIN_-- From Paul_Sangster@symantec.com Wed Jun 13 21:00:21 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 5A75A11E80F6; Wed, 13 Jun 2012 21:00:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 gnuNO5KNDGsO; Wed, 13 Jun 2012 21:00:16 -0700 (PDT) Received: from ecl1mtaoutpex02.symantec.com (ecl1mtaoutpex02.symantec.com [166.98.1.210]) by ietfa.amsl.com (Postfix) with ESMTP id 8425111E80EB; Wed, 13 Jun 2012 21:00:16 -0700 (PDT) X-AuditID: a66201d2-b7f756d000004ee0-14-4fd961cf045d Received: from tus1opsmtapin02.ges.symantec.com (tus1opsmtapin02.ges.symantec.com [192.168.214.44]) by ecl1mtaoutpex02.symantec.com (Symantec Messaging Gateway) with SMTP id 65.F2.20192.FC169DF4; Thu, 14 Jun 2012 04:00:15 +0000 (GMT) Received: from [155.64.220.138] (helo=TUS1XCHHUBPIN02.SYMC.SYMANTEC.COM) by tus1opsmtapin02.ges.symantec.com with esmtp (Exim 4.76) (envelope-from ) id 1Sf1EE-0004Cu-Uu; Thu, 14 Jun 2012 04:00:14 +0000 Received: from TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM ([155.64.220.150]) by TUS1XCHHUBPIN02.SYMC.SYMANTEC.COM ([172.24.185.246]) with mapi; Wed, 13 Jun 2012 21:00:15 -0700 From: Paul Sangster To: Alexey Melnikov , "draft-ietf-nea-pt-tls.all@tools.ietf.org" , "nea@ietf.org" Date: Wed, 13 Jun 2012 21:02:31 -0700 Thread-Topic: APPSDIR review of draft-ietf-nea-pt-tls-04 Thread-Index: Ac1ChIONzSZhkDZ1SQ2GmKWHIfcYdgHWLbtQ Message-ID: <6E79D623502C70419A9EAB18E4D274252B8B061618@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> References: <4FCD0614.5050902@isode.com> In-Reply-To: <4FCD0614.5050902@isode.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrOIsWRmVeSWpSXmKPExsVyYMU1Hd3ziTf9Df5NULaYsbrIYu7FCewW zzbOZ7H4/LbCgcVjyZKfTB6nmg09vlz+zBbAHMVlk5Kak1mWWqRvl8CVMfvdecaCPr2Knztn sjUwvlLpYuTgkBAwkXi6sryLkRPIFJO4cG89WxcjF4eQwGtGiX235jDBOWuXrGMHqRISWMUo cXmOIojNJmAgsfPIKbC4iMBKRom9f7NAbGYBZYmnm0CaOTlYBFQlDvfdZgSxhQXMJdqmXmaB qLeQOHygjRXCNpJ43beGDcTmFYiSODD7HdQuDYmjc1cyg9icApoS2482gs1kBLr0+6k1TBC7 xCVuPZnPBPGBgMSSPeeZIWxRiZeP/7FC1ItK3GlfzwhRryOxYPcnNghbW2LZwtfMEHsFJU7O fMIygVF8FpKxs5C0zELSMgtJywJGllWMMqnJOYa5JYn5pSUFqRUGRnrFlbmJwMhL1kvOz93E CIy+ZUmMl3Yw3j+se4hRgINRiYd3YthNfyHWxDKgykOMEhzMSiK8zxSAQrwpiZVVqUX58UWl OanFhxilOViUxHkv7NrqLySQnliSmp2aWpBaBJNl4uCUamDMuL/A5LPQLkcH2dOXds5ffmv7 4wlvPGdnMDufdDj8W6vdYQGfg+1LS/MJ/2/cKe1UvpY3vYEr03nihgc7Dktrf5zJaNOxTj7P QKd247mCqMknCx5Zdnr6b567dh6j15r3HitqC9fePcf6+FGjvnYI27Ovi+Iv5Km8Cah49fto +PsjqeIL+r5nKbEUZyQaajEXFScCAAyyTZ26AgAA Cc: "ietf@ietf.org" Subject: Re: [Nea] APPSDIR review of draft-ietf-nea-pt-tls-04 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, 14 Jun 2012 04:00:22 -0000 > -----Original Message----- > From: Alexey Melnikov [mailto:alexey.melnikov@isode.com] > Sent: Monday, June 04, 2012 12:02 PM > To: apps-discuss@ietf.org; draft-ietf-nea-pt-tls.all@tools.ietf.org > Cc: ietf@ietf.org > Subject: APPSDIR review of draft-ietf-nea-pt-tls-04 >=20 > I have been selected as the Applications Area Directorate reviewer for > this draft (for background on APPSDIR, please see > http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectora > te ). >=20 > Please resolve these comments along with any other Last Call comments > you may receive. Please wait for direction from your document shepherd > or AD before posting a new version of the draft. The review is not > copied to the IESG as the Last Call has not been announced yet. >=20 > Document: draft-ietf-nea-pt-tls-04 > Title: PT-TLS: A TCP-based Posture Transport (PT) Protocol > Reviewer: Alexey Melnikov > Review Date: June 4, 2012 >=20 > Summary: This document is almost ready for publication as a Proposed > Standard, although some [mostly] SASL related issues remain. >=20 > This document specifies PT-TLS, a TCP-based Posture Transport (PT) > protocol. The PT-TLS protocol carries the Network Endpoint > Assessment (NEA) message exchange under the protection of a Transport > Layer Security (TLS) secured tunnel. >=20 > (Note, I've reviewed -04, but I think all of this still applies to - > 05.) >=20 >=20 > Major: >=20 > In 3.4.2.1: RFC 6125 use details are missing. You need to describe > whether CN-IDs and SRV-IDs are allowed, whether wildcards are allowed, > etc. I can suggest some details. [PS:] Since you weren't happy with our first attempt to address this commen= t, we would like to take you up on your kind offer to provide suggestions. = Maybe we could do this off-line and included the text in -06? >=20 >=20 > Minor: >=20 > In Section 3.2: This document is not yet Internet Standard, it will be > Proposed Standard. Suggest saying "Publication on Standards Track" > instead instead of "Internet Standard". The same issue in the IANA > consideration section. [PS:] This sentence will be re-written to address the gen-art comment so th= e new text won't have this issue. >=20 > In 3.8.1: I think one instance of "SASL authentication messages" --> > "SASL authentication mechanisms". Otherwise this sentence is out of > place, as you are not talking about SASL messages. [PS:] Will make it more clear the relationship between SASL messages in PT-= TLS and the SASL mechanism exchanges inside the messages. The sentence men= tioned is about the PT-TLS client authentication messages. >=20 > In 3.8.4: in SASL the server doesn't return abort as an error code, it > just fails the authentication exchange. I suggest removing it as a > choice. [PS:] This text was attempting to support the abort as described in RFC4422= which says: 3.5. Aborting Authentication Exchanges A client or server may desire to abort an authentication exchange if it is unwilling or unable to continue (or enter into). A client may abort the authentication exchange by sending a message, the particulars of which are protocol specific, to the server, indicating that the exchange is aborted. The server may be required by the protocol to return a message in response to the client's abort message. Likewise, a server may abort the authentication exchange by sending a message, the particulars of which are protocol specific, to the client, indicating that the exchange is aborted. [PS]: Is this an unacceptable way to do this? =20 >=20 > In 3.8.7: you define the Reserved field which I assume is used for > padding? If yes, then you will not get proper alignment for the next > field, as SASL mechanism names are variable length. (If you intended > that they are always sent as 20 bytes, then this is missing from the > document.) [PS:] Sure, word alignment would have been a good reason for doing this but= we thought more about byte alignment. We also thought having these bits a= vailable could be useful later (e.g. for indicating preference or some othe= r semantic that could impact the mechanism selection). Since we didn't ne= ed an entire byte for the Mech Len we thought it made sense to at least byt= e align the Mechanism Name and the cost of 3 bits for some future purpose m= ade sense. >=20 > In 3.8.10: >=20 > The Abort choice is really not needed (as per above). >=20 > Also, can you give me an example of when the Mechanism Failure will be > returned instead of just Failure? [PS:] The document gives the example of authentication failure (incorrect c= redential) where mechanism failure is when the mechanism logic detects a fa= ilure in processing the authentication request that isn't related to the us= er's input (e.g. malloc error). >=20 > In 3.9: Failed Authentication error code - how does this differ from > SASL Authentication result with Failure code? [PS:] Hmm, I'm going to have to look into this more. One way they are diff= erent is the fact that the NEA Client is not allowed to send the SASL Resul= t TLV so can't use the Failure code but it could send a Failed Authenticati= on error code in the PT-TLS Error Message. >=20 > In 4.1.2, second block, the first bullet: I think you meant "client" > instead of the "server". [PS:] Thanks, good catch >=20 >=20 > Question (might not be an issue): >=20 > In 6.2: is it possible to register a vendor specific value without a > specification? [PS:] In order to be placed in the IANA registry a permanent specification = is required (as mentioned in section 6.1). Of course vendors are free to = use values in their name space without registering them with the IANA. >=20 > The same question for 6.3. >=20 >=20 > Nits: None From Paul_Sangster@symantec.com Wed Jun 13 21:41:44 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 50DAE11E8093; Wed, 13 Jun 2012 21:41:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 rD8xr70QaAKW; Wed, 13 Jun 2012 21:41:43 -0700 (PDT) Received: from tus1smtoutpex03.symantec.com (tus1smtoutpex03.symantec.com [216.10.195.243]) by ietfa.amsl.com (Postfix) with ESMTP id 2AD3321F852C; Wed, 13 Jun 2012 21:41:40 -0700 (PDT) X-AuditID: d80ac3f3-b7fd26d00000349b-fd-4fd96b839cfd Received: from tus1smtintpin01.ges.symantec.com (TUS1SMTINTPIN01.ges.symantec.com [192.168.215.101]) by tus1smtoutpex03.symantec.com (Symantec Brightmail Gateway out) with SMTP id D1.D1.13467.38B69DF4; Thu, 14 Jun 2012 04:41:39 +0000 (GMT) Received: from [155.64.220.138] (helo=TUS1XCHHUBPIN02.SYMC.SYMANTEC.COM) by tus1smtintpin01.ges.symantec.com with esmtp (Exim 4.76) (envelope-from ) id 1Sf1sG-0008SS-Qy; Thu, 14 Jun 2012 04:41:36 +0000 Received: from TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM ([155.64.220.150]) by TUS1XCHHUBPIN02.SYMC.SYMANTEC.COM ([172.24.185.246]) with mapi; Wed, 13 Jun 2012 21:41:39 -0700 From: Paul Sangster To: "Romascanu, Dan (Dan)" Date: Wed, 13 Jun 2012 21:42:53 -0700 Thread-Topic: Operations Directorate Review of draft-ietf-nea-pt-tls-05 Thread-Index: Ac1H3UDULckBLm7vQhq8Xci7wLPg+wCB24dQ Message-ID: <6E79D623502C70419A9EAB18E4D274252B8B061623@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrFIsWRmVeSWpSXmKPExsVyYMX1VN3m7Jv+BhveiFp8/fmD1eLz2wqL 3qYlzBbT915jd2DxOLhyDrvH2u6rbB5LlvxkCmCO4rJJSc3JLEst0rdL4MpoXX+IreCdRkXD 1hssDYznFboYOTkkBEwk5rx5xQJhi0lcuLeerYuRi0NI4COjxOP2WUwQzmtGibnztrFAOKsY JaY8P8YK0sImYCCx88gpdhBbREBf4uOMNcwgNrNAucT2XZPYQGwWAVWJ0y3zmUBsYQE3iUlL fjBC1LtL3J6+ghXCNpL48HgFUD0HB69AlMSF3/ogYSGBYIk3r36CjecUCJE49Xc3mM0IdOn3 U2uYIFaJS9x6AjFeQkBAYsme88wQtqjEy8f/WCHqRSXutK9nhKjXkViw+xMbhK0tsWzha7B6 XgFBiZMzn7BMYBSfhWTsLCQts5C0zELSsoCRZRWjTElpsWFxbkl+aUlBaoWBsV5xZW4iMP6S 9ZLzczcxAmPwBtfhzzsYF/7QP8QowMGoxMObmXzTX4g1sQyo8hCjBAezkgjvMwWgEG9KYmVV alF+fFFpTmrxIUZpDhYlcd6E/Vv9hQTSE0tSs1NTC1KLYLJMHJxSDYzaoSHT2t77rMkNO5R/ N35nWKVIgviGqSuEJ0svOr6Mbadt5Pfl61XXx/nO+CqZ7J68ImrO+eX2vIx99/qud8p+uLj+ n8+3T9sPc3x+/OtPefv0aKX5M5z4K6uyasJa3qSaP1uR48uR9I338pRzMtrfr1WvKDgW1G8m aF2w9rGMj2Z5bS3n0VYlluKMREMt5qLiRADwbMUIvQIAAA== Cc: "ops-dir@ietf.org" , "nea@ietf.org" Subject: Re: [Nea] Operations Directorate Review of draft-ietf-nea-pt-tls-05 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, 14 Jun 2012 04:41:44 -0000 Thanks for the review, comments are in-lined below... > -----Original Message----- > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > Sent: Monday, June 11, 2012 7:20 AM > To: Paul Sangster; ncamwing@cisco.com; Joe Salowey > Cc: ops-dir@ietf.org; Stephen Farrell; nea@ietf.org; > shanna@juniper.net; sethompso@cisco.com > Subject: Operations Directorate Review of draft-ietf-nea-pt-tls-05 >=20 > Hi, >=20 > This is an OPS-DIR review for draft-ietf-nea-pt-tls-05. Although this > is > not an easy reading for a non-expert, it's a well written specification, > based upon wide field experience with proprietary protocols, and I do > not expect major obstacles in operational deployment. >=20 >=20 > A few issues triggered by the checklist in RFC 5706: >=20 > 1. 'Does the new protocol need supporting services (e.g., DNS or > Authentication, Authorization, and Accounting - AAA) added to > an existing network?' >=20 > The protocol stacks atop of TLS. Section 3.4.3 (TLS requirements) > includes a SHOULD requirement for TLS 1.2, but neither here nor in > other > parts of the document I could find a requirement that PT-TLS > implementations MUST support TLS 1.0 and TLS 1.1. The authors may want > to add this. >=20 > I believe that mentioning the fact that the protocol is layered atop of > TLS in the title and Abstract would make this key design issue more > clear to the readers. [PS:] This protocol certainly does need to be carried in TLS. As you ment= ion, its discussed in the TLS Requirements section. The working group disc= ussed how to word the TLS 1.1 and 1.2 requirements on numerous occasions an= d we settled on this approach (SHOULD for 1.2 since it's not widely deploye= d yet and pointing out that 1.0/1.1 are also good transports of this protoc= ol without including a normative reference to a downgraded RFC). This appr= oach parallels the way some other specs are handling this tricky issues (e.= g. see OAuth at http://tools.ietf.org/html/draft-ietf-oauth-v2-26#section-1= .6). >=20 > 2. The protocol uses the Vendor PEN, but assumes it is limited to > 24-bit. >=20 > In Section 3.5 - Message Vendor ID - . >=20 > Consistent with PA-TNC and PB- > TNC, we depend on the PEN fitting in 24 bits, so if IANA were to > register a wider PEN than that PEN could not be used with NEA. > IETF namespace PT-TLS Message Types MUST use zero (0) in this > field. >=20 >=20 > However, discussions triggered by draft-liang-iana-pen-00 may end by > that document recommending that new protocols define at least 32-bit > PEN > fields. Is this impossible in this case? What are the 8 bits preceding > the Message Type Vendor ID Reserved for? [PS:] I believe we would rather stay consistent with the other protocols in= the NEA stack. There are A LOT of numbers left in the PEN space before >2= 4 bits is required unless for some reason the IANA started doing non-linear= allocations. Changing the protocol would only fix 1/3 of the NEA stack so= not really be of large benefit for interoperability and diverge from the e= xisting NAC protocols in the field. >=20 > 3. 'Have suggestions for verifying correct operation been discussed?' >=20 > Not really. How are assessment results communicated to the operators? > Are they public? Maybe they MUST NOT be public (because of privacy > concerns for example)? The document says nothing about this. Same > question about errors, authentication failures, or other error counts. [PS:] This protocol is just the transport for the assessment. The assessme= nt is the topic of PA-TNC and PB-TNC plus the NEA architecture RFCs. For i= tems like authentication failures those can be passed up the stack to highe= r layers which make the policy decisions on how/whether to proceed and in s= ome cases can display messages to the user or operator. These are more arc= hitectural issues for the higher layers then this simple transport protocol= . >=20 > 4. 'Has management interoperability been discussed?' >=20 > As with many other security-related protocols this document offers > little to none information about manageability, so interoperable > management does not seem to be an issue, or maybe these aspects are > discussed in another document. In any case, this could be explained in > text. [PS:] Agreed, this would be a topic for another specification since this is= just a transport protocol for the higher layer protocols in NEA. I'd expe= ct higher level concepts like NEA policies would need a management framewor= k and assessment statistics could be collected from the PB layer which know= s more about the assessment data and results then the transport. >=20 > 5. Editorial observation - Readability could be improved if acronyms > like MITM (Man-in-the Middle) would be expanded at their first > occurrence. [PS:] Thanks will expand the acronym on first use. Fortunately in this cas= e MITM is used in a reference to the NEA Asokan attack spec which defines t= he MITM attack in great detail so should help the interested reader. >=20 > Regards, >=20 > Dan >=20 From alexey.melnikov@isode.com Thu Jun 14 14:01:13 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 99B0921F85AD; Thu, 14 Jun 2012 14:01:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.203 X-Spam-Level: X-Spam-Status: No, score=-101.203 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 cZfqMLYjE+Mu; Thu, 14 Jun 2012 14:01:12 -0700 (PDT) Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id 725DB21F85A5; Thu, 14 Jun 2012 14:01:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1339707671; d=isode.com; s=selector; i=@isode.com; bh=Ih7jSg2aiSNcRKQWzAQPbbzQ5PN8yA8mUSNR074eHes=; 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=RlZqrq596aepScf9cAUNvnZ7xakXoSXYLzTry9gKS4eMrKI+sWSl0m1H3HMtqpI7MmcaDt X1Mo7sQe5175nkK+U0r2U4bIR3AgLemO4ww6gtXl2B5DxdN/XOMDH1k9l0dEiAR/vwEfQ0 +4gsUBoAbsyMCWlnIAs4um3A8dBZr6w=; Received: from [188.29.2.53] (188.29.2.53.threembb.co.uk [188.29.2.53]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Thu, 14 Jun 2012 22:01:11 +0100 References: <4FCD0614.5050902@isode.com> <6E79D623502C70419A9EAB18E4D274252B8B061618@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> In-Reply-To: <6E79D623502C70419A9EAB18E4D274252B8B061618@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> Message-Id: X-Mailer: iPad Mail (9B206) From: Alexey Melnikov Date: Thu, 14 Jun 2012 22:01:05 +0100 To: Paul Sangster MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii X-Mailman-Approved-At: Thu, 14 Jun 2012 14:06:43 -0700 Cc: "draft-ietf-nea-pt-tls.all@tools.ietf.org" , "nea@ietf.org" , "ietf@ietf.org" Subject: Re: [Nea] APPSDIR review of draft-ietf-nea-pt-tls-04 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, 14 Jun 2012 21:01:13 -0000 Hi Paul, On 14 Jun 2012, at 05:02, Paul Sangster wrote: >> -----Original Message----- >> From: Alexey Melnikov [mailto:alexey.melnikov@isode.com] >> Sent: Monday, June 04, 2012 12:02 PM >> To: apps-discuss@ietf.org; draft-ietf-nea-pt-tls.all@tools.ietf.org >> Cc: ietf@ietf.org >> Subject: APPSDIR review of draft-ietf-nea-pt-tls-04 >>=20 >> I have been selected as the Applications Area Directorate reviewer for >> this draft (for background on APPSDIR, please see >> http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectora >> te ). >>=20 >> Please resolve these comments along with any other Last Call comments >> you may receive. Please wait for direction from your document shepherd >> or AD before posting a new version of the draft. The review is not >> copied to the IESG as the Last Call has not been announced yet. >>=20 >> Document: draft-ietf-nea-pt-tls-04 >> Title: PT-TLS: A TCP-based Posture Transport (PT) Protocol >> Reviewer: Alexey Melnikov >> Review Date: June 4, 2012 >>=20 >> Summary: This document is almost ready for publication as a Proposed >> Standard, although some [mostly] SASL related issues remain. >>=20 >> This document specifies PT-TLS, a TCP-based Posture Transport (PT) >> protocol. The PT-TLS protocol carries the Network Endpoint >> Assessment (NEA) message exchange under the protection of a Transport >> Layer Security (TLS) secured tunnel. >>=20 >> (Note, I've reviewed -04, but I think all of this still applies to - >> 05.) >>=20 >>=20 >> Major: >>=20 >> In 3.4.2.1: RFC 6125 use details are missing. You need to describe >> whether CN-IDs and SRV-IDs are allowed, whether wildcards are allowed, >> etc. I can suggest some details. >=20 > [PS:] Since you weren't happy with our first attempt to address this comme= nt, we would like to take you up on your kind offer to provide suggestions. = Maybe we could do this off-line and included the text in -06? >=20 Yes. >> Minor: >>=20 >> In Section 3.2: This document is not yet Internet Standard, it will be >> Proposed Standard. Suggest saying "Publication on Standards Track" >> instead instead of "Internet Standard". The same issue in the IANA >> consideration section. >=20 > [PS:] This sentence will be re-written to address the gen-art comment so t= he new text won't have this issue. >=20 >>=20 >> In 3.8.1: I think one instance of "SASL authentication messages" --> >> "SASL authentication mechanisms". Otherwise this sentence is out of >> place, as you are not talking about SASL messages. >=20 > [PS:] Will make it more clear the relationship between SASL messages in PT= -TLS and the SASL mechanism exchanges inside the messages. The sentence men= tioned is about the PT-TLS client authentication messages. >=20 >>=20 >> In 3.8.4: in SASL the server doesn't return abort as an error code, it >> just fails the authentication exchange. I suggest removing it as a >> choice. >=20 > [PS:] This text was attempting to support the abort as described in RFC442= 2 which says: >=20 > 3.5. Aborting Authentication Exchanges >=20 > A client or server may desire to abort an authentication exchange if > it is unwilling or unable to continue (or enter into). >=20 > A client may abort the authentication exchange by sending a message, > the particulars of which are protocol specific, to the server, > indicating that the exchange is aborted. The server may be required > by the protocol to return a message in response to the client's abort > message. >=20 > Likewise, a server may abort the authentication exchange by sending a > message, the particulars of which are protocol specific, to the > client, indicating that the exchange is aborted. >=20 > [PS]: Is this an unacceptable way to do this? =20 >=20 Well, Ok, but nobody is sending a special message when a SASL server wants t= o abort the exchange. Existing open source API don't seem to support this ei= ther. I suppose the client can just treat this as an authentication failure, as it= can't know what caused the abort. >>=20 >> In 3.8.7: you define the Reserved field which I assume is used for >> padding? If yes, then you will not get proper alignment for the next >> field, as SASL mechanism names are variable length. (If you intended >> that they are always sent as 20 bytes, then this is missing from the >> document.) >=20 > [PS:] Sure, word alignment would have been a good reason for doing this bu= t we thought more about byte alignment. We also thought having these bits a= vailable could be useful later (e.g. for indicating preference or some other= semantic that could impact the mechanism selection). Since we didn't need= an entire byte for the Mech Len we thought it made sense to at least byte a= lign the Mechanism Name and the cost of 3 bits for some future purpose made s= ense. Ok. Never mind. Just to confirm: SASL mechanism names are not padded with spaces or NULs? >=20 >>=20 >> In 3.8.10: >>=20 >> The Abort choice is really not needed (as per above). >>=20 >> Also, can you give me an example of when the Mechanism Failure will be >> returned instead of just Failure? >=20 > [PS:] The document gives the example of authentication failure (incorrect c= redential) where mechanism failure is when the mechanism logic detects a fai= lure in processing the authentication request that isn't related to the user= 's input (e.g. malloc error). >=20 Ok. Having malloc failure as an example would help. >> In 3.9: Failed Authentication error code - how does this differ from >> SASL Authentication result with Failure code? >=20 > [PS:] Hmm, I'm going to have to look into this more. One way they are dif= ferent is the fact that the NEA Client is not allowed to send the SASL Resul= t TLV so can't use the Failure code but it could send a Failed Authenticatio= n error code in the PT-TLS Error Message. Wouldn't the client just send Abort in this case? (Abort makes sense for cli= ents) >=20 >>=20 >> In 4.1.2, second block, the first bullet: I think you meant "client" >> instead of the "server". >=20 > [PS:] Thanks, good catch >=20 >>=20 >>=20 >> Question (might not be an issue): >>=20 >> In 6.2: is it possible to register a vendor specific value without a >> specification? >=20 > [PS:] In order to be placed in the IANA registry a permanent specification= is required (as mentioned in section 6.1). Of course vendors are free to u= se values in their name space without registering them with the IANA. This might be a bit heavyweight and might discourage registrations. But if t= hat is what you want... >=20 >>=20 >> The same question for 6.3. >>=20 >>=20 >> Nits: None >=20 From ron.even.tlv@gmail.com Tue Jun 19 02:19:16 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 03CDD21F8618; Tue, 19 Jun 2012 02:19:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 IGQ-RRkv8ry0; Tue, 19 Jun 2012 02:19:11 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id D027421F860F; Tue, 19 Jun 2012 02:19:10 -0700 (PDT) Received: by wibhn6 with SMTP id hn6so2235993wib.13 for ; Tue, 19 Jun 2012 02:19:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:x-mailer:thread-index:content-language; bh=g0EcFfQrBnG3uPD774u0vmT2+lvD4+Ub2zDnXbZEWyk=; b=iltcSzC0ZYmpgYPjctDBqhtmvi+bvhCuU5eOlJPDEd8/+TQg7F5SwXAdcV6Mte0D7U FVN19SQdvjkbCXzyfGquOY122IShx42yO23NvLZgZCs4W3XCmUpgBSZFWQ2JrBtVCm2K HGLJHjK/HXJYa6o8KKSURBewhaQxlwyAT3b7foh9aIiX0yU8swHNumgg9BpisGWtepKx tDnMHDxpxiKZ5jo1jAryFZxQIs7nCPZOXLLbxx/ycKDy+LVgbr2o4jw5sLCiDUbHIZwt HPkUU4bW245HwqhGgu36mtgUN6SPGznwD4htBZ8rUUmT3JIKKgNVCHeC16ExZX4OAd5i Z7WQ== Received: by 10.180.86.194 with SMTP id r2mr1643274wiz.15.1340097549696; Tue, 19 Jun 2012 02:19:09 -0700 (PDT) Received: from windows8d787f9 (bzq-79-177-104-121.red.bezeqint.net. [79.177.104.121]) by mx.google.com with ESMTPS id bn9sm31214527wib.5.2012.06.19.02.19.03 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 19 Jun 2012 02:19:07 -0700 (PDT) From: "Roni Even" To: "'Paul Sangster'" , References: <4fcd272e.2968b40a.55d4.ffff9de3@mx.google.com> <6E79D623502C70419A9EAB18E4D274252B8B06102F@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> In-Reply-To: <6E79D623502C70419A9EAB18E4D274252B8B06102F@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> Date: Tue, 19 Jun 2012 12:16:19 +0300 Message-ID: <4fe0440b.6959b40a.7a49.6095@mx.google.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0223_01CD4E15.57B56D80" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac1Cl9xExNAkih6WSYeHA9SkXDOg7gG388dgASA4xdA= Content-Language: en-us X-Mailman-Approved-At: Tue, 19 Jun 2012 03:03:06 -0700 Cc: gen-art@ietf.org, nea@ietf.org, 'IETF' Subject: Re: [Nea] GenART LC review of draft-ietf-nea-pt-tls-05 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: Tue, 19 Jun 2012 09:19:16 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0223_01CD4E15.57B56D80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, I am OK with your responses. The only thing I am not sure is about using PEN 0 defined in the registry. Decimal | Organization | | Contact | | | Email | | | | 0 Reserved Internet Assigned Numbers Authority iana&iana.org I was wondering how this enterprise number should be specified since it appears as "Reserved" in the registry. I have no specific suggestion Roni From: Paul Sangster [mailto:Paul_Sangster@symantec.com] Sent: Wednesday, June 13, 2012 7:56 PM To: Roni Even; draft-ietf-nea-pt-tls.all@tools.ietf.org Cc: 'IETF'; gen-art@ietf.org; nea@ietf.org Subject: RE: GenART LC review of draft-ietf-nea-pt-tls-05 Thanks for the detailed review, comments are in-lined. From: Roni Even [mailto:ron.even.tlv@gmail.com] Sent: Monday, June 04, 2012 2:20 PM To: draft-ietf-nea-pt-tls.all@tools.ietf.org Cc: 'IETF'; gen-art@ietf.org Subject: GenART LC review of draft-ietf-nea-pt-tls-05 I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at . Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-nea-pt-tls-05 Reviewer: Roni Even Review Date:2012-6-4 IETF LC End Date: 2012-6-13 IESG Telechat date: Summary: This draft is almost ready for publication as a standard track RFC. Major issues: Minor issues: 1. In section 3.2 "Therefore, this specification requests the IANA reserve a TCP port number for use with the PT-TLS protocol upon publication of this specification as an Internet standard RFC." I think it will be better to have here the assigned port number and instruct the RFC editor to put the correct value. [PS:] Ok, we can reword this in hopes of getting a particular value (race condition with other upcoming RFCs). 2. In section 3.4.2.2 last paragraph you summarize the text from section 3.8 while in the paragraph above you provide the reference. Why do you need the last paragraph if 3.8 is referenced. [PS:] The goal of this section is to introduce and summarize the different phases of PT-TLS. We felt a brief discussion of the general message flow was helpful to the reader to understand what occurs during this phase (similar to what we did in the other sub-sections). Your correct that this information is covered later in more detail. 3. In various places you refer to SMI 0 as IETF SMI number while according to the table it is IANA SMI number. [PS:] I presume this is about the PEN 0 being for the IETF. Correct, it's the IETF's name space that administered by the IANA. What text would you like to see to make this more clear? Can we do it in one place, for example stating that the IETF name space is administered by the IANA? 4. I assume that all implementations MUST support message type vendor ID 0. Is this mentioned? [PS:] The purpose of this section was just to summarize and enumerate the message types for vendor id 0. I don't think it's a general rule that any message type defined in the IETF (IANA J) name space must (or should be) supported by all implementations. It will vary depending on the purpose of the message so that normative language is included in the descriptions of the message. 5. In section 3.5 and 6.1 you propose a policy of "Expert Review with Specification Required ". I think that according to RFC5226 expert review is implied if you select a specification required policy. [PS:] I agree, it says "Specification Required also implies use of a Designated Expert". The policy is just "Specification Required" so we could remove the "Expert Review with" and make it clear it's the Specification Required IANA policy. 6. In section 3.6 on 9+ "Recipients of messages of type 9 or higher that do not 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." I think this is true only for Message Type Vendor ID 0. [PS:] Thanks will reword this section to make it more clear. 7. In 3.7.1 for Max vers and prefs ver you say that they MUST be set to 1. I think it will be more correct here to say SHOULD since you explain afterwards that they may have other values. [PS:] I think this is a MUST. The next sentence just points out that this normative text might change in a future revision (which is not currently planned). 8. In section 3.7.2 "the recipient SHOULD send". Why not make it a MUST here. [PS:] I ok with making this change, let's see what others think . 9. In section 3.7.2 "The version selected MUST be within the Min Vers to Max Vers inclusive range sent in the Version Request Message" I was expecting to see pref ver here. [PS:] Perf is just an informational (hint) preference. 10. In section 3.8.3 " The SASL client authentication starts when the NEA Server enters the PT-TLS Negotiation phase and its policy indicates that an authentication of the NEA Client is necessary but was not performed during the TLS handshake protocol " my read of section 3.8 second paragraph is that it can be done even if was done in the TLS handshake so the last part of the sentence is not correct, if there is a policy you do it anyhow. This comment is also for the third paragraph. [PS:] Thanks, this was supposed to be an example. Will fix these. 11. In section 3.9 I noticed that you propose to send the entire original message. Isn't it enough to send only the message identifier. This is based on the last sentence of this section. [PS:] Not "the entire original message" as its at most the first 1024 bytes of the offending message. This allows the recipient to either caches recently sent messages and/or message identifiers when determining what caused the error. We thought this flexibility was useful and had very little cost. 12. Most of the text in section 6.1 repeats RFC5226 but in your words. Are you trying to change some of RFC5226 text if not why write it in different words? [PS:] We were hoping to emphasize the aspects of 5226 that are most important to this specification. We weren't trying to change how the IANA policy was interpreted. Did you think we did so? Is there a portion of this text that is most troubling or was this just a question? Nits/editorial comments: ------=_NextPart_000_0223_01CD4E15.57B56D80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

I am OK with your = responses. The only thing I am not sure is about using PEN 0 defined in = the registry.

 

Decimal

| = Organization

| | = Contact

| | | = Email

| | | = |

0

  = Reserved

    Internet Assigned Numbers = Authority

      = iana&iana.org

 

I was wondering how this = enterprise number should be specified since it appears as = "Reserved" in the registry. I have no specific = suggestion

Roni

 

 

<= span = style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:= = Paul Sangster [mailto:Paul_Sangster@symantec.com]
Sent: = Wednesday, June 13, 2012 7:56 PM
To: Roni Even; = draft-ietf-nea-pt-tls.all@tools.ietf.org
Cc: 'IETF'; = gen-art@ietf.org; nea@ietf.org
Subject: RE: GenART LC review = of draft-ietf-nea-pt-tls-05

 

Thanks for the detailed review, comments are = in-lined…

 

<= span = style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:= = Roni Even [mailto:ron.even.tlv@gmail.com]=
Sent: Monday, June 04, 2012 2:20 PM
To: draft-ietf-nea-p= t-tls.all@tools.ietf.org
Cc: 'IETF'; gen-art@ietf.org
Subject: = GenART LC review of = draft-ietf-nea-pt-tls-05

 

I am the = assigned Gen-ART reviewer for this draft. For background on Gen-ART, = please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq= >.

 

Please resolve these comments along with any other = Last Call comments you may receive.

 =

Document: = draft-ietf-nea-pt-tls-05

Reviewer: = Roni Even

Review = Date:2012–6–4

IETF LC = End Date: 2012–6–13

IESG = Telechat date:

 =

Summary: = This draft is almost ready for publication as a standard track = RFC.

 =

Major = issues:

 =

Minor = issues:

1.       = In section = 3.2 “Therefore, this specification requests the IANA reserve a TCP = port number for use with the PT-TLS protocol upon publication of this = specification as an Internet standard RFC.” I think it will  = be better to have here the assigned port number and instruct the RFC = editor to put the correct value.

 

[PS:] Ok, we can reword this in hopes of getting a particular value = (race condition with other upcoming = RFCs).

 

2.       = In section = 3.4.2.2 last paragraph you summarize the text from section 3.8 while in = the paragraph above you provide the reference. Why do you need the last = paragraph if 3.8 is referenced.

 

[PS:] The goal of this section is to introduce and summarize the = different phases of PT-TLS.  We felt a brief discussion of the = general message flow was helpful to the reader to understand what occurs = during this phase (similar to what we did in the other = sub-sections).  Your correct that this information is covered later = in more detail.

 

3.       = In various = places you refer to SMI 0 as IETF SMI number while according to the = table it is IANA SMI number.

 

[PS:] I presume this is about the PEN 0 being for the IETF.  = Correct, it’s the IETF’s name space that administered by the = IANA.  What text would you like to see to make this more = clear?  Can we do it in one place, for example stating that the = IETF name space is administered by the = IANA?

 

4.       = I assume = that all implementations MUST support message type vendor ID 0. Is this = mentioned?

 

[PS:] The purpose of this section was just to summarize and enumerate = the message types for vendor id 0.   I don’t think = it’s a general rule that any message type defined in the IETF = (IANA J) name space must (or should be) supported by all = implementations.  It will vary depending on the purpose of the = message so that normative language is included in the descriptions of = the message.

 

5.       = In section = 3.5 and 6.1 you propose a policy of “Expert Review with = Specification Required “. I think that according to RFC5226 expert = review is implied if you select a specification required = policy.

 

[PS:] I agree, it says “Specification Required also implies use = of a Designated Expert”.  The policy is just = “Specification Required” so we could remove the = “Expert Review with” and make it clear it’s the = Specification Required IANA policy.

 

6.       = In section = 3.6 on 9+ “Recipients of messages   of type 9 or higher = that do not 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.” I think this is true = only for Message Type Vendor ID 0.

 

[PS:] Thanks will reword this section to make it more = clear.

 

7.       = In 3.7.1 = for Max vers and prefs ver you say that they MUST be set to 1. I think = it will be more correct here to say SHOULD since you explain afterwards = that they may have other values.

 

[PS:] I think this is a MUST.  The next sentence just points out = that this normative text might change in a future revision (which is not = currently planned).

 

8.       = In section = 3.7.2 “the recipient SHOULD send”. Why not make it a MUST = here.

 

[PS:] I ok with making this change, let’s see what others think = …

 

9.       = In section = 3.7.2 “The version selected MUST be within the Min Vers to Max = Vers inclusive range sent in the Version Request   = Message” I was expecting to see pref ver = here.

 

[PS:] Perf is just an informational (hint) = preference.

 

10.   In section = 3.8.3 “ The SASL client authentication starts when the NEA = Server  enters the PT-TLS Negotiation phase and its policy = indicates  that an authentication of the NEA Client is necessary = but was not performed during the TLS handshake protocol “ my read = of  section 3.8 second paragraph is that it can be done even if was = done in the TLS handshake so the last part of the sentence is not = correct, if there is a policy you do it anyhow. This comment is also for = the third paragraph.

 

[PS:] Thanks, this was supposed to be an example.  Will fix = these.

 

11.   In section = 3.9 I noticed that you propose to send the entire original message. = Isn’t it enough to send only the message identifier. This is based = on the last sentence of this section.

 

[PS:] Not “the entire original message” as its at most = the first 1024 bytes of the offending message.  This allows the = recipient to either caches recently sent messages and/or message = identifiers when determining what caused the error.  We thought = this flexibility was useful and had very little = cost.

 

12.   Most of = the text in section 6.1 repeats RFC5226 but in your words. Are you = trying to change some of RFC5226 text if not why write it in different = words?

 

[PS:] We were hoping to emphasize the aspects of 5226 that are most = important to this specification.  We weren’t trying to change = how the IANA policy was interpreted.  Did you think we did = so?  Is there a portion of this text that is most troubling or was = this just a question?

 

 =

 =

 =

Nits/editor= ial comments:

 

------=_NextPart_000_0223_01CD4E15.57B56D80-- From Paul_Sangster@symantec.com Tue Jun 19 08:24:21 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 7BD3211E808F; Tue, 19 Jun 2012 08:24:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 AoiOk4cvj95A; Tue, 19 Jun 2012 08:24:15 -0700 (PDT) Received: from tus1smtoutpex02.symantec.com (tus1smtoutpex02.symantec.com [216.10.195.242]) by ietfa.amsl.com (Postfix) with ESMTP id D267021F8566; Tue, 19 Jun 2012 08:24:04 -0700 (PDT) X-AuditID: d80ac3f2-b7f806d0000068dc-a0-4fe099945643 Received: from tus1opsmtapin02.ges.symantec.com (tus1opsmtapin02.ges.symantec.com [192.168.214.44]) by tus1smtoutpex02.symantec.com (Symantec Brightmail Gateway out) with SMTP id 55.26.26844.49990EF4; Tue, 19 Jun 2012 15:24:04 +0000 (GMT) Received: from [155.64.220.138] (helo=TUS1XCHHUBPIN02.SYMC.SYMANTEC.COM) by tus1opsmtapin02.ges.symantec.com with esmtp (Exim 4.76) (envelope-from ) id 1Sh0Hk-0001GD-0W; Tue, 19 Jun 2012 15:24:04 +0000 Received: from TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM ([155.64.220.150]) by TUS1XCHHUBPIN02.SYMC.SYMANTEC.COM ([172.24.185.246]) with mapi; Tue, 19 Jun 2012 08:24:04 -0700 From: Paul Sangster To: Roni Even , "draft-ietf-nea-pt-tls.all@tools.ietf.org" Date: Tue, 19 Jun 2012 08:25:43 -0700 Thread-Topic: GenART LC review of draft-ietf-nea-pt-tls-05 Thread-Index: Ac1Cl9xExNAkih6WSYeHA9SkXDOg7gG388dgASA4xdAADb42MA== Message-ID: <6E79D623502C70419A9EAB18E4D274252B8B2C397F@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> References: <4fcd272e.2968b40a.55d4.ffff9de3@mx.google.com> <6E79D623502C70419A9EAB18E4D274252B8B06102F@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> <4fe0440b.6959b40a.7a49.6095@mx.google.com> In-Reply-To: <4fe0440b.6959b40a.7a49.6095@mx.google.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_6E79D623502C70419A9EAB18E4D274252B8B2C397FTUS1XCHEVSPIN_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrNIsWRmVeSWpSXmKPExsVyYMU1Hd0pMx/4G2y+zm4x9+IEdourrz6z WDzbOJ/F4vPbCou/7cwOrB47Z91l91iy5CeTx5fLn9kCmKO4bFJSczLLUov07RK4Mp5Mvsxe sH4uU8WE6YsZGxi//mbsYuTkkBAwkbh8dx4bhC0mceHeeiCbi0NI4AOjxJ3dh9khnNeMEl2r mpkhnFWMEr/fLgRrZxMwkNh55BRYlYhAI6PE1yVzmEESzAJJEsdnbGABsVkEVCXW35zCDmIL C1hKTPk+CSwuImAlsfTDRCYI20niyrnjYDavQJTE3Om7oFbvYpRY8/QpWDOngIXExg23WEFs RqBjv59awwSxTFzi1pP5TBBPCEgs2XOeGcIWlXj5+B9UvajEnfb1jBD1+RIP1pxih1gmKHFy 5hOWCYxis5CMmoWkbBaSMoi4jsSC3Z/YIGxtiWULXzPD2GcOPGZCFl/AyL6KUaaktNiwOLck v7SkILXCwEivuDI3ERjByXrJ+bmbGIFRfIPr8KcdjDeWKh5iFOBgVOLh3TDpgb8Qa2IZUOUh RgkOZiUR3roZQCHelMTKqtSi/Pii0pzU4kOM0hwsSuK8H3Zv9RcSSE8sSc1OTS1ILYLJMnFw SjUwTvO/mqp7O39hgQfrf+aqiQt1Qu0NZRetP2zSfOsJU3XDpjcHZ9kei3OJ7T/B/Lp2XdrV dSdXOP5/xXf55sPca523a9SKnKdUbWleKGJZrLBRZz1r1UTpx/P3CrWkdVwWF9vJFvDY4lyB uuxL4faQHFHH8Fe7FQzMg8L59j9+kME0w3jJW1EjJZbijERDLeai4kQAludT5d4CAAA= Cc: "gen-art@ietf.org" , "nea@ietf.org" , 'IETF' Subject: Re: [Nea] GenART LC review of draft-ietf-nea-pt-tls-05 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: Tue, 19 Jun 2012 15:24:21 -0000 --_000_6E79D623502C70419A9EAB18E4D274252B8B2C397FTUS1XCHEVSPIN_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable NEA has 2 existing RFCs (PA and PB protocols) that use the PEN of 0 in exac= tly the same way as PT-TLS. One option might be to change "Reserved" to "R= eserved for IETF Use". From: Roni Even [mailto:ron.even.tlv@gmail.com] Sent: Tuesday, June 19, 2012 2:16 AM To: Paul Sangster; draft-ietf-nea-pt-tls.all@tools.ietf.org Cc: 'IETF'; gen-art@ietf.org; nea@ietf.org Subject: RE: GenART LC review of draft-ietf-nea-pt-tls-05 Hi, I am OK with your responses. The only thing I am not sure is about using PE= N 0 defined in the registry. Decimal | Organization | | Contact | | | Email | | | | 0 Reserved Internet Assigned Numbers Authority iana&iana.org I was wondering how this enterprise number should be specified since it app= ears as "Reserved" in the registry. I have no specific suggestion Roni From: Paul Sangster [mailto:Paul_Sangster@symantec.com] Sent: Wednesday, June 13, 2012 7:56 PM To: Roni Even; draft-ietf-nea-pt-tls.all@tools.ietf.org Cc: 'IETF'; gen-art@ietf.org; nea@ietf.org Subject: RE: GenART LC review of draft-ietf-nea-pt-tls-05 Thanks for the detailed review, comments are in-lined... From: Roni Even [mailto:ron.even.tlv@gmail.com] Sent: Monday, June 04, 2012 2:20 PM To: draft-ietf-nea-pt-tls.all@tools.ietf.org Cc: 'IETF'; gen-art@ietf.org Subject: GenART LC review of draft-ietf-nea-pt-tls-05 I am the assigned Gen-ART reviewer for this draft. For background on Gen-AR= T, please see the FAQ at . Please resolve these comments along with any other Last Call comments you m= ay receive. Document: draft-ietf-nea-pt-tls-05 Reviewer: Roni Even Review Date:2012-6-4 IETF LC End Date: 2012-6-13 IESG Telechat date: Summary: This draft is almost ready for publication as a standard track RFC= . Major issues: Minor issues: 1. In section 3.2 "Therefore, this specification requests the IANA re= serve a TCP port number for use with the PT-TLS protocol upon publication o= f this specification as an Internet standard RFC." I think it will be bett= er to have here the assigned port number and instruct the RFC editor to put= the correct value. [PS:] Ok, we can reword this in hopes of getting a particular value (race c= ondition with other upcoming RFCs). 2. In section 3.4.2.2 last paragraph you summarize the text from sect= ion 3.8 while in the paragraph above you provide the reference. Why do you = need the last paragraph if 3.8 is referenced. [PS:] The goal of this section is to introduce and summarize the different = phases of PT-TLS. We felt a brief discussion of the general message flow w= as helpful to the reader to understand what occurs during this phase (simil= ar to what we did in the other sub-sections). Your correct that this infor= mation is covered later in more detail. 3. In various places you refer to SMI 0 as IETF SMI number while acco= rding to the table it is IANA SMI number. [PS:] I presume this is about the PEN 0 being for the IETF. Correct, it's = the IETF's name space that administered by the IANA. What text would you l= ike to see to make this more clear? Can we do it in one place, for example= stating that the IETF name space is administered by the IANA? 4. I assume that all implementations MUST support message type vendor= ID 0. Is this mentioned? [PS:] The purpose of this section was just to summarize and enumerate the m= essage types for vendor id 0. I don't think it's a general rule that any = message type defined in the IETF (IANA :)) name space must (or should be) s= upported by all implementations. It will vary depending on the purpose of = the message so that normative language is included in the descriptions of t= he message. 5. In section 3.5 and 6.1 you propose a policy of "Expert Review with= Specification Required ". I think that according to RFC5226 expert review = is implied if you select a specification required policy. [PS:] I agree, it says "Specification Required also implies use of a Design= ated Expert". The policy is just "Specification Required" so we could remo= ve the "Expert Review with" and make it clear it's the Specification Requir= ed IANA policy. 6. In section 3.6 on 9+ "Recipients of messages of type 9 or higher= that do not support the PT-TLS Message Type Vendor ID and PT-TLS Message T= ype of a received PT-TLS message MUST respond with a Type Not Supported PT-= TLS error code in a PT-TLS Error message." I think this is true only for Me= ssage Type Vendor ID 0. [PS:] Thanks will reword this section to make it more clear. 7. In 3.7.1 for Max vers and prefs ver you say that they MUST be set = to 1. I think it will be more correct here to say SHOULD since you explain = afterwards that they may have other values. [PS:] I think this is a MUST. The next sentence just points out that this = normative text might change in a future revision (which is not currently pl= anned). 8. In section 3.7.2 "the recipient SHOULD send". Why not make it a MU= ST here. [PS:] I ok with making this change, let's see what others think ... 9. In section 3.7.2 "The version selected MUST be within the Min Vers= to Max Vers inclusive range sent in the Version Request Message" I was e= xpecting to see pref ver here. [PS:] Perf is just an informational (hint) preference. 10. In section 3.8.3 " The SASL client authentication starts when the NEA= Server enters the PT-TLS Negotiation phase and its policy indicates that= an authentication of the NEA Client is necessary but was not performed dur= ing the TLS handshake protocol " my read of section 3.8 second paragraph i= s that it can be done even if was done in the TLS handshake so the last par= t of the sentence is not correct, if there is a policy you do it anyhow. Th= is comment is also for the third paragraph. [PS:] Thanks, this was supposed to be an example. Will fix these. 11. In section 3.9 I noticed that you propose to send the entire original= message. Isn't it enough to send only the message identifier. This is base= d on the last sentence of this section. [PS:] Not "the entire original message" as its at most the first 1024 bytes= of the offending message. This allows the recipient to either caches rece= ntly sent messages and/or message identifiers when determining what caused = the error. We thought this flexibility was useful and had very little cost= . 12. Most of the text in section 6.1 repeats RFC5226 but in your words. Ar= e you trying to change some of RFC5226 text if not why write it in differen= t words? [PS:] We were hoping to emphasize the aspects of 5226 that are most importa= nt to this specification. We weren't trying to change how the IANA policy = was interpreted. Did you think we did so? Is there a portion of this text= that is most troubling or was this just a question? Nits/editorial comments: --_000_6E79D623502C70419A9EAB18E4D274252B8B2C397FTUS1XCHEVSPIN_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

NEA has 2 existing RFCs (PA and PB protocols) that use the PE= N of 0 in exactly the same way as PT-TLS.  One option might be to chan= ge “Reserved” to “Reserved for IETF Use”.

From: Roni Even [mailto:ron.e= ven.tlv@gmail.com]
Sent: Tuesday, June 19, 2012 2:16 AM
To= : Paul Sangster; draft-ietf-nea-pt-tls.all@tools.ietf.org
Cc:= 'IETF'; gen-art@ietf.org; nea@ietf.org
Subject: RE: GenART LC re= view of draft-ietf-nea-pt-tls-05

 

Hi,

I am OK with your responses. The only thing I am not sure is abo= ut using PEN 0 defined in the registry.

 

Decimal

| Organization

| | Contact

| | | Email

| | | |

0

  Reserved

    In= ternet Assigned Numbers Authority

   &nb= sp;  iana&iana.org

 

<= span style=3D'color:#1F497D'>I was wondering how this enterprise number sho= uld be specified since it appears as "Reserved" in the registry. = I have no specific suggestion

Roni

<= span style=3D'color:#1F497D'> 

 

From: Paul Sangster [mailto:Paul_Sangster@symantec.com]=
Sent: Wednesday, June 13, 2012 7:56 PM
To: Roni Even;= draft-ietf-nea-pt-tls.all@tools.ietf.org
Cc: 'IETF'; gen-art@iet= f.org; nea@ietf.org
Subject: RE: GenART LC review of draft-ietf-n= ea-pt-tls-05

&nb= sp;

Thanks for = the detailed review, comments are in-lined…

 

=

From: Roni Even [mailto:ron.even.tlv@gmail.com]
Sent: Monda= y, June 04, 2012 2:20 PM
To: draft-ietf-nea-pt-tls.all@tools.ietf.org
= Cc: 'IETF'; gen-art@ietf.orgSubject: GenART LC review of draft-ietf-nea-pt-tls-05

 

I am the assigned Gen-ART reviewer for this draft. For background o= n Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/= area/gen/trac/wiki/GenArtfaq>.

 

Please resolve these comments along= with any other Last Call comments you may receive.

 

Document: draft-ietf-= nea-pt-tls-05

Reviewer: Roni Even

Review Date:2012–6–4

IETF LC End Date: 2012–6–13=

IESG Telechat date:

=

 

Summary: This= draft is almost ready for publication as a standard track RFC.<= /span>

 

Maj= or issues:

 

Minor issues:

1.       <= ![endif]>In section 3.2 “Therefore, this specification requests the IANA res= erve a TCP port number for use with the PT-TLS protocol upon publication of= this specification as an Internet standard RFC.” I think it will&nbs= p; be better to have here the assigned port number and instruct the RFC edi= tor to put the correct value.

=  

[PS= :] Ok, we can reword this in hopes of getting a particular value (race cond= ition with other upcoming RFCs).

 

2.       In sec= tion 3.4.2.2 last paragraph you summarize the text from section 3.8 while i= n the paragraph above you provide the reference. Why do you need the last p= aragraph if 3.8 is referenced.

 

[P= S:] The goal of this section is to introduce and summarize the different ph= ases of PT-TLS.  We felt a brief discussion of the general message flo= w was helpful to the reader to understand what occurs during this phase (si= milar to what we did in the other sub-sections).  Your correct that th= is information is covered later in more detail.

 

3.       <= /span>In various places you refer to SMI 0 as IETF SMI number while acco= rding to the table it is IANA SMI number.

 

<= i>[PS:] I presume this is about the PEN 0 being for the IETF.  = Correct, it’s the IETF’s name space that administered by the IA= NA.  What text would you like to see to make this more clear?  Ca= n we do it in one place, for example stating that the IETF name space is ad= ministered by the IANA?

 

4.&= nbsp;      I assume that a= ll implementations MUST support message type vendor ID 0. Is this mentioned= ?

 

[PS:] The purpose of this secti= on was just to summarize and enumerate the message types for vendor id 0.&n= bsp;  I don’t think it’s a general rule that any message t= ype defined in the IETF (IANA J)= name space must (or should be) supported by all implementations.  It = will vary depending on the purpose of the message so that normative languag= e is included in the descriptions of the message.=

 

5.       In section 3.5 and 6.1 you propose a policy of “Expert Rev= iew with Specification Required “. I think that according to RFC5226 = expert review is implied if you select a specification required policy.

 

[PS:] I agree, it says “Specif= ication Required also implies use of a Designated Expert”.  The = policy is just “Specification Required” so we could remove the = “Expert Review with” and make it clear it’s the Specifica= tion Required IANA policy.

 

6= .     = ;  In section 3.6 on 9+ “Recipients of m= essages   of type 9 or higher that do not support the PT-TLS Mess= age Type Vendor ID and PT-TLS Message Type of a received PT-TLS message MUS= T respond with a Type Not Supported PT-TLS error code in a PT-TLS Error mes= sage.” I think this is true only for Message Type Vendor ID 0.

 

<= p class=3DMsoPlainText>[PS:] Thanks will reword this section t= o make it more clear.

=  

= 7.&nb= sp;      In 3.7.1 for Max = vers and prefs ver you say that they MUST be set to 1. I think it will be m= ore correct here to say SHOULD since you explain afterwards that they may h= ave other values.

 

[PS:] I think = this is a MUST.  The next sentence just points out that this normative= text might change in a future revision (which is not currently planned).

 

8.    &n= bsp;  In section 3.7.2 “the recipient SH= OULD send”. Why not make it a MUST here.

 

[PS:] I ok with making this change, let’s see what othe= rs think …

 

9. &= nbsp;     In section 3.7.2 R= 20;The version selected MUST be within the Min Vers to Max Vers inclusive r= ange sent in the Version Request   Message” I was expecting= to see pref ver here.

=  

[PS:] Perf= is just an informational (hint) preference.

<= p class=3DMsoPlainText> 

10.   In section 3.8.3 = “ The SASL client authentication starts when the NEA Server  ent= ers the PT-TLS Negotiation phase and its policy indicates  that an aut= hentication of the NEA Client is necessary but was not performed during the= TLS handshake protocol “ my read of  section 3.8 second paragra= ph is that it can be done even if was done in the TLS handshake so the last= part of the sentence is not correct, if there is a policy you do it anyhow= . This comment is also for the third paragraph.

 

[PS:] Thanks, this was supposed to be an example.  Will= fix these.

 

11.  = In section 3.9 I noticed that you propose to send = the entire original message. Isn’t it enough to send only the message= identifier. This is based on the last sentence of this section.=

 

[PS:] Not “the entire original messag= e” as its at most the first 1024 bytes of the offending message. = ; This allows the recipient to either caches recently sent messages and/or = message identifiers when determining what caused the error.  We though= t this flexibility was useful and had very little cost.

 

12.   Most= of the text in section 6.1 repeats RFC5226 but in your words. Are you tryi= ng to change some of RFC5226 text if not why write it in different words?

 =

[PS:] We were hoping to emphasize = the aspects of 5226 that are most important to this specification.  We= weren’t trying to change how the IANA policy was interpreted.  = Did you think we did so?  Is there a portion of this text that is most= troubling or was this just a question?

 

=  

 

 

Nits/editorial com= ments:

 

= --_000_6E79D623502C70419A9EAB18E4D274252B8B2C397FTUS1XCHEVSPIN_--