From ietf@augustcellars.com Mon Oct 1 10:12:19 2012 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3767921F8811 for ; Mon, 1 Oct 2012 10:12:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.392 X-Spam-Level: X-Spam-Status: No, score=-2.392 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a3IYrTyvAH3A for ; Mon, 1 Oct 2012 10:12:18 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id 985B021F8810 for ; Mon, 1 Oct 2012 10:12:18 -0700 (PDT) Received: from Tobias (winery.augustcellars.com [206.212.239.129]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 8C07D2CA03; Mon, 1 Oct 2012 10:12:15 -0700 (PDT) From: "Jim Schaad" To: , Date: Mon, 1 Oct 2012 10:10:50 -0700 Message-ID: <00e401cd9ff7$b52212a0$1f6637e0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac2f9v+FDIoykt+NRVmWduL9qgMM2A== Content-Language: en-us Subject: [Emu] More COmments 2 on eap-tunnel-method X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2012 17:12:19 -0000 I found two that I forgot to include in the last message 1. When exporting the user-id, does there need to be a way to distinguish at export time between the different types of ids that are authenticated by the server? This does not seem to be an issue on the peer as it will only do mutual authentication to servers and thus only have server ids, however a server may authenticate to different types of identities on the peer. At the moment we have identified user and machines as types of entities to be identified, I suppose in the future we could add Ewoks as a different type of entity that could be identified. However the export function of user-ids does not make a distinction between the different types of authenticated entities. Should it do so or should it just export user authentications? 2. Is there a map of TLVs that should not be sent together or need to be processed in a specific order? The case I was looking at was for the Identity TLV and the EAP TLV. Is there a difference in how a peer should react for the following? Identity TLV (Send me a machine Identity), EAP TLV (Start the EAP type XX) EAP TLV (Start EAP type XXX), Identity TLV (Send me a machine Identity) Or should these two TLVs never occur in a single message? Jim From ietf@augustcellars.com Wed Oct 3 13:13:31 2012 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B3D921F850C for ; Wed, 3 Oct 2012 13:13:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.855 X-Spam-Level: X-Spam-Status: No, score=-2.855 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_05=-1.11, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qk0huUtf7JmT for ; Wed, 3 Oct 2012 13:13:30 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id B948921F8200 for ; Wed, 3 Oct 2012 13:13:30 -0700 (PDT) Received: from Tobias (173-8-216-38-Oregon.hfc.comcastbusiness.net [173.8.216.38]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id D527B2C9FB; Wed, 3 Oct 2012 13:13:27 -0700 (PDT) From: "Jim Schaad" To: , Date: Wed, 3 Oct 2012 13:11:59 -0700 Message-ID: <00e601cda1a3$5a230c80$0e692580$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac2hoi1rLrNrqIMITdOHfDt5EorDlA== Content-Language: en-us Subject: [Emu] Client Auth with TLS X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 20:13:31 -0000 This issue is one that I was dealing with while driving grapes back from the vineyard yesterday. I don't know that it needs to have any changes in the draft. I am putting this out to see if there is any controversy on the decisions that I would make about this issue. The client is going to use client authorization with the TLS tunnel. I make the assumption that the client does successfully authenticate the server's certificate and we are not in a total anonymous situation. At this point I believe the following possible scenarios exist: 1. The client provides no certificate - This would be accepted depending on the server policy about requiring a client certificate to be presented. 2. The client provides a certificate in the clear - This could be either a user or machine certificate, the server would check the identity against Its database (with the proviso that the certificate could be the entry in the database) and either accepts or rejects the TLS connection based on the identity presented. This would be done via a TLS alert. Note, I did have an argument with myself about the possibility that the server would accept the certificate and treat it as if it was an anonymous client. 3. The client provides the certificate in a protected manner - I had a problem at this point because I don't know enough TLS to properly go through this scenario, and I could not really read documents while driving. If the encrypted certificate extension was used, then there is no issue as the protected certificate would be passed in the initial handshake. However if the client starts the negotiation and then restarts it after it is encrypted, I don't know if this occurs before or after the finish message. If it starts after the finish method then there is an issue with having the server close an anonymous session if the client is then going to provide the certificate encrypted. Help on how this works would be appreciated. Jim From stefan.winter@restena.lu Wed Oct 3 23:09:56 2012 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B77721F85C2 for ; Wed, 3 Oct 2012 23:09:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4PD+B0I0xgpk for ; Wed, 3 Oct 2012 23:09:55 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 2C38C21F85C0 for ; Wed, 3 Oct 2012 23:09:54 -0700 (PDT) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id BAB7310584 for ; Thu, 4 Oct 2012 08:09:52 +0200 (CEST) Received: from [IPv6:2001:a18:1:8:230:5ff:fefe:5359] (unknown [IPv6:2001:a18:1:8:230:5ff:fefe:5359]) by smtprelay.restena.lu (Postfix) with ESMTPS id AE8B410581 for ; Thu, 4 Oct 2012 08:09:52 +0200 (CEST) Message-ID: <506D282C.6040909@restena.lu> Date: Thu, 04 Oct 2012 08:09:48 +0200 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120825 Thunderbird/15.0 MIME-Version: 1.0 To: emu@ietf.org References: <00e601cda1a3$5a230c80$0e692580$@augustcellars.com> In-Reply-To: <00e601cda1a3$5a230c80$0e692580$@augustcellars.com> X-Enigmail-Version: 1.4.4 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigE4D06CD816B0B64D1AAE4052" X-Virus-Scanned: ClamAV Subject: Re: [Emu] Client Auth with TLS X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 06:09:56 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigE4D06CD816B0B64D1AAE4052 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, > 3. The client provides the certificate in a protected manner - I had a= > problem at this point because I don't know enough TLS to properly go th= rough > this scenario, and I could not really read documents while driving. If= the > encrypted certificate extension was used, then there is no issue as the= > protected certificate would be passed in the initial handshake. Howeve= r if > the client starts the negotiation and then restarts it after it is > encrypted, I don't know if this occurs before or after the finish messa= ge. > If it starts after the finish method then there is an issue with having= the > server close an anonymous session if the client is then going to provid= e the > certificate encrypted. Help on how this works would be appreciated. FWIW, RFC5216 (EAP-TLS) already has provisions for a protected client credential exchange (for client privacy protection reasons). I didn't ever see it used (anyone?), but it's clearly a foreseen mode of operation. The text describing this is in section 2.1.4: "... In order to avoid disclosing the peer username, an EAP-TLS peer configured for privacy MUST negotiate a TLS ciphersuite supporting confidentiality and MUST provide a client certificate list containing no entries in response to the initial certificate_request from the EAP-TLS server. An EAP-TLS server supporting privacy MUST NOT treat a certificate list containing no entries as a terminal condition; instead, it MUST bring up the TLS session and then send a hello_request. The handshake then proceeds normally; the peer sends a client_hello and the server replies with a server_hello, certificate, server_key_exchange, certificate_request, server_hello_done, etc. For the calculation of exported keying material (see Section 2.3), the master_secret derived within the second handshake is used. An EAP-TLS peer supporting privacy MUST provide a certificate list containing at least one entry in response to the subsequent certificate_request sent by the server. If the EAP-TLS server supporting privacy does not receive a client certificate in response to the subsequent certificate_request, then it MUST abort the session. " There is a sequence diagram shortly afterwards which shows clearly that the "first" negotiation ends with a 'finished' and then immediately a new 'hello_request' - all in one EAP message. Greetings, Stefan >=20 > Jim >=20 >=20 > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu >=20 --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 --------------enigE4D06CD816B0B64D1AAE4052 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlBtKDAACgkQ+jm90f8eFWYcfgCeLOvnHjmYQyAszudbeVrA9U+E +xgAniESQHIBFVq5CzTNujkPrtYEydV7 =ykWV -----END PGP SIGNATURE----- --------------enigE4D06CD816B0B64D1AAE4052-- From hzhou@cisco.com Thu Oct 4 10:39:15 2012 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E199F21F86BE for ; Thu, 4 Oct 2012 10:39:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WDWNL-iDRl-O for ; Thu, 4 Oct 2012 10:39:12 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id BE84521F863F for ; Thu, 4 Oct 2012 10:39:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=49756; q=dns/txt; s=iport; t=1349372352; x=1350581952; h=from:to:cc:subject:date:message-id:mime-version; bh=A+J/jgW0KAvfcRXdHh6e0B6fiFoTfbr7uKcQXYujQW4=; b=BK7BRAsT3Q25PZpCrzPOt3FdcrnzjV8bTNzWPoFUTkD5dZI25TV91xEi tJhrl+G3QMwcUM0XLbmzP7aQoh36sjMnAgfpOy0vDsfWzsWFtImJ9XjEl JCw0bQeEGNytp5+CpmJLuJfHVLOPTK0s2ty9pvH1v4G1mnI0KyBkKEftt c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlgJANzIbVCtJV2d/2dsb2JhbAA8CYJLhF+BRLNcgkKBCIIgAQEBBAEBAQ8BB1QLDAYBCA4DBAEBCw4IAQYuCxQJCgQOBQgah2MLmCOgEgSLPhETglqCP2ADpCyBaYEugT+BWgIFHhg X-IronPort-AV: E=Sophos;i="4.80,537,1344211200"; d="scan'208,217";a="128142509" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-1.cisco.com with ESMTP; 04 Oct 2012 17:39:08 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id q94Hd8GG014263 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 4 Oct 2012 17:39:08 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.202]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0318.001; Thu, 4 Oct 2012 12:39:07 -0500 From: "Hao Zhou (hzhou)" To: Jim Schaad Thread-Topic: [Emu] Review of draft-ietf-emu-eap-tunnel-method-00 Thread-Index: AQHNolcnsIvA7junTwesvqtA+uoKMg== Date: Thu, 4 Oct 2012 17:39:07 +0000 Message-ID: <645B00545719594A88ADF4221831FD3813D697@xmb-rcd-x14.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 x-originating-ip: [64.101.219.104] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19238.000 x-tm-as-result: No--51.167500-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_645B00545719594A88ADF4221831FD3813D697xmbrcdx14ciscocom_" MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 04 Oct 2012 12:51:55 -0700 Cc: "emu@ietf.org" Subject: Re: [Emu] Review of draft-ietf-emu-eap-tunnel-method-00 X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 17:39:15 -0000 --_000_645B00545719594A88ADF4221831FD3813D697xmbrcdx14ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Jim: Thanks very much for your detailed review. Please see the comments below. W= e will respond to your other emails shortly. On 9/28/12 9:18 PM, "Jim Schaad" > wrote: 1. In section 3.2.3, it says that a new PAC can be requested after a full TLS handshake. Can one be requested following an abbreviated handshake? Or do you just re-use the existing PAC? [HZ] RFC5077 does not specify that client can request a new ticket after sending the TLS ticket, if the client is resuming a session using the session ticket, then it cannot request a new session ticket based on resumed session. We will add some language to clarify that it is not allowed. 2. Section 3.3 s/descried/described/ [HZ] Ok. 3. Section 3.4 - Is it possible to have multiple server ids after the authentication - one from the tunnel and others from the inner EAP methods. I realize that most EAP methods don't send a sender id, but some (IBAKE for example) currently do. Also, the client might have an idea of what the sender id is from configuration. If so, do these all need to get exported as server-id values? [HZ] Good catch. We will add a sentence similar to peer-ID, where multiple server IDs need to be exported. 4. In section 3.6.1 - It is not clear that an EAP-Failure packet is sent when 1) the server sends a fatal alert to the peer, 2) the peer requests a restart via a ClientHello and 3) the peer declines to permit the restart to occur. [HZ] We will clarify that EAP-Failure packet will be sent in those cases. 5. In section 3.6.1 - Is the restart only an issue for fatal alerts, or is it a problem for all alerts? [HZ] Restart is only allowed for non-fatal alerts, per TLS RFC. "Upon transmission or receipt of a fatal alert message, both parties immediately = close the connection.", so restart is not desired in this case. We will clarify that restart is only allowed in non-fatal alert cases. 6. In section 3.6.2 - Why SHOULD not MUST send clear text EAP-Failure? [HZ] We will change it to MUST. 7. In section 3.6 - do we need to discuss the question of errors in the outer EAP layer that is carrying the TLVs which contain the TLS content? This is a distinct location from the current list of where to handle errors. There is going to be a distinction (possibly) between errors that occur during phase 1 and errors during phase 2. Should the error return reflect if the error occurred inside or outside of the TLS tunnel? [HZ] Good catch. We will add some language to clarify dealing with outer packet errors. Something like: 1. If Outer TLVs are wrong, they will be ignored. 2. If others (version, length, flags, etc.) are wrong, the entire EAP packet will be ignored. 8. In section 3.8 - I have the following questions a) In the text "The request MAY be issued", I don't understand the MAY at this point. Is it supposed to say that the request can be issued either before or after the authentication has finished, or is it saying that the peer has the option of issuing or not issuing the request, but must wait until the authentication level has been reached? [HZ] It's the later. How about add "only" in front "after the peer has determined that..."? b) If a peer issues a PAC request, but the server has not yet satisfied it's policy, does the server remember the PAC request and send back the response after the internal policy has been satisfied or should it send back an error saying that policy has not yet been satisfied along with additional TLVs to attempt and satisfy that policy? [HZ] The server remembers that and issues the PAC after its policy is satisfied. We will clarify that. c) What should a peer do if it receives a PAC TLV with an unknown attribute? [HZ] Ignore that. 9. In section 3.9 - there is leaking on the POP, but not on identity at this point. I believe that there needs to be a requirement that an EAP method needs to be run which will provide an identity proof on the client prior to a certificate being issued. You may or may not then want to add text that says that the subject name(s) in the certificate request need to be checked against the set of authenticated identities prior to the certificate being issued. [HZ] Good point. We will add some that. 10. In section 3.10 - It is unclear to me if the Server Unauthenticated mode is because the server or the peer is unauthenticated at this point in time. The cipher suite would indicate that the server is not authenticated, however what about the case of the server providing an authenticated id to the peer, but the peer is unable to validate the identity of the server for some reason. This is also a Server Unauthenticated mode. [HZ] Yes. It covers both cases. We will add language to clarify that. 11. In section 4.1 - I would like to see a discussion that says that the following situation can never occur. The initial EAP message from the peer to the server (or the response) plus the Outer TLV data plus the EAP message headers exceeds the underlying packet size of the transport. In the event that it does, I am not sure how one finds the Outer TLV data start and where the fragmentation would occur to get the Outer TLV data between the peer and the server. [HZ] I think it should work as defined. The start of the Outer TLVs should be derived from the EAP message length and length of the TLS data. 12. Section 4.2 - I understand what is happening with an EMPTY TEAP message being sent in response to a list of TLVs that are marked optional, however I question if the statement that is MUST be sent is correct. There are two reasons for the question: a. A server could send a RESULT TLV in response to a message from the client that contains no TLVs that are either mandatory or recognized. [HZ] Good catch. We will clarify that. b. I am (very slightly) worried about the fact that the response is not authenticated by the tunnel in many manner. I would think that a NAK to any of the TLVs would be a better response if no other TLV messages are to be sent. The entity sending the TLV should know if it marked it as mandatory or not. The NAK is not the same as an Error TLV. [HZ] Agree. A NAK TLV should be sent in this case. We will clarify. 13. Section 4.2.2 - Should "Type" in the outdented list be "TLV Type"? s/filed/field/ [HZ] Yes. We will correct that. 14. Section 4.2.2 - Can multiple Authority-ID TLVs be transmitted to a peer? [HZ] No. It is mentioned in Section 4.3, Table of TLVs rules. 15. Section 4.2.3 - I assume that there should only be one Identity-Type TLV in a TEAP packet. Should a request for authentication be present in the packet as well? If multiple are allowed then information about how to treat this should be included. What should the peer respond with if it does have an identity of the type? This is not explicitly stated. [HZ] That's correct, only one Identity-Type TLV is allowed.The requested Id= entity type MUST comes with an EAP request or Basic-Password-Auth-Req. If the peer has the requested identity type, it should send back the same i= dentity type TLV in the response. We missed this and will add this clarific= ation. 16. Section 4.2.4 - I don't understand the default in the event that an unknown value is sent in the status field. If there is an ERROR TLV in the message, should I not use that error code rather than change it? [HZ] No. The error code in the Error TLV if being sent with the Result TLV = might mean something, but since the peer doesn't understand the Status fiel= d, and most likely will not understand the error code. Sending back Unexpec= ted_TLVs_Exchanged error code is probably appropriate. 17. Section 4.2.6 - Do we need a discussion about how to produce/deal with vender specific errors? Do you expect that vender specific TLVs will have an error mechanism built into them to return an error code? [HZ] We expect the vendor TLV will have its own error handling mechanism or= use the standard error codes defined. 18. Section 4.2.8 - Do we need to talk about the question of having some Vender TLVs be marked as mandatory and others not. Are we using the same TLV structure with the same rules for mandatoriness. If the mandatory bit is set, does that mean that I need to recognize the vendor-id or all combinations of vender-id/Vender-TLV type? [HZ] Yes. If the mandatory bit is set on the Vendor-Speific TLV, then the p= eer need to recognize the vendor ID and all combination of the vendor TLVs.= The Vendor TLV format is up to the vendor to define, as specified by the c= urrent draft. 19. Section 4.2.9 - After reading this, sketching out some scenarios and so forth, I find that I do not like the text and result being pushed here at all. My problems start, in some respects, with the name of the TLV as it does not map to how I would like to see this TLV treated. I would propose the following set of changes: a) The name of the TLV be changed from Request-Action TLV to Provisional-Result TLV [HZ] I am open with the name change, but think Request-Action probably capt= ure the essence better. b) It needs to be made clear that the TLV can be sent from either the server to the peer or the peer to the server. It is my belief that presently it is only sent from the peer to the client and only in response to a successful Result TLV. [HZ] Ok. I agree that we can extend that to be bidirectional and for either= success and failure Result TLV. c) The receiving entity MUST process the TLV. [HZ] Ok. d) The processing for the TLV is as follows: i) The entity MAY choose to process (or start?) any of the TLVs that are included in the message. ii) If the entity chooses NOT to process any TLV in the list, the Provisional-Result TLV is treated as a Result TLV with the code "status" iii) If multiple Provisional-Result TLVs are in the body, the session can continue if ANY of TLV in any Provisional-Result TLV is processed. iv) If multiple Provisional-Result TLVs are in the body and no sub-TLV is processed, then the most fatal status should be used. If a status is found which is not understood by the entity, then it should be treated as a fatal TLV. [HZ] Ok. The current text allows for the following: The server sends a Success to the peer The peer says please do this or go to fatal The server sends a clear success outside of the tunnel. [HZ] That's not correct. The last exchange in the tunnel should be an agree= d upon Result TLV exchange, before the tunnel is torn down and a clear text= EAP success is sent. I wonder if the capability needs to be added to say, please start this TLV. So that a server can say, If you don't start a Channel binding TLV, I will make this a failure return code, if you want to start the channel binding TLV then I am open to giving you a success return code. OK - so this is kind of there, but only one value can be placed there. One cannot say do either an EAP negotiation or process this TLV. [HZ] That's true. Only one request. 20. Section 4.2.12.4 - What does it mean to have an I-ID validation enforcement for PAC session renewal? Does it mean that the final message is not sent unless an appropriate ID is presented? Does it have to be an EAP authentication or is password based authentication sufficient? Should a PAC be invalidated on the server side (oops how do you do that) if it a PAC is presented and then the appropriate ID is not given? [HZ] The I-ID in the PAC is used to validate that the correct user is being= authenticated and using his PAC. If they don't match, then the authenticat= ion will be rejected as if the authentication failed, with the normal flow = including the final Result TLV and clear text EAP failure being sent. It ca= n be either the EAP authentication or the password based authentication. Th= e PAC is not invalidated if the I-ID doesn't match the authenticated identi= ty, the authentication will be rejected. 21. In section 4.2.12.6 - Is this supposed to be at the top level or embedded in the PAC-TLV? [HZ] Yes. 22. In section 4.2.16 - PKCS#7 has been superseded by CMS - the references should be to CMS and not to PCKS#7 [HZ] Ok with me. Any other feedback from the WG? 23. In IANA - Need to add the Request-Action TLV to the list of status codes [HZ] It is included in the Result TLV, Intermediate Result TOV status code = registry in the IANA section. I think it makes sense to have the same one. 24. In IANA - Should the Vender ID of the Vender-Specific TLV be kept in a registry? [HZ] Vendor ID per the draft, is the SMI Network Management Private Enterpr= ise Code already managed by IANA. Jim -----Original Message----- From: emu-bounces@ietf.org [mailto:emu-bounces= @ietf.org] On Behalf Of Alan DeKok Sent: Tuesday, September 25, 2012 8:04 AM To: emu@ietf.org Subject: [Emu] Looking for reviewers We'd like to get the final two documents into last call before the next meeting. Therefore, we're looking for reviewers: https://datatracker.ietf.org/doc/draft-ietf-emu-crypto-bind/ https://datatracker.ietf.org/doc/draft-ietf-emu-eap-tunnel-method/ Please post reviews to the list. If all goes well, we can get updated documents issued before the next meeting. Thanks to everyone for their help. Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu --_000_645B00545719594A88ADF4221831FD3813D697xmbrcdx14ciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Jim:

Thanks very much for your detailed review. Please see the comments belo= w. We will respond to your other emails shortly. 

On 9/28/12 9:18 PM, "Jim Schaad" <ietf@augustcellars.com> wrote:

1.  In section 3.2.3, it says that a new PAC can be requeste= d after a full
TLS handshake.  Can one be requested following an abbreviate= d handshake?
Or
do you just re-use the existing PAC?
[HZ] RFC5077 does not specify that client can request a new ticket afte= r
sending the TLS ticket, if the client is resuming a session using the
session ticket, then it cannot request a new session ticket based on
resumed session. We will add some language to clarify that it is not
allowed.

2.  Section 3.3 s/descried/described/
[HZ] Ok.

3.  Section 3.4 - Is it possible to have multiple server ids= after the
authentication - one from the tunnel and others from the inner EAP
methods.
I realize that most EAP methods don't send a sender id, but some (IBAK= E
for
example) currently do.  Also, the client might have an idea = of what the
sender id is from configuration.  If so, do these all need t= o get exported
as server-id values?
[HZ] Good catch. We will add a sentence similar to peer-ID, where multi= ple
server IDs need to be exported.

4. In section 3.6.1 - It is not clear that an EAP-Failure packet is se= nt
when 1) the server sends a fatal alert to the peer, 2) the peer reques= ts a
restart via a ClientHello and 3) the peer declines to permit the resta= rt
to
occur.
[HZ] We will clarify that EAP-Failure packet will be sent in those case= s.

5.  In section 3.6.1 - Is the restart only an issue for fata= l alerts, or
is
it a problem for all alerts?
[HZ] Restart is only allowed for non-fatal alerts, per TLS RFC. "U= pon
transmission or receipt of a fatal alert message, both parties imm= ediately close the connection.", so restart is not desired
in this case. We will clarify that restart is only allowed in non-fatal=
alert cases.


6.  In section 3.6.2 - Why SHOULD not MUST send clear text E= AP-Failure?
[HZ] We will change it to MUST.

7.  In section 3.6 - do we need to discuss the question of e= rrors in the
outer EAP layer that is carrying the TLVs which contain the TLS conten= t?
This is a distinct location from the current list of where to handle
errors.
There is going to be a distinction (possibly) between errors that occu= r
during phase 1 and errors during phase 2.  Should the error = return reflect
if the error occurred inside or outside of the TLS tunnel?
[HZ] Good catch. We will add some language to clarify dealing with oute= r
packet errors. Something like:
1. If Outer TLVs are wrong, they will be ignored.
2. If others (version, length, flags, etc.) are wrong, the entire EAP
packet will be ignored.


8.  In section 3.8 - I have the following questions
a) In the text "The request MAY be issued", I don't understa= nd the MAY at
this point.  Is it supposed to say that the request can be i= ssued either
before or after the authentication has finished, or is it saying that = the
peer has the option of issuing or not issuing the request, but must wa= it
until the authentication level has been reached?
[HZ] It's the later. How about add "only" in front "afte= r the peer has
determined that..."?

b) If a peer issues a PAC request, but the server has not yet satisfie= d
it's
policy, does the server remember the PAC request and send back the
response
after the internal policy has been satisfied or should it send back an=
error
saying that policy has not yet been satisfied along with additional TL= Vs
to
attempt and satisfy that policy?
[HZ] The server remembers that and issues the PAC after its policy is
satisfied. We will clarify that.

c) What should a peer do if it receives a PAC TLV with an unknown
attribute?
[HZ] Ignore that.

9.  In section 3.9 - there is leaking on the POP, but not on= identity at
this point.  I believe that there needs to be a requirement = that an EAP
method needs to be run which will provide an identity proof on the cli= ent
prior to a certificate being issued.  You may or may not the= n want to add
text that says that the subject name(s) in the certificate request nee= d to
be checked against the set of authenticated identities prior to the
certificate being issued.
[HZ] Good point. We will add some that.


10. In section 3.10 - It is unclear to me if the Server Unauthenticate= d
mode
is because the server or the peer is unauthenticated at this point in<= /div>
time.
The cipher suite would indicate that the server is not authenticated,<= /div>
however what about the case of the server providing an authenticated i= d to
the peer, but the peer is unable to validate the identity of the serve= r
for
some reason.  This is also a Server Unauthenticated mode.
[HZ] Yes. It covers both cases. We will add language to clarify that.


11.  In section 4.1 - I would like to see a discussion that = says that the
following situation can never occur.  The initial EAP messag= e from the
peer
to the server (or the response) plus the Outer TLV data plus the EAP
message
headers exceeds the underlying packet size of the transport. &nbs= p;In the event
that it does, I am not sure how one finds the Outer TLV data start and=
where
the fragmentation would occur to get the Outer TLV data between the pe= er
and
the server.
[HZ] I think it should work as defined. The start of the Outer TLVs sho= uld
be derived from the EAP message length and length of the TLS data.

12.  Section 4.2 - I understand what is happening with an EM= PTY TEAP
message
being sent in response to a list of TLVs that are marked optional,
however I
question if the statement that is MUST be sent is correct.  = There are two
reasons for the question:

a.  A server could send a RESULT TLV in response to a messag= e from the
client that contains no TLVs that are either mandatory or recognized.<= /div>
[HZ] Good catch. We will clarify that.

b.  I am (very slightly) worried about the fact that the res= ponse is not
authenticated by the tunnel in many manner.  I would think t= hat a NAK to
any
of the TLVs would be a better response if no other TLV messages are to= be
sent.  The entity sending the TLV should know if it marked i= t as mandatory
or not.  The NAK is not the same as an Error TLV.
[HZ] Agree. A NAK  TLV should be sent in this case. We will clarify= .

13.  Section 4.2.2 - Should "Type" in the outdente= d list be "TLV Type"?
s/filed/field/
[HZ] Yes. We will correct that.

14.  Section 4.2.2 - Can multiple Authority-ID TLVs be trans= mitted to a
peer?
[HZ] No. It is mentioned in Section 4.3, Table of TLVs rules.


15.  Section 4.2.3 - I assume that there should only be one = Identity-Type
TLV in a TEAP packet.  Should a request for authentication b= e present in
the
packet as well?  If multiple are allowed then information ab= out how to
treat
this should be included.  What should the peer respond with = if it does
have
an identity of the type?  This is not explicitly stated.
[HZ] That's correct, only one Identity-Type TLV is allowed.The requested= Identity type  MUST comes with an EAP request or Basic-Password-= Auth-Req. 
If the peer has the requested identity type, it should send back the sam= e identity type TLV in the response. We missed this and will add this clari= fication.

16.  Section 4.2.4 - I don't understand the default in the e= vent that an
unknown value is sent in the status field.  If there is an E= RROR TLV in
the
message, should I not use that error code rather than change it?
[HZ] No. The error code in the Error TLV if being sent with the Result T= LV might mean something, but since the peer doesn't understand the Status f= ield, and most likely will not understand the error code. Sending back Unexpected_TLVs_Exchanged error code is = probably appropriate.


17. Section 4.2.6 - Do we need a discussion about how to produce/deal = with
vender specific errors?  Do you expect that vender specific = TLVs will have
an error mechanism built into them to return an error code?
[HZ] We expect the vendor TLV will have its own error handling mechanism= or use the standard error codes defined.


18. Section 4.2.8 - Do we need to talk about the question of having so= me
Vender TLVs be marked as mandatory and others not.  Are we u= sing the same
TLV structure with the same rules for mandatoriness.  If the= mandatory bit
is set, does that mean that I need to recognize the vendor-id or all
combinations of vender-id/Vender-TLV type?
[HZ] Yes. If the mandatory bit is set on the V= endor-Speific TLV, then the peer need to recognize the vendor ID and all co= mbination of the vendor TLVs. The Vendor TLV format is up to the vendor to = define, as specified by the current draft.


19.  Section 4.2.9 - After reading this, sketching out some = scenarios and
so
forth, I find that I do not like the text and result being pushed here= at
all.  My problems start, in some respects, with the name of = the TLV as it
does not map to how I would like to see this TLV treated.  I= would propose
the following set of changes:
a) The name of the TLV be changed from Request-Action TLV to
Provisional-Result TLV
[HZ] I am open with the name change, but think Request-Action probably c= apture the essence better.

b) It needs to be made clear that the TLV can be sent from either the<= /div>
server
to the peer or the peer to the server.  It is my belief that= presently it
is
only sent from the peer to the client and only in response to a succes= sful
Result TLV.
[HZ] Ok. I agree that we can extend that to be bidirectional and for eit= her success and failure Result TLV.

c)  The receiving entity MUST process the TLV.
[HZ] Ok.

d)  The processing for the TLV is as follows:
   i) The entity MAY choose to process (or start?) any of th= e TLVs that
are
included in the message.
  ii) If the entity chooses NOT to process any TLV in the li= st, the
Provisional-Result TLV is treated as a Result TLV with the code "= status"
  iii) If multiple Provisional-Result TLVs are in the body, = the session
can
continue if ANY of TLV in any Provisional-Result TLV is processed.
  iv) If multiple Provisional-Result TLVs are in the body an= d no sub-TLV
is
processed, then the most fatal status should be used.  If a = status is
found
which is not understood by the entity, then it should be treated as a<= /div>
fatal
TLV.
[HZ] Ok.


The current text allows for the following:
The server sends a Success to the peer
The peer says please do this or go to fatal
The server sends a clear success outside of the tunnel.
[HZ] That's not correct. The last exchange in the tunnel should be an ag= reed upon Result TLV exchange, before the tunnel is torn down and a clear t= ext EAP success is sent.

I wonder if the capability needs to be added to say, please start this=
TLV.
So that a server can say, If you don't start a Channel binding TLV, I = will
make this a failure return code, if you want to start the channel bind= ing
TLV then I am open to giving you a success return code.
OK - so this is kind of there, but only one value can be placed there.
One cannot say do either an EAP negotiation or process this TLV.
[HZ] That's true. Only one request.

20. Section 4.2.12.4 - What does it mean to have an I-ID validation
enforcement for PAC session renewal?  Does it mean that the = final message
is
not sent unless an appropriate ID is presented?  Does it hav= e to be an EAP
authentication or is password based authentication sufficient? &n= bsp;Should a
PAC
be invalidated on the server side (oops how do you do that) if it a PA= C is
presented and then the appropriate ID is not given?
[HZ] The I-ID in the PAC is used to validate that the correct user is being= authenticated and using his PAC. If they don't match, then the authenticat= ion will be rejected as if the authentication failed, with the normal flow = including the final Result TLV and clear text EAP failure being sent. It can be either the EAP authentication= or the password based authentication. The PAC is not invalidated if the I-= ID doesn't match the authenticated identity, the authentication will be rej= ected.

21.  In section 4.2.12.6 - Is this supposed to be at the top= level or
embedded in the PAC-TLV?
[HZ] Yes.


22.  In section 4.2.16 - PKCS#7 has been superseded by CMS -= the
references
should be to CMS and not to PCKS#7
[HZ] Ok with me. Any other feedback from the WG?

23.  In IANA - Need to add the Request-Action TLV to the lis= t of status
codes
[HZ] It is included in the Result TLV, Interme= diate Result TOV status code registry in the IANA section. I thin= k it makes sense to have the same one.

24.  In IANA - Should the Vender ID of the Vender-Specific T= LV be kept in
a
registry?
[HZ] Vendor ID per the draft, is the SMI Network Management Private Enterprise Code already managed by IANA.=  

Jim

-----Original Message-----
Alan DeKok
Sent: Tuesday, September 25, 2012 8:04 AM
Subject: [Emu] Looking for reviewers
   We'd like to get the final two documents into last call b= efore the
next
meeting.  Therefore, we're looking for reviewers:
   Please post reviews to the list.  If all goes w= ell, we can get updated
documents issued before the next meeting.
   Thanks to everyone for their help.
   Alan DeKok.
_______________________________________________
Emu mailing list

_______________________________________________
Emu mailing list

--_000_645B00545719594A88ADF4221831FD3813D697xmbrcdx14ciscocom_-- From hzhou@cisco.com Thu Oct 4 14:55:43 2012 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08D5E21F8616 for ; Thu, 4 Oct 2012 14:55:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HTuI1xujtj2N for ; Thu, 4 Oct 2012 14:55:41 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id D4E8F21F8611 for ; Thu, 4 Oct 2012 14:55:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1981; q=dns/txt; s=iport; t=1349387741; x=1350597341; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=rrJgD4J7YVzev3g9YIyaIs7yzH0ti9h+a+cyVJ6OV0c=; b=Vg7dvpXmpH7LDyEKMFS/R1+tWWyZUqfgcEiJXhyZDfK1Vx0ONIP2CR8K taICZsU2hK7lJI4eQ7TfPvZXOao7nhS5JRLfERsI53AUmUJjOr8r9jM27 Oc4LpAm2NxgoLPpF/tzxs/0kHrGZJ3tbmwMqFDNs+WPvrz0Oqc/mFPEVZ E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAH8FblCtJV2Y/2dsb2JhbABFvxaBCIIiAQQBAQEPASc0HQEIDhQUNwslAQEEARIIGodjC5gToAsEkHtgA6QsgWmCbYIX X-IronPort-AV: E=Sophos;i="4.80,537,1344211200"; d="scan'208";a="128494776" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-3.cisco.com with ESMTP; 04 Oct 2012 21:55:40 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q94LteZJ010618 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 4 Oct 2012 21:55:40 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.202]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0318.001; Thu, 4 Oct 2012 16:55:39 -0500 From: "Hao Zhou (hzhou)" To: Jim Schaad , "emu@ietf.org" , "draft-ietf-emu-eap-tunnel-method@tools.ietf.org" Thread-Topic: [Emu] More comments for eap-tunnel-method Thread-Index: Ac2fNa8k+p3Xv8iySJGSGMwihVHFRQDTa+8A Date: Thu, 4 Oct 2012 21:55:39 +0000 Message-ID: <645B00545719594A88ADF4221831FD3813D8C0@xmb-rcd-x14.cisco.com> In-Reply-To: <009301cd9f35$b001e650$1005b2f0$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 x-originating-ip: [64.101.214.207] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19238.000 x-tm-as-result: No--33.201700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <8EDAC2E96CDBF547804AE937CF51C541@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Emu] More comments for eap-tunnel-method X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 21:55:43 -0000 Jim: Thanks for the review. Please see my comments below. On 9/30/12 2:01 PM, "Jim Schaad" wrote: >1. Should the Message Length field be present if the TLS Data field is >absent? [HZ] According to the text in the draft, the message length field should only be present if the L bit is set, usually for fragmented packets. In those cases, the TLS data field will be present, not absent. The only case TLS data will be absent is when empty TEAP packet it is used to indicate TEAP acknowledgement for either a fragmented message, a TLS Alert message or a TLS Finished message. So the message length field is not needed. We can clarify that in the draft. > >2. There is nothing to say which TLVs can and cannot occur in the Outer >TLVs in any easily findable method. Either a table or the string outer in >descriptions would be helpful. As an example, does the Authority-ID TLV >in >the outer TLV make sense? [HZ] We will add that table. > >3. I have gone through the fragmentation and did an implementation rather >than just reading it. The questions that I have on it now are slightly >different. Do TLVs need to be on a fragment boundary? Or do we just build >the entire message, fragment it into convenient sizes regardless of the >actual content of the message contents and sent the pieces across? If so >then the text should probably be re-written to be clearer. Specifically, >the message length is not useful for allocating the buffer on the first >round trip of messages where one can have a TLV added in to the content. >[HZ] Message length covers the whole TEAP packet even if fragmented. TLVs >do not need to be on a fragment boundary. Just build the whole message >contents and send the pieces across. We will provide some text to clarify >this. > > >_______________________________________________ >Emu mailing list >Emu@ietf.org >https://www.ietf.org/mailman/listinfo/emu From hzhou@cisco.com Thu Oct 4 15:06:00 2012 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C26E21F856F for ; Thu, 4 Oct 2012 15:06:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y05A7HlApYJo for ; Thu, 4 Oct 2012 15:05:59 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 5ADB821F8567 for ; Thu, 4 Oct 2012 15:05:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2113; q=dns/txt; s=iport; t=1349388359; x=1350597959; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=qNyFXQdP855gNN+Tfug1olB2j2Z2LgBjYm4Y7eAiPaI=; b=WLJGBQ5FIEoyflU1qJqt4JnpuB/Mjo8gQk1+tism3+GXWVR1RwBVcx0Q g2Zg99CO5AQj9eYKhs272BSz7nH1J3TbKNbhwnXuVpqg1QFuJOHWZWFDY mLxNia8kghuhGqluk4B7FhA8vbHugbATXyhsvQmQ/UH4OOakLXe+pszJA w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EADoHblCtJV2c/2dsb2JhbAA8Cb8WgQiCIgEEAQEBDwEnNB0BCA4UDgY3CyUBAQQBEggah2MLmBagCwSLT4Jtgj9gA5I4kXSBaYJtghc X-IronPort-AV: E=Sophos;i="4.80,537,1344211200"; d="scan'208";a="125464819" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-9.cisco.com with ESMTP; 04 Oct 2012 22:05:58 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id q94M5wZB003475 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 4 Oct 2012 22:05:58 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.202]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0318.001; Thu, 4 Oct 2012 17:05:58 -0500 From: "Hao Zhou (hzhou)" To: Jim Schaad , "emu@ietf.org" , "draft-ietf-emu-eap-tunnel-method@tools.ietf.org" Thread-Topic: [Emu] More COmments 2 on eap-tunnel-method Thread-Index: Ac2f9v+FDIoykt+NRVmWduL9qgMM2ACjc+4A Date: Thu, 4 Oct 2012 22:05:57 +0000 Message-ID: <645B00545719594A88ADF4221831FD3813D8D6@xmb-rcd-x14.cisco.com> In-Reply-To: <00e401cd9ff7$b52212a0$1f6637e0$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 x-originating-ip: [64.101.214.207] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19238.000 x-tm-as-result: No--37.716100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <76DC7103999D0B4EAF58BD12B76B7A53@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Emu] More COmments 2 on eap-tunnel-method X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 22:06:00 -0000 Jim: Please see comments below. On 10/1/12 1:10 PM, "Jim Schaad" wrote: >I found two that I forgot to include in the last message > >1. When exporting the user-id, does there need to be a way to distinguish >at export time between the different types of ids that are authenticated >by >the server? This does not seem to be an issue on the peer as it will only >do mutual authentication to servers and thus only have server ids, >however a >server may authenticate to different types of identities on the peer. At >the moment we have identified user and machines as types of entities to be >identified, I suppose in the future we could add Ewoks as a different type >of entity that could be identified. However the export function of >user-ids >does not make a distinction between the different types of authenticated >entities. Should it do so or should it just export user authentications? [HZ] It helps to export the identities as well as the corresponding identity types (from the Identity Type TLV). Will add text. > >2. Is there a map of TLVs that should not be sent together or need to be >processed in a specific order? The case I was looking at was for the >Identity TLV and the EAP TLV. Is there a difference in how a peer should >react for the following? > > Identity TLV (Send me a machine Identity), EAP TLV (Start the EAP type >XX) > EAP TLV (Start EAP type XXX), Identity TLV (Send me a machine Identity) > >Or should these two TLVs never occur in a single message? [HZ] We had some discussion in WG and take the design principal of TLV ordering should not matter. We disallow simultaneous EAP inner methods and/or with Basic Password Authentication, so rest of the TLVs order should not matter. If it does matter, it should be a nested TLV, as in Result TLV and Request-Action TLV. Need to add text to disallow Inner EAP method with parallel Basic Password Authentication TLV. > >Jim > > >_______________________________________________ >Emu mailing list >Emu@ietf.org >https://www.ietf.org/mailman/listinfo/emu From hzhou@cisco.com Thu Oct 4 20:55:40 2012 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A3281F0C61 for ; Thu, 4 Oct 2012 20:55:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2u6cjg4ISREv for ; Thu, 4 Oct 2012 20:55:38 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 359891F0C5C for ; Thu, 4 Oct 2012 20:55:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10992; q=dns/txt; s=iport; t=1349409338; x=1350618938; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=+3lhH6ndsyYZ9LDsotdwYt7lL5zJGLNRDDi0FoeRPeQ=; b=Ok3SSi3LO+1I1jbQrqtm+timYQVjdHyJJnVdOBTR/C86HZA3H9ePtx8D +m1SOoK/nRZ2BIDsacBTsaqcexnzi/Zw9H3vyMTQtDgDihHlSeYIKOdUE JFUJM9YdgBHSM9KqlT3uaOoEHFgKYYWN47C4fwHHHgneLfejVoVNlYEho c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArIHACFZblCtJV2d/2dsb2JhbABFgkuEX4FEs22CQ4EIgiIBBAEBAQ8BWx0BCA4UCxIuCxQRAQEEARIIGodjC5g8oAkEjhqCTWADkjiRdIFpgS6BP4FcIxg X-IronPort-AV: E=Sophos;i="4.80,538,1344211200"; d="scan'208,217";a="125534314" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-9.cisco.com with ESMTP; 05 Oct 2012 03:55:37 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id q953tbeg014113 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 5 Oct 2012 03:55:37 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.202]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.001; Thu, 4 Oct 2012 22:55:37 -0500 From: "Hao Zhou (hzhou)" To: Jim Schaad , "emu@ietf.org" Thread-Topic: [Emu] IMSK derivation issue Thread-Index: Ac2eg6tSqiKv0jgeQPyrmZ8Se1AN6QEMfxiA Date: Fri, 5 Oct 2012 03:55:37 +0000 Message-ID: <645B00545719594A88ADF4221831FD3813D9E9@xmb-rcd-x14.cisco.com> In-Reply-To: <008001cd9e83$ae8b6dd0$0ba24970$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 x-originating-ip: [10.98.51.18] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19238.000 x-tm-as-result: No--36.964100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_645B00545719594A88ADF4221831FD3813D9E9xmbrcdx14ciscocom_" MIME-Version: 1.0 Subject: Re: [Emu] IMSK derivation issue X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 03:55:40 -0000 --_000_645B00545719594A88ADF4221831FD3813D9E9xmbrcdx14ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Jim: Thanks for pointing out this issue. How about the following text with sligh= t modification with policy control from both sides to prevent downgrade att= ack. Added text in red. 1. The first sender of the Crypto-Binding TLV needs to create it as follows: a) If the EMSK is not available, then it computes the Compound MAC as is currently documented b) If the EMSK is available, and the sender's policy accepts MSK based MAC,= then it computes two Compound MAC values. The first is computed with the EMSK as is currently documented. The second is a Compound MAC that uses the MSK and the Buffer is modified by adding the string "EMSK" (or something similar). Both MACs are then send to the other Side. c) If the EMSK is available, but the sender's policy doesn't allow downgrad= e to MSK generated MAC, then it should only send EMSK based MAC. 2. The second sender of the Crypto-Binding TLV then: a) If the EMSK is available and an EMSK Compound MAC was sent validates it and creates a response using the EMSK and sends it back b) If the EMSK is not available and an EMSK compound MAC was sent - it validates the MSK using the modified BUFFER string and sends back a MSK generated response c) If no EMSK Compound MAC was sent, and its policy accepts MSK based MAC, = then it validates using the MSK - and if successful generates and returns an MSK generated response. d) If no EMSK Compound MAC was sent, and its policy doesn't accept MSK base= d MAC, then it handles like an invalid crypto-binding TLV with fatal error. On 9/29/12 4:47 PM, "Jim Schaad" > wrote: I agree that the IMSK needs to take into account the existence of the EMSK, however the current text has a severe problem with the way that it is done. It assumes that if the EMSK is exportable on one side, then it will be exportable on the other side as well. I don't believe this is the case. In order for this to work, and to prevent the downgrade attack by a MITM, I believe that the following changes need to be made: 1. The first sender of the Crypto-Binding TLV needs to create it as follows: a) If the EMSK is not available, then it computes the Compound MAC as is currently documented b) If the EMSK is available, then it computes two Compound MAC values. The first is computed with the EMSK as is currently documented. The second is = a Compound MAC that uses the MSK and the Buffer is modified by adding the string "EMSK" (or something similar). Both MACs are then send to the other side. 2. The second sender of the Crypto-Binding TLV then: a) If the EMSK is available and an EMSK Compound MAC was sent validates it and creates a response using the EMSK and sends it back b) If the EMSK is not available and an EMSK compound MAC was sent - it validates the MSK using the modified BUFFER string and sends back a MSK generated response c) If no EMSK Compound MAC was sent, it validates using the MSK - and if successful generates and returns an MSK generated response. If the EMSK compound MAC is removed in transit, then the MSK validated valu= e will fail as the BUFFER string is not modified to recognize that an EMSK Compound MAC was sent. 3. The first send then validates the returned values by: a) If it sent an EMSK Compound value - attempt to validate using the EMSK value. If it fails then go to b else succeed b) Validate using the MSK value using the unmodified buffer. Both sides will then need to remember if the MSK or EMSK value was used for validation in this step, but that is no different than the fact that the MS= K is currently being remembered. Jim _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu --_000_645B00545719594A88ADF4221831FD3813D9E9xmbrcdx14ciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <5869AAD1E2A2FB4C991F2983EDE8BD0B@cisco.com> Content-Transfer-Encoding: quoted-printable
Jim:

Thanks for pointing out this iss= ue. How about the following text with slight modification with policy contr= ol from both sides to prevent downgrade attack. Added text in red.

1. The first sender of the Crypto-Bind= ing TLV needs to create it as
follows:
a) If the EMSK is not available, then = it computes the Compound MAC as is
currently documented
b) If the EMSK is available, and= the sender's policy accepts MSK based MAC, t= hen it computes two Compound MAC values. The
first is computed with the EMSK as is = currently documented. The second is a
Compound MAC that uses the MSK and the= Buffer is modified by adding the
string "EMSK" (or something = similar). Both MACs are then send to the other
Side.
c) If the EMSK is available, but the send= er's policy doesn't allow downgrade to MSK generated MAC, then it should on= ly send EMSK based MAC. 

2. The second sender of the Crypto-Bin= ding TLV then:
a) If the EMSK is available and an EMS= K Compound MAC was sent validates it
and creates a response using the EMSK = and sends it back
b) If the EMSK is not available and an= EMSK compound MAC was sent - it
validates the MSK using the modified B= UFFER string and sends back a MSK
generated response
c) If no EMSK Compound MAC was sent, and its p= olicy accepts MSK based MAC, then it validates using the MSK - and i= f
successful generates and returns an MS= K generated response.
d) If no EMSK Compound MAC was se= nt, and its policy doesn't accept MSK based MA= C, then it handles like an invalid crypto-binding TLV with fatal err= or.

On 9/29/12 4:47 PM, "Jim Schaad&q= uot; <ietf@augustcellars.com> wrote:

I agree that the IMSK needs to take into account the existence of the = EMSK,
however the current text has a severe problem with the way that it is = done.
It assumes that if the EMSK is exportable on one side, then it will be=
exportable on the other side as well.  I don't believe this = is the case.

In order for this to work, and to prevent the downgrade attack by a MI= TM, I
believe that the following changes need to be made:

1.  The first sender of the Crypto-Binding TLV needs to crea= te it as
follows:
a) If the EMSK is not available, then it computes the Compound MAC as = is
currently documented
b) If the EMSK is available, then it computes two Compound MAC values.=   The
first is computed with the EMSK as is currently documented.  = ;The second is a
Compound MAC that uses the MSK and the Buffer is modified by adding th= e
string "EMSK" (or something similar).  Both MACs a= re then send to the other
side.

2.  The second sender of the Crypto-Binding TLV then:
a) If the EMSK is available and an EMSK Compound MAC was sent validate= s it
and creates a response using the EMSK and sends it back
b) If the EMSK is not available and an EMSK compound MAC was sent - it=
validates the MSK using the modified BUFFER string and sends back a MS= K
generated response
c) If no EMSK Compound MAC was sent, it validates using the MSK - and = if
successful generates and returns an MSK generated response.  = ;

If the EMSK compound MAC is removed in transit, then the MSK validated= value
will fail as the BUFFER string is not modified to recognize that an EM= SK
Compound MAC was sent.

--_000_645B00545719594A88ADF4221831FD3813D9E9xmbrcdx14ciscocom_-- From ietf@augustcellars.com Sun Oct 7 20:45:31 2012 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5C3521F8767 for ; Sun, 7 Oct 2012 20:45:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.192 X-Spam-Level: X-Spam-Status: No, score=-2.192 tagged_above=-999 required=5 tests=[AWL=-0.452, BAYES_20=-0.74, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fMot8OyCn+Wl for ; Sun, 7 Oct 2012 20:45:30 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id ACFF421F8760 for ; Sun, 7 Oct 2012 20:45:30 -0700 (PDT) Received: from Tobias (winery.augustcellars.com [206.212.239.129]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id CFE3E2CA19; Sun, 7 Oct 2012 20:45:26 -0700 (PDT) From: "Jim Schaad" To: "'Stefan Winter'" , References: <00e601cda1a3$5a230c80$0e692580$@augustcellars.com> <506D282C.6040909@restena.lu> In-Reply-To: <506D282C.6040909@restena.lu> Date: Sun, 7 Oct 2012 20:43:57 -0700 Message-ID: <010701cda507$27d9ed40$778dc7c0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQETIlXkRdUEOAmqRJpEVJ8MvvMTfAJlURHymRCe5mA= Content-Language: en-us Subject: Re: [Emu] Client Auth with TLS X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2012 03:45:31 -0000 Stefan, Thanks for the input. For the authors, Does this need to be documented as a mode of operation for TEAP or are = we going to say that this is not a supported mode? Jim > -----Original Message----- > From: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org] On Behalf Of > Stefan Winter > Sent: Wednesday, October 03, 2012 11:10 PM > To: emu@ietf.org > Subject: Re: [Emu] Client Auth with TLS >=20 > Hi, >=20 > > 3. The client provides the certificate in a protected manner - I = had > > a problem at this point because I don't know enough TLS to properly = go > > through this scenario, and I could not really read documents while > > driving. If the encrypted certificate extension was used, then = there > > is no issue as the protected certificate would be passed in the > > initial handshake. However if the client starts the negotiation and > > then restarts it after it is encrypted, I don't know if this occurs before or > after the finish message. > > If it starts after the finish method then there is an issue with > > having the server close an anonymous session if the client is then > > going to provide the certificate encrypted. Help on how this works would > be appreciated. >=20 > FWIW, RFC5216 (EAP-TLS) already has provisions for a protected client > credential exchange (for client privacy protection reasons). I didn't = ever see it > used (anyone?), but it's clearly a foreseen mode of operation. The = text > describing this is in section 2.1.4: >=20 > "... In order to avoid disclosing the peer username, an EAP-TLS = peer > configured for privacy MUST negotiate a TLS ciphersuite supporting > confidentiality and MUST provide a client certificate list = containing > no entries in response to the initial certificate_request from the > EAP-TLS server. >=20 > An EAP-TLS server supporting privacy MUST NOT treat a certificate > list containing no entries as a terminal condition; instead, it = MUST > bring up the TLS session and then send a hello_request. The > handshake then proceeds normally; the peer sends a client_hello and > the server replies with a server_hello, certificate, > server_key_exchange, certificate_request, server_hello_done, etc. >=20 > For the calculation of exported keying material (see Section 2.3), > the master_secret derived within the second handshake is used. >=20 > An EAP-TLS peer supporting privacy MUST provide a certificate list > containing at least one entry in response to the subsequent > certificate_request sent by the server. If the EAP-TLS server > supporting privacy does not receive a client certificate in = response > to the subsequent certificate_request, then it MUST abort the > session. > " >=20 > There is a sequence diagram shortly afterwards which shows clearly = that the > "first" negotiation ends with a 'finished' and then immediately a new > 'hello_request' - all in one EAP message. >=20 > Greetings, >=20 > Stefan >=20 > > > > Jim > > > > > > _______________________________________________ > > Emu mailing list > > Emu@ietf.org > > https://www.ietf.org/mailman/listinfo/emu > > >=20 >=20 > -- > Stefan WINTER > Ingenieur de Recherche > Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education = Nationale et de > la Recherche 6, rue Richard Coudenhove-Kalergi > L-1359 Luxembourg >=20 > Tel: +352 424409 1 > Fax: +352 422473 From ietf@augustcellars.com Sun Oct 7 21:54:43 2012 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0665D21F86B7 for ; Sun, 7 Oct 2012 21:54:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.739 X-Spam-Level: X-Spam-Status: No, score=-1.739 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e9JzObQEh4Vn for ; Sun, 7 Oct 2012 21:54:33 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1D14C21F8581 for ; Sun, 7 Oct 2012 21:54:32 -0700 (PDT) Received: from Tobias (173-12-183-193-oregon.hfc.comcastbusiness.net [173.12.183.193]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 4E6512CA07; Sun, 7 Oct 2012 21:54:31 -0700 (PDT) From: "Jim Schaad" To: "'Hao Zhou \(hzhou\)'" References: <645B00545719594A88ADF4221831FD3813D697@xmb-rcd-x14.cisco.com> In-Reply-To: <645B00545719594A88ADF4221831FD3813D697@xmb-rcd-x14.cisco.com> Date: Sun, 7 Oct 2012 21:53:03 -0700 Message-ID: <010c01cda510$cd743fe0$685cbfa0$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_010D_01CDA4D6.2129B330" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFffQCp54UCtsWCBlsjsXo3TochOpiLFKzg Content-Language: en-us X-Mailman-Approved-At: Sun, 07 Oct 2012 22:11:13 -0700 Cc: emu@ietf.org Subject: Re: [Emu] Review of draft-ietf-emu-eap-tunnel-method-00 X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2012 04:54:43 -0000 This is a multipart message in MIME format. ------=_NextPart_000_010D_01CDA4D6.2129B330 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hao, comments in line =20 From: Hao Zhou (hzhou) [mailto:hzhou@cisco.com]=20 Sent: Thursday, October 04, 2012 10:39 AM To: Jim Schaad Cc: emu@ietf.org Subject: Re: [Emu] Review of draft-ietf-emu-eap-tunnel-method-00 =20 Jim: =20 Thanks very much for your detailed review. Please see the comments = below. We will respond to your other emails shortly.=20 =20 On 9/28/12 9:18 PM, "Jim Schaad" wrote: =20 1. In section 3.2.3, it says that a new PAC can be requested after a = full TLS handshake. Can one be requested following an abbreviated handshake? Or do you just re-use the existing PAC? [HZ] RFC5077 does not specify that client can request a new ticket after sending the TLS ticket, if the client is resuming a session using the session ticket, then it cannot request a new session ticket based on resumed session. We will add some language to clarify that it is not allowed. =20 2. Section 3.3 s/descried/described/ [HZ] Ok. =20 3. Section 3.4 - Is it possible to have multiple server ids after the authentication - one from the tunnel and others from the inner EAP methods. I realize that most EAP methods don't send a sender id, but some (IBAKE for example) currently do. Also, the client might have an idea of what the sender id is from configuration. If so, do these all need to get = exported as server-id values? [HZ] Good catch. We will add a sentence similar to peer-ID, where = multiple server IDs need to be exported. =20 4. In section 3.6.1 - It is not clear that an EAP-Failure packet is sent when 1) the server sends a fatal alert to the peer, 2) the peer requests = a restart via a ClientHello and 3) the peer declines to permit the restart to occur. [HZ] We will clarify that EAP-Failure packet will be sent in those = cases. =20 [JLS] Just to be clear =96 this is a single case not three cases. It is = a sequence of events that should lead to the EAP-Failure packet. =20 =20 5. In section 3.6.1 - Is the restart only an issue for fatal alerts, or is it a problem for all alerts? [HZ] Restart is only allowed for non-fatal alerts, per TLS RFC. "Upon transmission or receipt of a fatal alert message, both parties = immediately close the connection.", so restart is not desired in this case. We will clarify that restart is only allowed in non-fatal alert cases. =20 [JLS] It may just be me, but this seems to be a bit odd from my point = of view. It is not clear that in the event of a non-fatal alert that there = is any need for the two parties to start a new negotiation that would ensue upon getting a Hello restart. There is a question in terms of closing = the connection if the TLS document means just the TLS session or the encapsulating transport is to be shut down as well. If it means the = latter then it makes sense that you could request a new TLS negotiation without having to build all of the EAP transport frame work (i.e the entire = RADIUS session?). =20 Please re-look at this and ensure that this is really what you mean. =20 =20 6. In section 3.6.2 - Why SHOULD not MUST send clear text EAP-Failure? [HZ] We will change it to MUST. =20 7. In section 3.6 - do we need to discuss the question of errors in the outer EAP layer that is carrying the TLVs which contain the TLS content? This is a distinct location from the current list of where to handle errors. There is going to be a distinction (possibly) between errors that occur during phase 1 and errors during phase 2. Should the error return = reflect if the error occurred inside or outside of the TLS tunnel? [HZ] Good catch. We will add some language to clarify dealing with outer packet errors. Something like: 1. If Outer TLVs are wrong, they will be ignored. 2. If others (version, length, flags, etc.) are wrong, the entire EAP packet will be ignored. =20 [JLS} Looks reasonable. =20 =20 =20 8. In section 3.8 - I have the following questions a) In the text "The request MAY be issued", I don't understand the MAY = at this point. Is it supposed to say that the request can be issued either before or after the authentication has finished, or is it saying that = the peer has the option of issuing or not issuing the request, but must wait until the authentication level has been reached? [HZ] It's the later. How about add "only" in front "after the peer has determined that..."? =20 [JLS] That does deal with the immediate issue. However the fact that = you need to do the Crypt-Binding TLV for tunnel validation does imply that = an EAP method that generates a key is a requirement before being able to = get a PAC. Is this what is intended? Should you be able to get a PAC just = from validating the tunnel with the server and knowing the servers name from = it=92s certificate? =20 b) If a peer issues a PAC request, but the server has not yet satisfied it's policy, does the server remember the PAC request and send back the response after the internal policy has been satisfied or should it send back an error saying that policy has not yet been satisfied along with additional TLVs to attempt and satisfy that policy? [HZ] The server remembers that and issues the PAC after its policy is satisfied. We will clarify that. =20 c) What should a peer do if it receives a PAC TLV with an unknown attribute? [HZ] Ignore that. [JLS] Please be detailed =96 ignore the attribute or ignore the PAC. =20 =20 9. In section 3.9 - there is leaking on the POP, but not on identity at this point. I believe that there needs to be a requirement that an EAP method needs to be run which will provide an identity proof on the = client prior to a certificate being issued. You may or may not then want to = add text that says that the subject name(s) in the certificate request need = to be checked against the set of authenticated identities prior to the certificate being issued. [HZ] Good point. We will add some that. =20 =20 10. In section 3.10 - It is unclear to me if the Server Unauthenticated mode is because the server or the peer is unauthenticated at this point in time. The cipher suite would indicate that the server is not authenticated, however what about the case of the server providing an authenticated id = to the peer, but the peer is unable to validate the identity of the server for some reason. This is also a Server Unauthenticated mode. [HZ] Yes. It covers both cases. We will add language to clarify that. =20 =20 11. In section 4.1 - I would like to see a discussion that says that = the following situation can never occur. The initial EAP message from the peer to the server (or the response) plus the Outer TLV data plus the EAP message headers exceeds the underlying packet size of the transport. In the = event that it does, I am not sure how one finds the Outer TLV data start and where the fragmentation would occur to get the Outer TLV data between the peer and the server. [HZ] I think it should work as defined. The start of the Outer TLVs = should be derived from the EAP message length and length of the TLS data. [JLS] I have gotten a better understanding =96 I may have suggested text elsewhere =20 =20 12. Section 4.2 - I understand what is happening with an EMPTY TEAP message being sent in response to a list of TLVs that are marked optional, however I question if the statement that is MUST be sent is correct. There are = two reasons for the question: =20 a. A server could send a RESULT TLV in response to a message from the client that contains no TLVs that are either mandatory or recognized. [HZ] Good catch. We will clarify that. =20 b. I am (very slightly) worried about the fact that the response is not authenticated by the tunnel in many manner. I would think that a NAK to any of the TLVs would be a better response if no other TLV messages are to = be sent. The entity sending the TLV should know if it marked it as = mandatory or not. The NAK is not the same as an Error TLV. [HZ] Agree. A NAK TLV should be sent in this case. We will clarify. =20 13. Section 4.2.2 - Should "Type" in the outdented list be "TLV Type"? s/filed/field/ [HZ] Yes. We will correct that. =20 14. Section 4.2.2 - Can multiple Authority-ID TLVs be transmitted to a peer? [HZ] No. It is mentioned in Section 4.3, Table of TLVs rules. [JLS} That says that you cannot send multiple Authority IDs in a single message, what about in multiple messages? =20 =20 =20 15. Section 4.2.3 - I assume that there should only be one = Identity-Type TLV in a TEAP packet. Should a request for authentication be present in the packet as well? If multiple are allowed then information about how to treat this should be included. What should the peer respond with if it does have an identity of the type? This is not explicitly stated. [HZ] That's correct, only one Identity-Type TLV is allowed.The requested Identity type MUST comes with an EAP request or = Basic-Password-Auth-Req.=20 If the peer has the requested identity type, it should send back the = same identity type TLV in the response. We missed this and will add this clarification. =20 16. Section 4.2.4 - I don't understand the default in the event that an unknown value is sent in the status field. If there is an ERROR TLV in the message, should I not use that error code rather than change it? [HZ] No. The error code in the Error TLV if being sent with the Result = TLV might mean something, but since the peer doesn't understand the Status field, and most likely will not understand the error code. Sending back Unexpected_TLVs_Exchanged error code is probably appropriate. [JLS] I was assuming that the client did understand the error code, otherwise I agree that using a well understood error is correct = behavior. =20 =20 17. Section 4.2.6 - Do we need a discussion about how to produce/deal = with vender specific errors? Do you expect that vender specific TLVs will = have an error mechanism built into them to return an error code? [HZ] We expect the vendor TLV will have its own error handling mechanism = or use the standard error codes defined. =20 =20 18. Section 4.2.8 - Do we need to talk about the question of having some Vender TLVs be marked as mandatory and others not. Are we using the = same TLV structure with the same rules for mandatoriness. If the mandatory = bit is set, does that mean that I need to recognize the vendor-id or all combinations of vender-id/Vender-TLV type? [HZ] Yes. If the mandatory bit is set on the Vendor-Speific TLV, then = the peer need to recognize the vendor ID and all combination of the vendor = TLVs. The Vendor TLV format is up to the vendor to define, as specified by the current draft. =20 =20 19. Section 4.2.9 - After reading this, sketching out some scenarios = and so forth, I find that I do not like the text and result being pushed here = at all. My problems start, in some respects, with the name of the TLV as = it does not map to how I would like to see this TLV treated. I would = propose the following set of changes: a) The name of the TLV be changed from Request-Action TLV to Provisional-Result TLV [HZ] I am open with the name change, but think Request-Action probably capture the essence better. =20 b) It needs to be made clear that the TLV can be sent from either the server to the peer or the peer to the server. It is my belief that presently = it is only sent from the peer to the client and only in response to a = successful Result TLV. [HZ] Ok. I agree that we can extend that to be bidirectional and for = either success and failure Result TLV. =20 c) The receiving entity MUST process the TLV. [HZ] Ok. =20 d) The processing for the TLV is as follows: i) The entity MAY choose to process (or start?) any of the TLVs that are included in the message. ii) If the entity chooses NOT to process any TLV in the list, the Provisional-Result TLV is treated as a Result TLV with the code "status" iii) If multiple Provisional-Result TLVs are in the body, the session can continue if ANY of TLV in any Provisional-Result TLV is processed. iv) If multiple Provisional-Result TLVs are in the body and no sub-TLV is processed, then the most fatal status should be used. If a status is found which is not understood by the entity, then it should be treated as a fatal TLV. [HZ] Ok. =20 =20 The current text allows for the following: The server sends a Success to the peer The peer says please do this or go to fatal The server sends a clear success outside of the tunnel. [HZ] That's not correct. The last exchange in the tunnel should be an = agreed upon Result TLV exchange, before the tunnel is torn down and a clear = text EAP success is sent. =20 [JLS] Just to be clear, you are saying that the conversation will look = like =20 Server =E0 Result TLV (Success) Request-Action (Status-Bletch, foobar) =DF Client Server =E0 Result TLV (Success) Result TVL (Success) =DF Client (knows that the server = must not be willing to do what was asked. =20 The server COULD send back the Bletch code if it decides to process the Request-Action TLV from the client. The client could send back Bletch = even if the server does not send it the second time. =20 =20 =20 I wonder if the capability needs to be added to say, please start this TLV. So that a server can say, If you don't start a Channel binding TLV, I = will make this a failure return code, if you want to start the channel = binding TLV then I am open to giving you a success return code. OK - so this is kind of there, but only one value can be placed there. One cannot say do either an EAP negotiation or process this TLV. [HZ] That's true. Only one request. =20 [JLS] Since you can only have one Request-Action TLV for a given status code, but presumably multiple Request-Action TLV with different status codes, that seems slightly restrictive. However, I can deal with = this. =20 =20 [JLS] Difference in opinion in the document. The text in 4.2.9 says = that multiple with different status codes ok, but the table says 0-1 in a = single message =20 =20 20. Section 4.2.12.4 - What does it mean to have an I-ID validation enforcement for PAC session renewal? Does it mean that the final = message is not sent unless an appropriate ID is presented? Does it have to be an = EAP authentication or is password based authentication sufficient? Should a PAC be invalidated on the server side (oops how do you do that) if it a PAC = is presented and then the appropriate ID is not given? [HZ] The I-ID in the PAC is used to validate that the correct user is = being authenticated and using his PAC. If they don't match, then the authentication will be rejected as if the authentication failed, with = the normal flow including the final Result TLV and clear text EAP failure = being sent. It can be either the EAP authentication or the password based authentication. The PAC is not invalidated if the I-ID doesn't match the authenticated identity, the authentication will be rejected. =20 21. In section 4.2.12.6 - Is this supposed to be at the top level or embedded in the PAC-TLV? [HZ] Yes. [JLS] I think the correct response is =96 =93I don=92t understand the = question=94 It is only embedded and I don=92t know why I ever thought it would be = at the top level. =20 =20 22. In section 4.2.16 - PKCS#7 has been superseded by CMS - the references should be to CMS and not to PCKS#7 [HZ] Ok with me. Any other feedback from the WG? =20 23. In IANA - Need to add the Request-Action TLV to the list of status codes [HZ] It is included in the Result TLV, Intermediate Result TOV status = code registry in the IANA section. I think it makes sense to have the same = one. [JLS] =96 my bad, I missed that it was in the list. =20 =20 24. In IANA - Should the Vender ID of the Vender-Specific TLV be kept = in a registry? [HZ] Vendor ID per the draft, is the SMI Network Management Private Enterprise Code already managed by IANA.=20 =20 Yes =96 I just missed that the first time around =96 sorry =20 =20 Jim =20 -----Original Message----- From: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org] On Behalf Of Alan DeKok Sent: Tuesday, September 25, 2012 8:04 AM To: emu@ietf.org Subject: [Emu] Looking for reviewers We'd like to get the final two documents into last call before the next meeting. Therefore, we're looking for reviewers: https://datatracker.ietf.org/doc/draft-ietf-emu-crypto-bind/ https://datatracker.ietf.org/doc/draft-ietf-emu-eap-tunnel-method/ Please post reviews to the list. If all goes well, we can get = updated documents issued before the next meeting. Thanks to everyone for their help. Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu =20 _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu =20 ------=_NextPart_000_010D_01CDA4D6.2129B330 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hao, comments in line

 

From:= = Hao Zhou (hzhou) [mailto:hzhou@cisco.com]
Sent: Thursday, = October 04, 2012 10:39 AM
To: Jim Schaad
Cc: = emu@ietf.org
Subject: Re: [Emu] Review of = draft-ietf-emu-eap-tunnel-method-00

 

Jim:

 

Thanks very = much for your detailed review. Please see the comments below. We will = respond to your other emails = shortly. 

 

On 9/28/12 = 9:18 PM, "Jim Schaad" <ietf@augustcellars.com> = wrote:

 

1.  = ;In section 3.2.3, it says that a new PAC can be requested after a = full

TLS = handshake.  Can one be requested following an abbreviated = handshake?

Or=

do you just = re-use the existing PAC?

[HZ] RFC5077 = does not specify that client can request a new ticket = after

sending the = TLS ticket, if the client is resuming a session using = the

session = ticket, then it cannot request a new session ticket based = on

resumed = session. We will add some language to clarify that it is = not

allowed.=

 

2.  = ;Section 3.3 = s/descried/described/

[HZ] = Ok.

 

3.  = ;Section 3.4 - Is it possible to have multiple server ids after = the

authenticatio= n - one from the tunnel and others from the inner = EAP

methods.=

I realize = that most EAP methods don't send a sender id, but some = (IBAKE

for

example) = currently do.  Also, the client might have an idea of what = the

sender id is = from configuration.  If so, do these all need to get = exported

as server-id = values?

[HZ] Good = catch. We will add a sentence similar to peer-ID, where = multiple

server IDs = need to be exported.

 

4. In = section 3.6.1 - It is not clear that an EAP-Failure packet is = sent

when 1) the = server sends a fatal alert to the peer, 2) the peer requests = a

restart via = a ClientHello and 3) the peer declines to permit the = restart

to=

occur.

[HZ] We will = clarify that EAP-Failure packet will be sent in those = cases.

 

[JLS] Just to be clear – this is a single case not three = cases.=A0 It is a sequence of events that should lead to the EAP-Failure = packet.

 

 

5.  = ;In section 3.6.1 - Is the restart only an issue for fatal alerts, = or

is=

it a problem = for all alerts?

[HZ] Restart = is only allowed for non-fatal alerts, per TLS RFC. = "Upon

transmission = or receipt of a fatal alert message, both parties immediately close = the connection.", so restart is not = desired

in this = case. We will clarify that restart is only allowed in = non-fatal

alert = cases.

 

[JLS]=A0 It may just be me, but this seems to be a bit odd from my = point of view.=A0 It is not clear that in the event of a non-fatal alert = that there is any need for the two parties to start a new negotiation = that would ensue upon getting a Hello restart. =A0There is a question in = terms of closing the connection if the TLS document means just the TLS = session or the encapsulating transport is to be shut down as well.=A0 If = it means the latter then it makes sense that you could request a new TLS = negotiation without having to build all of the EAP transport frame work = (i.e the entire RADIUS session?).

 

Please re-look at this and ensure that this is really what you = mean.

 

 

6.  = ;In section 3.6.2 - Why SHOULD not MUST send clear text = EAP-Failure?

[HZ] We will = change it to MUST.

 

7.  = ;In section 3.6 - do we need to discuss the question of errors in = the

outer EAP = layer that is carrying the TLVs which contain the TLS = content?

This is a = distinct location from the current list of where to = handle

errors.<= /o:p>

There is = going to be a distinction (possibly) between errors that = occur

during phase = 1 and errors during phase 2.  Should the error return = reflect

if the error = occurred inside or outside of the TLS = tunnel?

[HZ] Good = catch. We will add some language to clarify dealing with = outer

packet = errors. Something like:

1. If Outer = TLVs are wrong, they will be ignored.

2. If others = (version, length, flags, etc.) are wrong, the entire = EAP

packet will = be ignored.

 

[JLS} Looks reasonable.

 

 

 

8.  = ;In section 3.8 - I have the following = questions

a) In the = text "The request MAY be issued", I don't understand the MAY = at

this = point.  Is it supposed to say that the request can be issued = either

before or = after the authentication has finished, or is it saying that = the

peer has the = option of issuing or not issuing the request, but must = wait

until the = authentication level has been = reached?

[HZ] It's = the later. How about add "only" in front "after the peer = has

determined = that..."?

 

[JLS] That does deal with the immediate issue.=A0 However the fact = that you need to do the Crypt-Binding TLV for tunnel validation does = imply that an EAP method that generates a key is a requirement before = being able to get a PAC.=A0 Is this what is intended?=A0 Should you be = able to get a PAC just from validating the tunnel with the server and = knowing the servers name from it’s = certificate?

 

b) If a peer = issues a PAC request, but the server has not yet = satisfied

it's

policy, does = the server remember the PAC request and send back = the

response=

after the = internal policy has been satisfied or should it send back = an

error

saying that = policy has not yet been satisfied along with additional = TLVs

to=

attempt and = satisfy that policy?

[HZ] The = server remembers that and issues the PAC after its policy = is

satisfied. = We will clarify that.

 

c) What = should a peer do if it receives a PAC TLV with an = unknown

attribute?

[HZ] Ignore = that.

[JLS] Please be detailed – ignore the attribute or ignore the = PAC.

 

 

9.  = ;In section 3.9 - there is leaking on the POP, but not on identity = at

this = point.  I believe that there needs to be a requirement that an = EAP

method needs = to be run which will provide an identity proof on the = client

prior to a = certificate being issued.  You may or may not then want to = add

text that = says that the subject name(s) in the certificate request need = to

be checked = against the set of authenticated identities prior to = the

certificate = being issued.

[HZ] Good = point. We will add some that.

 

 

10. In = section 3.10 - It is unclear to me if the Server = Unauthenticated

mode

is because = the server or the peer is unauthenticated at this point = in

time.

The cipher = suite would indicate that the server is not = authenticated,

however what = about the case of the server providing an authenticated id = to

the peer, = but the peer is unable to validate the identity of the = server

for

some = reason.  This is also a Server Unauthenticated = mode.

[HZ] Yes. It = covers both cases. We will add language to clarify = that.

 

 

11. &nbs= p;In section 4.1 - I would like to see a discussion that says that = the

following = situation can never occur.  The initial EAP message from = the

peer

to the = server (or the response) plus the Outer TLV data plus the = EAP

message<= /o:p>

headers = exceeds the underlying packet size of the transport.  In the = event

that it = does, I am not sure how one finds the Outer TLV data start = and

where

the = fragmentation would occur to get the Outer TLV data between the = peer

and

the = server.

[HZ] I think = it should work as defined. The start of the Outer TLVs = should

be derived = from the EAP message length and length of the TLS = data.

[JLS] I have gotten a better understanding – I may have = suggested text elsewhere

 

 

12. &nbs= p;Section 4.2 - I understand what is happening with an EMPTY = TEAP

message<= /o:p>

being sent = in response to a list of TLVs that are marked = optional,

however = I

question if = the statement that is MUST be sent is correct.  There are = two

reasons for = the question:

 

a.  = ;A server could send a RESULT TLV in response to a message from = the

client that = contains no TLVs that are either mandatory or = recognized.

[HZ] Good = catch. We will clarify that.

<= p class=3DMsoNormal> 

b.  = ;I am (very slightly) worried about the fact that the response is = not

authenticated= by the tunnel in many manner.  I would think that a NAK = to

any

of the TLVs = would be a better response if no other TLV messages are to = be

sent. &n= bsp;The entity sending the TLV should know if it marked it as = mandatory

or = not.  The NAK is not the same as an Error = TLV.

[HZ] Agree. = A NAK  TLV should be sent in this case. We will = clarify.

 

13. &nbs= p;Section 4.2.2 - Should "Type" in the outdented list be = "TLV Type"?

s/filed/field= /

[HZ] Yes. We = will correct that.

<= p class=3DMsoNormal> 

14. &nbs= p;Section 4.2.2 - Can multiple Authority-ID TLVs be transmitted to = a

peer?

[HZ] No. It = is mentioned in Section 4.3, Table of TLVs = rules.

[JLS} That says that you cannot send multiple Authority IDs in a = single message, what about in multiple messages?

 

 

 

15. &nbs= p;Section 4.2.3 - I assume that there should only be one = Identity-Type

TLV in a = TEAP packet.  Should a request for authentication be present = in

the

packet as = well?  If multiple are allowed then information about how = to

treat

this should = be included.  What should the peer respond with if it = does

have

an identity = of the type?  This is not explicitly = stated.

[HZ] That's = correct, only one Identity-Type TLV is allowed.The requested Identity = type  MUST comes with an EAP request = or Basic-Password-Auth-Req. 

<= p class=3DMsoNormal>If the peer = has the requested identity type, it should send back the same identity = type TLV in the response. We missed this and will add this = clarification.

 

16. &nbs= p;Section 4.2.4 - I don't understand the default in the event that = an

unknown = value is sent in the status field.  If there is an ERROR TLV = in

the

message, = should I not use that error code rather than change = it?

[HZ] No. The = error code in the Error TLV if being sent with the Result TLV might mean = something, but since the peer doesn't understand the Status field, and = most likely will not understand the error code. Sending = back Unexpected_TLVs_Exchanged error code is probably = appropriate.

<= p class=3DMsoNormal>[JLS] I was assuming that the client did understand the error code, = otherwise I agree that using a well understood error is correct = behavior.

 

 

17. Section = 4.2.6 - Do we need a discussion about how to produce/deal = with

vender = specific errors?  Do you expect that vender specific TLVs will = have

an error = mechanism built into them to return an error = code?

[HZ] We = expect the vendor TLV will have its own error handling mechanism or use = the standard error codes defined.

<= p class=3DMsoNormal> 

 

18. Section = 4.2.8 - Do we need to talk about the question of having = some

Vender TLVs = be marked as mandatory and others not.  Are we using the = same

TLV = structure with the same rules for mandatoriness.  If the = mandatory bit

is set, does = that mean that I need to recognize the vendor-id or = all

combinations = of vender-id/Vender-TLV = type?

[HZ] Yes. If the = mandatory bit is set on the Vendor-Speific TLV, then the peer need to = recognize the vendor ID and all combination of the vendor TLVs. The = Vendor TLV format is up to the vendor to define, as specified = by the current draft.

 

 

19. &nbs= p;Section 4.2.9 - After reading this, sketching out some scenarios = and

so=

forth, I = find that I do not like the text and result being pushed here = at

all. &nb= sp;My problems start, in some respects, with the name of the TLV as = it

does not map = to how I would like to see this TLV treated.  I would = propose

the = following set of changes:

a) The name = of the TLV be changed from Request-Action TLV = to

Provisional-R= esult TLV

[HZ] I am = open with the name change, but think Request-Action probably capture the = essence better.

<= p class=3DMsoNormal> 

b) It needs = to be made clear that the TLV can be sent from either = the

server

to the peer = or the peer to the server.  It is my belief that presently = it

is=

only sent = from the peer to the client and only in response to a = successful

Result = TLV.

[HZ] Ok. I = agree that we can extend that to be bidirectional and for either success = and failure Result TLV.

<= p class=3DMsoNormal> 

c)  = ;The receiving entity MUST process the = TLV.

[HZ] Ok.

 

d)  = ;The processing for the TLV is as = follows:

   = i) The entity MAY choose to process (or start?) any of the TLVs = that

are

included in = the message.

  i= i) If the entity chooses NOT to process any TLV in the list, = the

Provisional-R= esult TLV is treated as a Result TLV with the code = "status"

  i= ii) If multiple Provisional-Result TLVs are in the body, the = session

can

continue if = ANY of TLV in any Provisional-Result TLV is = processed.

  i= v) If multiple Provisional-Result TLVs are in the body and no = sub-TLV

is=

processed, = then the most fatal status should be used.  If a status = is

found

which is not = understood by the entity, then it should be treated as = a

fatal

TLV.

[HZ] Ok.

 

 

The current = text allows for the following:

The server = sends a Success to the peer

The peer = says please do this or go to fatal

The server = sends a clear success outside of the = tunnel.

[HZ] That's = not correct. The last exchange in the tunnel should be an agreed upon = Result TLV exchange, before the tunnel is torn down and a clear text EAP = success is sent.

 

[JLS] Just to be clear, you are saying that the conversation will = look like

 

Server =E0= Result TLV (Success)

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Request-Action = (Status-Bletch, foobar) =DF= Client

Server =E0= Result TLV (Success)

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Result TVL (Success) = =DF= Client (knows that the server must not be willing to do what was = asked.

 

The server COULD send back the Bletch code if it decides to process = the Request-Action TLV from the client.=A0 The client could send back = Bletch even if the server does not send it the second = time.

 

=A0=A0=A0=A0

 

I wonder if = the capability needs to be added to say, please start = this

TLV.

So that a = server can say, If you don't start a Channel binding TLV, I = will

make this a = failure return code, if you want to start the channel = binding

TLV then I = am open to giving you a success return = code.

OK - so this = is kind of there, but only one value can be placed = there.

One cannot = say do either an EAP negotiation or process this = TLV.

[HZ] That's true. Only one request.

 

[JLS] Since you can only have one Request-Action TLV for a given = status code, but presumably multiple Request-Action TLV with different = status codes, =A0that seems slightly restrictive.=A0 =A0=A0However, I = can deal with this.=A0

 

[JLS] Difference in opinion in the document.=A0 The text in 4.2.9 = says that multiple with different status codes ok, but the table says=A0 = 0-1 in a single message

 

 

20. Section = 4.2.12.4 - What does it mean to have an I-ID = validation

enforcement = for PAC session renewal?  Does it mean that the final = message

is=

not sent = unless an appropriate ID is presented?  Does it have to be an = EAP

authenticatio= n or is password based authentication sufficient?  Should = a

PAC

be = invalidated on the server side (oops how do you do that) if it a PAC = is

presented = and then the appropriate ID is not = given?

[HZ] The I-ID in the PAC is used to validate that the correct user is = being authenticated and using his PAC. If they don't match, then the = authentication will be rejected as if the authentication failed, with = the normal flow including the final Result TLV and clear text EAP = failure being sent. It can be either the EAP authentication or the = password based authentication. The PAC is not invalidated if the I-ID = doesn't match the authenticated identity, the authentication will be = rejected.

 

21. &nbs= p;In section 4.2.12.6 - Is this supposed to be at the top level = or

embedded in = the PAC-TLV?

[HZ] = Yes.

[JLS] I think the correct response is – “I don’t = understand the question”=A0 It is only embedded and I don’t = know why I ever thought=A0 it would be at the top = level.

 

 

22. &nbs= p;In section 4.2.16 - PKCS#7 has been superseded by CMS - = the

references

should be to = CMS and not to PCKS#7

[HZ] Ok with = me. Any other feedback from the WG?

 

23. &nbs= p;In IANA - Need to add the Request-Action TLV to the list of = status

codes

[HZ] It is included in the Result TLV, = Intermediate Result TOV status code registry in the IANA = section. I think it makes sense to have the same = one.

[JLS] – my bad, I missed that it was in the = list.

 

 

24. &nbs= p;In IANA - Should the Vender ID of the Vender-Specific TLV be kept = in

a<= /span>

registry?

[HZ] Vendor ID = per the draft, is the SMI Network = Management = Private Enterprise Code already managed by = IANA. 

 

Yes – I just missed that the first time around – = sorry

 

 

Jim

 

-----Original= Message-----

From: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org] On = Behalf Of

Alan = DeKok

Sent: = Tuesday, September 25, 2012 8:04 AM

=

Subject: = [Emu] Looking for reviewers

   = We'd like to get the final two documents into last call before = the

next

meeting. = ; Therefore, we're looking for = reviewers:

   = Please post reviews to the list.  If all goes well, we can get = updated

documents = issued before the next meeting.

   = Thanks to everyone for their help.

   = Alan DeKok.

_____________= __________________________________

Emu mailing = list

=

 

_____________= __________________________________

Emu mailing = list

=

 

------=_NextPart_000_010D_01CDA4D6.2129B330-- From ietf@augustcellars.com Sun Oct 7 22:13:14 2012 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9C0821F8717 for ; Sun, 7 Oct 2012 22:13:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.669 X-Spam-Level: X-Spam-Status: No, score=-2.669 tagged_above=-999 required=5 tests=[AWL=0.930, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hjmrI+7wuZuL for ; Sun, 7 Oct 2012 22:13:14 -0700 (PDT) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) by ietfa.amsl.com (Postfix) with ESMTP id 47FB521F8707 for ; Sun, 7 Oct 2012 22:13:14 -0700 (PDT) Received: from Tobias (173-12-183-193-oregon.hfc.comcastbusiness.net [173.12.183.193]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id 2597938EEF; Sun, 7 Oct 2012 22:13:12 -0700 (PDT) From: "Jim Schaad" To: "'Hao Zhou \(hzhou\)'" , , References: <00e401cd9ff7$b52212a0$1f6637e0$@augustcellars.com> <645B00545719594A88ADF4221831FD3813D8D6@xmb-rcd-x14.cisco.com> In-Reply-To: <645B00545719594A88ADF4221831FD3813D8D6@xmb-rcd-x14.cisco.com> Date: Sun, 7 Oct 2012 22:11:44 -0700 Message-ID: <011101cda513$6aace5d0$4006b170$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQItOgsJ1vh4hT7aTkSAetghKtkk5pbvsipQ Content-Language: en-us Subject: Re: [Emu] More COmments 2 on eap-tunnel-method X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2012 05:13:15 -0000 > -----Original Message----- > From: Hao Zhou (hzhou) [mailto:hzhou@cisco.com] > Sent: Thursday, October 04, 2012 3:06 PM > To: Jim Schaad; emu@ietf.org; draft-ietf-emu-eap-tunnel- > method@tools.ietf.org > Subject: Re: [Emu] More COmments 2 on eap-tunnel-method > > Jim: > > Please see comments below. > > On 10/1/12 1:10 PM, "Jim Schaad" wrote: > > >I found two that I forgot to include in the last message > > > >1. When exporting the user-id, does there need to be a way to > >distinguish at export time between the different types of ids that are > >authenticated by the server? This does not seem to be an issue on the > >peer as it will only do mutual authentication to servers and thus only > >have server ids, however a server may authenticate to different types > >of identities on the peer. At the moment we have identified user and > >machines as types of entities to be identified, I suppose in the future > >we could add Ewoks as a different type of entity that could be > >identified. However the export function of user-ids does not make a > >distinction between the different types of authenticated entities. > >Should it do so or should it just export user authentications? > [HZ] It helps to export the identities as well as the corresponding identity > types (from the Identity Type TLV). Will add text. > > > >2. Is there a map of TLVs that should not be sent together or need to > >be processed in a specific order? The case I was looking at was for > >the Identity TLV and the EAP TLV. Is there a difference in how a peer > >should react for the following? > > > > Identity TLV (Send me a machine Identity), EAP TLV (Start the EAP > >type > >XX) > > EAP TLV (Start EAP type XXX), Identity TLV (Send me a machine > >Identity) > > > >Or should these two TLVs never occur in a single message? > [HZ] We had some discussion in WG and take the design principal of TLV > ordering should not matter. We disallow simultaneous EAP inner methods > and/or with Basic Password Authentication, so rest of the TLVs order should > not matter. If it does matter, it should be a nested TLV, as in Result TLV and > Request-Action TLV. Need to add text to disallow Inner EAP method with > parallel Basic Password Authentication TLV. [JLS] If order of TLVs does not matter, then there is an implied order that the TLVs should be processed. That is one should always process the Identity TLV before processing the EAP TLV as the identity TLV is a hint to the type of identity that is to be used in the EAP method. Conversely it might be that these two TLVs should never occur in the same message. Ditto with the Basic Password Authentication TLV and the Identity TLV. Jim > > > >Jim > > > > > >_______________________________________________ > >Emu mailing list > >Emu@ietf.org > >https://www.ietf.org/mailman/listinfo/emu From ietf@augustcellars.com Sun Oct 7 22:13:15 2012 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DBDB21F8707 for ; Sun, 7 Oct 2012 22:13:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.134 X-Spam-Level: X-Spam-Status: No, score=-3.134 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YcL54blivPPt for ; Sun, 7 Oct 2012 22:13:14 -0700 (PDT) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) by ietfa.amsl.com (Postfix) with ESMTP id CBA4D21F8710 for ; Sun, 7 Oct 2012 22:13:14 -0700 (PDT) Received: from Tobias (173-12-183-193-oregon.hfc.comcastbusiness.net [173.12.183.193]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id 4F5DA38EF5; Sun, 7 Oct 2012 22:13:14 -0700 (PDT) From: "Jim Schaad" To: "'Hao Zhou \(hzhou\)'" , , References: <009301cd9f35$b001e650$1005b2f0$@augustcellars.com> <645B00545719594A88ADF4221831FD3813D8C0@xmb-rcd-x14.cisco.com> In-Reply-To: <645B00545719594A88ADF4221831FD3813D8C0@xmb-rcd-x14.cisco.com> Date: Sun, 7 Oct 2012 22:11:44 -0700 Message-ID: <011201cda513$6ae55af0$40b010d0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIwO15WrsRiyhDfZuH/C6XDrt7wVpbpq6DQ Content-Language: en-us Subject: Re: [Emu] More comments for eap-tunnel-method X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2012 05:13:15 -0000 > -----Original Message----- > From: Hao Zhou (hzhou) [mailto:hzhou@cisco.com] > Sent: Thursday, October 04, 2012 2:56 PM > To: Jim Schaad; emu@ietf.org; draft-ietf-emu-eap-tunnel- > method@tools.ietf.org > Subject: Re: [Emu] More comments for eap-tunnel-method > > Jim: > > Thanks for the review. Please see my comments below. > > On 9/30/12 2:01 PM, "Jim Schaad" wrote: > > >1. Should the Message Length field be present if the TLS Data field is > >absent? > [HZ] According to the text in the draft, the message length field should only > be present if the L bit is set, usually for fragmented packets. In those cases, > the TLS data field will be present, not absent. The only case TLS data will be > absent is when empty TEAP packet it is used to > indicate TEAP acknowledgement for either a fragmented message, > a TLS Alert message or a TLS Finished message. So the message length > field is not needed. We can clarify that in the draft. > [JLS] I am not clear - are you saying that the first sever message sent with just TLVs cannot be fragmented? [JLS] There is a potential issue in the way that the Message Length field is described. For finding the location of the Outer TLVs it provides the length of the TLS Data field, but the internal description says that it gives the length of the message data in the event of a fragmented message. If the first client response message is both fragmented on length and contains TLVs, then the message length field must be the length of the TLS data in order to find the Outer TLV data but that means it is not the length of all of the fragmented data. This is not an issue after the first pair of messages as the Outer TLVs are no longer allowed at that point. [JLS] I presume that the Length needs to be present only if the message is fragmented as a hint to the receiver on the length of the buffer to allocate as I don't remember any error checks that the length of the message match the re-constructed message from the fragments (and if it did then the previous paragraph makes that faulty). Should there be an error check on the message length w/ the length of the re-constructed buffer? > > > >2. There is nothing to say which TLVs can and cannot occur in the > >Outer TLVs in any easily findable method. Either a table or the string > >outer in descriptions would be helpful. As an example, does the > >Authority-ID TLV in the outer TLV make sense? > [HZ] We will add that table. > > > >3. I have gone through the fragmentation and did an implementation > >rather than just reading it. The questions that I have on it now are > >slightly different. Do TLVs need to be on a fragment boundary? Or do > >we just build the entire message, fragment it into convenient sizes > >regardless of the actual content of the message contents and sent the > >pieces across? If so then the text should probably be re-written to be > >clearer. Specifically, the message length is not useful for allocating > >the buffer on the first round trip of messages where one can have a TLV > added in to the content. > >[HZ] Message length covers the whole TEAP packet even if fragmented. > >TLVs do not need to be on a fragment boundary. Just build the whole > >message contents and send the pieces across. We will provide some text > >to clarify this. [JLS] - see note above about finding the start of the Outer TLV data block on the first pair of messages. > > > > > >_______________________________________________ > >Emu mailing list > >Emu@ietf.org > >https://www.ietf.org/mailman/listinfo/emu From ietf@augustcellars.com Sun Oct 7 22:13:57 2012 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D16321F8714 for ; Sun, 7 Oct 2012 22:13:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.288 X-Spam-Level: X-Spam-Status: No, score=-3.288 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SSqZvcm49ISI for ; Sun, 7 Oct 2012 22:13:56 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id 7440D21F8609 for ; Sun, 7 Oct 2012 22:13:56 -0700 (PDT) Received: from Tobias (173-12-183-193-oregon.hfc.comcastbusiness.net [173.12.183.193]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id 184382CA15; Sun, 7 Oct 2012 22:13:56 -0700 (PDT) From: "Jim Schaad" To: "'Hao Zhou \(hzhou\)'" , References: <008001cd9e83$ae8b6dd0$0ba24970$@augustcellars.com> <645B00545719594A88ADF4221831FD3813D9E9@xmb-rcd-x14.cisco.com> In-Reply-To: <645B00545719594A88ADF4221831FD3813D9E9@xmb-rcd-x14.cisco.com> Date: Sun, 7 Oct 2012 22:12:26 -0700 Message-ID: <011301cda513$83c1a4c0$8b44ee40$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0114_01CDA4D8.D769D1A0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKxIfhZmV9uzKBf+3GTtKyZmzSkgpXn4uuw Content-Language: en-us Subject: Re: [Emu] IMSK derivation issue X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2012 05:13:57 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0114_01CDA4D8.D769D1A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I have no problems with adding the Policy steps to the processing. From: Hao Zhou (hzhou) [mailto:hzhou@cisco.com] Sent: Thursday, October 04, 2012 8:56 PM To: Jim Schaad; emu@ietf.org Subject: Re: [Emu] IMSK derivation issue Jim: Thanks for pointing out this issue. How about the following text with slight modification with policy control from both sides to prevent downgrade attack. Added text in red. 1. The first sender of the Crypto-Binding TLV needs to create it as follows: a) If the EMSK is not available, then it computes the Compound MAC as is currently documented b) If the EMSK is available, and the sender's policy accepts MSK based MAC, then it computes two Compound MAC values. The first is computed with the EMSK as is currently documented. The second is a Compound MAC that uses the MSK and the Buffer is modified by adding the string "EMSK" (or something similar). Both MACs are then send to the other Side. c) If the EMSK is available, but the sender's policy doesn't allow downgrade to MSK generated MAC, then it should only send EMSK based MAC. 2. The second sender of the Crypto-Binding TLV then: a) If the EMSK is available and an EMSK Compound MAC was sent validates it and creates a response using the EMSK and sends it back b) If the EMSK is not available and an EMSK compound MAC was sent - it validates the MSK using the modified BUFFER string and sends back a MSK generated response c) If no EMSK Compound MAC was sent, and its policy accepts MSK based MAC, then it validates using the MSK - and if successful generates and returns an MSK generated response. d) If no EMSK Compound MAC was sent, and its policy doesn't accept MSK based MAC, then it handles like an invalid crypto-binding TLV with fatal error. On 9/29/12 4:47 PM, "Jim Schaad" wrote: I agree that the IMSK needs to take into account the existence of the EMSK, however the current text has a severe problem with the way that it is done. It assumes that if the EMSK is exportable on one side, then it will be exportable on the other side as well. I don't believe this is the case. In order for this to work, and to prevent the downgrade attack by a MITM, I believe that the following changes need to be made: 1. The first sender of the Crypto-Binding TLV needs to create it as follows: a) If the EMSK is not available, then it computes the Compound MAC as is currently documented b) If the EMSK is available, then it computes two Compound MAC values. The first is computed with the EMSK as is currently documented. The second is a Compound MAC that uses the MSK and the Buffer is modified by adding the string "EMSK" (or something similar). Both MACs are then send to the other side. 2. The second sender of the Crypto-Binding TLV then: a) If the EMSK is available and an EMSK Compound MAC was sent validates it and creates a response using the EMSK and sends it back b) If the EMSK is not available and an EMSK compound MAC was sent - it validates the MSK using the modified BUFFER string and sends back a MSK generated response c) If no EMSK Compound MAC was sent, it validates using the MSK - and if successful generates and returns an MSK generated response. If the EMSK compound MAC is removed in transit, then the MSK validated value will fail as the BUFFER string is not modified to recognize that an EMSK Compound MAC was sent. 3. The first send then validates the returned values by: a) If it sent an EMSK Compound value - attempt to validate using the EMSK value. If it fails then go to b else succeed b) Validate using the MSK value using the unmodified buffer. Both sides will then need to remember if the MSK or EMSK value was used for validation in this step, but that is no different than the fact that the MSK is currently being remembered. Jim _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu ------=_NextPart_000_0114_01CDA4D8.D769D1A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I have no problems with adding the Policy steps to the = processing.

 

From:= = Hao Zhou (hzhou) [mailto:hzhou@cisco.com]
Sent: Thursday, = October 04, 2012 8:56 PM
To: Jim Schaad; = emu@ietf.org
Subject: Re: [Emu] IMSK derivation = issue

 

Jim:

 

Thanks for pointing out this issue. How about the following text with = slight modification with policy control from both sides to prevent = downgrade attack. Added text in r= ed.

 

1. The first sender of the Crypto-Binding TLV needs to create it = as

follows:

a) If the EMSK is not available, then it computes the Compound MAC as = is

currently documented

b) If the EMSK is available, and t= he sender's policy accepts MSK based MAC, then it = computes two Compound MAC values. The

first is computed with the EMSK as is currently documented. The second = is a

Compound MAC that uses the MSK and the Buffer is modified by adding = the

string "EMSK" (or something similar). Both MACs are then send = to the other

Side.

c= ) If the EMSK is available, but the sender's policy doesn't allow = downgrade to MSK generated MAC, then it should only send EMSK based = MAC. =

 

2. The second sender of the Crypto-Binding TLV = then:

a) If the EMSK is available and an EMSK Compound MAC was sent validates = it

and creates a response using the EMSK and sends it = back

b) If the EMSK is not available and an EMSK compound MAC was sent - = it

validates the MSK using the modified BUFFER string and sends back a = MSK

generated response

c) If no = EMSK Compound MAC was sent, and its policy = accepts MSK based MAC, then it validates using the MSK - and = if

successful generates and returns an MSK generated response. =

d) If no EMSK Compound MAC was sent, a= nd its policy doesn't accept MSK based MAC, then it handles like an invalid crypto-binding TLV with fatal = error.

 

On 9/29/12 4:47 PM, "Jim Schaad" <ietf@augustcellars.com> = wrote:

 

I agree that the IMSK needs to take into account the existence of the = EMSK,

however the current text has a severe problem with the way that it is = done.

It assumes that if the EMSK is exportable on one side, then it will = be

exportable on the other side as well.  I don't believe this = is the case.

 

In order for this to work, and to prevent the downgrade attack by a = MITM, I

believe that the following changes need to be = made:

 

1.  The first sender of the Crypto-Binding TLV needs to = create it as

follows:

a) If the EMSK is not available, then it computes the Compound MAC as = is

currently documented

b) If the EMSK is available, then it computes two Compound MAC = values.  The

first is computed with the EMSK as is currently = documented.  The second is = a

Compound MAC that uses the MSK and the Buffer is modified by adding = the

string "EMSK" (or something similar).  Both MACs = are then send to the other

side.

 

2.  The second sender of the Crypto-Binding TLV = then:

a) If the EMSK is available and an EMSK Compound MAC was sent validates = it

and creates a response using the EMSK and sends it = back

b) If the EMSK is not available and an EMSK compound MAC was sent - = it

validates the MSK using the modified BUFFER string and sends back a = MSK

generated response

c) If no EMSK Compound MAC was sent, it validates using the MSK - and = if

successful generates and returns an MSK generated = response.  

 

If the EMSK compound MAC is removed in transit, then the MSK validated = value

will fail as the BUFFER string is not modified to recognize that an = EMSK

Compound MAC was sent.

 

3.  The first send then validates the returned values = by:

 

a) If it sent an EMSK Compound value - attempt to validate using the = EMSK

value.  If it fails then go to b else = succeed

b) Validate using the MSK value using the unmodified = buffer.

 

Both sides will then need to remember if the MSK or EMSK value was used = for

validation in this step, but that is no different than the fact that = the MSK

is currently being remembered.

 

Jim

 

 

_______________________________________________

Emu mailing list

=

 

------=_NextPart_000_0114_01CDA4D8.D769D1A0-- From jsalowey@cisco.com Mon Oct 8 21:13:28 2012 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A06621F849C for ; Mon, 8 Oct 2012 21:13:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.414 X-Spam-Level: X-Spam-Status: No, score=-110.414 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id quwodEKevG7X for ; Mon, 8 Oct 2012 21:13:27 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 39C5C21F849B for ; Mon, 8 Oct 2012 21:13:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3443; q=dns/txt; s=iport; t=1349756007; x=1350965607; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=I2xZRlQkdQQ5KBpO8ipuyScU78wuuHo1BanLeGDGfOM=; b=d3GK7bY17Lpz1zRXO+bDJA0XJ0rjgX5njE//VprPXYmMrrc98zfiUj2D 7Z3v2KQ1dHk95LkZ4Lc3hcMrtTjNqXD1nXbNaYmJv7HBvxrQzISiilsAz OUdZHi3aK0HsxhYOSq82m0hJ/+tloteKAHSp8ke7JJ1IPGWIVbhlFTVIL I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAD2jc1CtJXG//2dsb2JhbAA8Cb80gQiCIAEBAQMBAQEBDwEnNAsFBwQCAQgOAwQBAQEKDgYJBycLFAkIAQEEDgUIGoddBguaXo9WkCUEi0cRgmOCP2ADkjqRdoFpgmANghc X-IronPort-AV: E=Sophos;i="4.80,557,1344211200"; d="scan'208";a="129589350" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-6.cisco.com with ESMTP; 09 Oct 2012 04:13:26 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id q994DQW7028151 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 9 Oct 2012 04:13:26 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.68]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.02.0318.001; Mon, 8 Oct 2012 23:13:26 -0500 From: "Joseph Salowey (jsalowey)" To: Jim Schaad Thread-Topic: [Emu] More COmments 2 on eap-tunnel-method Thread-Index: Ac2f9v+FDIoykt+NRVmWduL9qgMM2ACjc+4AAK4ghwAAMECdgA== Date: Tue, 9 Oct 2012 04:13:26 +0000 Message-ID: References: <00e401cd9ff7$b52212a0$1f6637e0$@augustcellars.com> <645B00545719594A88ADF4221831FD3813D8D6@xmb-rcd-x14.cisco.com> <011101cda513$6aace5d0$4006b170$@augustcellars.com> In-Reply-To: <011101cda513$6aace5d0$4006b170$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.248.63] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19252.004 x-tm-as-result: No--41.536200-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <1A55F86CB5F48C4BADBFA0BA085F677F@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , "" Subject: Re: [Emu] More COmments 2 on eap-tunnel-method X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 04:13:28 -0000 On Oct 7, 2012, at 10:11 PM, Jim Schaad wrote: >=20 >=20 >> -----Original Message----- >> From: Hao Zhou (hzhou) [mailto:hzhou@cisco.com] >> Sent: Thursday, October 04, 2012 3:06 PM >> To: Jim Schaad; emu@ietf.org; draft-ietf-emu-eap-tunnel- >> method@tools.ietf.org >> Subject: Re: [Emu] More COmments 2 on eap-tunnel-method >>=20 >> Jim: >>=20 >> Please see comments below. >>=20 >> On 10/1/12 1:10 PM, "Jim Schaad" wrote: >>=20 >>> I found two that I forgot to include in the last message >>>=20 >>> 1. When exporting the user-id, does there need to be a way to >>> distinguish at export time between the different types of ids that are >>> authenticated by the server? This does not seem to be an issue on the >>> peer as it will only do mutual authentication to servers and thus only >>> have server ids, however a server may authenticate to different types >>> of identities on the peer. At the moment we have identified user and >>> machines as types of entities to be identified, I suppose in the future >>> we could add Ewoks as a different type of entity that could be >>> identified. However the export function of user-ids does not make a >>> distinction between the different types of authenticated entities. >>> Should it do so or should it just export user authentications? >> [HZ] It helps to export the identities as well as the corresponding > identity >> types (from the Identity Type TLV). Will add text. >>>=20 >>> 2. Is there a map of TLVs that should not be sent together or need to >>> be processed in a specific order? The case I was looking at was for >>> the Identity TLV and the EAP TLV. Is there a difference in how a peer >>> should react for the following? >>>=20 >>> Identity TLV (Send me a machine Identity), EAP TLV (Start the EAP >>> type >>> XX) >>> EAP TLV (Start EAP type XXX), Identity TLV (Send me a machine >>> Identity) >>>=20 >>> Or should these two TLVs never occur in a single message? >> [HZ] We had some discussion in WG and take the design principal of TLV >> ordering should not matter. We disallow simultaneous EAP inner methods >> and/or with Basic Password Authentication, so rest of the TLVs order > should >> not matter. If it does matter, it should be a nested TLV, as in Result T= LV > and >> Request-Action TLV. Need to add text to disallow Inner EAP method with >> parallel Basic Password Authentication TLV. >=20 > [JLS] If order of TLVs does not matter, then there is an implied order t= hat > the TLVs should be processed. That is one should always process the > Identity TLV before processing the EAP TLV as the identity TLV is a hint = to > the type of identity that is to be used in the EAP method. Conversely it > might be that these two TLVs should never occur in the same message. >=20 > Ditto with the Basic Password Authentication TLV and the Identity TLV. >=20 [Joe] That makes sense. An implementation should check for an identity TL= V to provide a hint when determining what identity to use for and EAP or pa= ssword authentication. > Jim >=20 >>>=20 >>> Jim >>>=20 >>>=20 >>> _______________________________________________ >>> Emu mailing list >>> Emu@ietf.org >>> https://www.ietf.org/mailman/listinfo/emu >=20 > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu From jsalowey@cisco.com Mon Oct 8 21:22:36 2012 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F1E111E80D1 for ; Mon, 8 Oct 2012 21:22:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.441 X-Spam-Level: X-Spam-Status: No, score=-110.441 tagged_above=-999 required=5 tests=[AWL=0.159, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J31TVD-7XFle for ; Mon, 8 Oct 2012 21:22:35 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 42E6B11E80CC for ; Mon, 8 Oct 2012 21:22:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4315; q=dns/txt; s=iport; t=1349756555; x=1350966155; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=DZaM9T0mcxXTIsiTgVyI2wwpxjvRpjDxTW9J/1hRsdE=; b=U5FcqG+JDWqU7VI3k+K3UMogq3qHA5N2iHO3J5FF/LVSms5o6sGW7DHI RqcK8KXdG7O8dlxBAjzKckr6kYLOOC5v0bV/3ZOx2t7OXmX7qe79Mwso5 V3BUjQF0W5W1altrz2QUfj/bum5JQbUnD3iJQSDZ/YdNbLGujIbtAMv3I E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAIulc1CtJXG+/2dsb2JhbABFvzSBCIIgAQEBAwEBAQEJBgFbCwUHBAIBCA4DBAEBCx0HJwsUCQgCBA4FCA4Mh10GC5pgj1aQJQSLR4UzYAOII4oXkXaBaYJgDYIX X-IronPort-AV: E=Sophos;i="4.80,557,1344211200"; d="scan'208";a="129370813" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-1.cisco.com with ESMTP; 09 Oct 2012 04:22:35 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id q994MYsJ030165 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 9 Oct 2012 04:22:34 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.68]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.001; Mon, 8 Oct 2012 23:22:34 -0500 From: "Joseph Salowey (jsalowey)" To: Jim Schaad Thread-Topic: [Emu] Client Auth with TLS Thread-Index: AQETIlXkRdUEOAmqRJpEVJ8MvvMTfAJlURHymRCe5mCAAfEZAA== Date: Tue, 9 Oct 2012 04:22:33 +0000 Message-ID: References: <00e601cda1a3$5a230c80$0e692580$@augustcellars.com> <506D282C.6040909@restena.lu> <010701cda507$27d9ed40$778dc7c0$@augustcellars.com> In-Reply-To: <010701cda507$27d9ed40$778dc7c0$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.248.63] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19252.004 x-tm-as-result: No--55.536400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [Emu] Client Auth with TLS X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 04:22:36 -0000 I think it is worthwhile to support an mode of operation that supports peer= privacy. I've seen this implemented in tunnel methods in two different w= ays. One with renegotiation as described below and the other as an inner E= AP-TLS exchange after an anonymous outer exchange. I don't really have a = strong opinion as to which is better at this point. It seems that using an= inner EAP-TLS may be more flexible and would offer the same security prope= rties and might be a simpler model. =20 Any opinions on the list? =20 On Oct 7, 2012, at 8:43 PM, Jim Schaad wrote: > Stefan, >=20 > Thanks for the input. >=20 > For the authors, >=20 > Does this need to be documented as a mode of operation for TEAP or are we > going to say that this is not a supported mode? >=20 > Jim >=20 >=20 >> -----Original Message----- >> From: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org] On Behalf Of >> Stefan Winter >> Sent: Wednesday, October 03, 2012 11:10 PM >> To: emu@ietf.org >> Subject: Re: [Emu] Client Auth with TLS >>=20 >> Hi, >>=20 >>> 3. The client provides the certificate in a protected manner - I had >>> a problem at this point because I don't know enough TLS to properly go >>> through this scenario, and I could not really read documents while >>> driving. If the encrypted certificate extension was used, then there >>> is no issue as the protected certificate would be passed in the >>> initial handshake. However if the client starts the negotiation and >>> then restarts it after it is encrypted, I don't know if this occurs > before or >> after the finish message. >>> If it starts after the finish method then there is an issue with >>> having the server close an anonymous session if the client is then >>> going to provide the certificate encrypted. Help on how this works > would >> be appreciated. >>=20 >> FWIW, RFC5216 (EAP-TLS) already has provisions for a protected client >> credential exchange (for client privacy protection reasons). I didn't ev= er > see it >> used (anyone?), but it's clearly a foreseen mode of operation. The text >> describing this is in section 2.1.4: >>=20 >> "... In order to avoid disclosing the peer username, an EAP-TLS peer >> configured for privacy MUST negotiate a TLS ciphersuite supporting >> confidentiality and MUST provide a client certificate list containing >> no entries in response to the initial certificate_request from the >> EAP-TLS server. >>=20 >> An EAP-TLS server supporting privacy MUST NOT treat a certificate >> list containing no entries as a terminal condition; instead, it MUST >> bring up the TLS session and then send a hello_request. The >> handshake then proceeds normally; the peer sends a client_hello and >> the server replies with a server_hello, certificate, >> server_key_exchange, certificate_request, server_hello_done, etc. >>=20 >> For the calculation of exported keying material (see Section 2.3), >> the master_secret derived within the second handshake is used. >>=20 >> An EAP-TLS peer supporting privacy MUST provide a certificate list >> containing at least one entry in response to the subsequent >> certificate_request sent by the server. If the EAP-TLS server >> supporting privacy does not receive a client certificate in response >> to the subsequent certificate_request, then it MUST abort the >> session. >> " >>=20 >> There is a sequence diagram shortly afterwards which shows clearly that > the >> "first" negotiation ends with a 'finished' and then immediately a new >> 'hello_request' - all in one EAP message. >>=20 >> Greetings, >>=20 >> Stefan >>=20 >>>=20 >>> Jim >>>=20 >>>=20 >>> _______________________________________________ >>> Emu mailing list >>> Emu@ietf.org >>> https://www.ietf.org/mailman/listinfo/emu >>>=20 >>=20 >>=20 >> -- >> Stefan WINTER >> Ingenieur de Recherche >> Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education Nationa= le et de >> la Recherche 6, rue Richard Coudenhove-Kalergi >> L-1359 Luxembourg >>=20 >> Tel: +352 424409 1 >> Fax: +352 422473 >=20 >=20 > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu From aland@deployingradius.com Tue Oct 9 06:14:18 2012 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 315FC21F8813 for ; Tue, 9 Oct 2012 06:14:18 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zZ2O6FsSFIpI for ; Tue, 9 Oct 2012 06:14:17 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 862C021F85B4 for ; Tue, 9 Oct 2012 06:14:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 62A4022439F0; Tue, 9 Oct 2012 15:13:14 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LWhH-zECb45l; Tue, 9 Oct 2012 15:13:14 +0200 (CEST) Received: from Thor.local (206-47-95-94.dsl.ncf.ca [206.47.95.94]) by power.freeradius.org (Postfix) with ESMTPSA id BD4C3224070E; Tue, 9 Oct 2012 15:13:13 +0200 (CEST) Message-ID: <5074230B.6040900@deployingradius.com> Date: Tue, 09 Oct 2012 09:13:47 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: "Joseph Salowey (jsalowey)" References: <00e601cda1a3$5a230c80$0e692580$@augustcellars.com> <506D282C.6040909@restena.lu> <010701cda507$27d9ed40$778dc7c0$@augustcellars.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "" Subject: Re: [Emu] Client Auth with TLS X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 13:14:18 -0000 Joseph Salowey (jsalowey) wrote: > I think it is worthwhile to support an mode of operation that supports peer privacy. I've seen this implemented in tunnel methods in two different ways. One with renegotiation as described below and the other as an inner EAP-TLS exchange after an anonymous outer exchange. I don't really have a strong opinion as to which is better at this point. It seems that using an inner EAP-TLS may be more flexible and would offer the same security properties and might be a simpler model. > > Any opinions on the list? The inner EAP-TLS has proven to work before. It seems fine. Alan DeKok. From stefan.winter@restena.lu Tue Oct 9 07:23:41 2012 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 005CB21F856D for ; Tue, 9 Oct 2012 07:23:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6fvq366llnag for ; Tue, 9 Oct 2012 07:23:38 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 6218721F8569 for ; Tue, 9 Oct 2012 07:23:35 -0700 (PDT) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id D5A0110581; Tue, 9 Oct 2012 16:23:33 +0200 (CEST) Received: from [IPv6:2001:a18:1:8:2854:2fb0:36ff:b938] (unknown [IPv6:2001:a18:1:8:2854:2fb0:36ff:b938]) by smtprelay.restena.lu (Postfix) with ESMTPS id C1C1D1057F; Tue, 9 Oct 2012 16:23:33 +0200 (CEST) Message-ID: <50743361.5020304@restena.lu> Date: Tue, 09 Oct 2012 16:23:29 +0200 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120825 Thunderbird/15.0 MIME-Version: 1.0 To: "Joseph Salowey (jsalowey)" References: <00e601cda1a3$5a230c80$0e692580$@augustcellars.com> <506D282C.6040909@restena.lu> <010701cda507$27d9ed40$778dc7c0$@augustcellars.com> In-Reply-To: X-Enigmail-Version: 1.4.4 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigCBF25ACE7D57365F4BAE7F67" X-Virus-Scanned: ClamAV Cc: "" Subject: Re: [Emu] Client Auth with TLS X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 14:23:41 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigCBF25ACE7D57365F4BAE7F67 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, > I think it is worthwhile to support an mode of operation that supports = peer privacy. I've seen this implemented in tunnel methods in two diffe= rent ways. One with renegotiation as described below and the other as an= inner EAP-TLS exchange after an anonymous outer exchange. I don't real= ly have a strong opinion as to which is better at this point. It seems t= hat using an inner EAP-TLS may be more flexible and would offer the same = security properties and might be a simpler model. =20 >=20 > Any opinions on the list? =20 We have a couple of EAP-TLS realms which are also interested in NEA. I usually tell them that NEA data can't be put into the EAP channel with EAP-TLS, and that that is bad luck for them :-) If TEAP uses tunneled EAP-TLS as opposed to renegotiating, the inner EAP would/might allow for carrying extra attributes besides the cert exchange - thus enabling NEA-like exchanges. If my thinking isn't borked, that would mean I'd rather support inner EAP-TLS to enable these usages. Greetings, Stefan >=20 >=20 >=20 > On Oct 7, 2012, at 8:43 PM, Jim Schaad wrote: >=20 >> Stefan, >> >> Thanks for the input. >> >> For the authors, >> >> Does this need to be documented as a mode of operation for TEAP or are= we >> going to say that this is not a supported mode? >> >> Jim >> >> >>> -----Original Message----- >>> From: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org] On Behalf Of= >>> Stefan Winter >>> Sent: Wednesday, October 03, 2012 11:10 PM >>> To: emu@ietf.org >>> Subject: Re: [Emu] Client Auth with TLS >>> >>> Hi, >>> >>>> 3. The client provides the certificate in a protected manner - I ha= d >>>> a problem at this point because I don't know enough TLS to properly = go >>>> through this scenario, and I could not really read documents while >>>> driving. If the encrypted certificate extension was used, then ther= e >>>> is no issue as the protected certificate would be passed in the >>>> initial handshake. However if the client starts the negotiation and= >>>> then restarts it after it is encrypted, I don't know if this occurs >> before or >>> after the finish message. >>>> If it starts after the finish method then there is an issue with >>>> having the server close an anonymous session if the client is then >>>> going to provide the certificate encrypted. Help on how this works >> would >>> be appreciated. >>> >>> FWIW, RFC5216 (EAP-TLS) already has provisions for a protected client= >>> credential exchange (for client privacy protection reasons). I didn't= ever >> see it >>> used (anyone?), but it's clearly a foreseen mode of operation. The te= xt >>> describing this is in section 2.1.4: >>> >>> "... In order to avoid disclosing the peer username, an EAP-TLS pe= er >>> configured for privacy MUST negotiate a TLS ciphersuite supporting >>> confidentiality and MUST provide a client certificate list containi= ng >>> no entries in response to the initial certificate_request from the >>> EAP-TLS server. >>> >>> An EAP-TLS server supporting privacy MUST NOT treat a certificate >>> list containing no entries as a terminal condition; instead, it MUS= T >>> bring up the TLS session and then send a hello_request. The >>> handshake then proceeds normally; the peer sends a client_hello and= >>> the server replies with a server_hello, certificate, >>> server_key_exchange, certificate_request, server_hello_done, etc. >>> >>> For the calculation of exported keying material (see Section 2.3), >>> the master_secret derived within the second handshake is used. >>> >>> An EAP-TLS peer supporting privacy MUST provide a certificate list >>> containing at least one entry in response to the subsequent >>> certificate_request sent by the server. If the EAP-TLS server >>> supporting privacy does not receive a client certificate in respons= e >>> to the subsequent certificate_request, then it MUST abort the >>> session. >>> " >>> >>> There is a sequence diagram shortly afterwards which shows clearly th= at >> the >>> "first" negotiation ends with a 'finished' and then immediately a new= >>> 'hello_request' - all in one EAP message. >>> >>> Greetings, >>> >>> Stefan >>> >>>> >>>> Jim >>>> >>>> >>>> _______________________________________________ >>>> Emu mailing list >>>> Emu@ietf.org >>>> https://www.ietf.org/mailman/listinfo/emu >>>> >>> >>> >>> -- >>> Stefan WINTER >>> Ingenieur de Recherche >>> Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education Nati= onale et de >>> la Recherche 6, rue Richard Coudenhove-Kalergi >>> L-1359 Luxembourg >>> >>> Tel: +352 424409 1 >>> Fax: +352 422473 >> >> >> _______________________________________________ >> Emu mailing list >> Emu@ietf.org >> https://www.ietf.org/mailman/listinfo/emu >=20 --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 --------------enigCBF25ACE7D57365F4BAE7F67 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlB0M2UACgkQ+jm90f8eFWZvyQCdHpxtOUKTrzNJFnJDwViIxvPz EvEAoID8+uuYE/7O1Lshf30xZh2HBPsB =ehAs -----END PGP SIGNATURE----- --------------enigCBF25ACE7D57365F4BAE7F67-- From hzhou@cisco.com Tue Oct 9 08:14:43 2012 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0422421F86D4 for ; Tue, 9 Oct 2012 08:14:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kF5061nqKeqI for ; Tue, 9 Oct 2012 08:14:42 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 6429021F86DC for ; Tue, 9 Oct 2012 08:14:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6780; q=dns/txt; s=iport; t=1349795681; x=1351005281; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=8DhY/eZ6HteM7XlxKhNQcohf+xzKdRb3IINTqSQewJ0=; b=U4CqS6ms+2DOA6NCpb0eZYYsvP/0YCcC9cLe7YgMtvLlZQhUC+AbPZ6U +rH9gsi2Vm5YCAWVIUxkvl0y8JRqFBA+N8XkCutHTH00UOQ7gH0dMe4es S5Bne+js3MOavSPul5h9Bviw4BdijOKt5htx+h51A5GWm+Um33ndvPTr9 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAN8+dFCtJXHB/2dsb2JhbAA8Cb8vgQiCIAEBAQQBAQEJBgFUBwsMBgEIEQQBAQEKHS4LFAkIAQEEAQ0FCA4Mh2MLm2OPVpBAizkRhSJgA4gjihaERo0wgWuCbYIX X-IronPort-AV: E=Sophos;i="4.80,560,1344211200"; d="scan'208";a="129806780" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-3.cisco.com with ESMTP; 09 Oct 2012 15:14:40 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id q99FEeow022411 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 9 Oct 2012 15:14:40 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.51]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0318.001; Tue, 9 Oct 2012 10:14:40 -0500 From: "Hao Zhou (hzhou)" To: Stefan Winter , "Joseph Salowey (jsalowey)" Thread-Topic: [Emu] Client Auth with TLS Thread-Index: Ac2hoi1rLrNrqIMITdOHfDt5EorDlAAfpbkAAMQSaoAAM6O3gAAU/MOA///LO4A= Date: Tue, 9 Oct 2012 15:14:39 +0000 Message-ID: <645B00545719594A88ADF4221831FD3814BC40@xmb-rcd-x14.cisco.com> In-Reply-To: <50743361.5020304@restena.lu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 x-originating-ip: [64.101.219.104] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19254.003 x-tm-as-result: No--55.128500-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-ID: <417656A4DE2A0F429463A3AED401BC10@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [Emu] Client Auth with TLS X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 15:14:43 -0000 Stefan: Actually even if the client is authenticated as part of the TLS tunnel establishment, NEA data can still be passed inside TEAP tunnel. It is designed to carry additional data in Phase 2. The Current TEAP draft supports both of these modes, as in Section 3.2: "TEAP implementations MUST support client authentication during tunnel establishment using the TLS ciphersuites specified in Section 3.2 . The EAP peer does not need to authenticate as part of the TLS exchange, but can alternatively be authenticated through additional exchanges carried out in Phase 2. The TEAP tunnel protects peer identity information exchanged during phase 2 from disclosure outside the tunnel. Implementations that wish to provide identity privacy for the peer identity must carefully consider what information is disclosed outside the tunnel prior to phase 2. TEAP implementations SHOULD support the immediate renegotiation of a TLS session to initiate a new handshake message exchange under the protection of the current cipher suite. This allows support for protection of the peer's identity when using TLS client authentication." It properly doesn't describes the TLS exchanges as detailed as in EAP-TLS RFC, but something we could improve if desired. On 10/9/12 10:23 AM, "Stefan Winter" wrote: >Hi, > >> I think it is worthwhile to support an mode of operation that supports >>peer privacy. I've seen this implemented in tunnel methods in two >>different ways. One with renegotiation as described below and the other >>as an inner EAP-TLS exchange after an anonymous outer exchange. I >>don't really have a strong opinion as to which is better at this point. >>It seems that using an inner EAP-TLS may be more flexible and would >>offer the same security properties and might be a simpler model. >>=20 >> Any opinions on the list? > >We have a couple of EAP-TLS realms which are also interested in NEA. I >usually tell them that NEA data can't be put into the EAP channel with >EAP-TLS, and that that is bad luck for them :-) > >If TEAP uses tunneled EAP-TLS as opposed to renegotiating, the inner EAP >would/might allow for carrying extra attributes besides the cert >exchange - thus enabling NEA-like exchanges. > >If my thinking isn't borked, that would mean I'd rather support inner >EAP-TLS to enable these usages. > >Greetings, > >Stefan > >>=20 >>=20 >>=20 >> On Oct 7, 2012, at 8:43 PM, Jim Schaad wrote: >>=20 >>> Stefan, >>> >>> Thanks for the input. >>> >>> For the authors, >>> >>> Does this need to be documented as a mode of operation for TEAP or are >>>we >>> going to say that this is not a supported mode? >>> >>> Jim >>> >>> >>>> -----Original Message----- >>>> From: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org] On Behalf Of >>>> Stefan Winter >>>> Sent: Wednesday, October 03, 2012 11:10 PM >>>> To: emu@ietf.org >>>> Subject: Re: [Emu] Client Auth with TLS >>>> >>>> Hi, >>>> >>>>> 3. The client provides the certificate in a protected manner - I had >>>>> a problem at this point because I don't know enough TLS to properly >>>>>go >>>>> through this scenario, and I could not really read documents while >>>>> driving. If the encrypted certificate extension was used, then there >>>>> is no issue as the protected certificate would be passed in the >>>>> initial handshake. However if the client starts the negotiation and >>>>> then restarts it after it is encrypted, I don't know if this occurs >>> before or >>>> after the finish message. >>>>> If it starts after the finish method then there is an issue with >>>>> having the server close an anonymous session if the client is then >>>>> going to provide the certificate encrypted. Help on how this works >>> would >>>> be appreciated. >>>> >>>> FWIW, RFC5216 (EAP-TLS) already has provisions for a protected client >>>> credential exchange (for client privacy protection reasons). I didn't >>>>ever >>> see it >>>> used (anyone?), but it's clearly a foreseen mode of operation. The >>>>text >>>> describing this is in section 2.1.4: >>>> >>>> "... In order to avoid disclosing the peer username, an EAP-TLS >>>>peer >>>> configured for privacy MUST negotiate a TLS ciphersuite supporting >>>> confidentiality and MUST provide a client certificate list >>>>containing >>>> no entries in response to the initial certificate_request from the >>>> EAP-TLS server. >>>> >>>> An EAP-TLS server supporting privacy MUST NOT treat a certificate >>>> list containing no entries as a terminal condition; instead, it MUST >>>> bring up the TLS session and then send a hello_request. The >>>> handshake then proceeds normally; the peer sends a client_hello and >>>> the server replies with a server_hello, certificate, >>>> server_key_exchange, certificate_request, server_hello_done, etc. >>>> >>>> For the calculation of exported keying material (see Section 2.3), >>>> the master_secret derived within the second handshake is used. >>>> >>>> An EAP-TLS peer supporting privacy MUST provide a certificate list >>>> containing at least one entry in response to the subsequent >>>> certificate_request sent by the server. If the EAP-TLS server >>>> supporting privacy does not receive a client certificate in response >>>> to the subsequent certificate_request, then it MUST abort the >>>> session. >>>> " >>>> >>>> There is a sequence diagram shortly afterwards which shows clearly >>>>that >>> the >>>> "first" negotiation ends with a 'finished' and then immediately a new >>>> 'hello_request' - all in one EAP message. >>>> >>>> Greetings, >>>> >>>> Stefan >>>> >>>>> >>>>> Jim >>>>> >>>>> >>>>> _______________________________________________ >>>>> Emu mailing list >>>>> Emu@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/emu >>>>> >>>> >>>> >>>> -- >>>> Stefan WINTER >>>> Ingenieur de Recherche >>>> Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education Natio= nale >>>>et de >>>> la Recherche 6, rue Richard Coudenhove-Kalergi >>>> L-1359 Luxembourg >>>> >>>> Tel: +352 424409 1 >>>> Fax: +352 422473 >>> >>> >>> _______________________________________________ >>> Emu mailing list >>> Emu@ietf.org >>> https://www.ietf.org/mailman/listinfo/emu >>=20 > > >--=20 >Stefan WINTER >Ingenieur de Recherche >Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education Nationale= et >de la Recherche >6, rue Richard Coudenhove-Kalergi >L-1359 Luxembourg > >Tel: +352 424409 1 >Fax: +352 422473 > From ietf@augustcellars.com Tue Oct 9 09:36:34 2012 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67E3621F85F7 for ; Tue, 9 Oct 2012 09:36:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.057 X-Spam-Level: X-Spam-Status: No, score=-3.057 tagged_above=-999 required=5 tests=[AWL=0.542, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0LDzDv7FNfER for ; Tue, 9 Oct 2012 09:36:33 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id 84CFD21F85B8 for ; Tue, 9 Oct 2012 09:36:33 -0700 (PDT) Received: from Tobias (winery.augustcellars.com [206.212.239.129]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id CE1702CA2E; Tue, 9 Oct 2012 09:36:32 -0700 (PDT) From: "Jim Schaad" To: "'Joseph Salowey \(jsalowey\)'" References: <00e601cda1a3$5a230c80$0e692580$@augustcellars.com> <506D282C.6040909@restena.lu> <010701cda507$27d9ed40$778dc7c0$@augustcellars.com> In-Reply-To: Date: Tue, 9 Oct 2012 09:35:06 -0700 Message-ID: <01b301cda63c$0ab86e40$20294ac0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQETIlXkRdUEOAmqRJpEVJ8MvvMTfAJlURHyAiqX210CoPuTWZjsrDLQ Content-Language: en-us Cc: emu@ietf.org Subject: Re: [Emu] Client Auth with TLS X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 16:36:34 -0000 > -----Original Message----- > From: Joseph Salowey (jsalowey) [mailto:jsalowey@cisco.com] > Sent: Monday, October 08, 2012 9:23 PM > To: Jim Schaad > Cc: Stefan Winter; > Subject: Re: [Emu] Client Auth with TLS >=20 > I think it is worthwhile to support an mode of operation that supports peer > privacy. I've seen this implemented in tunnel methods in two = different > ways. One with renegotiation as described below and the other as an = inner > EAP-TLS exchange after an anonymous outer exchange. I don't really = have a > strong opinion as to which is better at this point. It seems that = using an inner > EAP-TLS may be more flexible and would offer the same security = properties > and might be a simpler model. >=20 > Any opinions on the list? Are you suggesting an inner EAP-TLS or an inner TEAP? Jim >=20 >=20 >=20 > On Oct 7, 2012, at 8:43 PM, Jim Schaad wrote: >=20 > > Stefan, > > > > Thanks for the input. > > > > For the authors, > > > > Does this need to be documented as a mode of operation for TEAP or = are > > we going to say that this is not a supported mode? > > > > Jim > > > > > >> -----Original Message----- > >> From: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org] On Behalf > Of > >> Stefan Winter > >> Sent: Wednesday, October 03, 2012 11:10 PM > >> To: emu@ietf.org > >> Subject: Re: [Emu] Client Auth with TLS > >> > >> Hi, > >> > >>> 3. The client provides the certificate in a protected manner - I > >>> had a problem at this point because I don't know enough TLS to > >>> properly go through this scenario, and I could not really read > >>> documents while driving. If the encrypted certificate extension = was > >>> used, then there is no issue as the protected certificate would be > >>> passed in the initial handshake. However if the client starts the > >>> negotiation and then restarts it after it is encrypted, I don't = know > >>> if this occurs > > before or > >> after the finish message. > >>> If it starts after the finish method then there is an issue with > >>> having the server close an anonymous session if the client is then > >>> going to provide the certificate encrypted. Help on how this = works > > would > >> be appreciated. > >> > >> FWIW, RFC5216 (EAP-TLS) already has provisions for a protected = client > >> credential exchange (for client privacy protection reasons). I = didn't > >> ever > > see it > >> used (anyone?), but it's clearly a foreseen mode of operation. The > >> text describing this is in section 2.1.4: > >> > >> "... In order to avoid disclosing the peer username, an EAP-TLS = peer > >> configured for privacy MUST negotiate a TLS ciphersuite = supporting > >> confidentiality and MUST provide a client certificate list = containing > >> no entries in response to the initial certificate_request from = the > >> EAP-TLS server. > >> > >> An EAP-TLS server supporting privacy MUST NOT treat a certificate > >> list containing no entries as a terminal condition; instead, it = MUST > >> bring up the TLS session and then send a hello_request. The > >> handshake then proceeds normally; the peer sends a client_hello = and > >> the server replies with a server_hello, certificate, > >> server_key_exchange, certificate_request, server_hello_done, etc. > >> > >> For the calculation of exported keying material (see Section = 2.3), > >> the master_secret derived within the second handshake is used. > >> > >> An EAP-TLS peer supporting privacy MUST provide a certificate = list > >> containing at least one entry in response to the subsequent > >> certificate_request sent by the server. If the EAP-TLS server > >> supporting privacy does not receive a client certificate in = response > >> to the subsequent certificate_request, then it MUST abort the > >> session. > >> " > >> > >> There is a sequence diagram shortly afterwards which shows clearly > >> that > > the > >> "first" negotiation ends with a 'finished' and then immediately a = new > >> 'hello_request' - all in one EAP message. > >> > >> Greetings, > >> > >> Stefan > >> > >>> > >>> Jim > >>> > >>> > >>> _______________________________________________ > >>> Emu mailing list > >>> Emu@ietf.org > >>> https://www.ietf.org/mailman/listinfo/emu > >>> > >> > >> > >> -- > >> Stefan WINTER > >> Ingenieur de Recherche > >> Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education = Nationale > >> et de la Recherche 6, rue Richard Coudenhove-Kalergi > >> L-1359 Luxembourg > >> > >> Tel: +352 424409 1 > >> Fax: +352 422473 > > > > > > _______________________________________________ > > Emu mailing list > > Emu@ietf.org > > https://www.ietf.org/mailman/listinfo/emu From jsalowey@cisco.com Tue Oct 9 09:43:37 2012 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16D5321F8804 for ; Tue, 9 Oct 2012 09:43:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.46 X-Spam-Level: X-Spam-Status: No, score=-110.46 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CQ3ONXjdtwTE for ; Tue, 9 Oct 2012 09:43:36 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 1EFC021F8803 for ; Tue, 9 Oct 2012 09:43:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5010; q=dns/txt; s=iport; t=1349801016; x=1351010616; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=bBlXjLsktY+bp7GL8W/SNoX+Yym3zwED+JzuFpk9eEY=; b=BXdm0g6UYOeKsog31/TwmI4NMZ+k5oEsiis+0j22SfHQeK2cjQtUz7+0 HPPS1BLkd0qqDbEUOo+NofFyWoOwVn7LcX50wtKZEruDNYQZUGe264HR1 VFo/uHC2sDeWXBSn2OQmiujtK/mtsaU+Tfo0o4Lv6mrw6d1Xd6DXpCvOv A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EALZTdFCtJXHA/2dsb2JhbABFvy+BCIIgAQEBAwEBAQEJBgFbCwUHBAIBCA4DBAEBAQodBycLFAkIAgQOBQgODIddBgubeo9WkDkEizmFM2ADiCOKFpF2gWuCbYIX X-IronPort-AV: E=Sophos;i="4.80,561,1344211200"; d="scan'208";a="129821203" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-7.cisco.com with ESMTP; 09 Oct 2012 16:43:35 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id q99GhZI6000405 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 9 Oct 2012 16:43:35 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.68]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0318.001; Tue, 9 Oct 2012 11:43:35 -0500 From: "Joseph Salowey (jsalowey)" To: Jim Schaad Thread-Topic: [Emu] Client Auth with TLS Thread-Index: AQETIlXkRdUEOAmqRJpEVJ8MvvMTfAJlURHymRCe5mCAAfEZAIAAzLIAgAACXQA= Date: Tue, 9 Oct 2012 16:43:35 +0000 Message-ID: References: <00e601cda1a3$5a230c80$0e692580$@augustcellars.com> <506D282C.6040909@restena.lu> <010701cda507$27d9ed40$778dc7c0$@augustcellars.com> <01b301cda63c$0ab86e40$20294ac0$@augustcellars.com> In-Reply-To: <01b301cda63c$0ab86e40$20294ac0$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.248.63] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19254.003 x-tm-as-result: No--57.758600-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [Emu] Client Auth with TLS X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 16:43:37 -0000 On Oct 9, 2012, at 9:35 AM, Jim Schaad wrote: >=20 >=20 >> -----Original Message----- >> From: Joseph Salowey (jsalowey) [mailto:jsalowey@cisco.com] >> Sent: Monday, October 08, 2012 9:23 PM >> To: Jim Schaad >> Cc: Stefan Winter; >> Subject: Re: [Emu] Client Auth with TLS >>=20 >> I think it is worthwhile to support an mode of operation that supports > peer >> privacy. I've seen this implemented in tunnel methods in two different >> ways. One with renegotiation as described below and the other as an inn= er >> EAP-TLS exchange after an anonymous outer exchange. I don't really hav= e > a >> strong opinion as to which is better at this point. It seems that using > an inner >> EAP-TLS may be more flexible and would offer the same security propertie= s >> and might be a simpler model. >>=20 >> Any opinions on the list? >=20 > Are you suggesting an inner EAP-TLS or an inner TEAP? >=20 [Joe] EAP-TLS as an inner method.=20 > Jim >=20 >>=20 >>=20 >>=20 >> On Oct 7, 2012, at 8:43 PM, Jim Schaad wrote: >>=20 >>> Stefan, >>>=20 >>> Thanks for the input. >>>=20 >>> For the authors, >>>=20 >>> Does this need to be documented as a mode of operation for TEAP or are >>> we going to say that this is not a supported mode? >>>=20 >>> Jim >>>=20 >>>=20 >>>> -----Original Message----- >>>> From: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org] On Behalf >> Of >>>> Stefan Winter >>>> Sent: Wednesday, October 03, 2012 11:10 PM >>>> To: emu@ietf.org >>>> Subject: Re: [Emu] Client Auth with TLS >>>>=20 >>>> Hi, >>>>=20 >>>>> 3. The client provides the certificate in a protected manner - I >>>>> had a problem at this point because I don't know enough TLS to >>>>> properly go through this scenario, and I could not really read >>>>> documents while driving. If the encrypted certificate extension was >>>>> used, then there is no issue as the protected certificate would be >>>>> passed in the initial handshake. However if the client starts the >>>>> negotiation and then restarts it after it is encrypted, I don't know >>>>> if this occurs >>> before or >>>> after the finish message. >>>>> If it starts after the finish method then there is an issue with >>>>> having the server close an anonymous session if the client is then >>>>> going to provide the certificate encrypted. Help on how this works >>> would >>>> be appreciated. >>>>=20 >>>> FWIW, RFC5216 (EAP-TLS) already has provisions for a protected client >>>> credential exchange (for client privacy protection reasons). I didn't >>>> ever >>> see it >>>> used (anyone?), but it's clearly a foreseen mode of operation. The >>>> text describing this is in section 2.1.4: >>>>=20 >>>> "... In order to avoid disclosing the peer username, an EAP-TLS pee= r >>>> configured for privacy MUST negotiate a TLS ciphersuite supporting >>>> confidentiality and MUST provide a client certificate list containing >>>> no entries in response to the initial certificate_request from the >>>> EAP-TLS server. >>>>=20 >>>> An EAP-TLS server supporting privacy MUST NOT treat a certificate >>>> list containing no entries as a terminal condition; instead, it MUST >>>> bring up the TLS session and then send a hello_request. The >>>> handshake then proceeds normally; the peer sends a client_hello and >>>> the server replies with a server_hello, certificate, >>>> server_key_exchange, certificate_request, server_hello_done, etc. >>>>=20 >>>> For the calculation of exported keying material (see Section 2.3), >>>> the master_secret derived within the second handshake is used. >>>>=20 >>>> An EAP-TLS peer supporting privacy MUST provide a certificate list >>>> containing at least one entry in response to the subsequent >>>> certificate_request sent by the server. If the EAP-TLS server >>>> supporting privacy does not receive a client certificate in response >>>> to the subsequent certificate_request, then it MUST abort the >>>> session. >>>> " >>>>=20 >>>> There is a sequence diagram shortly afterwards which shows clearly >>>> that >>> the >>>> "first" negotiation ends with a 'finished' and then immediately a new >>>> 'hello_request' - all in one EAP message. >>>>=20 >>>> Greetings, >>>>=20 >>>> Stefan >>>>=20 >>>>>=20 >>>>> Jim >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> Emu mailing list >>>>> Emu@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/emu >>>>>=20 >>>>=20 >>>>=20 >>>> -- >>>> Stefan WINTER >>>> Ingenieur de Recherche >>>> Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education Natio= nale >>>> et de la Recherche 6, rue Richard Coudenhove-Kalergi >>>> L-1359 Luxembourg >>>>=20 >>>> Tel: +352 424409 1 >>>> Fax: +352 422473 >>>=20 >>>=20 >>> _______________________________________________ >>> Emu mailing list >>> Emu@ietf.org >>> https://www.ietf.org/mailman/listinfo/emu >=20 From hzhou@cisco.com Tue Oct 9 11:43:00 2012 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97A431F0C3E for ; Tue, 9 Oct 2012 11:43:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P-cvcTHz2RNz for ; Tue, 9 Oct 2012 11:42:59 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 9A5C921F87E3 for ; Tue, 9 Oct 2012 11:42:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5271; q=dns/txt; s=iport; t=1349808179; x=1351017779; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=dtbC8tc5JFsl4T5lZsQi8uPBhv7Q2u5jSRwKNltsAJs=; b=hPSm/32teEHIJOu19kO6SvVJoFJURbULhPrgeQBnEDIHfDGxBANsgBjH KoksacJLnlhYOIkTjpWkV8dwcFI9roczH7gUfgXd18PsBQi9WkYrZbpac 3jMmOkm1e6Pi1d4AeEIpXFItzMngq1cpevVEL3xePtGK50KC7Eb4BuiG1 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAIhvdFCtJV2Y/2dsb2JhbABFvy6BCIIgAQEBBAEBAQ8BJzQXBgEIDgMEAQEBChQJLgsUCQgBAQQBEggah2MLmmCPWJA5BItDJIUPYAOSOpF2gWuCbYIX X-IronPort-AV: E=Sophos;i="4.80,561,1344211200"; d="scan'208";a="126868882" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-9.cisco.com with ESMTP; 09 Oct 2012 18:42:56 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q99IguPS021347 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 9 Oct 2012 18:42:56 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.51]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0318.001; Tue, 9 Oct 2012 13:42:55 -0500 From: "Hao Zhou (hzhou)" To: Jim Schaad , "emu@ietf.org" , "draft-ietf-emu-eap-tunnel-method@tools.ietf.org" Thread-Topic: [Emu] More comments for eap-tunnel-method Thread-Index: Ac2fNa8k+p3Xv8iySJGSGMwihVHFRQDTa+8AAK58ngAARjzJgA== Date: Tue, 9 Oct 2012 18:42:54 +0000 Message-ID: <645B00545719594A88ADF4221831FD3814BDB3@xmb-rcd-x14.cisco.com> In-Reply-To: <011201cda513$6ae55af0$40b010d0$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 x-originating-ip: [64.101.219.104] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19254.003 x-tm-as-result: No--53.895000-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <5665CFACC092E54690AFE240048A3B49@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Emu] More comments for eap-tunnel-method X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 18:43:01 -0000 Jim: Please see comments inline below. On 10/8/12 1:11 AM, "Jim Schaad" wrote: > > >> -----Original Message----- >> From: Hao Zhou (hzhou) [mailto:hzhou@cisco.com] >> Sent: Thursday, October 04, 2012 2:56 PM >> To: Jim Schaad; emu@ietf.org; draft-ietf-emu-eap-tunnel- >> method@tools.ietf.org >> Subject: Re: [Emu] More comments for eap-tunnel-method >>=20 >> Jim: >>=20 >> Thanks for the review. Please see my comments below. >>=20 >> On 9/30/12 2:01 PM, "Jim Schaad" wrote: >>=20 >> >1. Should the Message Length field be present if the TLS Data field is >> >absent? >> [HZ] According to the text in the draft, the message length field should >only >> be present if the L bit is set, usually for fragmented packets. In those >cases, >> the TLS data field will be present, not absent. The only case TLS data >will be >> absent is when empty TEAP packet it is used to >> indicate TEAP acknowledgement for either a fragmented message, >> a TLS Alert message or a TLS Finished message. So the message >length >> field is not needed. We can clarify that in the draft. >>=20 > >[JLS] I am not clear - are you saying that the first sever message sent >with just TLVs cannot be fragmented? [HZ] No, they can be fragmented. However, currently, Outer TLVs are only allowed in the first 2 messages in TEAP exchanges, 1st server to peer with TEAP start, and 2nd message client to server with Client_hello. It is unlikely the first server message will have lots of outer TLVs that needs the fragmentation (only one or two outer TLV is being defined so far). The 2nd message from client to server with client _hello might if the ticket extension is too big, but unlikely. =20 > >[JLS] There is a potential issue in the way that the Message Length field >is described. For finding the location of the Outer TLVs it provides the >length of the TLS Data field, but the internal description says that it >gives the length of the message data in the event of a fragmented message. >If the first client response message is both fragmented on length and >contains TLVs, then the message length field must be the length of the TLS >data in order to find the Outer TLV data but that means it is not the >length >of all of the fragmented data. This is not an issue after the first pair >of >messages as the Outer TLVs are no longer allowed at that point. [HZ] The message length is the total length of the TEAP packet if fragmented, to provide a hint for the peer to allocate the buffer. The start of the outer TLV can be calculated from the EAP message length and length field inside the TLS data, not dependent on the Message Length field. The current draft text in Section 4.1 Outer TLVs description incorrectly refers to message length field, will need to be corrected. Since Outer TLVs only occur in the first 2 TEAP exchanges, the TLS data is one type and relatively simple, it should not be too hard to figure out the start. > >[JLS] I presume that the Length needs to be present only if the message is >fragmented as a hint to the receiver on the length of the buffer to >allocate >as I don't remember any error checks that the length of the message match >the re-constructed message from the fragments (and if it did then the >previous paragraph makes that faulty). Should there be an error check on >the message length w/ the length of the re-constructed buffer? [HZ] I don't know if current TLS implementations do check for that error. Message length is only used for a hint. The EAP-TLS RFC doesn't cover that either. Thought it did provide more detailed description of the message length and L bit description, something we could use for the TEAP draft. > > >> > >> >2. There is nothing to say which TLVs can and cannot occur in the >> >Outer TLVs in any easily findable method. Either a table or the string >> >outer in descriptions would be helpful. As an example, does the >> >Authority-ID TLV in the outer TLV make sense? >> [HZ] We will add that table. >> > >> >3. I have gone through the fragmentation and did an implementation >> >rather than just reading it. The questions that I have on it now are >> >slightly different. Do TLVs need to be on a fragment boundary? Or do >> >we just build the entire message, fragment it into convenient sizes >> >regardless of the actual content of the message contents and sent the >> >pieces across? If so then the text should probably be re-written to be >> >clearer. Specifically, the message length is not useful for allocating >> >the buffer on the first round trip of messages where one can have a TLV >> added in to the content. >> >[HZ] Message length covers the whole TEAP packet even if fragmented. >> >TLVs do not need to be on a fragment boundary. Just build the whole >> >message contents and send the pieces across. We will provide some text >> >to clarify this. > >[JLS] - see note above about finding the start of the Outer TLV data block >on the first pair of messages. > >> > >> > >> >_______________________________________________ >> >Emu mailing list >> >Emu@ietf.org >> >https://www.ietf.org/mailman/listinfo/emu > From hzhou@cisco.com Tue Oct 9 11:57:48 2012 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DB8711E813A for ; Tue, 9 Oct 2012 11:57:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h8OJAnjFkn4X for ; Tue, 9 Oct 2012 11:57:47 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 8FB8D11E80A4 for ; Tue, 9 Oct 2012 11:57:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3132; q=dns/txt; s=iport; t=1349809067; x=1351018667; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=k7KpjNfmbUe9ZYVBTkwS+zsz1LabGbYkXJAln6iya8Y=; b=JoqWxID5DKoiRwXbhxfUB0DPIFYBDsrPgHL0V243LUBfr31Uzq38nXKe nGlzBAD+S/ovFsT/FPU4lW9v90Wa6mDCVhkor5HzxFkza9oH0Ulhl61uw nC+AVfoknhuQra9ELmJGnPOz1+fHgYTNP7p/QQuH13XgjrzBpyEpjnxxT 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAOBydFCtJXG9/2dsb2JhbAA8Cb8ugQiCIAEBAQQBAQEPASc0FwYBCA4DBAEBAQoOBgkuCxQJCAEBBAESCBqHYwuaRo9YkDYEi0MRgmOCP2ADkjqRdoFrgm2CFw X-IronPort-AV: E=Sophos;i="4.80,561,1344211200"; d="scan'208";a="129914380" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-4.cisco.com with ESMTP; 09 Oct 2012 18:57:47 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id q99IvlOi009329 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 9 Oct 2012 18:57:47 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.51]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.02.0318.001; Tue, 9 Oct 2012 13:57:46 -0500 From: "Hao Zhou (hzhou)" To: Jim Schaad , "emu@ietf.org" , "draft-ietf-emu-eap-tunnel-method@tools.ietf.org" Thread-Topic: [Emu] More COmments 2 on eap-tunnel-method Thread-Index: Ac2f9v+FDIoykt+NRVmWduL9qgMM2ACjc+4AAK4ghwAARsIAgA== Date: Tue, 9 Oct 2012 18:57:46 +0000 Message-ID: <645B00545719594A88ADF4221831FD3814BE56@xmb-rcd-x14.cisco.com> In-Reply-To: <011101cda513$6aace5d0$4006b170$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 x-originating-ip: [64.101.219.104] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19254.003 x-tm-as-result: No--40.824000-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <3FEA07BE1715174F84A37CB92481290F@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Emu] More COmments 2 on eap-tunnel-method X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 18:57:48 -0000 Agree. We will clarify that. On 10/8/12 1:11 AM, "Jim Schaad" wrote: > > >> -----Original Message----- >> From: Hao Zhou (hzhou) [mailto:hzhou@cisco.com] >> Sent: Thursday, October 04, 2012 3:06 PM >> To: Jim Schaad; emu@ietf.org; draft-ietf-emu-eap-tunnel- >> method@tools.ietf.org >> Subject: Re: [Emu] More COmments 2 on eap-tunnel-method >>=20 >> Jim: >>=20 >> Please see comments below. >>=20 >> On 10/1/12 1:10 PM, "Jim Schaad" wrote: >>=20 >> >I found two that I forgot to include in the last message >> > >> >1. When exporting the user-id, does there need to be a way to >> >distinguish at export time between the different types of ids that are >> >authenticated by the server? This does not seem to be an issue on the >> >peer as it will only do mutual authentication to servers and thus only >> >have server ids, however a server may authenticate to different types >> >of identities on the peer. At the moment we have identified user and >> >machines as types of entities to be identified, I suppose in the future >> >we could add Ewoks as a different type of entity that could be >> >identified. However the export function of user-ids does not make a >> >distinction between the different types of authenticated entities. >> >Should it do so or should it just export user authentications? >> [HZ] It helps to export the identities as well as the corresponding >identity >> types (from the Identity Type TLV). Will add text. >> > >> >2. Is there a map of TLVs that should not be sent together or need to >> >be processed in a specific order? The case I was looking at was for >> >the Identity TLV and the EAP TLV. Is there a difference in how a peer >> >should react for the following? >> > >> > Identity TLV (Send me a machine Identity), EAP TLV (Start the EAP >> >type >> >XX) >> > EAP TLV (Start EAP type XXX), Identity TLV (Send me a machine >> >Identity) >> > >> >Or should these two TLVs never occur in a single message? >> [HZ] We had some discussion in WG and take the design principal of TLV >> ordering should not matter. We disallow simultaneous EAP inner methods >> and/or with Basic Password Authentication, so rest of the TLVs order >should >> not matter. If it does matter, it should be a nested TLV, as in Result >>TLV >and >> Request-Action TLV. Need to add text to disallow Inner EAP method with >> parallel Basic Password Authentication TLV. > >[JLS] If order of TLVs does not matter, then there is an implied order >that >the TLVs should be processed. That is one should always process the >Identity TLV before processing the EAP TLV as the identity TLV is a hint >to >the type of identity that is to be used in the EAP method. Conversely it >might be that these two TLVs should never occur in the same message. > >Ditto with the Basic Password Authentication TLV and the Identity TLV. > >Jim > >> > >> >Jim >> > >> > >> >_______________________________________________ >> >Emu mailing list >> >Emu@ietf.org >> >https://www.ietf.org/mailman/listinfo/emu > From ietf@augustcellars.com Tue Oct 9 12:32:45 2012 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CFC611E80A4 for ; Tue, 9 Oct 2012 12:32:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.22 X-Spam-Level: X-Spam-Status: No, score=-3.22 tagged_above=-999 required=5 tests=[AWL=0.379, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 507Ny1IBmJKa for ; Tue, 9 Oct 2012 12:32:44 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3BE621F0C70 for ; Tue, 9 Oct 2012 12:32:44 -0700 (PDT) Received: from Tobias (winery.augustcellars.com [206.212.239.129]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id D84362C9BB; Tue, 9 Oct 2012 12:32:43 -0700 (PDT) From: "Jim Schaad" To: "'Hao Zhou \(hzhou\)'" , , References: <011201cda513$6ae55af0$40b010d0$@augustcellars.com> <645B00545719594A88ADF4221831FD3814BDB3@xmb-rcd-x14.cisco.com> In-Reply-To: <645B00545719594A88ADF4221831FD3814BDB3@xmb-rcd-x14.cisco.com> Date: Tue, 9 Oct 2012 12:31:15 -0700 Message-ID: <01cf01cda654$a757df70$f6079e50$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHpN/7utST7KeZjhBFR1Jd+EUlpMZd6OP4g Content-Language: en-us Subject: Re: [Emu] More comments for eap-tunnel-method X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 19:32:45 -0000 There does not seem to be anything in the TEAP document about the length of the TLS data. Are you suggesting that one should crack the TLS data blob to find the length of that data blob? Jim > -----Original Message----- > From: Hao Zhou (hzhou) [mailto:hzhou@cisco.com] > Sent: Tuesday, October 09, 2012 11:43 AM > To: Jim Schaad; emu@ietf.org; draft-ietf-emu-eap-tunnel- > method@tools.ietf.org > Subject: Re: [Emu] More comments for eap-tunnel-method > > Jim: > > Please see comments inline below. > > On 10/8/12 1:11 AM, "Jim Schaad" wrote: > > > > > > >> -----Original Message----- > >> From: Hao Zhou (hzhou) [mailto:hzhou@cisco.com] > >> Sent: Thursday, October 04, 2012 2:56 PM > >> To: Jim Schaad; emu@ietf.org; draft-ietf-emu-eap-tunnel- > >> method@tools.ietf.org > >> Subject: Re: [Emu] More comments for eap-tunnel-method > >> > >> Jim: > >> > >> Thanks for the review. Please see my comments below. > >> > >> On 9/30/12 2:01 PM, "Jim Schaad" wrote: > >> > >> >1. Should the Message Length field be present if the TLS Data field > >> >is absent? > >> [HZ] According to the text in the draft, the message length field > >> should > >only > >> be present if the L bit is set, usually for fragmented packets. In > >> those > >cases, > >> the TLS data field will be present, not absent. The only case TLS > >> data > >will be > >> absent is when empty TEAP packet it is used to > >> indicate TEAP acknowledgement for either a fragmented message, > >> a TLS Alert message or a TLS Finished message. So the > >> message > >length > >> field is not needed. We can clarify that in the draft. > >> > > > >[JLS] I am not clear - are you saying that the first sever message > >sent with just TLVs cannot be fragmented? > [HZ] No, they can be fragmented. However, currently, Outer TLVs are only > allowed in the first 2 messages in TEAP exchanges, 1st server to peer with > TEAP start, and 2nd message client to server with Client_hello. It is unlikely > the first server message will have lots of outer TLVs that needs the > fragmentation (only one or two outer TLV is being defined so far). The 2nd > message from client to server with client _hello might if the ticket extension > is too big, but unlikely. > > > > >[JLS] There is a potential issue in the way that the Message Length > >field is described. For finding the location of the Outer TLVs it > >provides the length of the TLS Data field, but the internal description > >says that it gives the length of the message data in the event of a > fragmented message. > >If the first client response message is both fragmented on length and > >contains TLVs, then the message length field must be the length of the > >TLS data in order to find the Outer TLV data but that means it is not > >the length of all of the fragmented data. This is not an issue after > >the first pair of messages as the Outer TLVs are no longer allowed at > >that point. > [HZ] The message length is the total length of the TEAP packet if fragmented, > to provide a hint for the peer to allocate the buffer. The start of the outer > TLV can be calculated from the EAP message length and length field inside > the TLS data, not dependent on the Message Length field. The current draft > text in Section 4.1 Outer TLVs description incorrectly refers to message > length field, will need to be corrected. > Since Outer TLVs only occur in the first 2 TEAP exchanges, the TLS data is one > type and relatively simple, it should not be too hard to figure out the start. > > > >[JLS] I presume that the Length needs to be present only if the message > >is fragmented as a hint to the receiver on the length of the buffer to > >allocate as I don't remember any error checks that the length of the > >message match the re-constructed message from the fragments (and if it > >did then the previous paragraph makes that faulty). Should there be an > >error check on the message length w/ the length of the re-constructed > >buffer? > [HZ] I don't know if current TLS implementations do check for that error. > Message length is only used for a hint. The EAP-TLS RFC doesn't cover that > either. Thought it did provide more detailed description of the message > length and L bit description, something we could use for the TEAP draft. > > > > > >> > > >> >2. There is nothing to say which TLVs can and cannot occur in the > >> >Outer TLVs in any easily findable method. Either a table or the > >> >string outer in descriptions would be helpful. As an example, does > >> >the Authority-ID TLV in the outer TLV make sense? > >> [HZ] We will add that table. > >> > > >> >3. I have gone through the fragmentation and did an implementation > >> >rather than just reading it. The questions that I have on it now > >> >are slightly different. Do TLVs need to be on a fragment boundary? > >> >Or do we just build the entire message, fragment it into convenient > >> >sizes regardless of the actual content of the message contents and > >> >sent the pieces across? If so then the text should probably be > >> >re-written to be clearer. Specifically, the message length is not > >> >useful for allocating the buffer on the first round trip of messages > >> >where one can have a TLV > >> added in to the content. > >> >[HZ] Message length covers the whole TEAP packet even if fragmented. > >> >TLVs do not need to be on a fragment boundary. Just build the whole > >> >message contents and send the pieces across. We will provide some > >> >text to clarify this. > > > >[JLS] - see note above about finding the start of the Outer TLV data > >block on the first pair of messages. > > > >> > > >> > > >> >_______________________________________________ > >> >Emu mailing list > >> >Emu@ietf.org > >> >https://www.ietf.org/mailman/listinfo/emu > > From hzhou@cisco.com Tue Oct 9 12:45:48 2012 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03BC911E808D for ; Tue, 9 Oct 2012 12:45:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SylBSW7iLsW4 for ; Tue, 9 Oct 2012 12:45:46 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 71B0611E8097 for ; Tue, 9 Oct 2012 12:45:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6432; q=dns/txt; s=iport; t=1349811946; x=1351021546; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=FVqgWgZruU3rFFofbbZCfeEzD4t2ntSz5KM6j3D23/U=; b=AblusAOStUSOQ0I/lmPklowW5v7RUF5EFrnRRrpFU/DYKqYN2FHBD7s+ 4di5uVi0EtaxmeJ+833HqQLGWUjZ2nsJ0KA+/0/M1rgwO5KT8KJ6QWF+q noFOUNgJN3YIy0ybsF/90IzUUyea5vU7i+xjAFpfQFtc72WkoBYqDPzpU w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EADN+dFCtJV2c/2dsb2JhbABFvzCBCIIgAQEBBAEBAQ8BJzQXBgEIDgMEAQEBChQJLgsUCQgBAQQBEggah2MLmh+PWJA8BItDJIUPYAOSOpF2gWuCbYIX X-IronPort-AV: E=Sophos;i="4.80,561,1344211200"; d="scan'208";a="129670811" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-1.cisco.com with ESMTP; 09 Oct 2012 19:45:44 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id q99JjiFP011741 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 9 Oct 2012 19:45:44 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.51]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0318.001; Tue, 9 Oct 2012 14:45:44 -0500 From: "Hao Zhou (hzhou)" To: Jim Schaad , "emu@ietf.org" , "draft-ietf-emu-eap-tunnel-method@tools.ietf.org" Thread-Topic: [Emu] More comments for eap-tunnel-method Thread-Index: Ac2fNa8k+p3Xv8iySJGSGMwihVHFRQDTa+8AAK58ngAARjzJgAAKEn+A///A/IA= Date: Tue, 9 Oct 2012 19:45:44 +0000 Message-ID: <645B00545719594A88ADF4221831FD3814BF49@xmb-rcd-x14.cisco.com> In-Reply-To: <01cf01cda654$a757df70$f6079e50$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 x-originating-ip: [64.101.214.207] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19254.003 x-tm-as-result: No--56.325100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Emu] More comments for eap-tunnel-method X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 19:45:48 -0000 That is the current thinking, and the only concrete use case for Outer TLV now is in the 1st message from server to peer with no TLS data. I am ok with adding another optional TLS data length field. On 10/9/12 3:31 PM, "Jim Schaad" wrote: >There does not seem to be anything in the TEAP document about the length >of >the TLS data. Are you suggesting that one should crack the TLS data blob >to find the length of that data blob? > >Jim > > >> -----Original Message----- >> From: Hao Zhou (hzhou) [mailto:hzhou@cisco.com] >> Sent: Tuesday, October 09, 2012 11:43 AM >> To: Jim Schaad; emu@ietf.org; draft-ietf-emu-eap-tunnel- >> method@tools.ietf.org >> Subject: Re: [Emu] More comments for eap-tunnel-method >>=20 >> Jim: >>=20 >> Please see comments inline below. >>=20 >> On 10/8/12 1:11 AM, "Jim Schaad" wrote: >>=20 >> > >> > >> >> -----Original Message----- >> >> From: Hao Zhou (hzhou) [mailto:hzhou@cisco.com] >> >> Sent: Thursday, October 04, 2012 2:56 PM >> >> To: Jim Schaad; emu@ietf.org; draft-ietf-emu-eap-tunnel- >> >> method@tools.ietf.org >> >> Subject: Re: [Emu] More comments for eap-tunnel-method >> >> >> >> Jim: >> >> >> >> Thanks for the review. Please see my comments below. >> >> >> >> On 9/30/12 2:01 PM, "Jim Schaad" wrote: >> >> >> >> >1. Should the Message Length field be present if the TLS Data field >> >> >is absent? >> >> [HZ] According to the text in the draft, the message length field >> >> should >> >only >> >> be present if the L bit is set, usually for fragmented packets. In >> >> those >> >cases, >> >> the TLS data field will be present, not absent. The only case TLS >> >> data >> >will be >> >> absent is when empty TEAP packet it is used to >> >> indicate TEAP acknowledgement for either a fragmented >>message, >> >> a TLS Alert message or a TLS Finished message. So the >> >> message >> >length >> >> field is not needed. We can clarify that in the draft. >> >> >> > >> >[JLS] I am not clear - are you saying that the first sever message >> >sent with just TLVs cannot be fragmented? >> [HZ] No, they can be fragmented. However, currently, Outer TLVs are only >> allowed in the first 2 messages in TEAP exchanges, 1st server to peer >>with >> TEAP start, and 2nd message client to server with Client_hello. It is >unlikely >> the first server message will have lots of outer TLVs that needs the >> fragmentation (only one or two outer TLV is being defined so far). The >>2nd >> message from client to server with client _hello might if the ticket >extension >> is too big, but unlikely. >>=20 >> > >> >[JLS] There is a potential issue in the way that the Message Length >> >field is described. For finding the location of the Outer TLVs it >> >provides the length of the TLS Data field, but the internal description >> >says that it gives the length of the message data in the event of a >> fragmented message. >> >If the first client response message is both fragmented on length and >> >contains TLVs, then the message length field must be the length of the >> >TLS data in order to find the Outer TLV data but that means it is not >> >the length of all of the fragmented data. This is not an issue after >> >the first pair of messages as the Outer TLVs are no longer allowed at >> >that point. >> [HZ] The message length is the total length of the TEAP packet if >fragmented, >> to provide a hint for the peer to allocate the buffer. The start of the >outer >> TLV can be calculated from the EAP message length and length field >>inside >> the TLS data, not dependent on the Message Length field. The current >>draft >> text in Section 4.1 Outer TLVs description incorrectly refers to message >> length field, will need to be corrected. >> Since Outer TLVs only occur in the first 2 TEAP exchanges, the TLS data >>is >one >> type and relatively simple, it should not be too hard to figure out the >start. >> > >> >[JLS] I presume that the Length needs to be present only if the message >> >is fragmented as a hint to the receiver on the length of the buffer to >> >allocate as I don't remember any error checks that the length of the >> >message match the re-constructed message from the fragments (and if it >> >did then the previous paragraph makes that faulty). Should there be an >> >error check on the message length w/ the length of the re-constructed >> >buffer? >> [HZ] I don't know if current TLS implementations do check for that >>error. >> Message length is only used for a hint. The EAP-TLS RFC doesn't cover >>that >> either. Thought it did provide more detailed description of the message >> length and L bit description, something we could use for the TEAP draft. >> > >> > >> >> > >> >> >2. There is nothing to say which TLVs can and cannot occur in the >> >> >Outer TLVs in any easily findable method. Either a table or the >> >> >string outer in descriptions would be helpful. As an example, does >> >> >the Authority-ID TLV in the outer TLV make sense? >> >> [HZ] We will add that table. >> >> > >> >> >3. I have gone through the fragmentation and did an implementation >> >> >rather than just reading it. The questions that I have on it now >> >> >are slightly different. Do TLVs need to be on a fragment boundary? >> >> >Or do we just build the entire message, fragment it into convenient >> >> >sizes regardless of the actual content of the message contents and >> >> >sent the pieces across? If so then the text should probably be >> >> >re-written to be clearer. Specifically, the message length is not >> >> >useful for allocating the buffer on the first round trip of messages >> >> >where one can have a TLV >> >> added in to the content. >> >> >[HZ] Message length covers the whole TEAP packet even if fragmented. >> >> >TLVs do not need to be on a fragment boundary. Just build the whole >> >> >message contents and send the pieces across. We will provide some >> >> >text to clarify this. >> > >> >[JLS] - see note above about finding the start of the Outer TLV data >> >block on the first pair of messages. >> > >> >> > >> >> > >> >> >_______________________________________________ >> >> >Emu mailing list >> >> >Emu@ietf.org >> >> >https://www.ietf.org/mailman/listinfo/emu >> > > From ietf@augustcellars.com Tue Oct 9 16:39:01 2012 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5823211E80D5 for ; Tue, 9 Oct 2012 16:39:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.254 X-Spam-Level: X-Spam-Status: No, score=-3.254 tagged_above=-999 required=5 tests=[AWL=0.345, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t6rm9z2f1YKJ for ; Tue, 9 Oct 2012 16:39:00 -0700 (PDT) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id A177121F85A4 for ; Tue, 9 Oct 2012 16:38:59 -0700 (PDT) Received: from Tobias (winery.augustcellars.com [206.212.239.129]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id 8012B38F26; Tue, 9 Oct 2012 16:38:55 -0700 (PDT) From: "Jim Schaad" To: "'Hao Zhou \(hzhou\)'" , , References: <01cf01cda654$a757df70$f6079e50$@augustcellars.com> <645B00545719594A88ADF4221831FD3814BF49@xmb-rcd-x14.cisco.com> In-Reply-To: <645B00545719594A88ADF4221831FD3814BF49@xmb-rcd-x14.cisco.com> Date: Tue, 9 Oct 2012 16:37:28 -0700 Message-ID: <01e901cda677$0bb961b0$232c2510$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQO+qmS45gRG7kXP9B86fRPuwVpz9pPPmPBg Content-Language: en-us Subject: Re: [Emu] More comments for eap-tunnel-method X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 23:39:01 -0000 I would be really against the idea that I needed to crack the TLS data blob to figure this out. Either adding a length for the TLS data field, or a length of the Outer TLV data would be preferable to me. If you did the second, then it would only affect processing on the first two messages. Jim > -----Original Message----- > From: Hao Zhou (hzhou) [mailto:hzhou@cisco.com] > Sent: Tuesday, October 09, 2012 12:46 PM > To: Jim Schaad; emu@ietf.org; draft-ietf-emu-eap-tunnel- > method@tools.ietf.org > Subject: Re: [Emu] More comments for eap-tunnel-method > > That is the current thinking, and the only concrete use case for Outer TLV > now is in the 1st message from server to peer with no TLS data. I am ok with > adding another optional TLS data length field. > > On 10/9/12 3:31 PM, "Jim Schaad" wrote: > > >There does not seem to be anything in the TEAP document about the > >length of > >the TLS data. Are you suggesting that one should crack the TLS data blob > >to find the length of that data blob? > > > >Jim > > > > > >> -----Original Message----- > >> From: Hao Zhou (hzhou) [mailto:hzhou@cisco.com] > >> Sent: Tuesday, October 09, 2012 11:43 AM > >> To: Jim Schaad; emu@ietf.org; draft-ietf-emu-eap-tunnel- > >> method@tools.ietf.org > >> Subject: Re: [Emu] More comments for eap-tunnel-method > >> > >> Jim: > >> > >> Please see comments inline below. > >> > >> On 10/8/12 1:11 AM, "Jim Schaad" wrote: > >> > >> > > >> > > >> >> -----Original Message----- > >> >> From: Hao Zhou (hzhou) [mailto:hzhou@cisco.com] > >> >> Sent: Thursday, October 04, 2012 2:56 PM > >> >> To: Jim Schaad; emu@ietf.org; draft-ietf-emu-eap-tunnel- > >> >> method@tools.ietf.org > >> >> Subject: Re: [Emu] More comments for eap-tunnel-method > >> >> > >> >> Jim: > >> >> > >> >> Thanks for the review. Please see my comments below. > >> >> > >> >> On 9/30/12 2:01 PM, "Jim Schaad" wrote: > >> >> > >> >> >1. Should the Message Length field be present if the TLS Data > >> >> >field is absent? > >> >> [HZ] According to the text in the draft, the message length field > >> >> should > >> >only > >> >> be present if the L bit is set, usually for fragmented packets. In > >> >> those > >> >cases, > >> >> the TLS data field will be present, not absent. The only case TLS > >> >> data > >> >will be > >> >> absent is when empty TEAP packet it is used to > >> >> indicate TEAP acknowledgement for either a fragmented > >>message, > >> >> a TLS Alert message or a TLS Finished message. So the > >> >> message > >> >length > >> >> field is not needed. We can clarify that in the draft. > >> >> > >> > > >> >[JLS] I am not clear - are you saying that the first sever message > >> >sent with just TLVs cannot be fragmented? > >> [HZ] No, they can be fragmented. However, currently, Outer TLVs are > >>only allowed in the first 2 messages in TEAP exchanges, 1st server to > >>peer with TEAP start, and 2nd message client to server with > >>Client_hello. It is > >unlikely > >> the first server message will have lots of outer TLVs that needs the > >>fragmentation (only one or two outer TLV is being defined so far). The > >>2nd message from client to server with client _hello might if the > >>ticket > >extension > >> is too big, but unlikely. > >> > >> > > >> >[JLS] There is a potential issue in the way that the Message Length > >> >field is described. For finding the location of the Outer TLVs it > >> >provides the length of the TLS Data field, but the internal > >> >description says that it gives the length of the message data in the > >> >event of a > >> fragmented message. > >> >If the first client response message is both fragmented on length > >> >and contains TLVs, then the message length field must be the length > >> >of the TLS data in order to find the Outer TLV data but that means > >> >it is not the length of all of the fragmented data. This is not an > >> >issue after the first pair of messages as the Outer TLVs are no > >> >longer allowed at that point. > >> [HZ] The message length is the total length of the TEAP packet if > >fragmented, > >> to provide a hint for the peer to allocate the buffer. The start of > >> the > >outer > >> TLV can be calculated from the EAP message length and length field > >>inside the TLS data, not dependent on the Message Length field. The > >>current draft text in Section 4.1 Outer TLVs description incorrectly > >>refers to message length field, will need to be corrected. > >> Since Outer TLVs only occur in the first 2 TEAP exchanges, the TLS > >>data is > >one > >> type and relatively simple, it should not be too hard to figure out > >> the > >start. > >> > > >> >[JLS] I presume that the Length needs to be present only if the > >> >message is fragmented as a hint to the receiver on the length of the > >> >buffer to allocate as I don't remember any error checks that the > >> >length of the message match the re-constructed message from the > >> >fragments (and if it did then the previous paragraph makes that > >> >faulty). Should there be an error check on the message length w/ > >> >the length of the re-constructed buffer? > >> [HZ] I don't know if current TLS implementations do check for that > >>error. > >> Message length is only used for a hint. The EAP-TLS RFC doesn't cover > >>that either. Thought it did provide more detailed description of the > >>message length and L bit description, something we could use for the > >>TEAP draft. > >> > > >> > > >> >> > > >> >> >2. There is nothing to say which TLVs can and cannot occur in > >> >> >the Outer TLVs in any easily findable method. Either a table or > >> >> >the string outer in descriptions would be helpful. As an > >> >> >example, does the Authority-ID TLV in the outer TLV make sense? > >> >> [HZ] We will add that table. > >> >> > > >> >> >3. I have gone through the fragmentation and did an > >> >> >implementation rather than just reading it. The questions that I > >> >> >have on it now are slightly different. Do TLVs need to be on a > fragment boundary? > >> >> >Or do we just build the entire message, fragment it into > >> >> >convenient sizes regardless of the actual content of the message > >> >> >contents and sent the pieces across? If so then the text should > >> >> >probably be re-written to be clearer. Specifically, the message > >> >> >length is not useful for allocating the buffer on the first round > >> >> >trip of messages where one can have a TLV > >> >> added in to the content. > >> >> >[HZ] Message length covers the whole TEAP packet even if > fragmented. > >> >> >TLVs do not need to be on a fragment boundary. Just build the > >> >> >whole message contents and send the pieces across. We will > >> >> >provide some text to clarify this. > >> > > >> >[JLS] - see note above about finding the start of the Outer TLV data > >> >block on the first pair of messages. > >> > > >> >> > > >> >> > > >> >> >_______________________________________________ > >> >> >Emu mailing list > >> >> >Emu@ietf.org > >> >> >https://www.ietf.org/mailman/listinfo/emu > >> > > > From hzhou@cisco.com Wed Oct 10 11:10:05 2012 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 258BA21F861A for ; Wed, 10 Oct 2012 11:10:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NVt1NpVbHU16 for ; Wed, 10 Oct 2012 11:10:04 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id D9ABC21F8610 for ; Wed, 10 Oct 2012 11:10:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7669; q=dns/txt; s=iport; t=1349892603; x=1351102203; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=yoq63DNWDI1pMKn8oVECajgH371dAoL5VEelNFnwP28=; b=hogh7PQWwmzraEoFRnn+84Fj2XluWjGe60VlZ/NuknE0OCok2mCkHSvW fvnzwnBC+KoRbHwtig3V2xH8a91qurd11KLADsbPMR3n/pX681DHJmkzp BIb60OI7sRJWxu7Zlvt96E49JIGGaHdFDdyBjKaWLNm8utm5ErVuqDJaf E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAHm5dVCtJXG8/2dsb2JhbABEvzGBCIIgAQEBBAEBAQ8BJzQXBgEIDgMEAQEBChQJLgsUCQgCBAESCBqHYguXQqAZBItHJIUcYAOSO5F2gWuCbYIX X-IronPort-AV: E=Sophos;i="4.80,565,1344211200"; d="scan'208";a="130253379" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-2.cisco.com with ESMTP; 10 Oct 2012 18:10:03 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id q9AIA3Rd021247 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 10 Oct 2012 18:10:03 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.51]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0318.001; Wed, 10 Oct 2012 13:10:02 -0500 From: "Hao Zhou (hzhou)" To: Jim Schaad , "emu@ietf.org" , "draft-ietf-emu-eap-tunnel-method@tools.ietf.org" Thread-Topic: [Emu] More comments for eap-tunnel-method Thread-Index: Ac2fNa8k+p3Xv8iySJGSGMwihVHFRQDTa+8AAK58ngAARjzJgAAKEn+A///A/ICAAIPOAIAA88qA Date: Wed, 10 Oct 2012 18:10:02 +0000 Message-ID: <645B00545719594A88ADF4221831FD3814D55E@xmb-rcd-x14.cisco.com> In-Reply-To: <01e901cda677$0bb961b0$232c2510$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 x-originating-ip: [64.101.219.104] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19258.000 x-tm-as-result: No--58.235100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <2A529D45C1A54646B2511E239626E100@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Emu] More comments for eap-tunnel-method X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 18:10:05 -0000 I think an optional length of Outer TLV field (controlled by the flag bit) would be preferable. On 10/9/12 7:37 PM, "Jim Schaad" wrote: >I would be really against the idea that I needed to crack the TLS data >blob >to figure this out. Either adding a length for the TLS data field, or a >length of the Outer TLV data would be preferable to me. If you did the >second, then it would only affect processing on the first two messages. > >Jim > >> -----Original Message----- >> From: Hao Zhou (hzhou) [mailto:hzhou@cisco.com] >> Sent: Tuesday, October 09, 2012 12:46 PM >> To: Jim Schaad; emu@ietf.org; draft-ietf-emu-eap-tunnel- >> method@tools.ietf.org >> Subject: Re: [Emu] More comments for eap-tunnel-method >>=20 >> That is the current thinking, and the only concrete use case for Outer >>TLV >> now is in the 1st message from server to peer with no TLS data. I am ok >with >> adding another optional TLS data length field. >>=20 >> On 10/9/12 3:31 PM, "Jim Schaad" wrote: >>=20 >> >There does not seem to be anything in the TEAP document about the >> >length of >> >the TLS data. Are you suggesting that one should crack the TLS data >blob >> >to find the length of that data blob? >> > >> >Jim >> > >> > >> >> -----Original Message----- >> >> From: Hao Zhou (hzhou) [mailto:hzhou@cisco.com] >> >> Sent: Tuesday, October 09, 2012 11:43 AM >> >> To: Jim Schaad; emu@ietf.org; draft-ietf-emu-eap-tunnel- >> >> method@tools.ietf.org >> >> Subject: Re: [Emu] More comments for eap-tunnel-method >> >> >> >> Jim: >> >> >> >> Please see comments inline below. >> >> >> >> On 10/8/12 1:11 AM, "Jim Schaad" wrote: >> >> >> >> > >> >> > >> >> >> -----Original Message----- >> >> >> From: Hao Zhou (hzhou) [mailto:hzhou@cisco.com] >> >> >> Sent: Thursday, October 04, 2012 2:56 PM >> >> >> To: Jim Schaad; emu@ietf.org; draft-ietf-emu-eap-tunnel- >> >> >> method@tools.ietf.org >> >> >> Subject: Re: [Emu] More comments for eap-tunnel-method >> >> >> >> >> >> Jim: >> >> >> >> >> >> Thanks for the review. Please see my comments below. >> >> >> >> >> >> On 9/30/12 2:01 PM, "Jim Schaad" wrote: >> >> >> >> >> >> >1. Should the Message Length field be present if the TLS Data >> >> >> >field is absent? >> >> >> [HZ] According to the text in the draft, the message length field >> >> >> should >> >> >only >> >> >> be present if the L bit is set, usually for fragmented packets. In >> >> >> those >> >> >cases, >> >> >> the TLS data field will be present, not absent. The only case TLS >> >> >> data >> >> >will be >> >> >> absent is when empty TEAP packet it is used to >> >> >> indicate TEAP acknowledgement for either a fragmented >> >>message, >> >> >> a TLS Alert message or a TLS Finished message. So the >> >> >> message >> >> >length >> >> >> field is not needed. We can clarify that in the draft. >> >> >> >> >> > >> >> >[JLS] I am not clear - are you saying that the first sever message >> >> >sent with just TLVs cannot be fragmented? >> >> [HZ] No, they can be fragmented. However, currently, Outer TLVs are >> >>only allowed in the first 2 messages in TEAP exchanges, 1st server to >> >>peer with TEAP start, and 2nd message client to server with >> >>Client_hello. It is >> >unlikely >> >> the first server message will have lots of outer TLVs that needs the >> >>fragmentation (only one or two outer TLV is being defined so far). The >> >>2nd message from client to server with client _hello might if the >> >>ticket >> >extension >> >> is too big, but unlikely. >> >> >> >> > >> >> >[JLS] There is a potential issue in the way that the Message Length >> >> >field is described. For finding the location of the Outer TLVs it >> >> >provides the length of the TLS Data field, but the internal >> >> >description says that it gives the length of the message data in the >> >> >event of a >> >> fragmented message. >> >> >If the first client response message is both fragmented on length >> >> >and contains TLVs, then the message length field must be the length >> >> >of the TLS data in order to find the Outer TLV data but that means >> >> >it is not the length of all of the fragmented data. This is not an >> >> >issue after the first pair of messages as the Outer TLVs are no >> >> >longer allowed at that point. >> >> [HZ] The message length is the total length of the TEAP packet if >> >fragmented, >> >> to provide a hint for the peer to allocate the buffer. The start of >> >> the >> >outer >> >> TLV can be calculated from the EAP message length and length field >> >>inside the TLS data, not dependent on the Message Length field. The >> >>current draft text in Section 4.1 Outer TLVs description incorrectly >> >>refers to message length field, will need to be corrected. >> >> Since Outer TLVs only occur in the first 2 TEAP exchanges, the TLS >> >>data is >> >one >> >> type and relatively simple, it should not be too hard to figure out >> >> the >> >start. >> >> > >> >> >[JLS] I presume that the Length needs to be present only if the >> >> >message is fragmented as a hint to the receiver on the length of the >> >> >buffer to allocate as I don't remember any error checks that the >> >> >length of the message match the re-constructed message from the >> >> >fragments (and if it did then the previous paragraph makes that >> >> >faulty). Should there be an error check on the message length w/ >> >> >the length of the re-constructed buffer? >> >> [HZ] I don't know if current TLS implementations do check for that >> >>error. >> >> Message length is only used for a hint. The EAP-TLS RFC doesn't cover >> >>that either. Thought it did provide more detailed description of the >> >>message length and L bit description, something we could use for the >> >>TEAP draft. >> >> > >> >> > >> >> >> > >> >> >> >2. There is nothing to say which TLVs can and cannot occur in >> >> >> >the Outer TLVs in any easily findable method. Either a table or >> >> >> >the string outer in descriptions would be helpful. As an >> >> >> >example, does the Authority-ID TLV in the outer TLV make sense? >> >> >> [HZ] We will add that table. >> >> >> > >> >> >> >3. I have gone through the fragmentation and did an >> >> >> >implementation rather than just reading it. The questions that I >> >> >> >have on it now are slightly different. Do TLVs need to be on a >> fragment boundary? >> >> >> >Or do we just build the entire message, fragment it into >> >> >> >convenient sizes regardless of the actual content of the message >> >> >> >contents and sent the pieces across? If so then the text should >> >> >> >probably be re-written to be clearer. Specifically, the message >> >> >> >length is not useful for allocating the buffer on the first round >> >> >> >trip of messages where one can have a TLV >> >> >> added in to the content. >> >> >> >[HZ] Message length covers the whole TEAP packet even if >> fragmented. >> >> >> >TLVs do not need to be on a fragment boundary. Just build the >> >> >> >whole message contents and send the pieces across. We will >> >> >> >provide some text to clarify this. >> >> > >> >> >[JLS] - see note above about finding the start of the Outer TLV data >> >> >block on the first pair of messages. >> >> > >> >> >> > >> >> >> > >> >> >> >_______________________________________________ >> >> >> >Emu mailing list >> >> >> >Emu@ietf.org >> >> >> >https://www.ietf.org/mailman/listinfo/emu >> >> > >> > > From ietf@augustcellars.com Wed Oct 10 11:43:55 2012 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A230221F8445 for ; Wed, 10 Oct 2012 11:43:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.307 X-Spam-Level: X-Spam-Status: No, score=-3.307 tagged_above=-999 required=5 tests=[AWL=0.291, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2m-kOxp4LY7y for ; Wed, 10 Oct 2012 11:43:55 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0586F21F8610 for ; Wed, 10 Oct 2012 11:43:54 -0700 (PDT) Received: from Tobias (winery.augustcellars.com [206.212.239.129]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 743BA2CA0E; Wed, 10 Oct 2012 11:43:54 -0700 (PDT) From: "Jim Schaad" To: "'Hao Zhou \(hzhou\)'" References: <010c01cda510$cd743fe0$685cbfa0$@augustcellars.com> <645B00545719594A88ADF4221831FD3814D595@xmb-rcd-x14.cisco.com> In-Reply-To: <645B00545719594A88ADF4221831FD3814D595@xmb-rcd-x14.cisco.com> Date: Wed, 10 Oct 2012 11:42:25 -0700 Message-ID: <023f01cda716$fe7ce710$fb76b530$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0240_01CDA6DC.521FE3D0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGhiHpiXe7W8eAuRObChKCKgT4SdJgLHM6A Content-Language: en-us Cc: emu@ietf.org Subject: Re: [Emu] Review of draft-ietf-emu-eap-tunnel-method-00 X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 18:43:55 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0240_01CDA6DC.521FE3D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I think that picks up all of my current comments. Looking forward to seeing the draft update. Jim From: Hao Zhou (hzhou) [mailto:hzhou@cisco.com] Sent: Wednesday, October 10, 2012 11:15 AM To: Jim Schaad Cc: emu@ietf.org Subject: Re: [Emu] Review of draft-ietf-emu-eap-tunnel-method-00 Jim: Please see comments below inline. ------=_NextPart_000_0240_01CDA6DC.521FE3D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I think that picks up all of my current comments.  Looking = forward to seeing the draft update.

 

Jim

 

 

From:= = Hao Zhou (hzhou) [mailto:hzhou@cisco.com]
Sent: Wednesday, = October 10, 2012 11:15 AM
To: Jim Schaad
Cc: = emu@ietf.org
Subject: Re: [Emu] Review of = draft-ietf-emu-eap-tunnel-method-00

 

Jim:

 

Please see comments below = inline.

 

------=_NextPart_000_0240_01CDA6DC.521FE3D0-- From ietf@augustcellars.com Wed Oct 10 12:49:38 2012 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4632221F85AC for ; Wed, 10 Oct 2012 12:49:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.351 X-Spam-Level: X-Spam-Status: No, score=-3.351 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Su6gu3FRkDn4 for ; Wed, 10 Oct 2012 12:49:37 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id 49F6421F85A2 for ; Wed, 10 Oct 2012 12:49:30 -0700 (PDT) Received: from Tobias (173-8-216-38-Oregon.hfc.comcastbusiness.net [173.8.216.38]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 2E1142CA1A; Wed, 10 Oct 2012 12:49:30 -0700 (PDT) From: "Jim Schaad" To: "'Joseph Salowey \(jsalowey\)'" References: <00e601cda1a3$5a230c80$0e692580$@augustcellars.com> <506D282C.6040909@restena.lu> <010701cda507$27d9ed40$778dc7c0$@augustcellars.com> <01b301cda63c$0ab86e40$20294ac0$@augustcellars.com> In-Reply-To: Date: Wed, 10 Oct 2012 12:48:02 -0700 Message-ID: <026201cda720$28dee220$7a9ca660$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQETIlXkRdUEOAmqRJpEVJ8MvvMTfAJlURHyAiqX210CoPuTWQJUKbioAhRbgHaYyy+4sA== Content-Language: en-us Cc: emu@ietf.org Subject: Re: [Emu] Client Auth with TLS X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 19:49:38 -0000 I think this approach may be better than trying to do the = re-negotiations inside of the TEAP and probably merits about 2 sentences in the = document. Jim > -----Original Message----- > From: Joseph Salowey (jsalowey) [mailto:jsalowey@cisco.com] > Sent: Tuesday, October 09, 2012 9:44 AM > To: Jim Schaad > Cc: Stefan Winter; > Subject: Re: [Emu] Client Auth with TLS >=20 >=20 > On Oct 9, 2012, at 9:35 AM, Jim Schaad wrote: >=20 > > > > > >> -----Original Message----- > >> From: Joseph Salowey (jsalowey) [mailto:jsalowey@cisco.com] > >> Sent: Monday, October 08, 2012 9:23 PM > >> To: Jim Schaad > >> Cc: Stefan Winter; > >> Subject: Re: [Emu] Client Auth with TLS > >> > >> I think it is worthwhile to support an mode of operation that > >> supports > > peer > >> privacy. I've seen this implemented in tunnel methods in two different > >> ways. One with renegotiation as described below and the other as = an > inner > >> EAP-TLS exchange after an anonymous outer exchange. I don't = really > have > > a > >> strong opinion as to which is better at this point. It seems that > >> using > > an inner > >> EAP-TLS may be more flexible and would offer the same security > >> properties and might be a simpler model. > >> > >> Any opinions on the list? > > > > Are you suggesting an inner EAP-TLS or an inner TEAP? > > >=20 > [Joe] EAP-TLS as an inner method. >=20 > > Jim > > > >> > >> > >> > >> On Oct 7, 2012, at 8:43 PM, Jim Schaad wrote: > >> > >>> Stefan, > >>> > >>> Thanks for the input. > >>> > >>> For the authors, > >>> > >>> Does this need to be documented as a mode of operation for TEAP or > >>> are we going to say that this is not a supported mode? > >>> > >>> Jim > >>> > >>> > >>>> -----Original Message----- > >>>> From: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org] On > Behalf > >> Of > >>>> Stefan Winter > >>>> Sent: Wednesday, October 03, 2012 11:10 PM > >>>> To: emu@ietf.org > >>>> Subject: Re: [Emu] Client Auth with TLS > >>>> > >>>> Hi, > >>>> > >>>>> 3. The client provides the certificate in a protected manner - = I > >>>>> had a problem at this point because I don't know enough TLS to > >>>>> properly go through this scenario, and I could not really read > >>>>> documents while driving. If the encrypted certificate extension > >>>>> was used, then there is no issue as the protected certificate > >>>>> would be passed in the initial handshake. However if the client > >>>>> starts the negotiation and then restarts it after it is = encrypted, > >>>>> I don't know if this occurs > >>> before or > >>>> after the finish message. > >>>>> If it starts after the finish method then there is an issue with > >>>>> having the server close an anonymous session if the client is = then > >>>>> going to provide the certificate encrypted. Help on how this > >>>>> works > >>> would > >>>> be appreciated. > >>>> > >>>> FWIW, RFC5216 (EAP-TLS) already has provisions for a protected > >>>> client credential exchange (for client privacy protection = reasons). > >>>> I didn't ever > >>> see it > >>>> used (anyone?), but it's clearly a foreseen mode of operation. = The > >>>> text describing this is in section 2.1.4: > >>>> > >>>> "... In order to avoid disclosing the peer username, an = EAP-TLS peer > >>>> configured for privacy MUST negotiate a TLS ciphersuite = supporting > >>>> confidentiality and MUST provide a client certificate list > >>>> containing no entries in response to the initial > >>>> certificate_request from the EAP-TLS server. > >>>> > >>>> An EAP-TLS server supporting privacy MUST NOT treat a = certificate > >>>> list containing no entries as a terminal condition; instead, it > >>>> MUST bring up the TLS session and then send a hello_request. = The > >>>> handshake then proceeds normally; the peer sends a client_hello = and > >>>> the server replies with a server_hello, certificate, > >>>> server_key_exchange, certificate_request, server_hello_done, etc. > >>>> > >>>> For the calculation of exported keying material (see Section = 2.3), > >>>> the master_secret derived within the second handshake is used. > >>>> > >>>> An EAP-TLS peer supporting privacy MUST provide a certificate = list > >>>> containing at least one entry in response to the subsequent > >>>> certificate_request sent by the server. If the EAP-TLS server > >>>> supporting privacy does not receive a client certificate in > >>>> response to the subsequent certificate_request, then it MUST = abort > >>>> the session. > >>>> " > >>>> > >>>> There is a sequence diagram shortly afterwards which shows = clearly > >>>> that > >>> the > >>>> "first" negotiation ends with a 'finished' and then immediately a > >>>> new 'hello_request' - all in one EAP message. > >>>> > >>>> Greetings, > >>>> > >>>> Stefan > >>>> > >>>>> > >>>>> Jim > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> Emu mailing list > >>>>> Emu@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/emu > >>>>> > >>>> > >>>> > >>>> -- > >>>> Stefan WINTER > >>>> Ingenieur de Recherche > >>>> Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education > >>>> Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi > >>>> L-1359 Luxembourg > >>>> > >>>> Tel: +352 424409 1 > >>>> Fax: +352 422473 > >>> > >>> > >>> _______________________________________________ > >>> Emu mailing list > >>> Emu@ietf.org > >>> https://www.ietf.org/mailman/listinfo/emu > > From hzhou@cisco.com Wed Oct 10 11:15:40 2012 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00D531F0381 for ; Wed, 10 Oct 2012 11:15:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jz1r8g3hP68j for ; Wed, 10 Oct 2012 11:15:36 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 2AB301F0429 for ; Wed, 10 Oct 2012 11:15:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=113134; q=dns/txt; s=iport; t=1349892924; x=1351102524; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=K1F0L46TXb99/KREwXOM9tYF1fv8IeR8L4JDRJeS9S8=; b=ZMJvJajgBpZ+yN+tR82TgAl0uaGkFuS4izTcGo2TEg1IiqwOzP1heliD r1C/TQndRULWBDgjFCXhp/d4ROmOjcpm6+/hUSkJiJ72l5MFF9e55/02j JMAqLeGb407GNdr4vJ0sMGZcIbDeQag2E3J9gj89SnaNyzjIS9Fqjd8eU 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAIm6dVCtJV2c/2dsb2JhbAA7CYJLvGaBCIIgAQEBBAEBAQ8BBwEMBkELDAYBCA4DAwEBAQsOCAEGLgsUCQgCBA4FCBqHYguXQ6AZBItHEROCXYI/YAOkMYFrgm2BWgIFHhg X-IronPort-AV: E=Sophos;i="4.80,565,1344211200"; d="scan'208,217";a="130255368" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-2.cisco.com with ESMTP; 10 Oct 2012 18:15:22 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id q9AIFMlH019493 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 10 Oct 2012 18:15:22 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.51]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.001; Wed, 10 Oct 2012 13:15:22 -0500 From: "Hao Zhou (hzhou)" To: Jim Schaad Thread-Topic: [Emu] Review of draft-ietf-emu-eap-tunnel-method-00 Thread-Index: AQHNolcnsIvA7junTwesvqtA+uoKMpevMLyAgAPBwoA= Date: Wed, 10 Oct 2012 18:15:21 +0000 Message-ID: <645B00545719594A88ADF4221831FD3814D595@xmb-rcd-x14.cisco.com> In-Reply-To: <010c01cda510$cd743fe0$685cbfa0$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 x-originating-ip: [64.101.219.104] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19258.000 x-tm-as-result: No--60.483900-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_645B00545719594A88ADF4221831FD3814D595xmbrcdx14ciscocom_" MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 10 Oct 2012 17:21:27 -0700 Cc: "emu@ietf.org" Subject: Re: [Emu] Review of draft-ietf-emu-eap-tunnel-method-00 X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 18:15:40 -0000 --_000_645B00545719594A88ADF4221831FD3814D595xmbrcdx14ciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Jim: Please see comments below inline. From: Jim Schaad > Date: Monday, October 8, 2012 12:53 AM To: Cisco Employee > Cc: "emu@ietf.org" > Subject: RE: [Emu] Review of draft-ietf-emu-eap-tunnel-method-00 Hao, comments in line From: Hao Zhou (hzhou) [mailto:hzhou@cisco.com] Sent: Thursday, October 04, 2012 10:39 AM To: Jim Schaad Cc: emu@ietf.org Subject: Re: [Emu] Review of draft-ietf-emu-eap-tunnel-method-00 Jim: Thanks very much for your detailed review. Please see the comments below. W= e will respond to your other emails shortly. On 9/28/12 9:18 PM, "Jim Schaad" > wrote: 1. In section 3.2.3, it says that a new PAC can be requested after a full TLS handshake. Can one be requested following an abbreviated handshake? Or do you just re-use the existing PAC? [HZ] RFC5077 does not specify that client can request a new ticket after sending the TLS ticket, if the client is resuming a session using the session ticket, then it cannot request a new session ticket based on resumed session. We will add some language to clarify that it is not allowed. 2. Section 3.3 s/descried/described/ [HZ] Ok. 3. Section 3.4 - Is it possible to have multiple server ids after the authentication - one from the tunnel and others from the inner EAP methods. I realize that most EAP methods don't send a sender id, but some (IBAKE for example) currently do. Also, the client might have an idea of what the sender id is from configuration. If so, do these all need to get exported as server-id values? [HZ] Good catch. We will add a sentence similar to peer-ID, where multiple server IDs need to be exported. 4. In section 3.6.1 - It is not clear that an EAP-Failure packet is sent when 1) the server sends a fatal alert to the peer, 2) the peer requests a restart via a ClientHello and 3) the peer declines to permit the restart to occur. [HZ] We will clarify that EAP-Failure packet will be sent in those cases. [JLS] Just to be clear =96 this is a single case not three cases. It is a = sequence of events that should lead to the EAP-Failure packet. [HZ] ok. 5. In section 3.6.1 - Is the restart only an issue for fatal alerts, or is it a problem for all alerts? [HZ] Restart is only allowed for non-fatal alerts, per TLS RFC. "Upon transmission or receipt of a fatal alert message, both parties immediately = close the connection.", so restart is not desired in this case. We will clarify that restart is only allowed in non-fatal alert cases. [JLS] It may just be me, but this seems to be a bit odd from my point of v= iew. It is not clear that in the event of a non-fatal alert that there is = any need for the two parties to start a new negotiation that would ensue up= on getting a Hello restart. There is a question in terms of closing the co= nnection if the TLS document means just the TLS session or the encapsulatin= g transport is to be shut down as well. If it means the latter then it mak= es sense that you could request a new TLS negotiation without having to bui= ld all of the EAP transport frame work (i.e the entire RADIUS session?). Please re-look at this and ensure that this is really what you mean. [HZ] Good point. I think the draft text is written in the way to allow rest= art for all alerts. I think the text is modeled after the EAP-TLS RFC 5216 = and is fine. 6. In section 3.6.2 - Why SHOULD not MUST send clear text EAP-Failure? [HZ] We will change it to MUST. 7. In section 3.6 - do we need to discuss the question of errors in the outer EAP layer that is carrying the TLVs which contain the TLS content? This is a distinct location from the current list of where to handle errors. There is going to be a distinction (possibly) between errors that occur during phase 1 and errors during phase 2. Should the error return reflect if the error occurred inside or outside of the TLS tunnel? [HZ] Good catch. We will add some language to clarify dealing with outer packet errors. Something like: 1. If Outer TLVs are wrong, they will be ignored. 2. If others (version, length, flags, etc.) are wrong, the entire EAP packet will be ignored. [JLS} Looks reasonable. 8. In section 3.8 - I have the following questions a) In the text "The request MAY be issued", I don't understand the MAY at this point. Is it supposed to say that the request can be issued either before or after the authentication has finished, or is it saying that the peer has the option of issuing or not issuing the request, but must wait until the authentication level has been reached? [HZ] It's the later. How about add "only" in front "after the peer has determined that..."? [JLS] That does deal with the immediate issue. However the fact that you n= eed to do the Crypt-Binding TLV for tunnel validation does imply that an EA= P method that generates a key is a requirement before being able to get a P= AC. Is this what is intended? Should you be able to get a PAC just from v= alidating the tunnel with the server and knowing the servers name from it= =92s certificate? [HZ] If there is an inner EAP method, then it makes sense to validating the= crypto binding to ensure the tunnel integrity and the inner EAP method. Ot= herwise, requesting PAC after validating the server is fine. Will add text = to clarify. b) If a peer issues a PAC request, but the server has not yet satisfied it's policy, does the server remember the PAC request and send back the response after the internal policy has been satisfied or should it send back an error saying that policy has not yet been satisfied along with additional TLVs to attempt and satisfy that policy? [HZ] The server remembers that and issues the PAC after its policy is satisfied. We will clarify that. c) What should a peer do if it receives a PAC TLV with an unknown attribute? [HZ] Ignore that. [JLS] Please be detailed =96 ignore the attribute or ignore the PAC. [HZ] Ignore the attribute. 9. In section 3.9 - there is leaking on the POP, but not on identity at this point. I believe that there needs to be a requirement that an EAP method needs to be run which will provide an identity proof on the client prior to a certificate being issued. You may or may not then want to add text that says that the subject name(s) in the certificate request need to be checked against the set of authenticated identities prior to the certificate being issued. [HZ] Good point. We will add some that. 10. In section 3.10 - It is unclear to me if the Server Unauthenticated mode is because the server or the peer is unauthenticated at this point in time. The cipher suite would indicate that the server is not authenticated, however what about the case of the server providing an authenticated id to the peer, but the peer is unable to validate the identity of the server for some reason. This is also a Server Unauthenticated mode. [HZ] Yes. It covers both cases. We will add language to clarify that. 11. In section 4.1 - I would like to see a discussion that says that the following situation can never occur. The initial EAP message from the peer to the server (or the response) plus the Outer TLV data plus the EAP message headers exceeds the underlying packet size of the transport. In the event that it does, I am not sure how one finds the Outer TLV data start and where the fragmentation would occur to get the Outer TLV data between the peer and the server. [HZ] I think it should work as defined. The start of the Outer TLVs should be derived from the EAP message length and length of the TLS data. [JLS] I have gotten a better understanding =96 I may have suggested text el= sewhere 12. Section 4.2 - I understand what is happening with an EMPTY TEAP message being sent in response to a list of TLVs that are marked optional, however I question if the statement that is MUST be sent is correct. There are two reasons for the question: a. A server could send a RESULT TLV in response to a message from the client that contains no TLVs that are either mandatory or recognized. [HZ] Good catch. We will clarify that. b. I am (very slightly) worried about the fact that the response is not authenticated by the tunnel in many manner. I would think that a NAK to any of the TLVs would be a better response if no other TLV messages are to be sent. The entity sending the TLV should know if it marked it as mandatory or not. The NAK is not the same as an Error TLV. [HZ] Agree. A NAK TLV should be sent in this case. We will clarify. 13. Section 4.2.2 - Should "Type" in the outdented list be "TLV Type"? s/filed/field/ [HZ] Yes. We will correct that. 14. Section 4.2.2 - Can multiple Authority-ID TLVs be transmitted to a peer? [HZ] No. It is mentioned in Section 4.3, Table of TLVs rules. [JLS} That says that you cannot send multiple Authority IDs in a single mes= sage, what about in multiple messages? [HZ] Authority ID is only to be sent in the first server to peer TEAP messa= ge, so shouldn't be multiple messages. Will clarify in the Outer TLV rule s= ection to be added. 15. Section 4.2.3 - I assume that there should only be one Identity-Type TLV in a TEAP packet. Should a request for authentication be present in the packet as well? If multiple are allowed then information about how to treat this should be included. What should the peer respond with if it does have an identity of the type? This is not explicitly stated. [HZ] That's correct, only one Identity-Type TLV is allowed.The requested Id= entity type MUST comes with an EAP request or Basic-Password-Auth-Req. If the peer has the requested identity type, it should send back the same i= dentity type TLV in the response. We missed this and will add this clarific= ation. 16. Section 4.2.4 - I don't understand the default in the event that an unknown value is sent in the status field. If there is an ERROR TLV in the message, should I not use that error code rather than change it? [HZ] No. The error code in the Error TLV if being sent with the Result TLV = might mean something, but since the peer doesn't understand the Status fiel= d, and most likely will not understand the error code. Sending back Unexpec= ted_TLVs_Exchanged error code is probably appropriate. [JLS] I was assuming that the client did understand the error code, otherwi= se I agree that using a well understood error is correct behavior. [HZ] Still, peer encounters an unknown or unexpected TLV, which is a differ= ent error than what the other side wants to convey on the error tlv. 17. Section 4.2.6 - Do we need a discussion about how to produce/deal with vender specific errors? Do you expect that vender specific TLVs will have an error mechanism built into them to return an error code? [HZ] We expect the vendor TLV will have its own error handling mechanism or= use the standard error codes defined. 18. Section 4.2.8 - Do we need to talk about the question of having some Vender TLVs be marked as mandatory and others not. Are we using the same TLV structure with the same rules for mandatoriness. If the mandatory bit is set, does that mean that I need to recognize the vendor-id or all combinations of vender-id/Vender-TLV type? [HZ] Yes. If the mandatory bit is set on the Vendor-Speific TLV, then the p= eer need to recognize the vendor ID and all combination of the vendor TLVs.= The Vendor TLV format is up to the vendor to define, as specified by the c= urrent draft. 19. Section 4.2.9 - After reading this, sketching out some scenarios and so forth, I find that I do not like the text and result being pushed here at all. My problems start, in some respects, with the name of the TLV as it does not map to how I would like to see this TLV treated. I would propose the following set of changes: a) The name of the TLV be changed from Request-Action TLV to Provisional-Result TLV [HZ] I am open with the name change, but think Request-Action probably capt= ure the essence better. b) It needs to be made clear that the TLV can be sent from either the server to the peer or the peer to the server. It is my belief that presently it is only sent from the peer to the client and only in response to a successful Result TLV. [HZ] Ok. I agree that we can extend that to be bidirectional and for either= success and failure Result TLV. c) The receiving entity MUST process the TLV. [HZ] Ok. d) The processing for the TLV is as follows: i) The entity MAY choose to process (or start?) any of the TLVs that are included in the message. ii) If the entity chooses NOT to process any TLV in the list, the Provisional-Result TLV is treated as a Result TLV with the code "status" iii) If multiple Provisional-Result TLVs are in the body, the session can continue if ANY of TLV in any Provisional-Result TLV is processed. iv) If multiple Provisional-Result TLVs are in the body and no sub-TLV is processed, then the most fatal status should be used. If a status is found which is not understood by the entity, then it should be treated as a fatal TLV. [HZ] Ok. The current text allows for the following: The server sends a Success to the peer The peer says please do this or go to fatal The server sends a clear success outside of the tunnel. [HZ] That's not correct. The last exchange in the tunnel should be an agree= d upon Result TLV exchange, before the tunnel is torn down and a clear text= EAP success is sent. [JLS] Just to be clear, you are saying that the conversation will look like Server --> Result TLV (Success) Request-Action (Status-Bletch, foobar) <-- Client Server --> Result TLV (Success) Result TVL (Success) <-- Client (knows that the server must = not be willing to do what was asked. The server COULD send back the Bletch code if it decides to process the Req= uest-Action TLV from the client. The client could send back Bletch even if= the server does not send it the second time. [HZ] Not quite. Status-Bletch indicates the result if the server does not p= rocess the action requested by the peer. So if the server does not process = the request, then it will look like this: Server --> Result TLV (Success) Request-Action (Status-Bletch, foobar) <-- Client Server --> Result TLV (Status-Bletch) Result TVL (Status-Bletch) If the server processes the request and succeeds, it will look like this: Server --> Result TLV (Success) Request-Action (Status-Bletch, foobar) <-- Client .. Process TLVs or start another EAP Server --> Result TLV (Success) Result TVL (Success) <-- Client I wonder if the capability needs to be added to say, please start this TLV. So that a server can say, If you don't start a Channel binding TLV, I will make this a failure return code, if you want to start the channel binding TLV then I am open to giving you a success return code. OK - so this is kind of there, but only one value can be placed there. One cannot say do either an EAP negotiation or process this TLV. [HZ] That's true. Only one request. [JLS] Since you can only have one Request-Action TLV for a given status cod= e, but presumably multiple Request-Action TLV with different status codes, = that seems slightly restrictive. However, I can deal with this. [JLS] Difference in opinion in the document. The text in 4.2.9 says that m= ultiple with different status codes ok, but the table says 0-1 in a single= message [HZ] Good catch, will fix. 20. Section 4.2.12.4 - What does it mean to have an I-ID validation enforcement for PAC session renewal? Does it mean that the final message is not sent unless an appropriate ID is presented? Does it have to be an EAP authentication or is password based authentication sufficient? Should a PAC be invalidated on the server side (oops how do you do that) if it a PAC is presented and then the appropriate ID is not given? [HZ] The I-ID in the PAC is used to validate that the correct user is being= authenticated and using his PAC. If they don't match, then the authenticat= ion will be rejected as if the authentication failed, with the normal flow = including the final Result TLV and clear text EAP failure being sent. It ca= n be either the EAP authentication or the password based authentication. Th= e PAC is not invalidated if the I-ID doesn't match the authenticated identi= ty, the authentication will be rejected. 21. In section 4.2.12.6 - Is this supposed to be at the top level or embedded in the PAC-TLV? [HZ] Yes. [JLS] I think the correct response is =96 =93I don=92t understand the quest= ion=94 It is only embedded and I don=92t know why I ever thought it would= be at the top level. [HZ] Yes, it is embedded in PAC-TLV. I meant that it should be at the top l= evel, meaning first TLV. 22. In section 4.2.16 - PKCS#7 has been superseded by CMS - the references should be to CMS and not to PCKS#7 [HZ] Ok with me. Any other feedback from the WG? 23. In IANA - Need to add the Request-Action TLV to the list of status codes [HZ] It is included in the Result TLV, Intermediate Result TOV status code = registry in the IANA section. I think it makes sense to have the same one. [JLS] =96 my bad, I missed that it was in the list. 24. In IANA - Should the Vender ID of the Vender-Specific TLV be kept in a registry? [HZ] Vendor ID per the draft, is the SMI Network Management Private Enterpr= ise Code already managed by IANA. Yes =96 I just missed that the first time around =96 sorry Jim -----Original Message----- From: emu-bounces@ietf.org [mailto:emu-bounces= @ietf.org] On Behalf Of Alan DeKok Sent: Tuesday, September 25, 2012 8:04 AM To: emu@ietf.org Subject: [Emu] Looking for reviewers We'd like to get the final two documents into last call before the next meeting. Therefore, we're looking for reviewers: https://datatracker.ietf.org/doc/draft-ietf-emu-crypto-bind/ https://datatracker.ietf.org/doc/draft-ietf-emu-eap-tunnel-method/ Please post reviews to the list. If all goes well, we can get updated documents issued before the next meeting. Thanks to everyone for their help. Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu --_000_645B00545719594A88ADF4221831FD3814D595xmbrcdx14ciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <7F190455CDF24549BAC264F20842F200@cisco.com> Content-Transfer-Encoding: quoted-printable
Jim:

Please see comments below inline.

From: Jim Schaad <ietf@augustcellars.com>
Date: Monday, October 8, 2012 12:53= AM
To: Cisco Employee <hzhou@cisco.com>
Cc: "emu@ietf.org" <emu@ietf.= org>
Subject: RE: [Emu] Review of draft-= ietf-emu-eap-tunnel-method-00

Hao, comments in line

 

From: Hao Zhou (hzhou) [mailto:hzhou@cisco.com]
Sent: Thursday, October 04, 2012 10:39 AM
To: Jim Schaad
Cc: emu@ietf.org
Subject: Re: [Emu] Review of draft-ietf-emu-eap-tunnel-method-00

 

Jim:

 

Thanks very much for your detailed review. Please see the com= ments below. We will respond to your other emails shortly. =

 

On 9/28/12 9:18 PM, "Jim Schaad" <ietf@augustcellars.com> wrote:

 

1.  In section 3.2.3, it says that a new PAC can be= requested after a full

TLS handshake.  Can one be requested following an a= bbreviated handshake?

Or

do you just re-use the existing PAC?

[HZ] RFC5077 does not specify that client can request a new t= icket after

sending the TLS ticket, if the client is resuming a session u= sing the

session ticket, then it cannot request a new session ticket b= ased on

resumed session. We will add some language to clarify that it= is not

allowed.

 

2.  Section 3.3 s/descried/described/

[HZ] Ok.

 

3.  Section 3.4 - Is it possible to have multiple s= erver ids after the

authentication - one from the tunnel and others from the inne= r EAP

methods.

I realize that most EAP methods don't send a sender id, but s= ome (IBAKE

for

example) currently do.  Also, the client might have= an idea of what the

sender id is from configuration.  If so, do these a= ll need to get exported

as server-id values?

[HZ] Good catch. We will add a sentence similar to peer-ID, w= here multiple

server IDs need to be exported.

 

4. In section 3.6.1 - It is not clear that an EAP-Failure pac= ket is sent

when 1) the server sends a fatal alert to the peer, 2) the pe= er requests a

restart via a ClientHello and 3) the peer declines to permit = the restart

to

occur.

[HZ] We will clarify that EAP-Failure packet will be sent in = those cases.

 

[JLS] Just to be clear =96 this is= a single case not three cases.  It is a sequence of events that shoul= d lead to the EAP-Failure packet.
[HZ] ok.

 

 

5.  In section 3.6.1 - Is the restart only an issue= for fatal alerts, or

is

it a problem for all alerts?

[HZ] Restart is only allowed for non-fatal alerts, per TLS RF= C. "Upon

transmission or receipt of a fatal alert message, both p= arties immediately close the connection.", so restart is not desired

in this case. We will clarify that restart is only allowed in= non-fatal

alert cases.

 

[JLS]  It may just be me, but= this seems to be a bit odd from my point of view.  It is not clear th= at in the event of a non-fatal alert that there is any need for the two parties to start a new negotiation that would ensu= e upon getting a Hello restart.  There is a question in terms of closi= ng the connection if the TLS document means just the TLS session or the enc= apsulating transport is to be shut down as well.  If it means the latter then it makes sense that you could r= equest a new TLS negotiation without having to build all of the EAP transpo= rt frame work (i.e the entire RADIUS session?).

 

Please re-look at this and ensure = that this is really what you mean.
[HZ] Good point. I think the draft text is written in the way to allow= restart for all alerts. I think the text is modeled after the EAP-TLS RFC = 5216 and is fine.

 

 

6.  In section 3.6.2 - Why SHOULD not MUST send cle= ar text EAP-Failure?

[HZ] We will change it to MUST.

 

7.  In section 3.6 - do we need to discuss the ques= tion of errors in the

outer EAP layer that is carrying the TLVs which contain the T= LS content?

This is a distinct location from the current list of where to= handle

errors.

There is going to be a distinction (possibly) between errors = that occur

during phase 1 and errors during phase 2.  Should t= he error return reflect

if the error occurred inside or outside of the TLS tunnel?

[HZ] Good catch. We will add some language to clarify dealing= with outer

packet errors. Something like:

1. If Outer TLVs are wrong, they will be ignored.<= /span>

2. If others (version, length, flags, etc.) are wrong, the en= tire EAP

packet will be ignored.

 

[JLS} Looks reasonable.=

 

 

 

8.  In section 3.8 - I have the following questions=

a) In the text "The request MAY be issued", I don't= understand the MAY at

this point.  Is it supposed to say that the request= can be issued either

before or after the authentication has finished, or is it say= ing that the

peer has the option of issuing or not issuing the request, bu= t must wait

until the authentication level has been reached?

[HZ] It's the later. How about add "only" in front = "after the peer has

determined that..."?

 

[JLS] That does deal with the imme= diate issue.  However the fact that you need to do the Crypt-Binding T= LV for tunnel validation does imply that an EAP method that generates a key is a requirement before being able to g= et a PAC.  Is this what is intended?  Should you be able to get a= PAC just from validating the tunnel with the server and knowing the server= s name from it=92s certificate?
[HZ] If there is an inner EAP method, then it makes sense to validatin= g the crypto binding to ensure the tunnel integrity and the inner EAP metho= d. Otherwise, requesting PAC after validating the server is fine. Will add = text to clarify.

 

b) If a peer issues a PAC request, but the server has not yet= satisfied

it's

policy, does the server remember the PAC request and send bac= k the

response

after the internal policy has been satisfied or should it sen= d back an

error

saying that policy has not yet been satisfied along with addi= tional TLVs

to

attempt and satisfy that policy?

[HZ] The server remembers that and issues the PAC after its p= olicy is

satisfied. We will clarify that.

 

c) What should a peer do if it receives a PAC TLV with an unk= nown

attribute?

[HZ] Ignore that.

[JLS] Please be detailed =96 ignor= e the attribute or ignore the PAC.
[HZ] Ignore the attribute.

 

 

9.  In section 3.9 - there is leaking on the POP, b= ut not on identity at

this point.  I believe that there needs to be a req= uirement that an EAP

method needs to be run which will provide an identity proof o= n the client

prior to a certificate being issued.  You may or ma= y not then want to add

text that says that the subject name(s) in the certificate re= quest need to

be checked against the set of authenticated identities prior = to the

certificate being issued.

[HZ] Good point. We will add some that.

 

 

10. In section 3.10 - It is unclear to me if the Server Unaut= henticated

mode

is because the server or the peer is unauthenticated at this = point in

time.

The cipher suite would indicate that the server is not authen= ticated,

however what about the case of the server providing an authen= ticated id to

the peer, but the peer is unable to validate the identity of = the server

for

some reason.  This is also a Server Unauthenticated= mode.

[HZ] Yes. It covers both cases. We will add language to clari= fy that.

 

 

11.  In section 4.1 - I would like to see a discuss= ion that says that the

following situation can never occur.  The initial E= AP message from the

peer

to the server (or the response) plus the Outer TLV data plus = the EAP

message

headers exceeds the underlying packet size of the transport.&= nbsp; In the event

that it does, I am not sure how one finds the Outer TLV data = start and

where

the fragmentation would occur to get the Outer TLV data betwe= en the peer

and

the server.

[HZ] I think it should work as defined. The start of the Oute= r TLVs should

be derived from the EAP message length and length of the TLS = data.

[JLS] I have gotten a better under= standing =96 I may have suggested text elsewhere

 

 

12.  Section 4.2 - I understand what is happening w= ith an EMPTY TEAP

message

being sent in response to a list of TLVs that are marked opti= onal,

however I

question if the statement that is MUST be sent is correct.&nb= sp; There are two

reasons for the question:

 

a.  A server could send a RESULT TLV in response to= a message from the

client that contains no TLVs that are either mandatory or rec= ognized.

[HZ] Good catch. We will clarify that.

 

b.  I am (very slightly) worried about the fact tha= t the response is not

authenticated by the tunnel in many manner.  I woul= d think that a NAK to

any

of the TLVs would be a better response if no other TLV messag= es are to be

sent.  The entity sending the TLV should know if it= marked it as mandatory

or not.  The NAK is not the same as an Error TLV.

[HZ] Agree. A NAK  TLV should be sent in this case. We w= ill clarify.=

 

13.  Section 4.2.2 - Should "Type" in the= outdented list be "TLV Type"?

s/filed/field/

[HZ] Yes. We will correct that.

 

14.  Section 4.2.2 - Can multiple Authority-ID TLVs= be transmitted to a

peer?

[HZ] No. It is mentioned in Section 4.3, Table of TLVs rules.=

[JLS} That says that you cannot se= nd multiple Authority IDs in a single message, what about in multiple messa= ges?
[HZ] Authority ID is only to be sent in the first server to peer TEAP messa= ge, so shouldn't be multiple messages. Will clarify in the Outer TLV rule s= ection to be added.

 

 

 

15.  Section 4.2.3 - I assume that there should onl= y be one Identity-Type

TLV in a TEAP packet.  Should a request for authent= ication be present in

the

packet as well?  If multiple are allowed then infor= mation about how to

treat

this should be included.  What should the peer resp= ond with if it does

have

an identity of the type?  This is not explicitly st= ated.

[HZ] That's correct, only one Identity-Type TLV is allowed.Th= e requested Identity type  MUST comes with an EAP request or Basi= c-Password-Auth-Req. 

If the peer has the requested identity type, it should send b= ack the same identity type TLV in the response. We missed this and will add= this clarification.

 

16.  Section 4.2.4 - I don't understand the default= in the event that an

unknown value is sent in the status field.  If ther= e is an ERROR TLV in

the

message, should I not use that error code rather than change = it?

[HZ] No. The error code in the Error TLV if being sent with t= he Result TLV might mean something, but since the peer doesn't understand t= he Status field, and most likely will not understand the error code. Sending back Unexpected_TLVs_Exchanged= error code is probably appropriate.

[JLS] I was assuming that the cl= ient did understand the error code, otherwise I agree that using a well und= erstood error is correct behavior.
[HZ] Still, peer encounters an unknown or unexpected TLV, which is a d= ifferent error than what the other side wants to convey on the error tlv.&n= bsp;

 

 

17. Section 4.2.6 - Do we need a discussion about how to prod= uce/deal with

vender specific errors?  Do you expect that vender = specific TLVs will have

an error mechanism built into them to return an error code?

[HZ] We expect the vendor TLV will have its own error handlin= g mechanism or use the standard error codes defined.

 

 

18. Section 4.2.8 - Do we need to talk about the question of = having some

Vender TLVs be marked as mandatory and others not.  = ;Are we using the same

TLV structure with the same rules for mandatoriness. &nb= sp;If the mandatory bit

is set, does that mean that I need to recognize the vendor-id= or all

combinations of vender-id/Vender-TLV type?<= /p>

[HZ] Yes. If th= e mandatory bit is set on the Vendor-Speific TLV, then the peer need to rec= ognize the vendor ID and all combination of the vendor TLVs. The Vendor TLV= format is up to the vendor to define, as specified by the current draft.

 

 

19.  Section 4.2.9 - After reading this, sketching = out some scenarios and

so

forth, I find that I do not like the text and result being pu= shed here at

all.  My problems start, in some respects, with the= name of the TLV as it

does not map to how I would like to see this TLV treated.&nbs= p; I would propose

the following set of changes:

a) The name of the TLV be changed from Request-Action TLV to<= o:p>

Provisional-Result TLV

[HZ] I am open with the name change, but think Request-Action= probably capture the essence better.

 

b) It needs to be made clear that the TLV can be sent from ei= ther the

server

to the peer or the peer to the server.  It is my be= lief that presently it

is

only sent from the peer to the client and only in response to= a successful

Result TLV.

[HZ] Ok. I agree that we can extend that to be bidirectional = and for either success and failure Result TLV.

 

c)  The receiving entity MUST process the TLV.=

[HZ] Ok.

 

d)  The processing for the TLV is as follows:<= /o:p>

   i) The entity MAY choose to process (or start?) = any of the TLVs that

are

included in the message.

  ii) If the entity chooses NOT to process any TLV = in the list, the

Provisional-Result TLV is treated as a Result TLV with the co= de "status"

  iii) If multiple Provisional-Result TLVs are in t= he body, the session

can

continue if ANY of TLV in any Provisional-Result TLV is proce= ssed.

  iv) If multiple Provisional-Result TLVs are in th= e body and no sub-TLV

is

processed, then the most fatal status should be used. &n= bsp;If a status is

found

which is not understood by the entity, then it should be trea= ted as a

fatal

TLV.

[HZ] Ok.

 

 

The current text allows for the following:<= /p>

The server sends a Success to the peer

The peer says please do this or go to fatal=

The server sends a clear success outside of the tunnel.<= /o:p>

[HZ] That= 's not correct. The last exchange in the tunnel should be an agreed upon Re= sult TLV exchange, before the tunnel is torn down and a clear text EAP succ= ess is sent.

 

[JLS] Just to be clear, you are saying that the conversat= ion will look like

 

Server =E0 Result TLV (Success)

         &nb= sp;        Request-Action (Status-Bletch= , foobar) =DF Client

Server =E0 Result TLV (Success)

         &nb= sp;     Result TVL (Success) =DF Client (knows that the server must not be wil= ling to do what was asked.

 

The server COULD send back the Bletch code if it decides = to process the Request-Action TLV from the client.  The client could s= end back Bletch even if the server does not send it the second time.

[HZ] Not quite. Status-Bletch=  indicates the result if the server does not process the ac= tion requested by the peer. So if the server does not process the request, then it will look&nb= sp;like this:

Server =E0 Result TLV (Success)

  &nbs= p;            &= nbsp;  Request-Action (Status-Bletch, foobar) =DF=  Cli= ent

Server =E0 Result TLV (Status-Bletch)

  &nbs= p;            Result= TVL (Sta= tus-Bletch) 


If the server processes the request and succeeds, it will look like this:=

Server =E0 Result TLV (Success)

  &nbs= p;            &= nbsp;  Request-Action (Status-Bletch, foobar) =DF=  Cli= ent

.. Process TLVs or start another&nb= sp;EAP

Server =E0 Result TLV (Success)

  &nbs= p;            Result= TVL (Success) =DF Client 

    

 

I wonder if the capability needs to be added to say, please s= tart this

TLV.

So that a server can say, If you don't start a Channel bindin= g TLV, I will

make this a failure return code, if you want to start the cha= nnel binding

TLV then I am open to giving you a success return code.<= /o:p>

OK - so this is kind of there, but only one value can be plac= ed there.

One cannot say do either an EAP negotiation or process this T= LV.

[HZ] That's true. Only one request.

 

[JLS] Since you can only have one = Request-Action TLV for a given status code, but presumably multiple Request= -Action TLV with different status codes,  that seems slightly restrictive.    However, I can de= al with this. 

 

[JLS] Difference in opinion in the= document.  The text in 4.2.9 says that multiple with different status= codes ok, but the table says  0-1 in a single message

 
[HZ] Good catch, will fix.

 

20. Section 4.2.12.4 - What does it mean to have an I-ID vali= dation

enforcement for PAC session renewal?  Does it mean = that the final message

is

not sent unless an appropriate ID is presented?  Do= es it have to be an EAP

authentication or is password based authentication sufficient= ?  Should a

PAC

be invalidated on the server side (oops how do you do that) i= f it a PAC is

presented and then the appropriate ID is not given?

[HZ] The I-ID in the PAC is used to validat= e that the correct user is being authenticated and using his PAC. If they d= on't match, then the authentication will be rejected as if the authentication failed, with the normal flow inc= luding the final Result TLV and clear text EAP failure being sent. It can b= e either the EAP authentication or the password based authentication. The P= AC is not invalidated if the I-ID doesn't match the authenticated identity, the authentication will be rejec= ted.

 

21.  In section 4.2.12.6 - Is this supposed to be a= t the top level or

embedded in the PAC-TLV?

[HZ] Yes.

[JLS] I think the correct response= is =96 =93I don=92t understand the question=94  It is only embedded a= nd I don=92t know why I ever thought  it would be at the top level.
[HZ] Yes, it is embedded in PAC-TLV. I meant that it should be at the top l= evel, meaning first TLV.

 

 

22.  In section 4.2.16 - PKCS#7 has been superseded= by CMS - the

references

should be to CMS and not to PCKS#7

[HZ] Ok with me. Any other feedback from the WG?

 

23.  In IANA - Need to add the Request-Action TLV t= o the list of status

codes

[HZ] It is incl= uded in the Result TLV, Intermediate Result TOV status code registry in the= IANA section. I think it makes sense to have the same = one.

[JLS] =96 my bad, I missed that it= was in the list.

 

 

24.  In IANA - Should the Vender ID of the Vender-S= pecific TLV be kept in

a

registry?

[HZ] Ve= ndor ID per the draft, is the SMI Network Management Private Enterprise Code already managed by IANA. = ;

 

Yes =96 I just missed that the fir= st time around =96 sorry

 

 

Jim

 

-----Original Message-----

Alan DeKok

Sent: Tuesday, September 25, 2012 8:04 AM

Subject: [Emu] Looking for reviewers

   We'd like to get the final two documents into la= st call before the

next

meeting.  Therefore, we're looking for reviewers:

   Please post reviews to the list.  If a= ll goes well, we can get updated

documents issued before the next meeting.

   Thanks to everyone for their help.

   Alan DeKok.

_______________________________________________

Emu mailing list

 

_______________________________________________

Emu mailing list

 

 --_000_645B00545719594A88ADF4221831FD3814D595xmbrcdx14ciscocom_-- From stefan.winter@restena.lu Thu Oct 11 02:21:06 2012 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1C6F21F873B for ; Thu, 11 Oct 2012 02:21:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XnsDlr95CtUW for ; Thu, 11 Oct 2012 02:21:05 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 2B9EE21F871A for ; Thu, 11 Oct 2012 02:21:05 -0700 (PDT) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id A9B9910590; Thu, 11 Oct 2012 11:20:59 +0200 (CEST) Received: from [IPv6:2001:a18:1:8:dd66:199e:ec28:e2ab] (unknown [IPv6:2001:a18:1:8:dd66:199e:ec28:e2ab]) by smtprelay.restena.lu (Postfix) with ESMTPS id 97CF41058E; Thu, 11 Oct 2012 11:20:59 +0200 (CEST) Message-ID: <50768F7B.1000705@restena.lu> Date: Thu, 11 Oct 2012 11:20:59 +0200 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120825 Thunderbird/15.0 MIME-Version: 1.0 To: "Hao Zhou (hzhou)" References: <645B00545719594A88ADF4221831FD3814BC40@xmb-rcd-x14.cisco.com> In-Reply-To: <645B00545719594A88ADF4221831FD3814BC40@xmb-rcd-x14.cisco.com> X-Enigmail-Version: 1.4.4 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigFE0ED422945B16ACA03CC54A" X-Virus-Scanned: ClamAV Cc: "" Subject: Re: [Emu] Client Auth with TLS X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2012 09:21:06 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigFE0ED422945B16ACA03CC54A Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, > Actually even if the client is authenticated as part of the TLS tunnel > establishment, NEA data can still be passed inside TEAP tunnel. It is > designed to carry additional data in Phase 2. >=20 > The Current TEAP draft supports both of these modes, as in Section 3.2:= Thanks for the explanation. Well, if it supports both then that opens space for misunderstandings. When configuring protected client auth, one implementation might on the wire choose to do protected client-side auth within the TLS handshake, but another might expect an inner EAP-TLS inste= ad. I fail to see why supporting *both* modes of operation is required. From my (non-implementer's) point of view, I see two code paths to achieve the same goal here. In terms of implementation complexity, it would appear to me that using inner EAP-TLS makes the client cert exchange "yet another inner EAP method" (ideally able to share code with other inner EAP method's session establishment), while a TLS-handshake operation creates a "special case" to be handled differently. Greetings, Stefan Winter >=20 > "TEAP implementations MUST support client authentication during tunnel > establishment using the TLS ciphersuites specified in Section 3.2 > > . > The EAP peer does not need to authenticate as part of the TLS > exchange, but can alternatively be authenticated through additional > exchanges carried out in Phase 2. >=20 > The TEAP tunnel protects peer identity information exchanged during > phase 2 from disclosure outside the tunnel. Implementations that > wish to provide identity privacy for the peer identity must carefull= y > consider what information is disclosed outside the tunnel prior to > phase 2. TEAP implementations SHOULD support the immediate > renegotiation of a TLS session to initiate a new handshake message > exchange under the protection of the current cipher suite. This > allows support for protection of the peer's identity when using TLS > client authentication." >=20 >=20 > It properly doesn't describes the TLS exchanges as detailed as in EAP-T= LS > RFC, but something we could improve if desired. >=20 >=20 > On 10/9/12 10:23 AM, "Stefan Winter" wrote: >=20 >> Hi, >> >>> I think it is worthwhile to support an mode of operation that support= s >>> peer privacy. I've seen this implemented in tunnel methods in two >>> different ways. One with renegotiation as described below and the ot= her >>> as an inner EAP-TLS exchange after an anonymous outer exchange. I >>> don't really have a strong opinion as to which is better at this poin= t. >>> It seems that using an inner EAP-TLS may be more flexible and would >>> offer the same security properties and might be a simpler model. >>> >>> Any opinions on the list? >> >> We have a couple of EAP-TLS realms which are also interested in NEA. I= >> usually tell them that NEA data can't be put into the EAP channel with= >> EAP-TLS, and that that is bad luck for them :-) >> >> If TEAP uses tunneled EAP-TLS as opposed to renegotiating, the inner E= AP >> would/might allow for carrying extra attributes besides the cert >> exchange - thus enabling NEA-like exchanges. >> >> If my thinking isn't borked, that would mean I'd rather support inner >> EAP-TLS to enable these usages. >> >> Greetings, >> >> Stefan >> >>> >>> >>> >>> On Oct 7, 2012, at 8:43 PM, Jim Schaad wrote: >>> >>>> Stefan, >>>> >>>> Thanks for the input. >>>> >>>> For the authors, >>>> >>>> Does this need to be documented as a mode of operation for TEAP or a= re >>>> we >>>> going to say that this is not a supported mode? >>>> >>>> Jim >>>> >>>> >>>>> -----Original Message----- >>>>> From: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org] On Behalf = Of >>>>> Stefan Winter >>>>> Sent: Wednesday, October 03, 2012 11:10 PM >>>>> To: emu@ietf.org >>>>> Subject: Re: [Emu] Client Auth with TLS >>>>> >>>>> Hi, >>>>> >>>>>> 3. The client provides the certificate in a protected manner - I = had >>>>>> a problem at this point because I don't know enough TLS to properl= y >>>>>> go >>>>>> through this scenario, and I could not really read documents while= >>>>>> driving. If the encrypted certificate extension was used, then th= ere >>>>>> is no issue as the protected certificate would be passed in the >>>>>> initial handshake. However if the client starts the negotiation a= nd >>>>>> then restarts it after it is encrypted, I don't know if this occur= s >>>> before or >>>>> after the finish message. >>>>>> If it starts after the finish method then there is an issue with >>>>>> having the server close an anonymous session if the client is then= >>>>>> going to provide the certificate encrypted. Help on how this work= s >>>> would >>>>> be appreciated. >>>>> >>>>> FWIW, RFC5216 (EAP-TLS) already has provisions for a protected clie= nt >>>>> credential exchange (for client privacy protection reasons). I didn= 't >>>>> ever >>>> see it >>>>> used (anyone?), but it's clearly a foreseen mode of operation. The >>>>> text >>>>> describing this is in section 2.1.4: >>>>> >>>>> "... In order to avoid disclosing the peer username, an EAP-TLS >>>>> peer >>>>> configured for privacy MUST negotiate a TLS ciphersuite supportin= g >>>>> confidentiality and MUST provide a client certificate list >>>>> containing >>>>> no entries in response to the initial certificate_request from th= e >>>>> EAP-TLS server. >>>>> >>>>> An EAP-TLS server supporting privacy MUST NOT treat a certificate= >>>>> list containing no entries as a terminal condition; instead, it M= UST >>>>> bring up the TLS session and then send a hello_request. The >>>>> handshake then proceeds normally; the peer sends a client_hello a= nd >>>>> the server replies with a server_hello, certificate, >>>>> server_key_exchange, certificate_request, server_hello_done, etc.= >>>>> >>>>> For the calculation of exported keying material (see Section 2.3)= , >>>>> the master_secret derived within the second handshake is used. >>>>> >>>>> An EAP-TLS peer supporting privacy MUST provide a certificate lis= t >>>>> containing at least one entry in response to the subsequent >>>>> certificate_request sent by the server. If the EAP-TLS server >>>>> supporting privacy does not receive a client certificate in respo= nse >>>>> to the subsequent certificate_request, then it MUST abort the >>>>> session. >>>>> " >>>>> >>>>> There is a sequence diagram shortly afterwards which shows clearly >>>>> that >>>> the >>>>> "first" negotiation ends with a 'finished' and then immediately a n= ew >>>>> 'hello_request' - all in one EAP message. >>>>> >>>>> Greetings, >>>>> >>>>> Stefan >>>>> >>>>>> >>>>>> Jim >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Emu mailing list >>>>>> Emu@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/emu >>>>>> >>>>> >>>>> >>>>> -- >>>>> Stefan WINTER >>>>> Ingenieur de Recherche >>>>> Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education Na= tionale >>>>> et de >>>>> la Recherche 6, rue Richard Coudenhove-Kalergi >>>>> L-1359 Luxembourg >>>>> >>>>> Tel: +352 424409 1 >>>>> Fax: +352 422473 >>>> >>>> >>>> _______________________________________________ >>>> Emu mailing list >>>> Emu@ietf.org >>>> https://www.ietf.org/mailman/listinfo/emu >>> >> >> >> --=20 >> Stefan WINTER >> Ingenieur de Recherche >> Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education Natio= nale et >> de la Recherche >> 6, rue Richard Coudenhove-Kalergi >> L-1359 Luxembourg >> >> Tel: +352 424409 1 >> Fax: +352 422473 >> >=20 --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 --------------enigFE0ED422945B16ACA03CC54A Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlB2j3sACgkQ+jm90f8eFWbSywCcC6aX6DC4rmpxP881SGkKtnhh 8H8An2LRnqc7d+HrmIAKAEyYcvHIWmX0 =CA6w -----END PGP SIGNATURE----- --------------enigFE0ED422945B16ACA03CC54A-- From jsalowey@cisco.com Mon Oct 15 08:58:39 2012 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 557EC1F0C44 for ; Mon, 15 Oct 2012 08:58:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.476 X-Spam-Level: X-Spam-Status: No, score=-110.476 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g0JhA67FVQ30 for ; Mon, 15 Oct 2012 08:58:38 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id CF82E1F042B for ; Mon, 15 Oct 2012 08:58:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=283; q=dns/txt; s=iport; t=1350316718; x=1351526318; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=PwjruE4OYVYAv38M01I4Fl+QObL/T8fuXXrK8lZ5f80=; b=DPBZQZH/sDyuhuOiUGwummcH41tLmG8zxsUAFwcJTx+Ffzz2sEuH5VyG 4xGLGf4uvcDCK0YerZ4at8vsES+4xBaqho44UKRll/se3i1XzwOZPOeHo n91Pf4/DLvo++0DB3uSsKHRbxBeLRTYcaAn3mOeHONhgKkc9TbVOX0uKZ A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EACQyfFCtJXG//2dsb2JhbABFv3eBCIIiAQQSASdRASoUQicEGxqHYpxngSifc5E2YAOkMYFrgm2CFw X-IronPort-AV: E=Sophos;i="4.80,588,1344211200"; d="scan'208";a="131725712" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-8.cisco.com with ESMTP; 15 Oct 2012 15:58:38 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id q9FFwcXt014859 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 15 Oct 2012 15:58:38 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.68]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0318.001; Mon, 15 Oct 2012 10:58:38 -0500 From: "Joseph Salowey (jsalowey)" To: "emu@ietf.org" Thread-Topic: EMU meting at IETF 85 Thread-Index: AQHNqu3we0JCJCqBRk+gJCxoqH+Z1g== Date: Mon, 15 Oct 2012 15:58:37 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.249.92] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19274.004 x-tm-as-result: No--26.384400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <6B643AA7301B874085A992C5A711662E@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Emu] EMU meting at IETF 85 X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2012 15:58:39 -0000 EMU is scheduled to meet Wednesday, November 7, 1440-1540. I expect we w= ill spend most of the meeting working on any remaining issues for TEAP and = mutual crypto binding work. Please let the chairs know if there are addit= ional topics to discuss. =20 Thanks, Joe= From alper.yegin@yegin.org Mon Oct 22 03:07:09 2012 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3E6021F8B03; Mon, 22 Oct 2012 03:07:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.541 X-Spam-Level: X-Spam-Status: No, score=-102.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i+Y3biSGU7iN; Mon, 22 Oct 2012 03:07:08 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 7300621F89EC; Mon, 22 Oct 2012 03:07:08 -0700 (PDT) Received: from [192.168.2.5] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0LyEBR-1TKh2J2VdN-015PtV; Mon, 22 Oct 2012 06:07:04 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Alper Yegin In-Reply-To: Date: Mon, 22 Oct 2012 13:06:40 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <81B15FE2-DD05-411B-A35B-0E0AB3E213A3@yegin.org> References: <6AB91560-84B9-4311-B383-95C0A01911E4@yegin.org> To: Sam Hartman X-Mailer: Apple Mail (2.1278) X-Provags-ID: V02:K0:jhPbu8Oj6KWdzEYlfaIoDuhMQrjQ4xqCIECf2LoJGHC +j92+N5fqRsq9PwkP2R9BgB9MBkY/UfKFRuAWYkQHPPxCQBeux S/qbKOoJfCbin68fVU9oj2GlNVMFL+D0SvKVJXAzb3RlCdqhwy fzyLvZDYVdO0j1hqlpBclxtSAmdQp+O/UMIYrpKIDgxrxmGR3Y 4hWfzq3YQkSaJkp5Hu/Lbed6cvNnKqApL5QFmiKdJMQbA/ad7Q gAZsTueGuzReLWEFUG5SjkgM2kA+oUGY/QoLLwm9HrrldUEc3A 0o+jMZC3e2bi2PNp7gdd2zr+CQtCanhM8XAoHhZaeJCD8ttiu+ sgIPEUJADxvn0dVl+3gxk0aJv2ewI3Sega2F2dfNss8V/mMZX2 wqfjjYMqw6qjw== Cc: radext@ietf.org, abfab@ietf.org, pcp-chairs@tools.ietf.org, emu@ietf.org, dime@ietf.org, eap@frascone.com Subject: [Emu] Tweaking EAP (RFC 3748) X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 10:07:09 -0000 On Oct 19, 2012, at 5:08 PM, Sam Hartman wrote: >>>>>> "Alper" =3D=3D Alper Yegin writes: >=20 > Alper> Hi Sam, Please also share this discussion with EAP WG and = EMU > Alper> WG mailing lists. That's where the EAP expertise is and they > Alper> should chime in, given that you are proposing to modify EAP > Alper> applicability statement. >=20 > The eap applicability statement update is a charter item of > ABFAB. We've agreed it will be last called in EMU. > Since it's a work item of abfab, it should be discussed on that list. > You're certainly free to let people know that the discussion if taking > place, although we've done that several times before. Sam, The type of changes you are talking about are well beyond the = "applicability statement changes" that ABFAB is chartered to make. Now you are discussing how EAP can be executed in a client-driven style = (as opposed to network driven), how server-initiated EAP = re-authentication may not be supported, how authorization parameters = (especially the session lifetime) is not set by the AAA server.=20 We need EAP and AAA expertise to get involved in the discussion. Not = only when ABFAB WG thinks it is done, but especially from the get go. This, IMHO, is re-engineering EAP and associated AAA procedures. Alper From internet-drafts@ietf.org Mon Oct 22 07:55:19 2012 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 446A421F8B8D; Mon, 22 Oct 2012 07:55:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.539 X-Spam-Level: X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wfMhDjqi0XTK; Mon, 22 Oct 2012 07:55:18 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C901421F84CF; Mon, 22 Oct 2012 07:55:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121022145518.17859.8199.idtracker@ietfa.amsl.com> Date: Mon, 22 Oct 2012 07:55:18 -0700 Cc: emu@ietf.org Subject: [Emu] I-D Action: draft-ietf-emu-eap-tunnel-method-04.txt X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 14:55:19 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the EAP Method Update Working Group of the IE= TF. Title : Tunnel EAP Method (TEAP) Version 1 Author(s) : Hao Zhou Nancy Cam-Winget Joseph Salowey Stephen Hanna Filename : draft-ietf-emu-eap-tunnel-method-04.txt Pages : 104 Date : 2012-10-22 Abstract: This document defines the Tunnel Extensible Authentication Protocol (TEAP) version 1. TEAP is a tunnel based EAP method that enables secure communication between a peer and a server by using the Transport Layer Security (TLS) to establish a mutually authenticated tunnel. Within the tunnel, Type-Length-Value (TLV) objects are used to convey authentication related data between the EAP peer and the EAP server. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-emu-eap-tunnel-method There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-emu-eap-tunnel-method-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-emu-eap-tunnel-method-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From alper.yegin@yegin.org Tue Oct 23 01:09:16 2012 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65D0321F8464; Tue, 23 Oct 2012 01:09:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.545 X-Spam-Level: X-Spam-Status: No, score=-102.545 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id leU1FS7HICmv; Tue, 23 Oct 2012 01:09:14 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 4975921F84B1; Tue, 23 Oct 2012 01:09:14 -0700 (PDT) Received: from [192.168.2.5] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0MKHde-1TOvdh1gIA-0025Fn; Tue, 23 Oct 2012 04:08:33 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Alper Yegin In-Reply-To: Date: Tue, 23 Oct 2012 11:08:09 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <47A4DA97-971F-4292-98D7-FF28A9CAB88C@yegin.org> References: <6AB91560-84B9-4311-B383-95C0A01911E4@yegin.org> <81B15FE2-DD05-411B-A35B-0E0AB3E213A3@yegin.org> To: Sam Hartman X-Mailer: Apple Mail (2.1278) X-Provags-ID: V02:K0:8yeC5v3uIkV11ucL5pEiYfjPbV6/f2fypAHjb2NVST0 geVIFTCbBDuhj83eim+SDdQjIgI0l/jpj11Txyi29qmH2IUgE+ dFVlITB/0YnWBWB1ka7vA9+M/gOi51biZf7CMVDx5AXttz193s j+M+9Ttd4QzlsiXuaHFWoeZUFCYHqkeaW3paXuHGFsVW5invpU GkzPw2V1niY2lJDeiEEXXoMIWHk84gdMioEHMcQYBomxXdj9zV Fv/Ea24uMFyXjYRBZSSiGi8cCGkt+ZuCvod+HoW8/I8qWzDlTe xCbNdLp8OOj8Fu7dbI16+NOLK9FcA+c5LEU5kj1rh48NcMUz/7 lDU8dcAf0b1s6PzeC+mOfIhDo8hV7D0stM/pJmxK8gHmyFbtFG SRXPZ2frzcwHw== Cc: radext@ietf.org, abfab@ietf.org, pcp-chairs@tools.ietf.org, emu@ietf.org, dime@ietf.org, eap@frascone.com Subject: Re: [Emu] [radext] Tweaking EAP (RFC 3748) X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 08:09:16 -0000 >>>>>> "Alper" =3D=3D Alper Yegin writes: >=20 > Alper> On Oct 19, 2012, at 5:08 PM, Sam Hartman wrote: >=20 >>>>>>> "Alper" =3D=3D Alper Yegin writes: >>>=20 > Alper> Hi Sam, Please also share this discussion with EAP WG and = EMU > Alper> WG mailing lists. That's where the EAP expertise is and they > Alper> should chime in, given that you are proposing to modify EAP > Alper> applicability statement. >>>=20 >>> The eap applicability statement update is a charter item of >>> ABFAB. We've agreed it will be last called in EMU. Since it's a >>> work item of abfab, it should be discussed on that list. You're >>> certainly free to let people know that the discussion if taking >>> place, although we've done that several times before. >=20 > Alper> Sam, >=20 > Alper> The type of changes you are talking about are well beyond = the > Alper> "applicability statement changes" that ABFAB is chartered to > Alper> make. =20 >=20 > First, I definitely encourage you to involve anyone in any IETF WG > discussion you believe will help form a better consensus. > So, absolutely, encourage people who you believe should join the > discussion to do so. >=20 Good. Please remember to keep these groups updated as you progress the = discussion. > I am a bit confused by your message, because I'm not discussing = changing > EAP, only discussing how some issues that seem relatively likely to = come > up will influence applying EAP authentication to application > authentication. I captured the issues you are raising as below: > how EAP can be executed in a client-driven style (as opposed to = network driven), how server-initiated EAP re-authentication may not be = supported, how authorization parameters (especially the session = lifetime) is not set by the AAA server.=20 These have potential impact on the EAP layer, and EAP lower-layer (both = the EAP peer to EAP Authenticator leg, and the EAP Authenticator to EAP = Authentication Server leg [a.k.a, the AAA protocol]). We need to fully = understand the implications. These are not mere "applicability" issues.=20= The ABFAB applicability update in my understanding is nothing more than = removing the somewhat artificial constraints in RFC 3748 that was = blocking the use of EAP for anything other than network access = authentication. The types of issues you are discussing now are well = beyond that. > My intent is to document existing, potentially hard to understand > aspects of EAP so that people can better apply EAP to their > applications. >=20 Alper > Thanks, >=20 > --Sam > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext From jsalowey@cisco.com Tue Oct 23 11:46:28 2012 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B93721F0CA4 for ; Tue, 23 Oct 2012 11:46:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.441 X-Spam-Level: X-Spam-Status: No, score=-110.441 tagged_above=-999 required=5 tests=[AWL=0.159, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jz5SXLaHNOj0 for ; Tue, 23 Oct 2012 11:46:28 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 1E69D1F042A for ; Tue, 23 Oct 2012 11:46:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=366; q=dns/txt; s=iport; t=1351017988; x=1352227588; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=vJEiijL8LSbq+YVtgZlueXpUwUbQDjDrQlkbhoOi3dU=; b=ECuhwQ0XOerLXoxjhThygYNpUrZUcaP6C/bxwfpNCMncPtoygqgkgeYd rLQ3hwpHTsij/kgnE7hFwRZQev7ZeHqE/UU1DDLJv3xCNYrwlJx/zUhoo HfQhOiRA1g0GAWc3jRfxoobXNxPd2F9i8pYGLAP8btlja3HDy4JDgCoQv w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AocFAITlhlCtJXG+/2dsb2JhbABEhU28MIEIgiABBBIBJ1EBKhRCJwQbGodiC5pUgSuPXJAwi2CFfmADlwmNN4Frgm+CGA X-IronPort-AV: E=Sophos;i="4.80,637,1344211200"; d="scan'208";a="134584975" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-5.cisco.com with ESMTP; 23 Oct 2012 18:46:27 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id q9NIkRug008240 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 23 Oct 2012 18:46:27 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.68]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0318.001; Tue, 23 Oct 2012 13:46:26 -0500 From: "Joseph Salowey (jsalowey)" To: "emu@ietf.org" Thread-Topic: Proposed EMU Agenda for IETF-85 Thread-Index: AQHNsU60P+UnjhFhJUqlvPsbnMmhug== Date: Tue, 23 Oct 2012 18:46:26 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.154.12.107] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19298.000 x-tm-as-result: No--20.567200-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <0F97D96293753F438FE161640EC01B96@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Emu] Proposed EMU Agenda for IETF-85 X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 18:46:28 -0000 EMU Meeting at IETF 85 WEDNESDAY, November 7, 2012 - 1440-1540 ------------------------------------------------- 1. Note Well, agenda, note takers (5 Min) 2. Tunnel Method (30 min) - Cam-Winget http://tools.ietf.org/html/draft-ietf-emu-eap-tunnel-method-04 3. Mutual Crypto Binding (10 Min) - Hartman http://tools.ietf.org/html/draft-ietf-emu-crypto-bind-00 From hartmans@painless-security.com Mon Oct 22 05:51:02 2012 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38F0821F8A87; Mon, 22 Oct 2012 05:51:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.909 X-Spam-Level: X-Spam-Status: No, score=0.909 tagged_above=-999 required=5 tests=[AWL=3.508, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BrcmBfjH27p0; Mon, 22 Oct 2012 05:51:01 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 4B29921F8842; Mon, 22 Oct 2012 05:51:00 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (c-98-217-126-210.hsd1.ma.comcast.net [98.217.126.210]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id 1A7632026C; Mon, 22 Oct 2012 08:50:39 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 6B5CB4AD5; Mon, 22 Oct 2012 08:50:56 -0400 (EDT) From: Sam Hartman To: Alper Yegin References: <6AB91560-84B9-4311-B383-95C0A01911E4@yegin.org> <81B15FE2-DD05-411B-A35B-0E0AB3E213A3@yegin.org> Date: Mon, 22 Oct 2012 08:50:56 -0400 In-Reply-To: <81B15FE2-DD05-411B-A35B-0E0AB3E213A3@yegin.org> (Alper Yegin's message of "Mon, 22 Oct 2012 13:06:40 +0300") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailman-Approved-At: Thu, 25 Oct 2012 08:17:11 -0700 Cc: radext@ietf.org, abfab@ietf.org, pcp-chairs@tools.ietf.org, emu@ietf.org, dime@ietf.org, eap@frascone.com Subject: Re: [Emu] Tweaking EAP (RFC 3748) X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 12:51:02 -0000 >>>>> "Alper" == Alper Yegin writes: Alper> On Oct 19, 2012, at 5:08 PM, Sam Hartman wrote: >>>>>> "Alper" == Alper Yegin writes: >> Alper> Hi Sam, Please also share this discussion with EAP WG and EMU Alper> WG mailing lists. That's where the EAP expertise is and they Alper> should chime in, given that you are proposing to modify EAP Alper> applicability statement. >> >> The eap applicability statement update is a charter item of >> ABFAB. We've agreed it will be last called in EMU. Since it's a >> work item of abfab, it should be discussed on that list. You're >> certainly free to let people know that the discussion if taking >> place, although we've done that several times before. Alper> Sam, Alper> The type of changes you are talking about are well beyond the Alper> "applicability statement changes" that ABFAB is chartered to Alper> make. First, I definitely encourage you to involve anyone in any IETF WG discussion you believe will help form a better consensus. So, absolutely, encourage people who you believe should join the discussion to do so. I am a bit confused by your message, because I'm not discussing changing EAP, only discussing how some issues that seem relatively likely to come up will influence applying EAP authentication to application authentication. My intent is to document existing, potentially hard to understand aspects of EAP so that people can better apply EAP to their applications. Thanks, --Sam From ietf-ipr@ietf.org Wed Oct 24 09:15:41 2012 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BA1221F8C87; Wed, 24 Oct 2012 09:15:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.434 X-Spam-Level: X-Spam-Status: No, score=-102.434 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CS000S52vDM6; Wed, 24 Oct 2012 09:15:38 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F6D821F8A39; Wed, 24 Oct 2012 09:15:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: hzhou@cisco.com, ncamwing@cisco.com, jsalowey@cisco.com, shanna@juniper.net X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121024161538.12819.83234.idtracker@ietfa.amsl.com> Date: Wed, 24 Oct 2012 09:15:38 -0700 X-Mailman-Approved-At: Thu, 25 Oct 2012 08:17:11 -0700 Cc: emu@ietf.org, ipr-announce@ietf.org, stephen.farrell@cs.tcd.ie Subject: [Emu] IPR Disclosure: Cisco's Statement of IPR Related to draft-ietf-emu-eap-tunnel-method-04 X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 16:15:41 -0000 Dear Hao Zhou, Nancy Cam-Winget, Joseph A. Salowey, Stephen R. Hanna: An IPR disclosure that pertains to your Internet-Draft entitled "Tunnel EAP Method (TEAP) Version 1" (draft-ietf-emu-eap-tunnel-method) was submitted t= o the IETF Secretariat on 2012-10-23 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1902/). The title of the IPR disclosure is "Cisco's Statement of IPR Related to draft-ietf-emu-eap-tunnel-method-04.""= ); The IETF Secretariat