From hartmans@mit.edu Thu Feb 2 08:37: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 7D71121F8534 for ; Thu, 2 Feb 2012 08:37:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.445 X-Spam-Level: X-Spam-Status: No, score=-102.445 tagged_above=-999 required=5 tests=[AWL=-1.669, BAYES_05=-1.11, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4EXnwwsDcR2M for ; Thu, 2 Feb 2012 08:37:38 -0800 (PST) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id A83AA21F8530 for ; Thu, 2 Feb 2012 08:37:37 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id A02602023F for ; Thu, 2 Feb 2012 11:36:34 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id BFC884690; Thu, 2 Feb 2012 11:37:15 -0500 (EST) From: Sam Hartman To: emu@ietf.org Date: Thu, 02 Feb 2012 11:37:15 -0500 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 Subject: [Emu] Channel Binding: EAP Success handling 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, 02 Feb 2012 16:37:38 -0000 Hi. EAP has a complex history of success indications over the years. Some methods have protected success indications; some don't. Especially as channel bindings are being initially deployed it's going to be common to want to send channel bindings and possibly fail if they do not match but not to require the server to support them. So, bidding down attacks are a real concern. First, if you are using an EAP method where success indications are not protected then you have a kind of hopeless situation. I'm not entirely sure how things are defined, but that might be incompatible with providing mutual authentication as a security claim. Channel bindings already does require mutual authentication out of the method. But there's another issue. Howe carefully does the client look at this. >From a state machine standpoint is' really important that your client not just accept an eap success packet as success if the method does have an internal success indication. If a client does accept an eap success packet then a malicious NAS could inject such a packet. The value of the attack may be limited by a couple of factors: 1) The client may be expecting keying material. It's probably possible with some methods to get the client its keying material 2) If the NAS interrupts the conversation with the server, then it probably doesn't get its copy of the keying material. However form things that don't really use the keying material, this may be an issue. I think it's worth writing up a security consideration that clients implementing channel binding should be careful about their state machine in this regard. From hartmans@mit.edu Mon Feb 6 07:27:51 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 955A021F856F for ; Mon, 6 Feb 2012 07:27:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.021 X-Spam-Level: X-Spam-Status: No, score=-103.021 tagged_above=-999 required=5 tests=[AWL=-0.756, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jcQ3-6Lmob-a for ; Mon, 6 Feb 2012 07:27:51 -0800 (PST) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id D70A421F844C for ; Mon, 6 Feb 2012 07:27:47 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 72524201C1; Mon, 6 Feb 2012 10:26:39 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id CB7DA4731; Mon, 6 Feb 2012 10:27:16 -0500 (EST) From: Sam Hartman To: Sam Hartman References: Date: Mon, 06 Feb 2012 10:27:16 -0500 In-Reply-To: (Sam Hartman's message of "Thu, 02 Feb 2012 11:37:15 -0500") 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 Cc: emu@ietf.org Subject: Re: [Emu] Channel Binding: EAP Success handling 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, 06 Feb 2012 15:27:51 -0000 >>>>> "Sam" == Sam Hartman writes: Sam> Hi. Sam> EAP has a complex history of success indications over the Sam> years. Some methods have protected success indications; some Sam> don't. Sam> Especially as channel bindings are being initially deployed Sam> it's going to be common to want to send channel bindings and Sam> possibly fail if they do not match but not to require the Sam> server to support them. So, bidding down attacks are a real Sam> concern. Sam> But there's another issue. Howe carefully does the client look Sam> at this. From a state machine standpoint is' really important Sam> that your client not just accept an eap success packet as Sam> success if the method does have an internal success indication. Sam> If a client does accept an eap success packet then a malicious Sam> NAS could inject such a packet. Hi. As we're starting to gain implementation experience, it looks like this is a real problem with a lot of implementations out there. The server we're looking at just sends back an EAP success packet (unencrypted) as soon as it's sure that you've reached a success state. It's actually being a bit tricky to convince the server to send a channel binding reply. So, putting it mildly, I suspect a lot of clients will be fairly liberal in accepting unprotected success. This is kind of serious if you want to work with old servers, but it definitely is something we're going to want to document somewhere and discuss the implications. Obviously, we're going to want to define our standards-track tunnel method not to have these issues. From hartmans@mit.edu Mon Feb 6 07:33: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 1778921F8602 for ; Mon, 6 Feb 2012 07:33:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.983 X-Spam-Level: X-Spam-Status: No, score=-102.983 tagged_above=-999 required=5 tests=[AWL=-0.718, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dW6f6ZXdi8NQ for ; Mon, 6 Feb 2012 07:33:35 -0800 (PST) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 9B76521F85FC for ; Mon, 6 Feb 2012 07:33:35 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 6FAE72023F; Mon, 6 Feb 2012 10:32:29 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 592684731; Mon, 6 Feb 2012 10:33:07 -0500 (EST) From: Sam Hartman To: emu@ietf.org Date: Mon, 06 Feb 2012 10:33:07 -0500 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 Cc: mrw@painless-security.com Subject: [Emu] IETF 83 agenda request: channel binding implementation 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, 06 Feb 2012 15:33:36 -0000 I think that a number of participants will be familiar with some channel binding implementation work by IETF 83 and I think it would be valuable to brienf the WG on lessons learned. At one level, we perhaps don't care about implementation-specific problems or issues that pop up when adding channel bindings to non-standards-track methods. However, I think we have a lot to learn in terms of looking at similar issues that may cross implementations and in terms of what to specify to get the security we need in new standards track methods. So, I think this could really be worth a bit of discussion at IETF 83. From aland@deployingradius.com Tue Feb 7 01:02: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 3113D21F8622 for ; Tue, 7 Feb 2012 01:02:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.356 X-Spam-Level: X-Spam-Status: No, score=-102.356 tagged_above=-999 required=5 tests=[AWL=0.243, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ModwTxlFQwCz for ; Tue, 7 Feb 2012 01:02:54 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 83FB921F861A for ; Tue, 7 Feb 2012 01:02:54 -0800 (PST) Message-ID: <4F30E8A1.60709@deployingradius.com> Date: Tue, 07 Feb 2012 10:02:25 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Sam Hartman References: In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: mrw@painless-security.com, emu@ietf.org Subject: Re: [Emu] IETF 83 agenda request: channel binding implementation 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, 07 Feb 2012 09:02:55 -0000 Sam Hartman wrote: > I think that a number of participants will be familiar with some channel > binding implementation work by IETF 83 and I think it would be valuable > to brienf the WG on lessons learned. At one level, we perhaps don't > care about implementation-specific problems or issues that pop up when > adding channel bindings to non-standards-track methods. I agree. The work so far on CB has been on requirements. It would be good to know about implementation issues. > However, I think we have a lot to learn in terms of looking at similar > issues that may cross implementations and in terms of what to specify to > get the security we need in new standards track methods. So, I think > this could really be worth a bit of discussion at IETF 83. We'll schedule some time for this at the meeting. Alan DeKok. From aland@deployingradius.com Tue Feb 7 01:09:04 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 3FE3A21F86D8 for ; Tue, 7 Feb 2012 01:09:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.362 X-Spam-Level: X-Spam-Status: No, score=-102.362 tagged_above=-999 required=5 tests=[AWL=0.237, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pU9y+xzto4+Q for ; Tue, 7 Feb 2012 01:09:03 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id AA0FF21F86D3 for ; Tue, 7 Feb 2012 01:09:03 -0800 (PST) Message-ID: <4F30EA14.3030104@deployingradius.com> Date: Tue, 07 Feb 2012 10:08:36 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Sam Hartman References: In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: emu@ietf.org Subject: Re: [Emu] Channel Binding: EAP Success handling 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, 07 Feb 2012 09:09:04 -0000 Sam Hartman wrote: > Hi. As we're starting to gain implementation experience, it looks like > this is a real problem with a lot of implementations out there. The > server we're looking at just sends back an EAP success packet > (unencrypted) as soon as it's sure that you've reached a success state. I would imagine many implementations have similar behaviors. An EAP success means... send success, right? There are unlikely to be provisions in the EAP state machine for "success, but not really" cases. > It's actually being a bit tricky to convince the server to send a > channel binding reply. So, putting it mildly, I suspect a lot of > clients will be fairly liberal in accepting unprotected success. I agree. Alan DeKok. From hannes.tschofenig@nsn.com Wed Feb 8 05:04:53 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 BD41321F85EE for ; Wed, 8 Feb 2012 05:04:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.428 X-Spam-Level: X-Spam-Status: No, score=-106.428 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oVtdnOFeVc+k for ; Wed, 8 Feb 2012 05:04:53 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 964D121F855F for ; Wed, 8 Feb 2012 05:04:38 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q18D4amR002285 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 8 Feb 2012 14:04:36 +0100 Received: from DEMUEXC048.nsn-intra.net ([10.159.32.94]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q18D4ZIx015075; Wed, 8 Feb 2012 14:04:35 +0100 Received: from FIESEXC035.nsn-intra.net ([10.159.0.25]) by DEMUEXC048.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 8 Feb 2012 14:04:35 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 8 Feb 2012 15:06:29 +0200 Message-ID: <999913AB42CC9341B05A99BBF358718D011596B0@FIESEXC035.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] IETF 83 agenda request: channel binding implementation Thread-Index: Aczk5LlAFvYqyEi3RF+0EjZWaE6DmwADrZQQ References: From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Sam Hartman" , X-OriginalArrivalTime: 08 Feb 2012 13:04:35.0565 (UTC) FILETIME=[34E729D0:01CCE662] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 1236 X-purgate-ID: 151667::1328706276-00007EDF-83447359/0-0/0-0 Cc: mrw@painless-security.com Subject: Re: [Emu] IETF 83 agenda request: channel binding implementation 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, 08 Feb 2012 13:04:53 -0000 I am looking forward to the discussion.=20 I care about implementation specific aspects, particularly if they hide some underlying problems.=20 > -----Original Message----- > From: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org] On Behalf Of > ext Sam Hartman > Sent: Monday, February 06, 2012 5:33 PM > To: emu@ietf.org > Cc: mrw@painless-security.com > Subject: [Emu] IETF 83 agenda request: channel binding implementation >=20 >=20 > I think that a number of participants will be familiar with some channel > binding implementation work by IETF 83 and I think it would be valuable > to brienf the WG on lessons learned. At one level, we perhaps don't > care about implementation-specific problems or issues that pop up when > adding channel bindings to non-standards-track methods. >=20 > However, I think we have a lot to learn in terms of looking at similar > issues that may cross implementations and in terms of what to specify to > get the security we need in new standards track methods. So, I think > this could really be worth a bit of discussion at IETF 83. > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu From hartmans@mit.edu Fri Feb 17 14:04:27 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 0928D11E80A0 for ; Fri, 17 Feb 2012 14:04:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.69 X-Spam-Level: X-Spam-Status: No, score=-103.69 tagged_above=-999 required=5 tests=[AWL=-1.425, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GN1qVPRdUb71 for ; Fri, 17 Feb 2012 14:04:26 -0800 (PST) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 8A53111E809F for ; Fri, 17 Feb 2012 14:04:26 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 7DA8920348 for ; Fri, 17 Feb 2012 17:03:05 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id CAA8C434F; Fri, 17 Feb 2012 17:04:18 -0500 (EST) From: Sam Hartman To: emu@ietf.org Date: Fri, 17 Feb 2012 17:04:18 -0500 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 Subject: [Emu] draft-ietf-emu-eap-tunnel-method 7.6: inadequate for interoperable implementation 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, 17 Feb 2012 22:04:27 -0000 Hi. I'm writing up a draft on mutual crypto binding. As such, I happened to glance at section 7.6 on server certificate validation. The advice there is entirely inadequate for interoperable implementation and violates the tunnel method requirements: 1) . There's a SHOULD check the server name, but there are no mandatory-to-implement name forms. That is, I don't know how to map something the peer is likely to have such as the realm in a NAI to something that could be in a certificate. 2) Section 3.9 of the tunnel method requirements talks about certificateless authentication. this is incompatible with MUST verify server cert as well as the false claim that during TLS negotiation a server always sends a certificate to a client. I'd recommend resolving as follows: 1) Peers and servers MUST implement certificate modes of TLS; covered elsewhere in the doc. 2) Peers MUST implement and SHOULD validate server certs to a known trust anchor. 3) Pick a name form. Peers MUST implement validation of names against this name form. Describe where peers get the name to check against (obvious options include the NAI and separate configuration). 4) Peers SHOULD default to checking the name. 5) Describe other certificate properties such as keyusage, EKU, etc or point back to TLS if appropriate. 6) we probably need language dealing with the sort of stuff I'm writing up when some of these shoulds need to be upgraded. For example I think it's highly unadvisable to run channel bindings without checking the cert and binding back to a specific name or strong mutual crypto binding. From ietf@augustcellars.com Sat Feb 18 10:06:17 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 5CC4E21F85CE for ; Sat, 18 Feb 2012 10:06:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.949 X-Spam-Level: X-Spam-Status: No, score=-2.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KC2zmSaj+pHK for ; Sat, 18 Feb 2012 10:06:16 -0800 (PST) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id C7FD721F85CD for ; Sat, 18 Feb 2012 10:06:16 -0800 (PST) Received: from Tobias (176.120.168.69.static.onlinenw.com [69.168.120.176]) (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 39A192C9C5; Sat, 18 Feb 2012 10:06:16 -0800 (PST) From: "Jim Schaad" To: "'Sam Hartman'" , References: In-Reply-To: Date: Sat, 18 Feb 2012 10:05:31 -0800 Message-ID: <010f01ccee67$e7920390$b6b60ab0$@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: AQIZpOR75s484Q5wC35TFL8714SZ65WphYOQ Content-Language: en-us Subject: Re: [Emu] draft-ietf-emu-eap-tunnel-method 7.6: inadequate for interoperable implementation 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: Sat, 18 Feb 2012 18:06:17 -0000 There is one other item that is also worrying me about this. In doing the check of certificates, one should be doing revocation checking. However if one is trying to get network access, one cannot independently download the revocation information until access is granted, and one cannot get access granted until one has finished the EAP negotiation. Currently there is only a limited ability to download the information inside of the TLS exchange, but that needs to be a requirement. Jim > -----Original Message----- > From: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org] On Behalf Of > Sam Hartman > Sent: Friday, February 17, 2012 2:04 PM > To: emu@ietf.org > Subject: [Emu] draft-ietf-emu-eap-tunnel-method 7.6: inadequate for > interoperable implementation > > > Hi. > I'm writing up a draft on mutual crypto binding. > As such, I happened to glance at section 7.6 on server certificate validation. > > The advice there is entirely inadequate for interoperable implementation > and violates the tunnel method requirements: > > 1) . There's a SHOULD check the server name, but there are no mandatory- > to-implement name forms. > That is, I don't know how to map something the peer is likely to have such as > the realm in a NAI to something that could be in a certificate. > > > 2) Section 3.9 of the tunnel method requirements talks about certificateless > authentication. this is incompatible with MUST verify server cert as well as > the false claim that during TLS negotiation a server always sends a certificate > to a client. > > I'd recommend resolving as follows: > > 1) Peers and servers MUST implement certificate modes of TLS; covered > elsewhere in the doc. > > 2) Peers MUST implement and SHOULD validate server certs to a known trust > anchor. > > 3) Pick a name form. Peers MUST implement validation of names against this > name form. Describe where peers get the name to check against (obvious > options include the NAI and separate configuration). > > 4) Peers SHOULD default to checking the name. > > 5) Describe other certificate properties such as keyusage, EKU, etc or point > back to TLS if appropriate. > > 6) we probably need language dealing with the sort of stuff I'm writing up > when some of these shoulds need to be upgraded. For example I think it's > highly unadvisable to run channel bindings without checking the cert and > binding back to a specific name or strong mutual crypto binding. > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu From hartmans@mit.edu Sat Feb 18 11:28: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 C97E921F8575 for ; Sat, 18 Feb 2012 11:28:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.644 X-Spam-Level: X-Spam-Status: No, score=-103.644 tagged_above=-999 required=5 tests=[AWL=-1.379, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8k5snDM2KVWq for ; Sat, 18 Feb 2012 11:28:15 -0800 (PST) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 5C7C221F8573 for ; Sat, 18 Feb 2012 11:28:15 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 1D04820383; Sat, 18 Feb 2012 14:26:53 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 4E260434F; Sat, 18 Feb 2012 14:28:05 -0500 (EST) From: Sam Hartman To: "Jim Schaad" References: <010f01ccee67$e7920390$b6b60ab0$@augustcellars.com> Date: Sat, 18 Feb 2012 14:28:05 -0500 In-Reply-To: <010f01ccee67$e7920390$b6b60ab0$@augustcellars.com> (Jim Schaad's message of "Sat, 18 Feb 2012 10:05:31 -0800") 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 Cc: 'Sam Hartman' , emu@ietf.org Subject: Re: [Emu] draft-ietf-emu-eap-tunnel-method 7.6: inadequate for interoperable implementation 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: Sat, 18 Feb 2012 19:28:15 -0000 >>>>> "Jim" == Jim Schaad writes: Jim> There is one other item that is also worrying me about this. Jim> In doing the check of certificates, one should be doing Jim> revocation checking. However if one is trying to get network Jim> access, one cannot independently download the revocation Jim> information until access is granted, and one cannot get access Jim> granted until one has finished the EAP negotiation. TLS these days has the ability to present an OCSP response inline, right? Wouldn't that be a eaiser-to-implement strategy? From ietf@augustcellars.com Sat Feb 18 12:03:44 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 8571921E8011 for ; Sat, 18 Feb 2012 12:03:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.274 X-Spam-Level: X-Spam-Status: No, score=-3.274 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V-fz6DG9UMBR for ; Sat, 18 Feb 2012 12:03:44 -0800 (PST) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) by ietfa.amsl.com (Postfix) with ESMTP id 193CC11E8072 for ; Sat, 18 Feb 2012 12:03:44 -0800 (PST) Received: from Tobias (176.120.168.69.static.onlinenw.com [69.168.120.176]) (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 C753738EFA; Sat, 18 Feb 2012 12:03:43 -0800 (PST) From: "Jim Schaad" To: "'Sam Hartman'" References: <010f01ccee67$e7920390$b6b60ab0$@augustcellars.com> In-Reply-To: Date: Sat, 18 Feb 2012 12:02:58 -0800 Message-ID: <011501ccee78$50372820$f0a57860$@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: AQIZpOR75s484Q5wC35TFL8714SZ6wJW9cBVAfKic72Vh1n0QA== Content-Language: en-us Cc: emu@ietf.org Subject: Re: [Emu] draft-ietf-emu-eap-tunnel-method 7.6: inadequate for interoperable implementation 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: Sat, 18 Feb 2012 20:03:44 -0000 TLS can present an OCSP response for the end certificate, if you have TA->CA1->EE then you can't get it for the CA1 certificate. Jim > -----Original Message----- > From: Sam Hartman [mailto:hartmans-ietf@mit.edu] > Sent: Saturday, February 18, 2012 11:28 AM > To: Jim Schaad > Cc: 'Sam Hartman'; emu@ietf.org > Subject: Re: [Emu] draft-ietf-emu-eap-tunnel-method 7.6: inadequate for > interoperable implementation > > >>>>> "Jim" == Jim Schaad writes: > > Jim> There is one other item that is also worrying me about this. > Jim> In doing the check of certificates, one should be doing > Jim> revocation checking. However if one is trying to get network > Jim> access, one cannot independently download the revocation > Jim> information until access is granted, and one cannot get access > Jim> granted until one has finished the EAP negotiation. > > > TLS these days has the ability to present an OCSP response inline, right? > Wouldn't that be a eaiser-to-implement strategy? From hzhou@cisco.com Tue Feb 21 08:42: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 F346021F85C5 for ; Tue, 21 Feb 2012 08:42:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.833 X-Spam-Level: X-Spam-Status: No, score=-5.833 tagged_above=-999 required=5 tests=[AWL=1.301, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dw8tnwnJDVHR for ; Tue, 21 Feb 2012 08:42:31 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id A59A421F85CD for ; Tue, 21 Feb 2012 08:42:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=hzhou@cisco.com; l=4038; q=dns/txt; s=iport; t=1329842551; x=1331052151; h=date:subject:from:to:message-id:mime-version; bh=JyTo1Xrmcv5CewebIlg3vcjEbIs/GLJxgMNaDnzW/0E=; b=c2GPQU9t1HWLjs9b1iyi2Mv1VvqlSVytWU1Q8BcpjktgXyB2xmm7m3Zl DqUEddvFzCZimcRG55lR8vkB2fMY6r8+vPVB/D0Cy/ijsYCk47JfofVTY 8KQLijrDTLRWJz3tXTcaVvsSP2cqSocABUmCS+c8j687s4FWW5MY9UgRn M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Al4IACzJQ0+tJXG9/2dsb2JhbAA5AQmCUKZgiChsAoEHgXUBBBIBKk4BDIEaAQQ1h2eea4EnAZcoiVsBBIJwBQEPAoNRRSSDHgSIHDOMaZMLgTY X-IronPort-AV: E=Sophos;i="4.73,458,1325462400"; d="scan'208,217";a="60648751" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-5.cisco.com with ESMTP; 21 Feb 2012 16:42:31 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id q1LGgUJe030520 for ; Tue, 21 Feb 2012 16:42:30 GMT Received: from xmb-rcd-203.cisco.com ([72.163.62.210]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 21 Feb 2012 10:42:31 -0600 Received: from 64.101.222.167 ([64.101.222.167]) by XMB-RCD-203.cisco.com ([72.163.62.210]) via Exchange Front-End Server email.cisco.com ([72.163.62.136]) with Microsoft Exchange Server HTTP-DAV ; Tue, 21 Feb 2012 16:42:30 +0000 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Tue, 21 Feb 2012 11:42:28 -0500 From: Hao Zhou To: Message-ID: Thread-Topic: Proposed Resolution: EMU Issue track #36 Thread-Index: Aczwt8wNKEQUKtFPTUeyINKOXCLXYw== Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3412669350_6503778" X-OriginalArrivalTime: 21 Feb 2012 16:42:31.0057 (UTC) FILETIME=[CDDFA810:01CCF0B7] Subject: [Emu] Proposed Resolution: EMU Issue track #36 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, 21 Feb 2012 16:42:34 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3412669350_6503778 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable http://trac.tools.ietf.org/wg/emu/trac/ticket/36 Old Text: =B3In the case of multiple peer authentications, the Peer-ID is determined from the first peer authenticatication.=B2 New Text: =B3In the case of multiple peer authentications, all authenticated peer identities need to be exported. =B2 Rational: It is desirable to export all peer identities that have been authenticated by the tunnel method. And there is no limit to the number of peer identitie= s being exported, provided the interface is available. RFC 5247, EAP Keying Framework says: =B3It is possible for more than one Peer-Id to be exported by an EAP method. For example, a peer certificate can contain more than one peer identity; in a tunnel method, peer identities can be authenticated within both an outer and inner exchange, and these identities could be different in type and contents. For example, an outer exchange could provide a Peer-Id in the form of a Relative Distinguished Name (RDN), whereas an inner exchange could identify the peer via its NAI or MAC address. Where EAP keying material is determined solely from the outer exchange, only the outer Peer-Id(s) are exported; where the EAP keying material is determined from both the inner and outer exchanges, then both the inner and outer Peer-Id(s) are exported by the tunnel method.=B2 --B_3412669350_6503778 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Proposed Resolution: EMU Issue track #36 h= ttp://trac.tools.ietf.org/wg/emu/trac/ticket/36

Old Text:
“In the case of multiple peer aut= hentications, the Peer-ID is determined from the first peer authenticaticati= on.”

New Text:
“In the case of multiple peer authentications, all authenticated peer= identities need to be exported. ”

Rational:
It is desirable to export all peer identities that have been authenticated = by the tunnel method. And there is no limit to the number of peer identities= being exported, provided the interface is available.

RFC 5247, EAP Keying Framework says:

“It is possible for more than one Peer-Id to be exported by an EAP    method.  For example, a peer certificate can contain= more than one
   peer identity; in a tunnel method, peer identities can be=
   authenticated within both an outer and inner exchange, an= d these
   identities could be different in type and contents.  = ;For example, an
   outer exchange could provide a Peer-Id in the form of a R= elative
   Distinguished Name (RDN), whereas an inner exchange could= identify
   the peer via its NAI or MAC address.  Where EAP keyi= ng material is
   determined solely from the outer exchange, only the outer= Peer-Id(s)
   are exported; where the EAP keying material is determined= from both
   the inner and outer exchanges, then both the inner and ou= ter
   Peer-Id(s) are exported by the tunnel method.”
 --B_3412669350_6503778-- From hzhou@cisco.com Tue Feb 21 08:55:07 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 62A4021F87FC for ; Tue, 21 Feb 2012 08:55:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.484 X-Spam-Level: X-Spam-Status: No, score=-6.484 tagged_above=-999 required=5 tests=[AWL=0.651, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xw0YwDhQnRrd for ; Tue, 21 Feb 2012 08:55:05 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id F316421F8880 for ; Tue, 21 Feb 2012 08:55:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=hzhou@cisco.com; l=3490; q=dns/txt; s=iport; t=1329843305; x=1331052905; h=date:subject:from:to:message-id:in-reply-to:mime-version; bh=wbVV/4YuY09e+iPbIkmfDXEcwzpgFMzZju9R70/ANzo=; b=DP+ofBC47J0mnfGZt5kldpHPGYYfRTHo4/EN0E1ZFd+M8nCO7mChoAQB 2KG77kBHieIkfWZydFebqkVIvr7c1TsWwl/HRgpmk3lBYqVw8WtCFNhfP k9RQPT6EPJ/5sPuARVJbQilZm3OvQCgHi0tp1r0xt3xtfYElCUkiDCtjU I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Al4IABrMQ0+tJXG9/2dsb2JhbABDgk2mYIgobAKBB4F1AQQSASpOAQyBGQEBBDWHZ5g+gScBnw+LdgsPQAUBDAMCg1FFJIMeBIgcM4xpkws X-IronPort-AV: E=Sophos;i="4.73,458,1325462400"; d="scan'208,217";a="60632250" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-6.cisco.com with ESMTP; 21 Feb 2012 16:55:04 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id q1LGt4C0006790 for ; Tue, 21 Feb 2012 16:55:04 GMT Received: from xmb-rcd-203.cisco.com ([72.163.62.210]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 21 Feb 2012 10:55:04 -0600 Received: from 64.101.222.167 ([64.101.222.167]) by XMB-RCD-203.cisco.com ([72.163.62.210]) via Exchange Front-End Server email.cisco.com ([72.163.62.204]) with Microsoft Exchange Server HTTP-DAV ; Tue, 21 Feb 2012 16:55:04 +0000 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Tue, 21 Feb 2012 11:55:01 -0500 From: Hao Zhou To: Message-ID: Thread-Topic: [Emu] Proposed Resolution: EMU Issue track #37 Thread-Index: Aczwt8wNKEQUKtFPTUeyINKOXCLXYwAAcDQn In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3412670102_6567078" X-OriginalArrivalTime: 21 Feb 2012 16:55:04.0522 (UTC) FILETIME=[8EF94AA0:01CCF0B9] Subject: [Emu] Proposed Resolution: EMU Issue track #37 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, 21 Feb 2012 16:55:07 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3412670102_6567078 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable http://trac.tools.ietf.org/wg/emu/trac/ticket/37 Clarify that if peer only supports a higher version than the server supports, peer should send a NAK with other proposed EAP method if available.=20 Old Text: =B3If the TEAP peer does not support this version, it responds with an EAP-Response of EAP type=3DTEAP and the highest supported version number that's less than the number proposed by the TEAP server.=B2 New Text: =B3If the TEAP peer does not support this version but supports the version that=B9s lower than the version proposed by the TEAP server, it responds with an EAP-Response of EAP type=3DTEAP and the highest supported version number. If the TEAP peer only supports the version that=B9s higher than the version proposed by the TEAP server, then use of TEAP will not be possible. In this case, the TEAP peer should send back an EAP-Nak with other propose= d EAP method if available.=B2 >=20 --B_3412670102_6567078 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable [Emu] Proposed Resolution: EMU Issue track #37
http://trac.tools.ietf.org/wg/emu/trac/ticket/37
Clarify that if peer only supports a higher version= than the server supports, peer should send  a NAK with other proposed = EAP method if available.

Old Text:
“If the TEAP peer does not supp= ort this version, it responds with
      an EAP-Response of EAP type=3DTEAP and th= e highest supported version
      number that's less than the number prop= osed by the TEAP server.”

New Text:
“If the TEAP peer does not support this version but supports the vers= ion that’s lower than the version proposed by the TEAP server, it resp= onds with
      an EAP-Response of EAP type=3DTEAP and th= e highest supported version number. If the TEAP peer only supports the versi= on that’s higher than the version proposed by the TEAP server, then us= e of TEAP will not be possible. In this case, the TEAP peer should send &nbs= p;back an EAP-Nak with other proposed EAP method if available.”



--B_3412670102_6567078-- From hzhou@cisco.com Tue Feb 21 09:40:58 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 D395321F8852 for ; Tue, 21 Feb 2012 09:40:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.701 X-Spam-Level: X-Spam-Status: No, score=-6.701 tagged_above=-999 required=5 tests=[AWL=0.434, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Anwi34qFjmjW for ; Tue, 21 Feb 2012 09:40:54 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 8B32C21F8858 for ; Tue, 21 Feb 2012 09:40:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=hzhou@cisco.com; l=6705; q=dns/txt; s=iport; t=1329846054; x=1331055654; h=date:subject:from:to:message-id:in-reply-to:mime-version; bh=E1jbA0mpF9TSUAflC1g3mkD2ogKO8yKBTUnFaXXkbVI=; b=O3IrKaiFVvK7VZlwSrh4hi/5itIrL+OZCbPB+67+M3Mney+ZJH05ddc9 69b2/oeT6F6uAVF1Ru9fBtOiVnXkINtXqLgRh1P3QHQFDq08MlbFdqRjH Ik9DSZtaNOjfPy95U+8mU2HSzuv26RX8kiJTd/5IL60pNj9wZnpjiyZrD Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Al8IAM3WQ0+tJV2Y/2dsb2JhbABDgk2mYAGIJ2wCgQeBdQEEEgEqQQ0BgSUBAQQ1h2eYLoEnAZ8Ti3YaQAUBEYNRQwKDQgSIHDOMaZML X-IronPort-AV: E=Sophos;i="4.73,458,1325462400"; d="scan'208,217";a="60661269" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-3.cisco.com with ESMTP; 21 Feb 2012 17:40:54 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q1LHesGT028011 for ; Tue, 21 Feb 2012 17:40:54 GMT Received: from xmb-rcd-203.cisco.com ([72.163.62.210]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 21 Feb 2012 11:40:54 -0600 Received: from 64.101.222.167 ([64.101.222.167]) by XMB-RCD-203.cisco.com ([72.163.62.210]) via Exchange Front-End Server email.cisco.com ([72.163.62.136]) with Microsoft Exchange Server HTTP-DAV ; Tue, 21 Feb 2012 17:40:54 +0000 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Tue, 21 Feb 2012 12:40:53 -0500 From: Hao Zhou To: Message-ID: Thread-Topic: Proposed Resolution: EMU Issue track #38 Thread-Index: Aczwt8wNKEQUKtFPTUeyINKOXCLXYwAAcDQnAAGaFQg= In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3412672853_6732926" X-OriginalArrivalTime: 21 Feb 2012 17:40:54.0171 (UTC) FILETIME=[F5E46EB0:01CCF0BF] Subject: [Emu] Proposed Resolution: EMU Issue track #38 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, 21 Feb 2012 17:40:59 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3412672853_6732926 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable >=20 http://trac.tools.ietf.org/wg/emu/trac/ticket/38 Clarify that crypto-binding TLV will always be run after every single EAP authentication, also even if there is no inner EAP authentication or, to ensure the outer TLVs and EAP type, version are verified. TEAP draft =AD01,=20 http://tools.ietf.org/html/draft-ietf-emu-eap-tunnel-method-01 Section 3.3 Old text: =B3Phase 2 MUST always end with a protected termination exchange described in Section 3.3.3. =B3 New Text: =B3Phase 2 MUST always end with a crypto-binding TLV exchange descried in Section 4.2.9 and protected termination exchange described in Section 3.3.3= . =B3 Section 4.2.9: Old Text: =B3The Crypto-Binding TLV is used to prove that both the peer and server participated in the tunnel establishment and sequence of authentications. It also provides verification of the TEAP version negotiated before TLS tunnel establishment, see Section 3.1 . The Crypto-Binding TLV MUST be included with the Intermediate-Result TLV to perform Cryptographic Binding after each successful EAP method in a sequence of EAP methods. The Crypto-Binding TLV can be issued at other times as well.=B2 New Text: =B3The Crypto-Binding TLV is used to prove that both the peer and server participated in the tunnel establishment and sequence of authentications. It also provides verification of the TEAP type, versio= n negotiated, outer TLVs exchanged before the TLS tunnel establishment. The Crypto-Binding TLV MUST be exchanged and verified before the final Result TLV exchange, regardless whether there is an inner EAP method authentication or not. It MUST be included with the Intermediate-Result TLV to perform Cryptographic Binding after each successful EAP method in a sequence of EAP methods, before proceeding with another inner EAP method.=B2 >=20 >=20 --B_3412672853_6732926 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Proposed Resolution: EMU Issue track #38

http://trac.tools.ietf.org/wg/emu/trac/ticket/38
Clarify that crypto-binding TLV will always be run = after every single EAP authentication, also even if there is no inner EAP au= thentication or, to ensure the outer TLVs and EAP type, version are verified= .

TEAP draft –01, http://tools.ietf.org/html/draft-ietf-emu-eap-tunnel-met= hod-01

Section 3.3
Old text:
“Phase 2 MUST always end= with a protected termination exchange described in Section 3.3.3. “

New Text:
“Phase 2 MUST always end= with a crypto-binding TLV exchange descried in Section 4.2.9 and protected = termination exchange described in Section 3.3.3. “

Section 4.2.9:

Old Text:
“The Crypto-Binding TLV is used= to prove that both the peer and server
   participated in the tunnel establishment and sequence of<= BR>    authentications.  It also provides verification of t= he TEAP version
   negotiated before TLS tunnel establishment, see Section 3= .1 .

  <= SPAN STYLE=3D'font-size:10.5pt'>The Crypto-Binding TLV MUST be included with t= he Intermediate-Result
   TLV to perform Cryptographic Binding after each successfu= l EAP method
   in a sequence of EAP methods.  The Crypto-Binding TL= V can be issued
   at other times as well.”

New Text:
“The Crypto-Binding TLV is used= to prove that both the peer and server
   participated in the tunnel establishment and sequence of<= BR>    authentications.  It also provides verification of t= he TEAP type, version
   negotiated, outer TLVs exchanged before the TLS tunnel es= tablishment.

  <= SPAN STYLE=3D'font-size:10.5pt'>The Crypto-Binding TLV MUST be exchanged and v= erified before the final Result TLV exchange, regardless whether there is an= inner EAP method authentication or not. It MUST be included with the Interm= ediate-Result
   TLV to perform Cryptographic Binding after each successfu= l EAP method
   in a sequence of EAP methods, before proceeding with anot= her inner EAP method.R= 21;


--B_3412672853_6732926-- From hzhou@cisco.com Tue Feb 21 09:57:04 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 CD16321F87D2 for ; Tue, 21 Feb 2012 09:57:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.81 X-Spam-Level: X-Spam-Status: No, score=-6.81 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PjlS7ka5Kkth for ; Tue, 21 Feb 2012 09:57:00 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 89DE621F880C for ; Tue, 21 Feb 2012 09:57:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=hzhou@cisco.com; l=3063; q=dns/txt; s=iport; t=1329847020; x=1331056620; h=date:subject:from:to:message-id:mime-version; bh=LTcCeeiCI/JeMah49ohv26hmYfD7xbTw49at6bcWbW4=; b=C96a2DgCVPDkmtzIeE9aQ6j8FrX59coKDVTgp/tF/wN4B5/sPbfsdhGe ewb3pM82gVJppxfBlqqW+datgWmMwebBJDbi8riqBn/9Xb78GSK9pPSCH hYaLJKJtUOJMzYZR+u/Vffzi9FW9+ZgAGzu+DjMrkLvx6zSnnQJ3GT93x 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Al8IAI/aQ0+tJV2Y/2dsb2JhbABDgk2mYAGIJ2wCgQeBdQEEEgEqTgEMgRoBBDWHZ5gkgScBnxOMUAUBDAMCg1FDAoNCBIgcM4xpkws X-IronPort-AV: E=Sophos;i="4.73,458,1325462400"; d="scan'208,217";a="60671082" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-1.cisco.com with ESMTP; 21 Feb 2012 17:57:00 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q1LHv0H9007496 for ; Tue, 21 Feb 2012 17:57:00 GMT Received: from xmb-rcd-203.cisco.com ([72.163.62.210]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 21 Feb 2012 11:57:00 -0600 Received: from 64.101.222.167 ([64.101.222.167]) by XMB-RCD-203.cisco.com ([72.163.62.210]) via Exchange Front-End Server email.cisco.com ([72.163.62.204]) with Microsoft Exchange Server HTTP-DAV ; Tue, 21 Feb 2012 17:57:00 +0000 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Tue, 21 Feb 2012 12:56:59 -0500 From: Hao Zhou To: "emu@ietf.org" Message-ID: Thread-Topic: Proposed Resolution: EMU Track Issue #40 Thread-Index: AczwwjT5DOxdCU+rvUamsSdCp8Q6RA== Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3412673819_6755526" X-OriginalArrivalTime: 21 Feb 2012 17:57:00.0242 (UTC) FILETIME=[35B72B20:01CCF0C2] Subject: [Emu] Proposed Resolution: EMU Track Issue #40 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, 21 Feb 2012 17:57:04 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3412673819_6755526 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable http://trac.tools.ietf.org/wg/emu/trac/ticket/40 Channel Binding TLV should match Channel Binding Spec. clarify that channe= l binding tlv can be used bidirectional to transmit channel back data and verification result. TEAP draft =AD01,=20 http://tools.ietf.org/html/draft-ietf-emu-eap-tunnel-method-01 Section 4.2.15 Old text: =B3The Channel-Binding TLV allows an EAP-peer to send channel binding data to the EAP-server as described in [I-D.ietf-emu-chbind] . =B3 New Text: =B3The Channel-Binding TLV provides a mechanism for carrying channel binding data from the peer to the EAP server and a channel binding response from the EAP server to the peer as described in [I-D.ietf-emu-chbind]. =B3 --B_3412673819_6755526 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Proposed Resolution: EMU Track Issue #40
http://trac.tools.ietf.org/wg/emu/trac/= ticket/40
Channel Binding TLV should match Channel= Binding Spec.  clarify that channel binding tlv can be used bidirectio= nal to transmit channel back data and verification result.

TEAP draft –01, http://tools.ietf.org/html/draf= t-ietf-emu-eap-tunnel-method-01

Section 4.2.15
Old text:
“The Channel-Binding TLV= allows an EAP-peer to send channel binding
   data to the EAP-server as described in [I-D.ietf-emu-chbi= nd] . “

New Text:
“The Channel-Binding TLV= provides a mechanism for carrying channel binding data=
   from the peer to the EAP server and a channel binding res= ponse from
   the EAP server to the peer as described in [I-D.ietf-emu-= chbind]. “

 --B_3412673819_6755526-- From hzhou@cisco.com Tue Feb 21 13:08: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 1BDBE21F86D5 for ; Tue, 21 Feb 2012 13:08:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.875 X-Spam-Level: X-Spam-Status: No, score=-6.875 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZhP2g7zfBEH8 for ; Tue, 21 Feb 2012 13:08:01 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id D9C4821F86CB for ; Tue, 21 Feb 2012 13:08:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=hzhou@cisco.com; l=3473; q=dns/txt; s=iport; t=1329858481; x=1331068081; h=date:subject:from:to:message-id:mime-version; bh=g5UNlKbnvqk/bEBy7arTOrJsmlL9tkbpgWtvLpsSME8=; b=Xrk28yMoS8XhXzrHtU87xDQNSexX/fF39Qzky6H0FQ+uXhPi9v1VpvhB r1PI88+zPl7/I60jFgK4/o7/HdvC53+rLaTSPfwVYAZv7YZIjDmbCo2St UwF0R7CE0T12IjT6pvxeT4kjaKEMHvjj2FY4TUmfRgtxYtdtPJHfkKZ8W Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Al8IAJ0GRE+tJXHB/2dsb2JhbABDgk2mYAGIJ2sCgQeBdQEEEgEqTgEMgRoBBDWHZ5d6gScBnx+MUAUBDAMCg1FDAoNCBIgcM4xpkws X-IronPort-AV: E=Sophos;i="4.73,459,1325462400"; d="scan'208,217";a="60723923" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-6.cisco.com with ESMTP; 21 Feb 2012 21:08:00 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id q1LL80oN009158 for ; Tue, 21 Feb 2012 21:08:00 GMT Received: from xmb-rcd-203.cisco.com ([72.163.62.210]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 21 Feb 2012 15:08:00 -0600 Received: from 64.101.222.167 ([64.101.222.167]) by XMB-RCD-203.cisco.com ([72.163.62.210]) via Exchange Front-End Server email.cisco.com ([72.163.63.13]) with Microsoft Exchange Server HTTP-DAV ; Tue, 21 Feb 2012 21:07:59 +0000 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Tue, 21 Feb 2012 16:07:59 -0500 From: Hao Zhou To: "emu@ietf.org" Message-ID: Thread-Topic: Proposed resolution: EMU Issue track #34 Thread-Index: Aczw3OOqaGkADhStEkaCqN3x/1vWxQ== Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3412685279_7457270" X-OriginalArrivalTime: 21 Feb 2012 21:08:00.0148 (UTC) FILETIME=[E45A0D40:01CCF0DC] Subject: [Emu] Proposed resolution: EMU Issue track #34 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, 21 Feb 2012 21:08:05 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3412685279_7457270 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable http://trac.tools.ietf.org/wg/emu/trac/ticket/34 Dan proposed text for server unauthenticated provisioning. This is still i= n discussion on the list and has not be incorporated into the the draft. TEAP draft =AD01,=20 http://tools.ietf.org/html/draft-ietf-emu-eap-tunnel-method-01 Section 3.2=20 Old text: "Other ciphersuites MAY be supported. It is RECOMMENDED in the case when the inner authentication method provides man-in-the-middle protection [Editor's Note: The use of Anonymous Cipher Suites is still under discussion on the list]." New Text: "Other ciphersuites MAY be supported. It is REQUIRED that anonymous ciphersuites such as TLS_DH_anon_WITH_AES_128_CBC_SHA only be used in the case when the inner authentication method provides mutual authentication, key generation, and resistance to to man-in-the-middle and dictionary attack." Suggest to leave the Server Unauthenticated Provisioning Mode to another document. --B_3412685279_7457270 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Proposed resolution: EMU Issue track #34
http://trac.tools.ietf.org/wg/emu/trac/= ticket/34
Dan proposed text for server unauthentic= ated provisioning.  This is still in discussion on the list and has not= be incorporated into the the draft.

TEAP draft –01, http://tools.ietf.org/html/draf= t-ietf-emu-eap-tunnel-method-01

Section 3.2
Old text:
     "Other ciphersuites MAY be supported. &n= bsp;It is RECOMMENDED in the case when the inner authentication method provi= des
   man-in-the-middle protection [Editor's Note: The use of A= nonymous
   Cipher Suites is still under discussion on the list].&quo= t;

New Text:
     "Other ciphersuites MAY be supported. &n= bsp;It is REQUIRED that anonymous
      ciphersuites such as TLS_DH_anon_WITH_A= ES_128_CBC_SHA only be used
      in the case when the inner authenticati= on method provides mutual authentication, key generation, and resistance to<= BR>      to man-in-the-middle and dictionary attack.&q= uot;

Suggest to leave the Server Unauthenticated Provisioning Mode to another do= cument.
 --B_3412685279_7457270-- From dharkins@lounge.org Thu Feb 23 00:21: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 53EE921E8038 for ; Thu, 23 Feb 2012 00:21:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.48 X-Spam-Level: X-Spam-Status: No, score=-4.48 tagged_above=-999 required=5 tests=[AWL=-0.629, BAYES_40=-0.185, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lFruPixg5dXf for ; Thu, 23 Feb 2012 00:21:33 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 3B42D21E8024 for ; Thu, 23 Feb 2012 00:21:32 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id CD877A88810E for ; Thu, 23 Feb 2012 00:21:31 -0800 (PST) Received: from 62.50.228.72 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Thu, 23 Feb 2012 00:21:31 -0800 (PST) Message-ID: <6ec2ced704f2df4876e8de889938b384.squirrel@www.trepanning.net> Date: Thu, 23 Feb 2012 00:21:31 -0800 (PST) From: "Dan Harkins" To: "emu@ietf.org" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: [Emu] emu ticket #35 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, 23 Feb 2012 08:21:34 -0000 Hi, Ticket #35 was about the TLV numbering which had gaps of "unassigned" in it. The ticket has been closed with the resolution, "In -01 TLV numbering starts a (sic) 1". While that might be true in -01, the issue should not be closed. TLVs 8, 16, and 17 are still "unassigned" according to section 6. This is a new protocol, its TLVs are new and there is no reason to have gaps. Please reopen this ticket. thanks, Dan. From glenzorn@gmail.com Thu Feb 23 01:27:07 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 14CA021F85D9 for ; Thu, 23 Feb 2012 01:27:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.487 X-Spam-Level: X-Spam-Status: No, score=-3.487 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H+KhHiycWxLw for ; Thu, 23 Feb 2012 01:27:05 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id C78AD21F85C5 for ; Thu, 23 Feb 2012 01:27:05 -0800 (PST) Received: by pbcwz7 with SMTP id wz7so1232718pbc.31 for ; Thu, 23 Feb 2012 01:27:05 -0800 (PST) Received-SPF: pass (google.com: domain of glenzorn@gmail.com designates 10.68.213.234 as permitted sender) client-ip=10.68.213.234; Authentication-Results: mr.google.com; spf=pass (google.com: domain of glenzorn@gmail.com designates 10.68.213.234 as permitted sender) smtp.mail=glenzorn@gmail.com; dkim=pass header.i=glenzorn@gmail.com Received: from mr.google.com ([10.68.213.234]) by 10.68.213.234 with SMTP id nv10mr1723823pbc.71.1329989225607 (num_hops = 1); Thu, 23 Feb 2012 01:27:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=QjX77ABwOsHuF0HLyp2eD//P+q8o0/H3IrHPzqBStCI=; b=e81P2bTIdQRHzKV0yjNzZtbarApcnluI7/HZVMYJExfARtSlBkAbJ5zHhldQGZtycb 3qfkwZ4OlQQWv73cn1bUrOl2u3vj0R7LMpxFtAk6iDTbjBEH1Toa69u020VVatUFuS4X 9CZsV7od6vXaF+Uh5xxMkdUxOErQUBKd+qmBA= Received: by 10.68.213.234 with SMTP id nv10mr1431902pbc.71.1329989225573; Thu, 23 Feb 2012 01:27:05 -0800 (PST) Received: from [192.168.1.98] (ppp-124-120-49-112.revip2.asianet.co.th. [124.120.49.112]) by mx.google.com with ESMTPS id u9sm1012427pbj.39.2012.02.23.01.27.02 (version=SSLv3 cipher=OTHER); Thu, 23 Feb 2012 01:27:04 -0800 (PST) Message-ID: <4F460661.6020702@gmail.com> Date: Thu, 23 Feb 2012 16:26:57 +0700 From: Glen Zorn User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Dan Harkins References: <6ec2ced704f2df4876e8de889938b384.squirrel@www.trepanning.net> In-Reply-To: <6ec2ced704f2df4876e8de889938b384.squirrel@www.trepanning.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "emu@ietf.org" Subject: Re: [Emu] emu ticket #35 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, 23 Feb 2012 09:27:07 -0000 On 2/23/2012 3:21 PM, Dan Harkins wrote: > > Hi, > > Ticket #35 was about the TLV numbering which had gaps of "unassigned" > in it. The ticket has been closed with the resolution, "In -01 TLV > numbering starts a (sic) 1". While that might be true in -01, the issue > should not be closed. TLVs 8, 16, and 17 are still "unassigned" according > to section 6. > > This is a new protocol, its TLVs are new and there is no reason to > have gaps. Please reopen this ticket. +1 > > thanks, > > Dan. > > > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu From hzhou@cisco.com Thu Feb 23 06:11:23 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 A520B21F8646 for ; Thu, 23 Feb 2012 06:11:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.617 X-Spam-Level: X-Spam-Status: No, score=-7.617 tagged_above=-999 required=5 tests=[AWL=0.915, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oz1VONYkL5Qq for ; Thu, 23 Feb 2012 06:11:21 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 9BF8F21F865A for ; Thu, 23 Feb 2012 06:11:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=hzhou@cisco.com; l=746; q=dns/txt; s=iport; t=1330006276; x=1331215876; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=qz3q+KrOQCmiU0SBeMrbD7IIvENxh1MnMn0zpdyXPBc=; b=RQbUzsAioDKZXpEPcKM7+ywhmVLeUWXnTSaBg2n/AIu4GWA3BQAgeU31 i5FHzcv4EqUjiFSs1qAhL3dgdYhluOWN6X2xpzWfWB+Npb9GRFAM6XN2F lNUCFiemL/O8o6sn+9iIGi1sKnhUwgLEvLud/3wJ+cAd3/5PoqtjozNo4 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq0JAFxIRk+tJV2c/2dsb2JhbABEslgCgQeBcwEBAQMBAQEBDwEnAgExHQEIDl8wAQEEARIih18JmXoBnnQEjHUPFRgBAjcQAQwCAwECAoVUGhKDPASIT4xpkws X-IronPort-AV: E=Sophos;i="4.73,470,1325462400"; d="scan'208";a="61225401" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-6.cisco.com with ESMTP; 23 Feb 2012 14:11:15 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id q1NEBFtV032632; Thu, 23 Feb 2012 14:11:15 GMT Received: from xmb-rcd-203.cisco.com ([72.163.62.210]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 23 Feb 2012 08:11:15 -0600 Received: from 64.101.222.169 ([64.101.222.169]) by XMB-RCD-203.cisco.com ([72.163.62.210]) via Exchange Front-End Server email.cisco.com ([72.163.63.12]) with Microsoft Exchange Server HTTP-DAV ; Thu, 23 Feb 2012 14:11:15 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Thu, 23 Feb 2012 09:11:11 -0500 From: Hao Zhou To: Dan Harkins , "emu@ietf.org" Message-ID: Thread-Topic: [Emu] emu ticket #35 Thread-Index: AczyNP6QIN+5MNtaxkeyViAQZpOYIw== In-Reply-To: <6ec2ced704f2df4876e8de889938b384.squirrel@www.trepanning.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 23 Feb 2012 14:11:15.0612 (UTC) FILETIME=[015025C0:01CCF235] Subject: Re: [Emu] emu ticket #35 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, 23 Feb 2012 14:11:23 -0000 Dan: I will reopen the ticket and address it in -02. On 2/23/12 3:21 AM, "Dan Harkins" wrote: > > Hi, > > Ticket #35 was about the TLV numbering which had gaps of "unassigned" > in it. The ticket has been closed with the resolution, "In -01 TLV > numbering starts a (sic) 1". While that might be true in -01, the issue > should not be closed. TLVs 8, 16, and 17 are still "unassigned" according > to section 6. > > This is a new protocol, its TLVs are new and there is no reason to > have gaps. Please reopen this ticket. > > thanks, > > Dan. > > > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu From jsalowey@cisco.com Wed Feb 29 21:57:24 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 41D3221E800C for ; Wed, 29 Feb 2012 21:57:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.885 X-Spam-Level: X-Spam-Status: No, score=-108.885 tagged_above=-999 required=5 tests=[AWL=1.714, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OXmgRPu2arh3 for ; Wed, 29 Feb 2012 21:57:23 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 8C49221E801E for ; Wed, 29 Feb 2012 21:57:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jsalowey@cisco.com; l=845; q=dns/txt; s=iport; t=1330581442; x=1331791042; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=hKYT/rBgB8ZDEwRgd8EUkvuni1IWvYgRw/igm8dXs9k=; b=VT6DuV0EDLOgrf/tPFBOJ0B+RKGOYGrMlI/WOPL1NDzPCeZNRcGaxCJ4 MVlVWCrr84lJSDnEGkkYAEPbd5+r/v42kNmln9yWL2XHCw7hkGZkUMXpx mDEPwkL6zRnicjO/LQyI67TOS8BwxFlTVB6v+5P6i2pbjSEafuOzUZ9ZE w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AukHAI0OT0+rRDoH/2dsb2JhbABDgxOwc4EHghMBJ4Iyh2afNYEnAZcijQIVCA4CCAIKAQYLAgYHDwYBCQEDAwMChQqBAII7YwSIT4xwhV+NMw X-IronPort-AV: E=Sophos;i="4.73,507,1325462400"; d="scan'208";a="33462317" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 01 Mar 2012 05:57:22 +0000 Received: from [10.33.251.187] ([10.33.251.187]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q215vL5w015116 for ; Thu, 1 Mar 2012 05:57:21 GMT From: Joe Salowey Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 29 Feb 2012 21:57:17 -0800 Message-Id: <1F2377A9-DCBD-4AAB-8F4F-56802F56C8FB@cisco.com> To: emu@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [Emu] Issue 33: Certificate enrollment 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, 01 Mar 2012 05:57:24 -0000 The current tunnel method draft contains TLVs for PKCS#10 and PKCS#7 = TLVs. =20 The purpose of either of these TLVs is not well described. I think we = need to describe the purpose of these TLVs better or remove them. =20 The PKCS#10 TLV makes a brief reference to the Simple PKI request of CMS = (RFC 5272), but does not provide much more description than that = reference. The PKCS#7 TLV doesn't really describe it usage. It could be used to = carry the enrollment response, or it could be used to send a root = certificate to the peer in the case where an inner method is used to = authenticate the tunnel. =20 It doesn't seem that either of these is a complete enough specification. = =20 Does someone care enough about this functionality to provide better and = more complete test for it?=20 Thanks, Joe= From dharkins@lounge.org Wed Feb 29 22:09:25 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 61EE421F856F for ; Wed, 29 Feb 2012 22:09:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.684 X-Spam-Level: X-Spam-Status: No, score=-5.684 tagged_above=-999 required=5 tests=[AWL=0.581, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XfecaOG8deAd for ; Wed, 29 Feb 2012 22:09:24 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id D028A21F856C for ; Wed, 29 Feb 2012 22:09:24 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id D92E41022404A; Wed, 29 Feb 2012 22:09:23 -0800 (PST) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Wed, 29 Feb 2012 22:09:24 -0800 (PST) Message-ID: <45f46e460f698bc6bb8ef1a871a617eb.squirrel@www.trepanning.net> In-Reply-To: <1F2377A9-DCBD-4AAB-8F4F-56802F56C8FB@cisco.com> References: <1F2377A9-DCBD-4AAB-8F4F-56802F56C8FB@cisco.com> Date: Wed, 29 Feb 2012 22:09:24 -0800 (PST) From: "Dan Harkins" To: "Joe Salowey" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: emu@ietf.org Subject: Re: [Emu] Issue 33: Certificate enrollment 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, 01 Mar 2012 06:09:25 -0000 On Wed, February 29, 2012 9:57 pm, Joe Salowey wrote: > The current tunnel method draft contains TLVs for PKCS#10 and PKCS#7 TLVs. > > The purpose of either of these TLVs is not well described. I think we > need to describe the purpose of these TLVs better or remove them. > > The PKCS#10 TLV makes a brief reference to the Simple PKI request of CMS > (RFC 5272), but does not provide much more description than that > reference. > > The PKCS#7 TLV doesn't really describe it usage. It could be used to > carry the enrollment response, or it could be used to send a root > certificate to the peer in the case where an inner method is used to > authenticate the tunnel. > > It doesn't seem that either of these is a complete enough specification. > > Does someone care enough about this functionality to provide better and > more complete test for it? I care about this functionality and will be willing to describe the syntax of these messages but what test are you talking about? Dan. From jsalowey@cisco.com Wed Feb 29 22:29:35 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 891D421F8522 for ; Wed, 29 Feb 2012 22:29:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.099 X-Spam-Level: X-Spam-Status: No, score=-109.099 tagged_above=-999 required=5 tests=[AWL=1.500, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hxQRM-8PPFQ0 for ; Wed, 29 Feb 2012 22:29:34 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id ABF8421F8514 for ; Wed, 29 Feb 2012 22:29:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jsalowey@cisco.com; l=1249; q=dns/txt; s=iport; t=1330583374; x=1331792974; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=O45YpYCo/rxAzznP5yYu34QxeoDU5JMo5h5JrybFnIs=; b=XHxdeB6DvqB6chKLfoAWBoPQzl4Cv1Ve65dXIFPquDd4Ywm1qqnBAnAv 1EZ5D+HuE78Lpq2Rx1tY2m8HDWVgHMxz6g2kYNjFBNBcYW5knCJjMG4P/ MTQvODS0WrKanUTlB8LjZ0h/oafNcH2+O+Oqlh7/NhtlzG4R1HquXe/eW 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuwHAKsWT0+rRDoG/2dsb2JhbABCgxOwdIEHgXoBAQEDARIBJz8FCwUGDgouVwYkEYdiBKBTAZcbjQIaAw4CCAIKAQYLAgYHDwYBCQEGAwKFCoM7YwSIT4xwhV+NMw X-IronPort-AV: E=Sophos;i="4.73,507,1325462400"; d="scan'208";a="31240014" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 01 Mar 2012 06:29:34 +0000 Received: from [10.33.251.187] ([10.33.251.187]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q216TXZL009542; Thu, 1 Mar 2012 06:29:34 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Joe Salowey X-Priority: 3 (Normal) In-Reply-To: <45f46e460f698bc6bb8ef1a871a617eb.squirrel@www.trepanning.net> Date: Wed, 29 Feb 2012 22:29:29 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <0A606854-3084-4C27-9E9B-631567EBC8EF@cisco.com> References: <1F2377A9-DCBD-4AAB-8F4F-56802F56C8FB@cisco.com> <45f46e460f698bc6bb8ef1a871a617eb.squirrel@www.trepanning.net> To: "Dan Harkins" X-Mailer: Apple Mail (2.1084) Cc: emu@ietf.org Subject: Re: [Emu] Issue 33: Certificate enrollment 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, 01 Mar 2012 06:29:35 -0000 On Feb 29, 2012, at 10:09 PM, Dan Harkins wrote: >=20 > On Wed, February 29, 2012 9:57 pm, Joe Salowey wrote: >> The current tunnel method draft contains TLVs for PKCS#10 and PKCS#7 = TLVs. >>=20 >> The purpose of either of these TLVs is not well described. I think = we >> need to describe the purpose of these TLVs better or remove them. >>=20 >> The PKCS#10 TLV makes a brief reference to the Simple PKI request of = CMS >> (RFC 5272), but does not provide much more description than that >> reference. >>=20 >> The PKCS#7 TLV doesn't really describe it usage. It could be used to >> carry the enrollment response, or it could be used to send a root >> certificate to the peer in the case where an inner method is used to >> authenticate the tunnel. >>=20 >> It doesn't seem that either of these is a complete enough = specification. >>=20 >> Does someone care enough about this functionality to provide better = and >> more complete test for it? >=20 > I care about this functionality and will be willing to describe > the syntax of these messages but what test are you talking about? >=20 [Joe] Thanks Dan, I was thinking of walking on hot coals... Ooops, I = meant text. =20 > Dan. >=20 >=20