From hartmans@mit.edu Mon Mar 5 15:32: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 CD9FF21F87BF for ; Mon, 5 Mar 2012 15:32:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.614 X-Spam-Level: X-Spam-Status: No, score=-103.614 tagged_above=-999 required=5 tests=[AWL=-1.349, 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 BACVxjMFUNhq for ; Mon, 5 Mar 2012 15:32:09 -0800 (PST) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 5888A21F85B1 for ; Mon, 5 Mar 2012 15:32:09 -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 EC34E203BA; Mon, 5 Mar 2012 18:31:51 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id DB55D4350; Mon, 5 Mar 2012 18:32:02 -0500 (EST) From: Sam Hartman To: emu@ietf.org Date: Mon, 05 Mar 2012 18:32:02 -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: draft-hartman-emu-mutual-crypto-bind@tools.ietf.org Subject: [Emu] New draft on mutual crypto binding problem 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, 05 Mar 2012 23:32:10 -0000 Folks, I'd like to draw your attention to a draft we've put together describing the crypto binding interaction with channel binding and other peer-focused EAP services that I posted back in January. Please see draft-hartman-emu-mutual-crypto-bind-00.txt. there are a few rough edges. A couple of figures need to be added. we'd also like to describe where existing tunnel methods are in terms of vulnerability to these issues and where inner methods are in terms of providing keys and EMSKS. Dacheng zhang has compiled a lot of this data but I didn't get a chance to integrate it today. I'd like to thank all those who have helped with this so far and welcome any feedback. We'd like to request time at the EMU session to discuss this attack and the implications for our ongoing work. From aland@deployingradius.com Tue Mar 6 05:38:22 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 DC71721F887E for ; Tue, 6 Mar 2012 05:38:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.658 X-Spam-Level: X-Spam-Status: No, score=-101.658 tagged_above=-999 required=5 tests=[AWL=-0.548, BAYES_05=-1.11, 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 WXLOEqvyIGTX for ; Tue, 6 Mar 2012 05:38:22 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 542EC21F8857 for ; Tue, 6 Mar 2012 05:38:22 -0800 (PST) Message-ID: <4F561332.1070806@deployingradius.com> Date: Tue, 06 Mar 2012 14:37:54 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: "emu@ietf.org" X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Emu] Call for Agenda items 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, 06 Mar 2012 13:38:23 -0000 Please submit requests for agenda items to the EMU chairs. Alan DeKok. From dharkins@lounge.org Tue Mar 6 11:05: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 2D3B221F87D8 for ; Tue, 6 Mar 2012 11:05:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.748 X-Spam-Level: X-Spam-Status: No, score=-5.748 tagged_above=-999 required=5 tests=[AWL=0.517, 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 LGYmi+KY+VWN for ; Tue, 6 Mar 2012 11:05:54 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 5705F21F87D1 for ; Tue, 6 Mar 2012 11:05:54 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 03BE9A88810C; Tue, 6 Mar 2012 11:05:54 -0800 (PST) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Tue, 6 Mar 2012 11:05:54 -0800 (PST) Message-ID: <1334778a6f943bf51640456889457a35.squirrel@www.trepanning.net> In-Reply-To: <0A606854-3084-4C27-9E9B-631567EBC8EF@cisco.com> References: <1F2377A9-DCBD-4AAB-8F4F-56802F56C8FB@cisco.com> <45f46e460f698bc6bb8ef1a871a617eb.squirrel@www.trepanning.net> <0A606854-3084-4C27-9E9B-631567EBC8EF@cisco.com> Date: Tue, 6 Mar 2012 11:05:54 -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: Tue, 06 Mar 2012 19:05:55 -0000 Hi Joe, Here are my 4 suggestions to address certificate enrollment: 1. Add New section ------------------ 3.9 Certificate Provisioning Within the Tunnel Provisioning of a peer's certificate is supported in TEAP by performing the Simple PKI Request/Response from [RFC5272] using PKCS#10 and PKCS#7 TLVs, respectively. A peer sends the Simple PKI Request using a PKCS#10 CertificateRequest encoded into the body of a PKCS#10 TLV (see section 4.2.14). The TEAP Server issues a Simple PKI Response using a PKCS#7 degenerate "certs-only" message encoded into the body of a PKCS#7 TLV (see section 4.2.13). The Simple PKI Request/Response generation and processing rules of [RFC5272] SHALL apply to TEAP, with the exception of error conditions. In the event of an error, the TEAP Server SHOULD respond with an Error TLV using the most descriptive error code possible; it MAY ignore the PKCS#10 request which generated the error. 2. Modify 4.2.4 --------------- Add error codes 2003 Unsupported Algorithm in CertificateSigning request 2004 Unsupported Extensions in CertificateSigning request 2005 Bad Identity in CertificateSigning request 2006 Bad CertificateSigning request 2007 Internal CA Error 2008 General PKI Error 3. Modify 4.2.13 ---------------- Old text 4.2.13. PKCS#7 TLV The PKCS#7 TLV is sent by the EAP server to the peer inside the Server-Trusted-Root TLV. It contains PKCS#7-wrapped [RFC2315] X.509 certificates. The format consists of a certificate or certificate chain in a Certificates-Only PKCS#7 SignedData message as defined in [RFC2311]. The PKCS#7 TLV is always marked as optional, which cannot be responded to with a NAK TLV. TEAP server implementations that claim to support the dynamic provisioning defined in this document SHOULD support this TLV. TEAP peer implementations MAY support this TLV. If the PKCS#7 TLV contains a certificate or certificate chain that is not acceptable to the peer, then the peer MUST ignore the TLV. New text 4.2.13. PKCS#7 TLV The PKCS#7 TLV is used by the EAP server to deliver (a) certificate(s) to the peer. The format consists of a certificate or certificate chain in a degenerate certificates-only PKCS#7 SignedData Content as defined in [RFC2311]. When used in response to a Trusted-Server-Root TLV request from the peer, the EAP server MUST send the PKCS#7 TLV inside a Trusted-Server-Root TLV. When used in response to a PKCS#10 certificate enrollment request from the peer, the EAP server MUST send the PKCS#7 TLV without a Trusted-Server-Root TLV. The PKCS#7 TLV is always marked as optional, which cannot be responded to with a NAK TLV. TEAP implementations that support the Trusted-Server-Root TLV or the PKCS#10 TLV MUST support this TLV. Peers MUST NOT assume that the certificates in a PKCS#7 are in any order. TEAP Servers SHOULD include all intermediate certificates needed to form complete certificate paths to one or more trust anchors, and not just return the newly issued certificate(s). TEAP Servers MAY return CRLs in the CRL bag. TEAP Servers MAY return self-signed certificates. Peers that handle self-signed certificates or trust anchors MUST NOT implicitly trust these certificates merely due to their presence in the certificate bag. Note: Peer's are advised to take great care in deciding whether to use a received certificate as a trust anchor. The authenticated nature of the tunnel in which a PKCS#7 bag is received can provide a level of authenticity to the certificates contained therein. Peers are advised to take into account the implied authority of the EAP server and to constrain the trust it can achieve through the trust anchor received in a PKCS#7 TLV. 4. Remove reference to RFC5422 ------------------------------ regards, Dan. On Wed, February 29, 2012 10:29 pm, Joe Salowey wrote: > > On Feb 29, 2012, at 10:09 PM, Dan Harkins wrote: > >> >> 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? >> > > [Joe] Thanks Dan, I was thinking of walking on hot coals... Ooops, I > meant text. > >> Dan. >> >> > > From hzhou@cisco.com Wed Mar 7 10:14: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 3A73521E80B1 for ; Wed, 7 Mar 2012 10:14:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.747 X-Spam-Level: X-Spam-Status: No, score=-7.747 tagged_above=-999 required=5 tests=[AWL=0.785, 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 DwUzSS2RD3ZR for ; Wed, 7 Mar 2012 10:14:04 -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 7CB0321E8081 for ; Wed, 7 Mar 2012 10:14:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=hzhou@cisco.com; l=3455; q=dns/txt; s=iport; t=1331144044; x=1332353644; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=3iMMW5AsyDk82v00zToQ+8FgJ0uks0uOs3N0dukN/go=; b=ccwdu4obuaA/9BYomgszR/mgXmXkE/ZoHonxBui5cFAdCUqUrjiNe+4V lyaMWbDUjBSaLyIFovqvuvWj+1ut5XhTbvr4A+akFT4VBGzqVo6fBUNhx FsXXJIBLq2tk5ZPKniiJ7RWiFAAxw9Bn8LgYl7r1RpES33Gg2g6ayd3Xx U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnsIAEWlV0+tJV2a/2dsb2JhbAAuFg61DgKBB4IKAQEBAwEBAQEPAScCATELEgEIK0IwAQEEAQ0FIodhBQuaPQGfEASKFYZaBIhShySFS5AXgixVgTgX X-IronPort-AV: E=Sophos;i="4.73,547,1325462400"; d="scan'208";a="64581093" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-5.cisco.com with ESMTP; 07 Mar 2012 18:13:57 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q27IDvP8000867; Wed, 7 Mar 2012 18:13:57 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); Wed, 7 Mar 2012 12:13:57 -0600 Received: from 64.101.222.128 ([64.101.222.128]) 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 ; Wed, 7 Mar 2012 18:13:56 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Wed, 07 Mar 2012 13:13:51 -0500 From: Hao Zhou To: Sam Hartman , Message-ID: Thread-Topic: [Emu] New draft on mutual crypto binding problem Thread-Index: Acz8jgxe1OrWJm7jS0SjkAsriX0Tnw== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 07 Mar 2012 18:13:57.0256 (UTC) FILETIME=[10197080:01CCFC8E] Cc: draft-hartman-emu-mutual-crypto-bind@tools.ietf.org Subject: Re: [Emu] New draft on mutual crypto binding problem 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, 07 Mar 2012 18:14:05 -0000 Sam: This is a well thought and well written draft, it covers a lot of background and aspect of the attacks and mitigations. However, I have few comments: 1. I don't agree that Mutual crypto-binding is the recommended mitigation and should be added to TEAP. I actually think proper server authentication or server policy is better mitigation. Reasons: A. Mutual crypto-binding required the use of EMSK, not all existing EAP method generate and export EMSK. It will also break intermediate AAA servers. More importantly, it would only work for an EAP method that generates keys. Part of the goal of Tunnel Method is to protect weak authentication or EAP method, this would not benefits them. B. The root of the problem is a legitimate NAS acting as something it shouldn't be. If the peer can detect that from the beginning, that will prevent further damages such as leaking of credentials, sensitive data etc. Thus I strong recommend we emphasize on server cert validation and introduce the concept of authorization to the server authentication. Certain server can be only used for the services that are authorized. If the peer is seeking certain services and encounter a server that is not on the authorized server offering this type of service, despite it is a legit server for other services, it should refuse to connect to it. It's like you don't log onto Facebook to do your bank transactions:) I don't think Standard cert naming is enough, we need some sort of authorization built into the cert name or a peer side policy, what service the holder can offer. C. Adding Crypto-binding to TEAP would complicate things, we will need to try to negotiate that and fall back to the case where inner method doesn't generate EMSK. And it doesn't protect the methods that doesn't generate keys. D. Enforcing server policy would be another good way to go, if server can demand tunnel method only, eliminate the chance of inner method MSK being sent to the attacker. 2. I am not sure "Mutual Crypto-binding" is a good term, as the existing crypto-binding is already mutually authenticating the peer and the server. Maybe more accurate to be called "Crypto-binding based on EMSK" or "Extended Crypto-binding" etc. Some small nits: 1. In introduction, EAP RFC is 3748, not 3778. 2. In abstract, "[RFC3748]" probably should be "Cryptographic binding defined in [RFC3748]". On 3/5/12 6:32 PM, "Sam Hartman" wrote: > > Folks, I'd like to draw your attention to a draft we've put together > describing the crypto binding interaction with channel binding and other > peer-focused EAP services that I posted back in January. Please see > draft-hartman-emu-mutual-crypto-bind-00.txt. > > there are a few rough edges. A couple of figures need to be added. we'd > also like to describe where existing tunnel methods are in terms of > vulnerability to these issues and where inner methods are in terms of > providing keys and EMSKS. > Dacheng zhang has compiled a lot of this data but I didn't get a chance > to integrate it today. > > I'd like to thank all those who have helped with this so far and > welcome any feedback. > > We'd like to request time at the EMU session to discuss this attack and > the implications for our ongoing work. > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu From jsalowey@cisco.com Thu Mar 8 20: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 0556F21F84EF for ; Thu, 8 Mar 2012 20:37:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.399 X-Spam-Level: X-Spam-Status: No, score=-109.399 tagged_above=-999 required=5 tests=[AWL=1.200, 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 8w8L4bNLNHah for ; Thu, 8 Mar 2012 20:37:37 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 15DD421F8460 for ; Thu, 8 Mar 2012 20:37:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jsalowey@cisco.com; l=5729; q=dns/txt; s=iport; t=1331267857; x=1332477457; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=c9d+1QGweQanO+7oyzvAhQ4gzU2vJr23C0X4cqDZ/Bw=; b=l+KMHs+MpAqSbrAYM25/sOr4CoxZYGh3G62Gt7V8+gfBYmHhGIKis8z/ LW1ANkch9Jwg8BvAdlLbQCVJ0WiyoISYlgbhRv1qU0MJv6vzbHuwnVnM7 +fZIQZKDFFB1m+VicBxO5YfnKrBMl2BUPIr2W54zNyniPA/O7XbHinrOb I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjMIAJqIWU+rRDoG/2dsb2JhbAA5CYMWrw2DEoEHggoBAQEDARIBJz8QBQYOChUZVwYkEYdjBKAPAZZviiCDCIJLYwSIU4x1hWaKNIME X-IronPort-AV: E=Sophos;i="4.73,556,1325462400"; d="scan'208";a="32686196" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 09 Mar 2012 04:37:36 +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 q294baTX001437; Fri, 9 Mar 2012 04:37:36 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: <1334778a6f943bf51640456889457a35.squirrel@www.trepanning.net> Date: Thu, 8 Mar 2012 20:37:24 -0800 Content-Transfer-Encoding: 7bit Message-Id: References: <1F2377A9-DCBD-4AAB-8F4F-56802F56C8FB@cisco.com> <45f46e460f698bc6bb8ef1a871a617eb.squirrel@www.trepanning.net> <0A606854-3084-4C27-9E9B-631567EBC8EF@cisco.com> <1334778a6f943bf51640456889457a35.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: Fri, 09 Mar 2012 04:37:38 -0000 Thanks Dan, Lets update the draft and have some discussion of it in the Paris meeting. Cheers, Joe On Mar 6, 2012, at 11:05 AM, Dan Harkins wrote: > > Hi Joe, > > Here are my 4 suggestions to address certificate enrollment: > > 1. Add New section > ------------------ > > 3.9 Certificate Provisioning Within the Tunnel > > Provisioning of a peer's certificate is supported in TEAP by performing > the Simple PKI Request/Response from [RFC5272] using PKCS#10 and > PKCS#7 TLVs, respectively. A peer sends the Simple PKI Request using a > PKCS#10 CertificateRequest encoded into the body of a PKCS#10 TLV (see > section 4.2.14). The TEAP Server issues a Simple PKI Response using a > PKCS#7 degenerate "certs-only" message encoded into the body of a PKCS#7 > TLV (see section 4.2.13). > > The Simple PKI Request/Response generation and processing rules of > [RFC5272] SHALL apply to TEAP, with the exception of error conditions. > In the event of an error, the TEAP Server SHOULD respond with an Error > TLV using the most descriptive error code possible; it MAY ignore > the PKCS#10 request which generated the error. > > > 2. Modify 4.2.4 > --------------- > > Add error codes > > 2003 Unsupported Algorithm in CertificateSigning request > 2004 Unsupported Extensions in CertificateSigning request > 2005 Bad Identity in CertificateSigning request > 2006 Bad CertificateSigning request > 2007 Internal CA Error > 2008 General PKI Error > > > 3. Modify 4.2.13 > ---------------- > > Old text > > 4.2.13. PKCS#7 TLV > > The PKCS#7 TLV is sent by the EAP server to the peer inside the > Server-Trusted-Root TLV. It contains PKCS#7-wrapped [RFC2315] X.509 > certificates. The format consists of a certificate or certificate > chain in a Certificates-Only PKCS#7 SignedData message as defined in > [RFC2311]. > > The PKCS#7 TLV is always marked as optional, which cannot be > responded to with a NAK TLV. TEAP server implementations that claim > to support the dynamic provisioning defined in this document SHOULD > support this TLV. TEAP peer implementations MAY support this TLV. > > If the PKCS#7 TLV contains a certificate or certificate chain that is > not acceptable to the peer, then the peer MUST ignore the TLV. > > New text > > 4.2.13. PKCS#7 TLV > > The PKCS#7 TLV is used by the EAP server to deliver (a) certificate(s) > to the peer. The format consists of a certificate or certificate chain > in a degenerate certificates-only PKCS#7 SignedData Content as defined > in [RFC2311]. > > When used in response to a Trusted-Server-Root TLV request from the peer, > the EAP server MUST send the PKCS#7 TLV inside a Trusted-Server-Root TLV. > When used in response to a PKCS#10 certificate enrollment request from > the peer, the EAP server MUST send the PKCS#7 TLV without a > Trusted-Server-Root TLV. > > The PKCS#7 TLV is always marked as optional, which cannot be responded > to with a NAK TLV. TEAP implementations that support the > Trusted-Server-Root TLV or the PKCS#10 TLV MUST support this TLV. > > Peers MUST NOT assume that the certificates in a PKCS#7 are in any > order. TEAP Servers SHOULD include all intermediate certificates needed > to form complete certificate paths to one or more trust anchors, and not > just return the newly issued certificate(s). TEAP Servers MAY return > CRLs in the CRL bag. TEAP Servers MAY return self-signed certificates. > Peers that handle self-signed certificates or trust anchors MUST > NOT implicitly trust these certificates merely due to their presence > in the certificate bag. > > Note: > Peer's are advised to take great care in deciding whether to use a > received certificate as a trust anchor. The authenticated nature of the > tunnel in which a PKCS#7 bag is received can provide a level of > authenticity to the certificates contained therein. Peers are advised > to take into account the implied authority of the EAP server and to > constrain the trust it can achieve through the trust anchor received > in a PKCS#7 TLV. > > 4. Remove reference to RFC5422 > ------------------------------ > > regards, > > Dan. > > On Wed, February 29, 2012 10:29 pm, Joe Salowey wrote: >> >> On Feb 29, 2012, at 10:09 PM, Dan Harkins wrote: >> >>> >>> 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? >>> >> >> [Joe] Thanks Dan, I was thinking of walking on hot coals... Ooops, I >> meant text. >> >>> Dan. >>> >>> >> >> > > From jsalowey@cisco.com Thu Mar 8 21:43:08 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 9F6EE21E8052 for ; Thu, 8 Mar 2012 21:43:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.508 X-Spam-Level: X-Spam-Status: No, score=-109.508 tagged_above=-999 required=5 tests=[AWL=1.091, 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 7XRZmSjBPH4A for ; Thu, 8 Mar 2012 21:43:05 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 5E97721E8043 for ; Thu, 8 Mar 2012 21:43:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jsalowey@cisco.com; l=2588; q=dns/txt; s=iport; t=1331271783; x=1332481383; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=eX49WALpfGQieQ09qiD8MCgogTXnzuRWibNHlwDqbiA=; b=b8g4wJct18LQzsx6ajQx4u9fPUopU+Youjbpr6i15xdxqJ6d41N6bq96 6+F5ORzfz0CQvUxcQ2xYsEbP/xp1zgfzN5YETZiPe+V3zJNfpjVnKMjW+ Zs2ooQBmOlGoSW6iNubEe/BgWjCPdb20RxRDO9CSIkhV+bUCP6wC4B9xA c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj8HAAOYWU+rRDoH/2dsb2JhbABCDoMIsh+BB4IKAQEBAwEBAQEPASc0CxALRicwBhMih2MEDKADAZZmBIozhUBjBIhTjHWFZoo0gixYgTUX X-IronPort-AV: E=Sophos;i="4.73,556,1325462400"; d="scan'208";a="32701197" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-3.cisco.com with ESMTP; 09 Mar 2012 05:43:03 +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 q295h2Nw031512; Fri, 9 Mar 2012 05:43:02 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Joe Salowey In-Reply-To: Date: Thu, 8 Mar 2012 21:42:50 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Sam Hartman X-Mailer: Apple Mail (2.1084) 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: Fri, 09 Mar 2012 05:43:08 -0000 Hi Sam, If we added something along the following lines to the document would it = be sufficient: "When performing server certificate validation implementations MUST = provide support rules in RFC 5280 for validating certificates against a = known trust anchor. In addition, implementations SHOULD support = matching the realm portion of the client's NAI against a SubjectAltName = of type dNSName within the server certificate. " I'm not sure about EKU. I don't particularly like using the same EKU's = as TLS. If we define a new EKU then servers will need to get new = certs. Do you think we need EKUs? =20 Thanks, Joe On Feb 17, 2012, at 2:04 PM, Sam Hartman wrote: >=20 > 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. >=20 > The advice there is entirely inadequate for interoperable > implementation and violates the tunnel method requirements: >=20 > 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. >=20 >=20 > 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. >=20 > I'd recommend resolving as follows: >=20 > 1) Peers and servers MUST implement certificate modes of TLS; covered > elsewhere in the doc. >=20 > 2) Peers MUST implement and SHOULD validate server certs to a known > trust anchor. >=20 > 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). >=20 > 4) Peers SHOULD default to checking the name. >=20 > 5) Describe other certificate properties such as keyusage, EKU, etc or > point back to TLS if appropriate. >=20 > 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 pascal.urien@gmail.com Sun Mar 11 11:22:32 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 E138421F8721 for ; Sun, 11 Mar 2012 11:22:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ar07jeO9zl9k for ; Sun, 11 Mar 2012 11:22:32 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4213821F864F for ; Sun, 11 Mar 2012 11:22:32 -0700 (PDT) Received: by yhpp34 with SMTP id p34so2180804yhp.31 for ; Sun, 11 Mar 2012 11:22:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=NKOfm7DSHRBJ1qFtK1UBxJbGxTCKPQxGur1e5PVnrh4=; b=TKQuQciH4hKJI5ueCZb4rLw7owFWRQd7TUwNBlIRYhM00Lw/ruWnLPiiMGRPOo1o5O qDY5UxQ/x+PIEYjxqEGkSpqe1RsEF0NWn3iWMbnoylNKhrYvxm8t4O+s592+SC4nbkbM dsvGqor+a6iY0PtSFCjNjfP8HlCP/1NjJxI4ZPcRa++S+ECPrkRGcnHWBcGA9inDfS53 Zz/+3/k0KMTfbQo8xPcOArSUfkUKOhKGVwCxjna578aY5dGNZlA+NtXpFylRw0QSK1gT zDG7Xc4PMxlQWSKJ2BPu7R11HxyuvCAWQ64XLVeo5EIzJK7h6MZQjfDWycycfi0o7FDc uPQA== MIME-Version: 1.0 Received: by 10.224.30.206 with SMTP id v14mr5465030qac.18.1331490151891; Sun, 11 Mar 2012 11:22:31 -0700 (PDT) Received: by 10.229.16.211 with HTTP; Sun, 11 Mar 2012 11:22:31 -0700 (PDT) In-Reply-To: <4F561332.1070806@deployingradius.com> References: <4F561332.1070806@deployingradius.com> Date: Sun, 11 Mar 2012 19:22:31 +0100 Message-ID: From: Pascal Urien To: Alan DeKok Content-Type: multipart/alternative; boundary=20cf3074d6a68683fb04bafbb563 Cc: "emu@ietf.org" Subject: Re: [Emu] Call for Agenda items 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: Sun, 11 Mar 2012 18:22:33 -0000 --20cf3074d6a68683fb04bafbb563 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi All I would like present the draft-urien-eap-smartcard-22.txt ( http://tools.ietf.org/html/draft-urien-eap-smartcard-22 ) at the next EMU IETF meeting in Paris. This draft, whose first version was issued in 2002, is an ISO7816 interface for EAP methods such as EAP-SIM, EAP-AKA and EAP-TLS. It has been validated/tested with many most secure microcontrollers supporting the javacard language and associated JVM (i.e. javacards). It comprises three sets of test vectors for EAP-SIM, EAP-AKA and EAP-TLS. Recent smartphones (Android, RIM, =85 ) include Secure Elements, usually embedded in NFC controllers that are equipped with javacard JVM, and which are consequently compatible with this draft. The tested EAP methods implementations need require less than 20KB of nonvolatile memory and 1KB of RAM, these features are compatible with the Secure Elements resources. Regards Pascal Urien 2012/3/6 Alan DeKok > Please submit requests for agenda items to the EMU chairs. > > Alan DeKok. > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu > --20cf3074d6a68683fb04bafbb563 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi All

I would like present the draft-urien-eap-smartcard-22.txt ( <= a href=3D"http://tools.ietf.org/html/draft-urien-eap-smartcard-22">http://t= ools.ietf.org/html/draft-urien-eap-smartcard-22 ) at the next EMU IETF = meeting in Paris.

This draft, whose first version was issued in 2002, is an ISO7816 inter= face for EAP methods such as EAP-SIM, EAP-AKA and EAP-TLS. It has been vali= dated/tested with many most secure microcontrollers supporting the javacard= language and associated JVM (i.e. javacards). It comprises three sets of t= est vectors for EAP-SIM, EAP-AKA and EAP-TLS.

Recent smartphones (Android, RIM, =85 ) include Secure Elements, usuall= y embedded in NFC controllers that are equipped with javacard JVM, and whic= h are consequently compatible with this draft.

The tested EAP method= s implementations need require less than 20KB of nonvolatile memory and 1KB= of RAM, these features are compatible with the Secure Elements resources.<= br>
Regards

Pascal Urien


2012/= 3/6 Alan DeKok <aland@deployingradius.com>
=A0Please submit requests for agenda items to the EMU chairs.

=A0Alan DeKok.
_______________________________________________
Emu mailing list
Emu@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/emu

--20cf3074d6a68683fb04bafbb563-- From internet-drafts@ietf.org Sun Mar 11 16:01:29 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 1329321F8705; Sun, 11 Mar 2012 16:01:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.029, 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 eJ6Mw-bXPK4S; Sun, 11 Mar 2012 16:01:28 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80E9821F8716; Sun, 11 Mar 2012 16:01:28 -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.00 Message-ID: <20120311230128.17071.98060.idtracker@ietfa.amsl.com> Date: Sun, 11 Mar 2012 16:01:28 -0700 Cc: emu@ietf.org Subject: [Emu] I-D Action: draft-ietf-emu-eap-tunnel-method-02.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: Sun, 11 Mar 2012 23:01:29 -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 th= e IETF. 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-02.txt Pages : 91 Date : 2012-03-11 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-emu-eap-tunnel-method-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-emu-eap-tunnel-method-02.txt From hzhou@cisco.com Sun Mar 11 16:07: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 D2FF521F85D3 for ; Sun, 11 Mar 2012 16:07:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.202 X-Spam-Level: X-Spam-Status: No, score=-9.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] 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 wqOodijlsm4d for ; Sun, 11 Mar 2012 16:07:55 -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 F01A721F85C0 for ; Sun, 11 Mar 2012 16:07:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=hzhou@cisco.com; l=2505; q=dns/txt; s=iport; t=1331507275; x=1332716875; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version; bh=txQcpZOeUSPwMiYdvrUPl/EkslYnPfxUVhMSqtxKiKY=; b=bxoiL4ZMoYbRuwtqN8coymKpdu9AO4WQvnv1PhpPfVwE30LY9wRNV1o0 txeM/3yByB5CNfRbLDJ+Je8/oeLxtF7lZRslvJt4jWJgGU7ZGsemOo+FV 77kXoI4zvZ7eqPLv9TBkaUtRU0qwxoy+S0nwrkRryciuONCqN060BpMON w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFALAvXU+tJXG//2dsb2JhbABBglKyDnKBB4IJAQEBAwEBAQEPAQogMQsFDQEIBAFoMAEBBA4FCRmHYwULn2ABlgWRAQSIITOMeJAjgwE X-IronPort-AV: E=Sophos;i="4.73,568,1325462400"; d="scan'208,217";a="65492119" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-6.cisco.com with ESMTP; 11 Mar 2012 23:07:54 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id q2BN7sKY008516; Sun, 11 Mar 2012 23:07:54 GMT Received: from xmb-rcd-203.cisco.com ([72.163.62.210]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 11 Mar 2012 18:07:54 -0500 Received: from 10.21.105.63 ([10.21.105.63]) by XMB-RCD-203.cisco.com ([72.163.62.210]) via Exchange Front-End Server email.cisco.com ([128.107.191.79]) with Microsoft Exchange Server HTTP-DAV ; Sun, 11 Mar 2012 23:07:54 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Sun, 11 Mar 2012 19:07:52 -0500 From: Hao Zhou To: Alan DeKok Message-ID: Thread-Topic: [Emu] Call for Agenda items Thread-Index: Acz/28jg3DXjyR4rFUeP1pNNS4VCLw== In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3414337672_12250508" X-OriginalArrivalTime: 11 Mar 2012 23:07:54.0580 (UTC) FILETIME=[CA6A8140:01CCFFDB] Cc: "emu@ietf.org" Subject: Re: [Emu] Call for Agenda items 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: Sun, 11 Mar 2012 23:07:56 -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_3414337672_12250508 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable > I would like 30 mins of discussion on TEAP, > http://www.ietf.org/id/draft-ietf-emu-eap-tunnel-method-02.txt >=20 >=20 > 2012/3/6 Alan DeKok >> =A0Please submit requests for agenda items to the EMU chairs. >>=20 >> =A0Alan DeKok. >> _______________________________________________ >> Emu mailing list >> Emu@ietf.org >> https://www.ietf.org/mailman/listinfo/emu >=20 >=20 >=20 > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu --B_3414337672_12250508 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [Emu] Call for Agenda items
I would like 30 mins of discussion on TEAP, http://www.ietf.org/i= d/draft-ietf-emu-eap-tunnel-method-02.txt


2012/3/6 Alan DeKok <aland@deploying= radius.com>
<= SPAN STYLE=3D'font-size:11pt'> =A0Please submit requests for agenda items to the= EMU chairs.

 =A0Alan DeKok.
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/ma= ilman/listinfo/emu


___________= ____________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/ma= ilman/listinfo/emu
--B_3414337672_12250508-- From hartmans@mit.edu Mon Mar 12 13:12:59 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 2731821F897C for ; Mon, 12 Mar 2012 13:12:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.534 X-Spam-Level: X-Spam-Status: No, score=-103.534 tagged_above=-999 required=5 tests=[AWL=-1.269, 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 XAMrZ5xhmvfQ for ; Mon, 12 Mar 2012 13:12:58 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 3E05621F8976 for ; Mon, 12 Mar 2012 13:12:57 -0700 (PDT) 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 33B872021E for ; Mon, 12 Mar 2012 16:12:32 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 4C4A34766; Mon, 12 Mar 2012 16:12:49 -0400 (EDT) From: Sam Hartman To: emu@ietf.org Date: Mon, 12 Mar 2012 16:12:49 -0400 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] Security considerations text for draft-ietf-emu-chbind 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, 12 Mar 2012 20:12:59 -0000 Hi. I'm posting a new version of the channel bindings draft in response to AD review comments. I've been requested to develop security considerations text in response to attacks I wrote about on the list. Here's the text I'm including in the new draft. Comments are welcome. I don't know if Sean will simply issue the IETF last call and allow us to comment on this text during the last call or if he'll seek comments on this text before the last call. Either way, you should send comments on this new security considerations text now if you have some. At the bottom of section 9.1 I've added: This trust model is a significant departure from the standard EAP model. In many EAP deployments today attacks where one NAS can impersonate another are out of scope. Channel bindings brings these attacks into scope; the system as a whole needs to be analyzed to evaluate cases where one NAS may impersonate another and to evaluate the impact of this impersonation. One attractive implementation strategy for channel binding is to add channel binding support to a tunnel method which can tunnel an inner EAP authentication. This way, channel binding can be achieved with any method that can act as an inner method even if that inner method does not have native channel binding support. The requirement for mutual authentication and key derivation is at the layer of EAP that actually performs the channel binding. Tunnel methods sometimes use cryptographic binding, a process where a peer proves that the peer for the outer method is the same as the peer for an inner method to tie authentication at one layer together with an inner layer. Cryptographic binding does not always provide mutual authentication; its definition does not require the server to prove that the inner server and outer server are the same. Even when cryptographic binding does attempt to confirm that the inner and outer server are the same, the Master Session Key (MSK) is typically used to protect the binding. However, the MSK is disclosed to the NAS, which can typically attack cryptographic binding if it terminates the tunnel at the NAS instead of the EAP server. This attack was not in scope for existing threat models for cryptographic binding because one NAS impersonating another is considered out of scope. Thus, existing cryptographic binding does not typically provide mutual authentication required for channel binding. I've added a new section 9.3: 9.3. Bid-Down Attacks EAP methods that add channel binding will typically negotiate its use. Even for entirely new EAP methods designed with channel binding from the first version, some deployments may not use it. It is desirable to protect against attacks on the negotiation of channel bindings. An attacker including the NAS SHOULD NOT be able to prevent a peer and server who support channel bindings from using it. Unfortunately existing EAP methods may make it difficult or impossible to protect against attacks on negotiation. For example, many EAP state machines will accept a success message at any point after key derivation to terminate authentication. EAP success methods are not integrity protected; an attacker who could insert a message can generate one. The NAS is always in a position to generate a success message. Common EAP servers take advantage of state machines accepting success messages even in cases where an EAP method might support a protected indication of success. It may be challenging to define channel binding support for existing EAP methods in a manner that permits peers to distinguish an old EAP server that sends a success indication and does not support channel binding from an attacker injecting a success indication. From internet-drafts@ietf.org Mon Mar 12 13:31:21 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 4DD6A11E8094; Mon, 12 Mar 2012 13:31:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.583 X-Spam-Level: X-Spam-Status: No, score=-102.583 tagged_above=-999 required=5 tests=[AWL=0.016, 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 assqZhsb72Um; Mon, 12 Mar 2012 13:31:20 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B45CA21F89B6; Mon, 12 Mar 2012 13:31:20 -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.00 Message-ID: <20120312203120.24918.38440.idtracker@ietfa.amsl.com> Date: Mon, 12 Mar 2012 13:31:20 -0700 Cc: emu@ietf.org Subject: [Emu] I-D Action: draft-ietf-emu-chbind-14.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, 12 Mar 2012 20:31:21 -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 th= e IETF. Title : Channel Binding Support for EAP Methods Author(s) : Sam Hartman T. Charles Clancy Katrin Hoeper Filename : draft-ietf-emu-chbind-14.txt Pages : 32 Date : 2012-03-12 This document defines how to implement channel bindings for Extensible Authentication Protocol (EAP) methods to address the lying NAS as well as the lying provider problem. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-emu-chbind-14.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-emu-chbind-14.txt From turners@ieca.com Mon Mar 12 13:32: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 3995B11E809D for ; Mon, 12 Mar 2012 13:32:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.863 X-Spam-Level: X-Spam-Status: No, score=-101.863 tagged_above=-999 required=5 tests=[AWL=0.402, 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 Z8K-0XHV4S2S for ; Mon, 12 Mar 2012 13:32:13 -0700 (PDT) Received: from gateway16.websitewelcome.com (gateway16.websitewelcome.com [69.56.233.8]) by ietfa.amsl.com (Postfix) with ESMTP id 893B411E80AE for ; Mon, 12 Mar 2012 13:32:13 -0700 (PDT) Received: by gateway16.websitewelcome.com (Postfix, from userid 5007) id EE6E7773449A; Mon, 12 Mar 2012 15:32:12 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway16.websitewelcome.com (Postfix) with ESMTP id DE0F67734442 for ; Mon, 12 Mar 2012 15:32:12 -0500 (CDT) Received: from [96.241.1.58] (port=44221 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1S7Bud-0007NS-MS; Mon, 12 Mar 2012 15:32:12 -0500 Message-ID: <4F5E5D4C.3060103@ieca.com> Date: Mon, 12 Mar 2012 16:32:12 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Sam Hartman References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [96.241.1.58]:44221 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 4 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: emu@ietf.org Subject: Re: [Emu] Security considerations text for draft-ietf-emu-chbind 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, 12 Mar 2012 20:32:14 -0000 I'd like to see any comments by March 16th. spt On 3/12/12 4:12 PM, Sam Hartman wrote: > Hi. > I'm posting a new version of the channel bindings draft in response to > AD review comments. > I've been requested to develop security considerations text in response > to attacks I wrote about on the list. > > Here's the text I'm including in the new draft. > Comments are welcome. > > I don't know if Sean will simply issue the IETF last call and allow us > to comment on this text during the last call or if he'll seek comments > on this text before the last call. Either way, you should send comments > on this new security considerations text now if you have some. > > At the bottom of section 9.1 I've added: > > This trust model is a significant departure from the standard EAP > model. In many EAP deployments today attacks where one NAS can > impersonate another are out of scope. Channel bindings brings these > attacks into scope; the system as a whole needs to be analyzed to > evaluate cases where one NAS may impersonate another and to evaluate > the impact of this impersonation. > > One attractive implementation strategy for channel binding is to add > channel binding support to a tunnel method which can tunnel an inner > EAP authentication. This way, channel binding can be achieved with > any method that can act as an inner method even if that inner method > does not have native channel binding support. The requirement for > mutual authentication and key derivation is at the layer of EAP that > actually performs the channel binding. Tunnel methods sometimes use > cryptographic binding, a process where a peer proves that the peer > for the outer method is the same as the peer for an inner method to > tie authentication at one layer together with an inner layer. > Cryptographic binding does not always provide mutual authentication; > its definition does not require the server to prove that the inner > server and outer server are the same. Even when cryptographic > binding does attempt to confirm that the inner and outer server are > the same, the Master Session Key (MSK) is typically used to protect > the binding. However, the MSK is disclosed to the NAS, which can > typically attack cryptographic binding if it terminates the tunnel at > the NAS instead of the EAP server. This attack was not in scope for > existing threat models for cryptographic binding because one NAS > impersonating another is considered out of scope. Thus, existing > cryptographic binding does not typically provide mutual > authentication required for channel binding. > > I've added a new section 9.3: > > 9.3. Bid-Down Attacks > > EAP methods that add channel binding will typically negotiate its > use. Even for entirely new EAP methods designed with channel binding > from the first version, some deployments may not use it. It is > desirable to protect against attacks on the negotiation of channel > bindings. An attacker including the NAS SHOULD NOT be able to > prevent a peer and server who support channel bindings from using it. > > Unfortunately existing EAP methods may make it difficult or > impossible to protect against attacks on negotiation. For example, > many EAP state machines will accept a success message at any point > after key derivation to terminate authentication. EAP success > methods are not integrity protected; an attacker who could insert a > message can generate one. The NAS is always in a position to > generate a success message. Common EAP servers take advantage of > state machines accepting success messages even in cases where an EAP > method might support a protected indication of success. It may be > challenging to define channel binding support for existing EAP > methods in a manner that permits peers to distinguish an old EAP > server that sends a success indication and does not support channel > binding from an attacker injecting a success indication. > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu > From hartmans@mit.edu Tue Mar 13 10:59:12 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 998ED21F8634 for ; Tue, 13 Mar 2012 10:59:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.489 X-Spam-Level: X-Spam-Status: No, score=-103.489 tagged_above=-999 required=5 tests=[AWL=-1.224, 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 3hHVHLN2dh+b for ; Tue, 13 Mar 2012 10:59:11 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 8F38321F85B1 for ; Tue, 13 Mar 2012 10:59:11 -0700 (PDT) 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 582CF2021E; Tue, 13 Mar 2012 13:58:44 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id A04C54767; Tue, 13 Mar 2012 13:59:00 -0400 (EDT) From: Sam Hartman To: Pascal Urien References: <4F561332.1070806@deployingradius.com> Date: Tue, 13 Mar 2012 13:59:00 -0400 In-Reply-To: (Pascal Urien's message of "Sun, 11 Mar 2012 19:22:31 +0100") 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] Call for Agenda items 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, 13 Mar 2012 17:59:12 -0000 Hi. I'm confused. I'd like to understand why you'd like to present this draft? What response are you hoping for from the EMU working group? From pascal.urien@gmail.com Tue Mar 13 15:11: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 99E2721E803F for ; Tue, 13 Mar 2012 15:11:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.398 X-Spam-Level: X-Spam-Status: No, score=-3.398 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 48DxtXXj+PCG for ; Tue, 13 Mar 2012 15:11:19 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 93A9621E8028 for ; Tue, 13 Mar 2012 15:11:18 -0700 (PDT) Received: by ggmi1 with SMTP id i1so1271682ggm.31 for ; Tue, 13 Mar 2012 15:11:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Znb+wO7G2/hbLRRfVrvNtyiq9LLmX4smGAoGq51OyzI=; b=d5BcwupV6HFIxuN5Uejl81Q/oA+04YvSJ8AmMC+eig8po3ePZPn0y2kdMPCs1LFJtK j2KgAf9iJQ0rO/3YUEC9lCtUwlI6Nob3LhA/lwCaPIEDezAFQd/oODqf6saKblZ/vH1F BSKIdHITVLL0GJviN5uWzXgRphjYDTp97Y3Un556LxP/9Jgtbc9Rfi89WircnKEF4rRU Ayht2rHdFyG9YZMkRp0aazWgqWCd9qqOxQUmRHmy2NrTXTP4b1vjVaYaZc1XEwWS0vy4 rqECGjVNlzGz/yWVU4uOnZkHjWfvzhQMFrte5O76P52s/ju23vD1V+HYT1F59AEt2403 /KjQ== MIME-Version: 1.0 Received: by 10.229.136.196 with SMTP id s4mr79593qct.71.1331676678141; Tue, 13 Mar 2012 15:11:18 -0700 (PDT) Received: by 10.229.16.211 with HTTP; Tue, 13 Mar 2012 15:11:18 -0700 (PDT) In-Reply-To: References: <4F561332.1070806@deployingradius.com> Date: Tue, 13 Mar 2012 23:11:18 +0100 Message-ID: From: Pascal Urien To: Sam Hartman Content-Type: multipart/alternative; boundary=00235452e7505b398704bb272381 Cc: "emu@ietf.org" Subject: Re: [Emu] Call for Agenda items 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, 13 Mar 2012 22:11:19 -0000 --00235452e7505b398704bb272381 Content-Type: text/plain; charset=ISO-8859-1 Hi Sam "EAP Support in Smartcard" targets an Informational RFC. The first version was released in 2002 and presented at the IETF 55th in Atlanta., last version (http://tools.ietf.org/html/draft-urien-eap-smartcard-22) was issued in January 2012. Today many implementations (EAP-SIM, EAP-AKA , EAP-TLS) of this draft are working in Secure Elements, with or without NFC connectivity. The goal of the presentation at the IETF 83 in Paris is to push this draft as an Informational RFC. Regards Pascal 2012/3/13 Sam Hartman > Hi. > I'm confused. > I'd like to understand why you'd like to present this draft? > What response are you hoping for from the EMU working group? > --00235452e7505b398704bb272381 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi Sam

"EAP Support in Smartcard" targets an Informational RFC. The first version was released in 2002 and presented at the IETF 55th in Atlanta., last version (http://tools.ietf.org/html/draft-urien-eap-smartcard-22= ) was issued in January 2012.


Today many implementations (EAP-SIM, EAP-AKA , EAP-TLS) of this draft are working in Secure Elements, with or without NFC connectivity= .


The goal of the presentation at the IETF 83 in Paris= is to push this draft as an Informational RFC.


Regards

Pascal

2012/3/13 Sam H= artman <hartm= ans-ietf@mit.edu>
Hi.
I'm confused.
I'd like to understand why you'd like to present this draft?
What response are you hoping for from the EMU working group?

--00235452e7505b398704bb272381-- From hartmans@mit.edu Wed Mar 14 08:01:08 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 87D9821F87DC for ; Wed, 14 Mar 2012 08:01:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.468 X-Spam-Level: X-Spam-Status: No, score=-103.468 tagged_above=-999 required=5 tests=[AWL=-1.203, 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 fpSa0YAhwM3J for ; Wed, 14 Mar 2012 08:01:08 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 17AF221F87C7 for ; Wed, 14 Mar 2012 08:01:07 -0700 (PDT) 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 0CC64203BA; Wed, 14 Mar 2012 11:00:40 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 0DD474767; Wed, 14 Mar 2012 11:00:57 -0400 (EDT) From: Sam Hartman To: Pascal Urien References: <4F561332.1070806@deployingradius.com> Date: Wed, 14 Mar 2012 11:00:57 -0400 In-Reply-To: (Pascal Urien's message of "Tue, 13 Mar 2012 23:11:18 +0100") 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] Call for Agenda items 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, 14 Mar 2012 15:01:08 -0000 >>>>> "Pascal" == Pascal Urien writes: Pascal> The goal of the presentation at the IETF 83 in Paris is to Pascal> push this draft as an Informational RFC. Hi. I'm glad you want to publish this work as an RFC because I believe it's valuable and I'd like to see it an archival form. I'm supportive of efficiently publishing it as an RFC. I remaind confused because I don't understand how presenting the draft again to EMU will help that. Are you hoping that emu will adopt the document and we'll publish an informational rfc through emu? If so, I'm confused because I don't think that's in our charter. If you're hoping for an informational RFC not through EMU (either independent stream or IETF stream), how does the presentation help your goal? From jsalowey@cisco.com Wed Mar 14 11:04: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 1189221F86F3 for ; Wed, 14 Mar 2012 11:04:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.742 X-Spam-Level: X-Spam-Status: No, score=-109.742 tagged_above=-999 required=5 tests=[AWL=0.857, 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 E-7KsC3kaoOL for ; Wed, 14 Mar 2012 11:04:30 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 788F921F8535 for ; Wed, 14 Mar 2012 11:04:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jsalowey@cisco.com; l=517; q=dns/txt; s=iport; t=1331748270; x=1332957870; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=kbXeh2/2GWgt+HjC1DT8CDbwmzg2UI8zHpdHEHEIE5U=; b=RRFs52HmeHmk1E8feNQ/AA6es+gT8EGlbFP+ObPZRJz1qcm1lKCzZxqL GfmTSl6M7iR+tvqOEOclSrYzqBEMANvsjHPrP+nZYbJafk0+QU6rTt6K2 Ea4wUoHdSqD15UG7WWKbaoO8c5g6P1+6tzX/zAccgPf0sordIbo7hTILF Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: At8IAHDdYE+rRDoG/2dsb2JhbABDgwywBYMcgQeCIgEngjKHZ5pKgSefKY1cgj9jBIhXjH+Fa4hVgWiDBg X-IronPort-AV: E=Sophos;i="4.73,585,1325462400"; d="scan'208";a="36023162" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-4.cisco.com with ESMTP; 14 Mar 2012 18:04:30 +0000 Received: from [10.33.251.22] ([10.33.251.22]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q2EI4Txg008633 for ; Wed, 14 Mar 2012 18:04:29 GMT From: Joe Salowey Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 14 Mar 2012 11:04:26 -0700 Message-Id: To: emu@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [Emu] Proposed Agenda for IETF 83 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, 14 Mar 2012 18:04:31 -0000 IETF-83 EMU Agenda THURSDAY, March 29, 2012, 520-1720 Afternoon Session II, Room 252A Agenda ----------- 1. Administrivia (blue sheets, agenda, note takers, jabber) (5 min) 2. Mutual Crypto Binging and Channel Binding (Sam Hartman) (50 min) - draft-hartman-emu-mutual-crypto-bind - draft-ietf-emu-chbind 3. EAP Tunnel Method (Hao Zhou) (50 min) - draft-ietf-emu-eap-tunnel-method 4. DANE and TTLS (Jim Schaad) (10 min) - 5. EAP SmartCard (Pascal Urien) (Time permitting) - draft-urien-eap-smartcard From pascal.urien@gmail.com Wed Mar 14 14:26: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 255FF21F8875 for ; Wed, 14 Mar 2012 14:26:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.465 X-Spam-Level: X-Spam-Status: No, score=-3.465 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NdgZqyiX2+In for ; Wed, 14 Mar 2012 14:25:59 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0D52321F8872 for ; Wed, 14 Mar 2012 14:25:58 -0700 (PDT) Received: by ggmi1 with SMTP id i1so2648517ggm.31 for ; Wed, 14 Mar 2012 14:25:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=73MZrqkbm0N+YLbRQvoFo2Lr/+kdmBxSsqj7wXs4hIo=; b=CzGeEWJxsYSdPhqosZd65wGXt3hhgcVOkn4NkiH8FJOxemYtTFJE9aodGpz62TRNOE hKaPVn+sTkIo7ioeWD7WGyF1Lhe2/l+WZ9fsPG5TnrSeuQuPxvs9HY+d+Zh3f5gzpIyl AbJ+Y1nDmz1IwYuQxBgK1hDAyXxgkdqgSolpw/FMdbMjqKUsO0MWEM0P3wi+qDtdjZ9y qSKhS8Cv9lWQ1fyZiYLmqqDPJSQiJTbuWTa4IKP02IZfusoILboq5JiVTAxt7YiwWSg1 2y9OONohwqV0+fGH823NVZqVA/cFglzrqQQXNXLPytsAetWS1kPMHYOJTcECmABmx0j8 0wTw== MIME-Version: 1.0 Received: by 10.229.77.141 with SMTP id g13mr1488567qck.11.1331760358521; Wed, 14 Mar 2012 14:25:58 -0700 (PDT) Received: by 10.229.16.211 with HTTP; Wed, 14 Mar 2012 14:25:58 -0700 (PDT) In-Reply-To: References: <4F561332.1070806@deployingradius.com> Date: Wed, 14 Mar 2012 22:25:58 +0100 Message-ID: From: Pascal Urien To: Sam Hartman Content-Type: multipart/alternative; boundary=00235429cbe0187a7d04bb3a9f1b Cc: "emu@ietf.org" Subject: Re: [Emu] Call for Agenda items 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, 14 Mar 2012 21:26:00 -0000 --00235429cbe0187a7d04bb3a9f1b Content-Type: text/plain; charset=ISO-8859-1 Hi Sam EMU meansEAP Method Update. The EMU WG is the child of the EAP WG The eap smartcard draft was presented several times to the EAP WG. But the support of efficient implementation and its compatibility with smartphone OS, required more time than the EAP WG lifetime Regards Pascal 2012/3/14 Sam Hartman > >>>>> "Pascal" == Pascal Urien writes: > > > Pascal> The goal of the presentation at the IETF 83 in Paris is to > Pascal> push this draft as an Informational RFC. > > Hi. I'm glad you want to publish this work as an RFC because I believe > it's valuable and I'd like to see it an archival form. > I'm supportive of efficiently publishing it as an RFC. > > I remaind confused because I don't understand how presenting the draft > again to EMU will help that. Are you hoping that emu will adopt the > document and we'll publish an informational rfc through emu? If so, I'm > confused because I don't think that's in our charter. > > If you're hoping for an informational RFC not through EMU (either > independent stream or IETF stream), how does the presentation help your > goal? > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu > --00235429cbe0187a7d04bb3a9f1b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi Sam


EMU meansEAP Method Update.


The EMU WG is the child of the EAP WG


The eap smartcard draft was presented several times = to the EAP WG.


But the support of efficient implementation and its compatibility with smartphone OS, required more time than the EAP WG lifeti= me


Regards


Pascal



2012/3/14 Sam Hartman = <hartmans-ietf@mit.edu><= /span>
>>>>> "Pascal" =3D=3D Pascal Urien <pascal.urien@gmail.com> writes:


=A0 =A0Pascal> The goal of the presentation at the IETF 83 in Paris is = to
=A0 =A0Pascal> push this draft as an Informational RFC.

Hi. I'm glad you want to publish this work as an RFC because I believe<= br> it's valuable and I'd like to see it an archival form.
I'm supportive of efficiently publishing it as an RFC.

I remaind confused because I don't understand how presenting the draft<= br> again to EMU will help that. =A0Are you hoping that emu will adopt the
document and we'll publish an informational rfc through emu? =A0If so, = I'm
confused because I don't think that's in our charter.

If you're hoping for an informational RFC not through EMU (either
independent stream or IETF stream), how does the presentation help your
goal?
_________________________________________= ______
Emu mailing list
Emu@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/emu

--00235429cbe0187a7d04bb3a9f1b-- From hartmans@mit.edu Wed Mar 14 17:35: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 8C93F11E8081 for ; Wed, 14 Mar 2012 17:35:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.448 X-Spam-Level: X-Spam-Status: No, score=-103.448 tagged_above=-999 required=5 tests=[AWL=-1.183, 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 kP1NP7Bl56Bn for ; Wed, 14 Mar 2012 17:34:59 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 9C7F511E8075 for ; Wed, 14 Mar 2012 17:34:58 -0700 (PDT) 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 EC77020289; Wed, 14 Mar 2012 20:34:29 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 3B0ED4767; Wed, 14 Mar 2012 20:34:46 -0400 (EDT) From: Sam Hartman To: Pascal Urien References: <4F561332.1070806@deployingradius.com> Date: Wed, 14 Mar 2012 20:34:46 -0400 In-Reply-To: (Pascal Urien's message of "Wed, 14 Mar 2012 22:25:58 +0100") 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] Call for Agenda items 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, 15 Mar 2012 00:35:00 -0000 >>>>> "Pascal" == Pascal Urien writes: Pascal> Hi Sam EMU meansEAP Method Update. Hi. Thanks for the clarification. It turns out I'm reasonably familiar with the history of the EMU and EAP working groups. I remain confused. If you are ready to publish your draft, why do you need to present it to anyone? Based on my understanding of your document, you can simply ask the RFC editor to publish your draft as an informational document. Doing that is almost certainly the most efficient process for getting your document published. Again, I think it would be a great idea to see this work published. From pascal.urien@gmail.com Fri Mar 16 12:24: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 E271321F8687 for ; Fri, 16 Mar 2012 12:24:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.498 X-Spam-Level: X-Spam-Status: No, score=-3.498 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JQksryh8iFg9 for ; Fri, 16 Mar 2012 12:24:40 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8C6F321F8620 for ; Fri, 16 Mar 2012 12:24:39 -0700 (PDT) Received: by yenm5 with SMTP id m5so5189922yen.31 for ; Fri, 16 Mar 2012 12:24:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ZUYyM2bZDW8U9bFUTmShPbjKat4I73FmIBsfAuLdz+0=; b=TfCWfNHtoAUR0JwxR8tp+XSt/Mwg576fJubincgetQg7WkZx4Yr0TnjxPL2sXZvzT/ XRXigffIFD0SXYVf2E/DOM4N3iTQ6WOlWUtL/mlTYIa8cHigVLvQx+W+lMaUg08HWaWl o8brfgBzXTmEgxv4tiSP2jckVmWXwY+EAevbRUdNTuD/QxPBTE0ORY0cHmgW3lk48Vco qiRZw98Xu93jXADY4sTfORSZa/jmiCYClOwU42qpmoBtLggTJog29xbQHzNOvqCF4tJp QsBr1ZR1PiKcMbCxAEs8JMg18z29Q8aS4m0Wi+S0E6XkPQkwoKWfufJEmlKHF3F3fxHk g2Qw== MIME-Version: 1.0 Received: by 10.229.201.105 with SMTP id ez41mr1447723qcb.39.1331925879124; Fri, 16 Mar 2012 12:24:39 -0700 (PDT) Received: by 10.229.17.194 with HTTP; Fri, 16 Mar 2012 12:24:38 -0700 (PDT) In-Reply-To: References: <4F561332.1070806@deployingradius.com> Date: Fri, 16 Mar 2012 20:24:38 +0100 Message-ID: From: Pascal Urien To: Sam Hartman , turners@ieca.com Content-Type: multipart/alternative; boundary=00504502961ee4728704bb612861 Cc: "emu@ietf.org" Subject: Re: [Emu] Call for Agenda items 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, 16 Mar 2012 19:24:41 -0000 --00504502961ee4728704bb612861 Content-Type: text/plain; charset=ISO-8859-1 Hi Sam, Thank you for this support. I am going to publish this draft as informational document I will attend to this next EMU WG meeting in Paris Regards Pascal 2012/3/15 Sam Hartman > >>>>> "Pascal" == Pascal Urien writes: > > Pascal> Hi Sam EMU meansEAP Method Update. > > Hi. Thanks for the clarification. It turns out I'm reasonably familiar > with the history of the EMU and EAP working groups. > > I remain confused. If you are ready to publish your draft, why do you > need to present it to anyone? Based on my understanding of your > document, you can simply ask the RFC editor to publish your draft as an > informational document. > Doing that is almost certainly the most efficient process for getting > your document published. > > Again, I think it would be a great idea to see this work published. > --00504502961ee4728704bb612861 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Sam,
=A0
=A0Thank you for this support.
=A0
=A0 I am going to publish this draft as informational docu= ment
=A0
=A0 I will attend to this next EMU WG meeting= in Paris
=A0
Regards
=A0
Pascal=A0
=A0 =

2012/3/15 Sam Hartman <hartmans-ietf@mit.edu>
>>>>> "Pascal" = =3D=3D Pascal Urien <pascal.ur= ien@gmail.com> writes:

=A0 =A0Pascal> Hi Sam EMU meansEAP Method Update.

Hi. Thanks for the clarification. It turns out I'm reasonably familiar<= br> with the history of the EMU and EAP working groups.

I remain confused. If you are ready to publish your draft, why do you
need to present it to anyone? =A0Based on my understanding of your
document, you can simply ask the RFC editor to publish your draft as an
informational document.
Doing that is almost certainly the most efficient process for getting
your document published.

Again, I think it would be a great idea to see this work published.

--00504502961ee4728704bb612861-- From hartmans@mit.edu Mon Mar 19 12:01: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 79FDA21F88ED for ; Mon, 19 Mar 2012 12:01:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.35 X-Spam-Level: X-Spam-Status: No, score=-103.35 tagged_above=-999 required=5 tests=[AWL=-1.085, 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 SlcB4AYciOBo for ; Mon, 19 Mar 2012 12:01:24 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 72DC621E8015 for ; Mon, 19 Mar 2012 12:01:17 -0700 (PDT) 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 4B26A2058F; Mon, 19 Mar 2012 15:00:41 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id D045A4767; Mon, 19 Mar 2012 15:00:52 -0400 (EDT) From: Sam Hartman To: Hao Zhou References: Date: Mon, 19 Mar 2012 15:00:52 -0400 In-Reply-To: (Hao Zhou's message of "Wed, 07 Mar 2012 13:13:51 -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: draft-hartman-emu-mutual-crypto-bind@tools.ietf.org, zhangdacheng@huawei.com, Sam Hartman , emu@ietf.org Subject: Re: [Emu] New draft on mutual crypto binding problem 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, 19 Mar 2012 19:01:24 -0000 Dear Hao: I was pleased to hear your analysis of areas where mutual crypto binding may be tricky to deploy because I would like to accurately describe this problem space. I believe the draft covers most of the points you raise but I will definitely incorporate your feedback. I was a bit frustrated though that you proposed simply focusing on certificate validation without responding to the concerns that the draft raises in that area because I put a fair bit of time into analyzing that problem space and I was hoping to try and explain that there are no easy answers. I hear that you are concerned about the complexity of EMSK-based cryptographic binding; I'm guessing you'd like to make rapid progress on your draft. However I'm concerned when I think we may be discarding an option like EMSK-based cryptographic binding in favor of an option that we believe doesn't cover a number of deployments that we've decided in our requirements analysis are important to us. I think both of our options have merit. Would you be willing to get together with me and Dacheng before the EMU meeting to work on a design for EMSK-based cryptographic binding in your method and to work on understanding what's required to get the most out of certificate binding? I'd like to have a well-informed discussion about the complexity of EMSK-based cryptographic binding, the discussion of complexity of certificate validation and the environments where they can both function. I'd appreciate your help in getting to that point! I'd also be interested in working with anyone else on this problem. Currently I'm available Monday morning, Monday during lunch, Monday during the first afternoon session. It also looks like I have a fair bit of availability Tuesday. From hzhou@cisco.com Mon Mar 19 15:19:22 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 DCE5A21F884F for ; Mon, 19 Mar 2012 15:19:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.901 X-Spam-Level: X-Spam-Status: No, score=-9.901 tagged_above=-999 required=5 tests=[AWL=0.699, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 tDn1oJuutstT for ; Mon, 19 Mar 2012 15:19:22 -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 39E6821F8843 for ; Mon, 19 Mar 2012 15:19:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=hzhou@cisco.com; l=2052; q=dns/txt; s=iport; t=1332195562; x=1333405162; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=WyqsDf3W3h//9yzSGV46963A6T4eAS6/PAbzpr2dk1w=; b=FwVhea0SXXFnz961Ao2CRsCxB0Y9pkI3C2xfozsuwwatVWmnByEvbcDk 1ALPUeRlskTRM08a/CceBYeGjLAZhxj6QX8L+QpS6h3rDQ5LDMc0uYRc3 QufNBO8gQVVbKBTTJ591Ao4dm/T4dDB0GlOxajY8O8MKDxVGVH/afRiGl o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAL2vZ0+tJV2b/2dsb2JhbABBDrZJgQeCCQEBAQMBEgEnAgE8BQ0BCIEdAQEEDgUih2MFmAifCZBlBJVojkCBaIIvU4E6Fw X-IronPort-AV: E=Sophos;i="4.73,614,1325462400"; d="scan'208";a="67505635" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-1.cisco.com with ESMTP; 19 Mar 2012 22:19:21 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q2JMJLE8013521; Mon, 19 Mar 2012 22:19:21 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); Mon, 19 Mar 2012 17:19:21 -0500 Received: from 10.21.104.118 ([10.21.104.118]) by XMB-RCD-203.cisco.com ([72.163.62.210]) via Exchange Front-End Server email.cisco.com ([128.107.191.79]) with Microsoft Exchange Server HTTP-DAV ; Mon, 19 Mar 2012 22:19:21 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Mon, 19 Mar 2012 18:19:19 -0400 From: Hao Zhou To: Sam Hartman Message-ID: Thread-Topic: [Emu] New draft on mutual crypto binding problem Thread-Index: Ac0GHlPmT2O0BI5QfkGnxXZ/tGrKLQ== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 19 Mar 2012 22:19:21.0541 (UTC) FILETIME=[556A0750:01CD061E] Cc: draft-hartman-emu-mutual-crypto-bind@tools.ietf.org, zhangdacheng@huawei.com, emu@ietf.org Subject: Re: [Emu] New draft on mutual crypto binding problem 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, 19 Mar 2012 22:19:23 -0000 Hi, Sam: I can meet with you and Dacheng either during Monday lunch or first afternoon session to discuss the options. Thanks. On 3/19/12 3:00 PM, "Sam Hartman" wrote: > Dear Hao: > > I was pleased to hear your analysis of areas where mutual crypto binding > may be tricky to deploy because I would like to accurately describe this > problem space. I believe the draft covers most of the points you raise > but I will definitely incorporate your feedback. > > I was a bit frustrated though that you proposed simply focusing on > certificate validation without responding to the concerns that the draft > raises in that area because I put a fair bit of time into analyzing > that problem space and I was hoping to try and explain that there are no > easy answers. I hear that you are concerned about the complexity of > EMSK-based cryptographic binding; I'm guessing you'd like to make rapid > progress on your draft. > > However I'm concerned when I think we may be discarding an option like > EMSK-based cryptographic binding in favor of an option that we believe > doesn't cover a number of deployments that we've decided in our > requirements analysis are important to us. > I think both of our options have merit. > Would you be willing to get together with me and Dacheng before the EMU > meeting to work on a design for EMSK-based cryptographic binding in your > method and to work on understanding what's required to get the most out > of certificate binding? I'd like to have a well-informed discussion > about the complexity of EMSK-based cryptographic binding, the discussion > of complexity of certificate validation and the environments where they > can both function. I'd appreciate your help in getting to that point! > I'd also be interested in working with anyone else on this problem. > > Currently I'm available Monday morning, Monday during lunch, Monday > during the first afternoon session. It also looks like I have a fair bit > of availability Tuesday. From ietf@augustcellars.com Tue Mar 20 03:22: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 74D0521F866B for ; Tue, 20 Mar 2012 03:22:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 JJap-GYKSYG2 for ; Tue, 20 Mar 2012 03:22:39 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id 9053E21F8658 for ; Tue, 20 Mar 2012 03:22:39 -0700 (PDT) Received: from Tobias (68-25-130-116.pools.static.spcsdns.net [68.25.130.116]) (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 B76202CA26; Tue, 20 Mar 2012 03:22:37 -0700 (PDT) From: "Jim Schaad" To: "Sam Hartman" , , Date: Tue, 20 Mar 2012 03:21:46 -0700 Message-ID: <01fe01cd0683$43027790$c90766b0$@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: Ac0GN1gInqISJcyoT1GJ4J2Ypr/OxA== Content-Language: en-us Cc: emu@ietf.org Subject: [Emu] Comments on draft-hartman-emu-mutual-crypto-bind 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, 20 Mar 2012 10:22:40 -0000 Sam et al, 1. In section 1 after the Classic Tunnel Attack figure, I believe there are three methods listed as possible mitigation strategies, however I don't understand how the second one - a sufficiently strong inner method - could possibly be a mitigation by itself. The three I see are 1) Policy 2) strong inner method 3) Cryptographic binding. 2. In section 3.2.2 - For the more traditional MITM attack. There is a requirement for this defense that the internal authentication methods are going to be able to support the cryptographic binding that you are postulating. If this is not true then this would not be a detectible attack. I think this should go into the paragraph before the diagram rather than being (kind of) implicit in the paragraph after the figure. 3. 3.2.3 or 3.2.2 - If you had a non EAP method, and it derived a key (just like a good EAP method). Is there any reason why you could not do the cryptographic binding? Other than it is not currently defined in one of the current tunneling methods. One could see that it could be defined as saying after you do this, then perform the same binding as any key deriving EAP method would do,. 4. Section 3.2.4 - Item #4 - did you mean that it MUST prevent an attacker from downgrading the binding from mutual to just MSK-based? Also if the down grade occurs, do you still want to claim that it is still mutual if step 4 is downgraded? The current text implies this to me and that seems wrong. 5. Section 3.2.4 - last paragraph - the last sentence confuses the heck out of me. 6. Section 4.2 - I don't understand why things like doing channel binding require that a mutual authentication be present. I can understand a statement that the peer MUST have doing an adequate job of authenticating the server, but I am less clear why the server needs to have authenticated the client. Thus for example I think that cryptographic binding should be sufficient to deal with these cases. (i.e. Tunnel is authenticated to certificate and mutual auth is tied to the tunnel). Jim From hartmans@mit.edu Tue Mar 20 12:01:26 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 47EFC21F854E for ; Tue, 20 Mar 2012 12:01:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.334 X-Spam-Level: X-Spam-Status: No, score=-103.334 tagged_above=-999 required=5 tests=[AWL=-1.069, 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 u1+IsY0rAWgo for ; Tue, 20 Mar 2012 12:01:25 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id DB20A21F862F for ; Tue, 20 Mar 2012 12:01:20 -0700 (PDT) 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 7F89820244; Tue, 20 Mar 2012 15:00:45 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 45D3D4767; Tue, 20 Mar 2012 15:00:57 -0400 (EDT) From: Sam Hartman To: Hao Zhou References: Date: Tue, 20 Mar 2012 15:00:57 -0400 In-Reply-To: (Hao Zhou's message of "Mon, 19 Mar 2012 18:19:19 -0400") 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: draft-hartman-emu-mutual-crypto-bind@tools.ietf.org, zhangdacheng@huawei.com, Sam Hartman , emu@ietf.org Subject: Re: [Emu] New draft on mutual crypto binding problem 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, 20 Mar 2012 19:01:26 -0000 Let's meet Monday at lunch. We should try and get a count of interested people. From ietf@augustcellars.com Wed Mar 21 03:16: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 A438D21F868C for ; Wed, 21 Mar 2012 03:16:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[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 zxrJixQQUNeo for ; Wed, 21 Mar 2012 03:16:18 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8CE7821F8680 for ; Wed, 21 Mar 2012 03:16:18 -0700 (PDT) Received: from Tobias (unknown [68.25.130.116]) (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 8309E2CA19; Wed, 21 Mar 2012 03:16:17 -0700 (PDT) From: "Jim Schaad" To: Date: Wed, 21 Mar 2012 03:15:19 -0700 Message-ID: <001301cd074b$8af02cf0$a0d086d0$@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: Ac0GkudGZ1gCcnEBRvqrIb0aX6h+Ow== Content-Language: en-us Cc: emu@ietf.org Subject: [Emu] Comments on emu-eap-tunnel-method-02 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, 21 Mar 2012 10:16:19 -0000 1. After the first exchange of messages, if the version does not match the agreed on version - what happens? 2. Section 3.2 says that one should be able to do a renegotiate for getting the peers identity certificate. Do the following points need to be made? a) If you are doing a re-negotiation - then you SHOULD not be using an anonymous cipher suite b) Once you have started phase 2, re-negotiation MUST NOT be done. 3. in section 3.3.1 - did you miss changing and EAP-TLS to a TEAP? "For example, EAP-TLS..." If not, then I would suggest changing to a std track protocol. 4. In section 3.4 - I want to make sure that what I read is what you intend. == If I do multiple (one or more) inner EAP methods, the authenticated peer identity is the set of all of these identities. == If I do zero inner EAP methods and I do a client auth TLS, the authenticated peer identity comes from the certificate. == If I do zero inner EAP methods and do not do a client auth TLS, then I have no authenticated peer identity. -- specifically - should the client auth TLS identity be excluded if I run an inner EAP method -- Specifically - should the all non EAP methods be excluded -- include the TEAP defined user name/password -- Specifically - should any EAP server name established in an EAP method be excluded from its name set? 5. In section 3.8 - potentially ambiguous statement: "The request MAY be issued after the peer has determined..." Is the request the MAY or the timing of the request the MAY? 6. In section 4.2.3 - What is the registration policy for the Identity-Type field of the Identity-Type TLV? Do there need to be reserved ranges for use by specific Servers - i.e. local use? Or is that insane? 7. In section 4.2.4 - What do I do for an defined value. Do these values only match those of the available through the base document or are other 8. In section 4.2.9 - Are the TLVs to be processed and the EAP to negotiate to be included in the peer response? 9. Does the order of items in the TLV list matter? Or are specific TLVs expected to be processed first. For example what would be the expected order on the Identity-Type TLV and the EAP-Payload TLV? 10. Section 4.2.12.2 says the key is of a specific length, yet there is length field. Why is a specific length mentioned esp as the length was just changed in the last version. I assume this key length is dependent on the PAC type and should not be fixed. 11. Section 4.2.15 - If we change the "standard" way of doing name preparation, should we be creating a new item, or should we have a byte field that specifies the username/password processing function. 12. Section 5.2 - Does the truncation and expansion to 32-bytes still hold true if the TLS-PRF were to use a new cypher suite that used P_SHA512? Jim From hzhou@cisco.com Wed Mar 21 11:26: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 092D021F85D1 for ; Wed, 21 Mar 2012 11:26:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.845 X-Spam-Level: X-Spam-Status: No, score=-7.845 tagged_above=-999 required=5 tests=[AWL=0.687, 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 zN8cBykIbwJ3 for ; Wed, 21 Mar 2012 11:26:34 -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 81F0221F856C for ; Wed, 21 Mar 2012 11:26:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=hzhou@cisco.com; l=5290; q=dns/txt; s=iport; t=1332354393; x=1333563993; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=csNwYYdihvjiaaK+zZI5GSRu2dzAU7Mf2La4WnRRKqo=; b=i8XwzwRPT7l2iS6/iBL7D4ZoDCMpg4R5LIgREKfnFZDWFVz1EQcNqRPT VtZmldRdiBoE9FVR5Y7dEkIn2IZ/Wkgbgysedfk+kPw2J4ExgQRCbBSaa VlyS2TKdQKbju9jFeeQE5+TsR85A4Qg2ezBGoryGs7ba5ahzi2uFc01YY g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuQJADQdak+tJXG+/2dsb2JhbAA7CbcHAoEHggkBAQEDAQEBAQ8BJwIBMQsFDQEIDiACPTABAQQBDQUih2MFC5h5nwIEilmDAgYHgxkElV+OP4FogwOBOhc X-IronPort-AV: E=Sophos;i="4.73,624,1325462400"; d="scan'208";a="68358682" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-4.cisco.com with ESMTP; 21 Mar 2012 18:26:29 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id q2LIQTtg030472; Wed, 21 Mar 2012 18:26:29 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); Wed, 21 Mar 2012 13:26:29 -0500 Received: from 64.101.219.105 ([64.101.219.105]) 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 ; Wed, 21 Mar 2012 18:26:29 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Wed, 21 Mar 2012 14:26:26 -0400 From: Hao Zhou To: Jim Schaad , Message-ID: Thread-Topic: [Emu] Comments on emu-eap-tunnel-method-02 Thread-Index: Ac0GkudGZ1gCcnEBRvqrIb0aX6h+OwA/TjmQ In-Reply-To: <001301cd074b$8af02cf0$a0d086d0$@augustcellars.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 21 Mar 2012 18:26:29.0371 (UTC) FILETIME=[222D94B0:01CD0790] Cc: emu@ietf.org Subject: Re: [Emu] Comments on emu-eap-tunnel-method-02 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, 21 Mar 2012 18:26:38 -0000 Jim: Thanks for the detailed review. My comments are below inline: On 3/21/12 6:15 AM, "Jim Schaad" wrote: > 1. After the first exchange of messages, if the version does not match the > agreed on version - what happens? > [HZ] Good catch. Both sides should stick with the version negotiated. I guess we will add some language to describe the behavior handling exceptions. My initial thoughts are both sides should treat it as fatal error and proceed with fatal error processing, e.g., server should just send back EAP-Failure and peer sends back EAP-Nak. > 2. Section 3.2 says that one should be able to do a renegotiate for getting > the peers identity certificate. Do the following points need to be made? > a) If you are doing a re-negotiation - then you SHOULD not be using an > anonymous cipher suite > b) Once you have started phase 2, re-negotiation MUST NOT be done. > [HZ] Good points. I will add them. > 3. in section 3.3.1 - did you miss changing and EAP-TLS to a TEAP? "For > example, EAP-TLS..." If not, then I would suggest changing to a std track > protocol. > [HZ] No. It is meant to say EAP-TLS. I thought EAP-TLS RFC5216 is a std track RFC. > 4. In section 3.4 - I want to make sure that what I read is what you > intend. > == If I do multiple (one or more) inner EAP methods, the authenticated peer > identity is the set of all of these identities. > == If I do zero inner EAP methods and I do a client auth TLS, the > authenticated peer identity comes from the certificate. > == If I do zero inner EAP methods and do not do a client auth TLS, then I > have no authenticated peer identity. > [HZ] Correct except last one. I would say the authenticated peer identity comes from any inner method, not necessary EAP method. So if a password TLV exchange happened, then the authenticated peer identity is coming from that password authentication TLV exchange. I think we will change the word "inner EAP method" to "inner authentication method". > -- specifically - should the client auth TLS identity be excluded if I run > an inner EAP method [HZ] No. > -- Specifically - should the all non EAP methods be excluded -- include the > TEAP defined user name/password [HZ] No. > -- Specifically - should any EAP server name established in an EAP method > be excluded from its name set? > [HZ] It could be included as part of the Server-ID if the server is not authenticated as part of the tunnel establishment. I will add some text to address this. > 5. In section 3.8 - potentially ambiguous statement: "The request MAY be > issued after the peer has determined..." Is the request the MAY or the > timing of the request the MAY? > [HZ] Good catch. It is "the request MAY". Timing is should be after validating the crypto-binding TLV. I will address that. > 6. In section 4.2.3 - What is the registration policy for the Identity-Type > field of the Identity-Type TLV? Do there need to be reserved ranges for use > by specific Servers - i.e. local use? Or is that insane? > [HZ] I missed that in IANA section. It should be Spec Required as others. I don't see need for local use types. > 7. In section 4.2.4 - What do I do for an defined value. Do these values > only match those of the available through the base document or are other > [HZ} I am confused. Are you talking about Section 4.2.4 Result TLV or others? > 8. In section 4.2.9 - Are the TLVs to be processed and the EAP to negotiate > to be included in the peer response? > [HZ] Yes. I will add a sentence or two describe this. > 9. Does the order of items in the TLV list matter? Or are specific TLVs > expected to be processed first. For example what would be the expected > order on the Identity-Type TLV and the EAP-Payload TLV? > [HZ] It shouldn't matter. But I would think Identity-Type TLV should precede EAP-Payload TLV. Let me think about maybe some other cases order is important and document that. > 10. Section 4.2.12.2 says the key is of a specific length, yet there is > length field. Why is a specific length mentioned esp as the length was just > changed in the last version. I assume this key length is dependent on the > PAC type and should not be fixed. [HZ] You are correct. It shouldn't be fixed, to be crypto-agile. Will fix that. 48 octets are just an example, maybe minimum length. > > 11. Section 4.2.15 - If we change the "standard" way of doing name > preparation, should we be creating a new item, or should we have a byte > field that specifies the username/password processing function. > [HZ] Can you provide an example why UTF-8 is not sufficient? Are you proposing adding a namespace or type for the name preparation, as opposed to standard UTF-8? > 12. Section 5.2 - Does the truncation and expansion to 32-bytes still hold > true if the TLS-PRF were to use a new cypher suite that used P_SHA512? > [HZ] Good question. In current draft, the key length of the keying materials to be mixed are somewhat fixed. I didn't see the need to extend it yet. > Jim > > > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu From ietf@augustcellars.com Wed Mar 21 13:57:32 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 6E36F21E8098 for ; Wed, 21 Mar 2012 13:57:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[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 PYGcsDIhkdoy for ; Wed, 21 Mar 2012 13:57:31 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id E55C021E8051 for ; Wed, 21 Mar 2012 13:57:31 -0700 (PDT) Received: from Tobias (68-25-130-116.pools.static.spcsdns.net [68.25.130.116]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 0B4792CA10; Wed, 21 Mar 2012 13:57:20 -0700 (PDT) From: "Jim Schaad" To: "'Hao Zhou'" , References: <001301cd074b$8af02cf0$a0d086d0$@augustcellars.com> In-Reply-To: Date: Wed, 21 Mar 2012 13:56:12 -0700 Message-ID: <004d01cd07a5$1c7636c0$5562a440$@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: AQF8fF58Mv0g7OCcr6vTeg1jIeLFNpcWTsNQ Content-Language: en-us Cc: emu@ietf.org Subject: Re: [Emu] Comments on emu-eap-tunnel-method-02 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, 21 Mar 2012 20:57:32 -0000 > -----Original Message----- > From: Hao Zhou [mailto:hzhou@cisco.com] > Sent: Wednesday, March 21, 2012 11:26 AM > To: Jim Schaad; draft-ietf-emu-eap-tunnel-method@tools.ietf.org > Cc: emu@ietf.org > Subject: Re: [Emu] Comments on emu-eap-tunnel-method-02 > > Jim: > > Thanks for the detailed review. My comments are below inline: > > > On 3/21/12 6:15 AM, "Jim Schaad" wrote: > > > 7. In section 4.2.4 - What do I do for an defined value. Do these > > values only match those of the available through the base document or > > are other > > > [HZ} I am confused. Are you talking about Section 4.2.4 Result TLV or others? I was looking at the result TLV, I was thinking in terms of a Not Available at this time - but that should probably be in the NAK not in the Result. As there are only two possible results to be returned at the top level EAP - this is probably an extraneous comment. > > 11. Section 4.2.15 - If we change the "standard" way of doing name > > preparation, should we be creating a new item, or should we have a > > byte field that specifies the username/password processing function. > > > [HZ] Can you provide an example why UTF-8 is not sufficient? Are you > proposing adding a namespace or type for the name preparation, as opposed > to standard UTF-8? No the thing that will change is SASLPrep. We will want to be able to move to a string mangling function that matches the current Unicode standard and use the (or one of the) result(s) of the precs working group. > > 12. Section 5.2 - Does the truncation and expansion to 32-bytes still > > hold true if the TLS-PRF were to use a new cypher suite that used > P_SHA512? > > > [HZ] Good question. In current draft, the key length of the keying materials > to be mixed are somewhat fixed. I didn't see the need to extend it yet. As long as the PRF is based on HMAC there is no problem with having a "short" key. Jim > > > Jim > > > > > > _______________________________________________ > > Emu mailing list > > Emu@ietf.org > > https://www.ietf.org/mailman/listinfo/emu From ietf@augustcellars.com Wed Mar 21 17:53:52 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 DD0A221F853E for ; Wed, 21 Mar 2012 17:53:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[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 SX3Mgsg7Zk0P for ; Wed, 21 Mar 2012 17:53:51 -0700 (PDT) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) by ietfa.amsl.com (Postfix) with ESMTP id DE06121F8549 for ; Wed, 21 Mar 2012 17:53:51 -0700 (PDT) Received: from Tobias (68-25-130-116.pools.static.spcsdns.net [68.25.130.116]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id D8CB038EEE; Wed, 21 Mar 2012 17:53:49 -0700 (PDT) From: "Jim Schaad" To: "'Hao Zhou'" , References: <001301cd074b$8af02cf0$a0d086d0$@augustcellars.com> In-Reply-To: Date: Wed, 21 Mar 2012 17:52:58 -0700 Message-ID: <005701cd07c6$2223e830$666bb890$@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: AQF8fF58Mv0g7OCcr6vTeg1jIeLFNpcWkvgw Content-Language: en-us Cc: emu@ietf.org Subject: Re: [Emu] Comments on emu-eap-tunnel-method-02 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, 22 Mar 2012 00:53:53 -0000 You might also need to put in an IANA consideration for the use of the TLS Exporter (http://www.iana.org/assignments/tls-parameters/tls-parameters.xml#exporter- labels) Jim > -----Original Message----- > From: Hao Zhou [mailto:hzhou@cisco.com] > Sent: Wednesday, March 21, 2012 11:26 AM > To: Jim Schaad; draft-ietf-emu-eap-tunnel-method@tools.ietf.org > Cc: emu@ietf.org > Subject: Re: [Emu] Comments on emu-eap-tunnel-method-02 > > Jim: > > Thanks for the detailed review. My comments are below inline: > > > On 3/21/12 6:15 AM, "Jim Schaad" wrote: > > > 1. After the first exchange of messages, if the version does not > > match the agreed on version - what happens? > > > [HZ] Good catch. Both sides should stick with the version negotiated. I guess > we will add some language to describe the behavior handling exceptions. My > initial thoughts are both sides should treat it as fatal error and proceed with > fatal error processing, e.g., server should just send back EAP-Failure and peer > sends back EAP-Nak. > > > 2. Section 3.2 says that one should be able to do a renegotiate for > > getting the peers identity certificate. Do the following points need to be > made? > > a) If you are doing a re-negotiation - then you SHOULD not be using an > > anonymous cipher suite > > b) Once you have started phase 2, re-negotiation MUST NOT be done. > > > [HZ] Good points. I will add them. > > > 3. in section 3.3.1 - did you miss changing and EAP-TLS to a TEAP? > > "For example, EAP-TLS..." If not, then I would suggest changing to a > > std track protocol. > > > [HZ] No. It is meant to say EAP-TLS. I thought EAP-TLS RFC5216 is a std track > RFC. > > > 4. In section 3.4 - I want to make sure that what I read is what you > > intend. > > == If I do multiple (one or more) inner EAP methods, the > > authenticated peer identity is the set of all of these identities. > > == If I do zero inner EAP methods and I do a client auth TLS, the > > authenticated peer identity comes from the certificate. > > == If I do zero inner EAP methods and do not do a client auth TLS, > > then I have no authenticated peer identity. > > > [HZ] Correct except last one. I would say the authenticated peer identity > comes from any inner method, not necessary EAP method. So if a password > TLV exchange happened, then the authenticated peer identity is coming > from that password authentication TLV exchange. I think we will change the > word "inner EAP method" to "inner authentication method". > > > -- specifically - should the client auth TLS identity be excluded if > > I run an inner EAP method > [HZ] No. > > -- Specifically - should the all non EAP methods be excluded -- > > include the TEAP defined user name/password > [HZ] No. > > -- Specifically - should any EAP server name established in an EAP > > method be excluded from its name set? > > > [HZ] It could be included as part of the Server-ID if the server is not > authenticated as part of the tunnel establishment. I will add some text to > address this. > > 5. In section 3.8 - potentially ambiguous statement: "The request > > MAY be issued after the peer has determined..." Is the request the > > MAY or the timing of the request the MAY? > > > [HZ] Good catch. It is "the request MAY". Timing is should be after validating > the crypto-binding TLV. I will address that. > > 6. In section 4.2.3 - What is the registration policy for the > > Identity-Type field of the Identity-Type TLV? Do there need to be > > reserved ranges for use by specific Servers - i.e. local use? Or is that > insane? > > > [HZ] I missed that in IANA section. It should be Spec Required as others. I > don't see need for local use types. > > > 7. In section 4.2.4 - What do I do for an defined value. Do these > > values only match those of the available through the base document or > > are other > > > [HZ} I am confused. Are you talking about Section 4.2.4 Result TLV or others? > > > 8. In section 4.2.9 - Are the TLVs to be processed and the EAP to > > negotiate to be included in the peer response? > > > [HZ] Yes. I will add a sentence or two describe this. > > > 9. Does the order of items in the TLV list matter? Or are specific > > TLVs expected to be processed first. For example what would be the > > expected order on the Identity-Type TLV and the EAP-Payload TLV? > > > [HZ] It shouldn't matter. But I would think Identity-Type TLV should precede > EAP-Payload TLV. Let me think about maybe some other cases order is > important and document that. > > > 10. Section 4.2.12.2 says the key is of a specific length, yet there > > is length field. Why is a specific length mentioned esp as the length > > was just changed in the last version. I assume this key length is > > dependent on the PAC type and should not be fixed. > [HZ] You are correct. It shouldn't be fixed, to be crypto-agile. Will fix that. 48 > octets are just an example, maybe minimum length. > > > > 11. Section 4.2.15 - If we change the "standard" way of doing name > > preparation, should we be creating a new item, or should we have a > > byte field that specifies the username/password processing function. > > > [HZ] Can you provide an example why UTF-8 is not sufficient? Are you > proposing adding a namespace or type for the name preparation, as opposed > to standard UTF-8? > > 12. Section 5.2 - Does the truncation and expansion to 32-bytes still > > hold true if the TLS-PRF were to use a new cypher suite that used > P_SHA512? > > > [HZ] Good question. In current draft, the key length of the keying materials > to be mixed are somewhat fixed. I didn't see the need to extend it yet. > > > Jim > > > > > > _______________________________________________ > > Emu mailing list > > Emu@ietf.org > > https://www.ietf.org/mailman/listinfo/emu From hartmans@painless-security.com Sun Mar 25 04:50:52 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 6C45421F861B for ; Sun, 25 Mar 2012 04:50:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.71 X-Spam-Level: X-Spam-Status: No, score=-103.71 tagged_above=-999 required=5 tests=[AWL=-1.445, 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 HiQlPhmFn2AO for ; Sun, 25 Mar 2012 04:50:50 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 1573921F8619 for ; Sun, 25 Mar 2012 04:50:50 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (dhcp-43ac.meeting.ietf.org [130.129.67.172]) (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 CD2B5202D8 for ; Sun, 25 Mar 2012 07:50:08 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id CED4E4766; Sun, 25 Mar 2012 07:50:45 -0400 (EDT) From: Sam Hartman To: emu@ietf.org Date: Sun, 25 Mar 2012 07:50:45 -0400 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] Review of draft-ietf-emu-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: Sun, 25 Mar 2012 11:50:52 -0000 1) TEAP extends TLS RFC 5077 In section 2, TEAP discusses using phase 2 TLVs to include a TLS session ticket and an associated secret key. RFc 5077 only permits session tickets to be sent using the session ticket message. I believe that this is an extension to TLS that would need to go through the TLS working group. My preference is to remove TLS tickets sent via a manner other than the session ticket handshake message. If support for this is needed a better solution that does not involve changing TLS would be to provision a key for use with a TLS preshared key ciphersuite. 2) TEAP server is separate architectural element from inner server So, in section 2 the document says that the TEAP server and inner server are separate architectural elements. However, in section 1 a design goal was avoiding MITM attacks. To meet that goal and to have an architecture where these servers are separate, a lot more clarity is required around what a MITM is and what is an acceptable intermediate. I also suspect significant security analysis will be required on this point. Let's start by coming up with a clear definition of what a MITM is for this protocol and work from there. Section 7.3 is inadequate. It does not clearly explain who is involved in the trust relationship. IN particular, does the peer need to trust the intermediate, or do the inner servers need to trust the intermediate or both? I think it depends for different vulnerabilities. In order to understand the architectural implications of this I'd like to ask those who want to support this architectural separation to go through every reference to MITM or man-in-the-middle or mutual authentication in the document. For each reference, answer the following questions: A) Who is negatively affected if the attack is possible or the security claim not maintained? (eap server, peer, intermediate, combination) B) for security claims especially those about inner methods. Which parties need to confirm the claim in order to avoid the harm identified in A above? I also think we need clarity around mutual authentication and what that means especially when looking at compositions. 3) Section 3.2: resistance to MITM attack The specification refers to inner methods providing resistance to man-in-the-middle attacks as if this is an RFC 3748 security claim. I assume this refers to the discussion in section 7.4 of RFC 3748. I don't think that claim is strong enough to provide secure composition of inner methods with anonymous ciphersuites. This is related and possibly a superset of the problems discussed in draft-hartman-emu-mutual-crypto-binding). Clearly checking the certificates is an inadequate solution for anonymous TLS ciphersuites. 4) Section 3.2.2: overly much detail on TLS workings I think that having something called a PAC which is really just a TLS session ticket is undesirable. I don't think we need a new name for TLS concepts we're reusing. I am concerned that we specify so much information about how TLS session resumption works. What if future versions of TLS change that? What if our spec is inconsistent with TLS? I recommend we remove most of the information about server and client TLS session resumption and fall back to full vs abbreviated handshakes. 5) Section 3.3.3: confused I'm confused when I read section 3.3.3 on protected negotiation indication. I don't understand when an intermediate result TLV is or is not required for the peer and server. Also, shouldn't the crypto binding TLV always be required here? 6) Section 3.3.3: please require peers reject EAP success without protected negotiation. I think it is very important that we mandate peers implementing TEAP MUST not treat an EAP success packet prior to the peer and server reaching protected result indication as successful. When peers do this (as many do with existing methods) it permits several bid-down attacks. Se the new text in one of the most recent channel bindings specs for an example. 7) Section 3.3.3: How does a peer do channel binding What should a peer do if it wishes to perform channel binding and server sends back a protected success? Request-action seems inefficient for this because the first message is the channel binding request coming from the client to server. 8) Examples with section 3.3 I think that section 3.3 could benefit from several examples: 1) A peer wishes to use a client certificate but wishes to hide its identity and thus use renegotiation. The server requests some inner method in the first phase 2 message before the client can start renegotiation at TLS. Show an example flow of how this works out and how the parties get back in sync. 2) A peer wishes to use an inner eap method even when the server is happy to offer success in the first message. Show how many result indications are required. 3) Show how channel bindings interact with the result indications. 8) Section 3.4: what is a peer ID? Section 3.4 needs a reference to where the concept of peer ID is defined. 9) Section 3.5: session ID First, you need a reference to what an EAP session ID is. second, do TLS implementations really make this value available? The text is unclear how this interacts with session resumption. I'd like to start by understanding whether we want the session ID to change for session resumption. I wonder if using something we've already standardized like the construction in section 3 of RFC 5929 would be a better choice for something that we can implement here? From hartmans@mit.edu Sun Mar 25 05:20: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 C61B921F8483 for ; Sun, 25 Mar 2012 05:20:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.503 X-Spam-Level: X-Spam-Status: No, score=-103.503 tagged_above=-999 required=5 tests=[AWL=-1.238, 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 R1PkENl7V93x for ; Sun, 25 Mar 2012 05:20:15 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 3F63021F847C for ; Sun, 25 Mar 2012 05:20:15 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (dhcp-9251.meeting.ietf.org [130.129.10.81]) (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 50BEF2023F; Sun, 25 Mar 2012 08:19:34 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id B16E34766; Sun, 25 Mar 2012 08:20:12 -0400 (EDT) From: Sam Hartman To: "Jim Schaad" References: <01fe01cd0683$43027790$c90766b0$@augustcellars.com> Date: Sun, 25 Mar 2012 08:20:12 -0400 In-Reply-To: <01fe01cd0683$43027790$c90766b0$@augustcellars.com> (Jim Schaad's message of "Tue, 20 Mar 2012 03:21:46 -0700") 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, zhangdacheng@huawei.com, emu@ietf.org Subject: Re: [Emu] Comments on draft-hartman-emu-mutual-crypto-bind 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: Sun, 25 Mar 2012 12:20:15 -0000 >>>>> "Jim" == Jim Schaad writes: Jim> 3. 3.2.3 or 3.2.2 - If you had a non EAP method, and it Jim> derived a key (just like a good EAP method). Is there any Jim> reason why you could not do the cryptographic binding? Other Jim> than it is not currently defined in one of the current Jim> tunneling methods. One could see that it could be defined as Jim> saying after you do this, then perform the same binding as any Jim> key deriving EAP method would do,. I guess. I don't know that key expert is really defined for the non-EAP inners in a well-defined manner. But yes, I think something like this would be a good idea, although I'm not sure it is practical when compared to just forcing EAP inner methods. Jim> 4. Section 3.2.4 - Item #4 - did you mean that it MUST prevent Jim> an attacker from downgrading the binding from mutual to just Jim> MSK-based? Also if the down grade occurs, do you still want to Jim> claim that it is still mutual if step 4 is downgraded? The Jim> current text implies this to me and that seems wrong. I'd love to discuss this with you in person if you're available. Jim> 5. Section 3.2.4 - last paragraph - the last sentence confuses Jim> the heck out of me. And everyone else; it's wrong:-) Will propose fixes to this and other comments. Jim> 6. Section 4.2 - I don't understand why things like doing Jim> channel binding require that a mutual authentication be Jim> present. I can understand a statement that the peer MUST have Jim> doing an adequate job of authenticating the server, but I am Jim> less clear why the server needs to have authenticated the Jim> client. Thus for example I think that cryptographic binding Jim> should be sufficient to deal with these cases. (i.e. Tunnel is Jim> authenticated to certificate and mutual auth is tied to the Jim> tunnel). I think there's an assumption that EAP always provides peer authentication (although sometimes to an anonymous identity, isn't semantics fun?) so mutual auth and server auth are synonyms. And draft-ietf-emu-chbind has required mutual auth since well before I started working on it. I didn't re-evaluate that requirement. Jim> Jim Jim> _______________________________________________ Emu mailing Jim> list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu From stefan.winter@restena.lu Tue Mar 27 02:25: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 1651121F8974 for ; Tue, 27 Mar 2012 02:25:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] 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 4DiRFoQYcpBs for ; Tue, 27 Mar 2012 02:25:43 -0700 (PDT) Received: from legolas.restena.lu (legolas.restena.lu [IPv6:2001:a18:1::34]) by ietfa.amsl.com (Postfix) with ESMTP id 6A38821F896E for ; Tue, 27 Mar 2012 02:25:43 -0700 (PDT) Received: from legolas.restena.lu (localhost [127.0.0.1]) by legolas.restena.lu (Postfix) with ESMTP id 228889DD13 for ; Tue, 27 Mar 2012 11:25:42 +0200 (CEST) Received: from [158.64.15.214] (214-15.vpn.restena.lu [158.64.15.214]) by legolas.restena.lu (Postfix) with ESMTPSA id 0C1769DD12 for ; Tue, 27 Mar 2012 11:25:42 +0200 (CEST) Message-ID: <4F718795.4080105@restena.lu> Date: Tue, 27 Mar 2012 11:25:41 +0200 From: Stefan Winter User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120313 Thunderbird/11.0 MIME-Version: 1.0 To: emu@ietf.org X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV Subject: [Emu] Suggestion for eap-tunnel-method on Phase 1 failure 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, 27 Mar 2012 09:25:44 -0000 Hello, during a discussion yesterday with some folks on EAP-PWD, we hit an issue which I think is also of relevance for TEAP. The issue is: assume an ongoing TEAP tunnel setup, the server sends a certificate, but it's not the one the client expects. With the current tunneled EAP methods (and also PWD in its current form), the client will recognise that it doesn't like the remote end and will stop communicating immediately. For the client, there is no negative side-effect to that. It can simply discard all EAP session state and that's it. The server side though only sees its last EAP-Request going out to the EAP peer, and will wait for a response. The response will never come, but the server needs to keep EAP session state for the conversation until it hits a (potentially very long) timeout. The underlying problem is that the EAP state machine doesn't finish, it just hangs mid-air. One end knows and discards, the other doesn't. This means the server will pile up useless state information. It also makes debugging client problems harder, because there is no final Reject going out to the client (when doing EAP over RADIUS, often Accepts and Rejects are logged, but intermediate Access-Challenges aren't). If there were a "bailout" trailer to end a failed server ID verification, things could get much cleaner in that respect. I'm not sure how exactly to encode it; maybe a EAP-Response with a TLS alert. Upon receiving the alert, the EAP server could craft its final EAP-Failure, send it out, and discard session state. Of course one argument is: if the ID verification failure is because you were connecting to a rogue server, you as a client shouldn't be so kind to help the rogue clean up his state. While that's true, verification failures are extremely often simply due to user misconfiguration (typo in expected server name, wrong CA box ticked) or subtle mis-configuration on the server side (not adding the TLS Web Server OID as Extended Usage, which the Windows supplicant chokes about). In these cases, it is quite helpful to make the server actively aware that something went wrong. I wonder if "something like that" could be considered for TEAP. In eduroam, we sort of miss it in PEAP at least. FreeRADIUS has a heuristic that "guesses" that it's an ID verification problem, but only does so in debug mode. And it being a heuristic, sometimes it's just wrong. So getting a clear "The client didn't like me" message to act upen would be a good thing IMHO. Greetings, Stefan Winter From hzhou@cisco.com Tue Mar 27 04:41: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 AD23721F89D5 for ; Tue, 27 Mar 2012 04:41:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.25 X-Spam-Level: X-Spam-Status: No, score=-10.25 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 NRchSpIOO3sF for ; Tue, 27 Mar 2012 04:41:54 -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 6CE3221F89D7 for ; Tue, 27 Mar 2012 04:41:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=hzhou@cisco.com; l=3628; q=dns/txt; s=iport; t=1332848513; x=1334058113; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=/+XgDXqce9a2fjoM0BZsKykP3HCdLhqYWJ6ZL9OlGHQ=; b=CGnP2hfS4RU9Sp72yHdQAQUdMEllbMt36OtcdUb5Anmjqf4Py70HQwW5 aXfLRqTfFB0G402+rRcZ8Pp8/jezJnOJYsGrxuF3sBD6BBjKYNXGOPI1c dzonw+0FC3bllnqJ8RPIrI9beg2OqOPc4yPSDm8kMs7dv074OlIPnFEtd g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAPWmcU+tJXG8/2dsb2JhbABFuD+BB4IJAQEBAwEBAQEPAScCATEQDQEIbSIBDQEBBAESIodjBQuaUZ8LBJEPBJVhjkWBaIMD X-IronPort-AV: E=Sophos;i="4.73,656,1325462400"; d="scan'208";a="69681976" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-2.cisco.com with ESMTP; 27 Mar 2012 11:41:53 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core2-1.cisco.com (8.14.3/8.14.3) with ESMTP id q2RBfqG2032515; Tue, 27 Mar 2012 11:41:52 GMT Received: from xmb-rcd-203.cisco.com ([72.163.62.210]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 27 Mar 2012 06:41:52 -0500 Received: from 10.21.104.219 ([10.21.104.219]) by XMB-RCD-203.cisco.com ([72.163.62.210]) via Exchange Front-End Server email.cisco.com ([128.107.191.32]) with Microsoft Exchange Server HTTP-DAV ; Tue, 27 Mar 2012 11:41:52 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Tue, 27 Mar 2012 07:41:45 -0400 From: Hao Zhou To: Stefan Winter , Message-ID: Thread-Topic: [Emu] Suggestion for eap-tunnel-method on Phase 1 failure Thread-Index: Ac0MDpYLSwZvBGRoakGNTsmNhSJqyg== In-Reply-To: <4F718795.4080105@restena.lu> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 27 Mar 2012 11:41:52.0622 (UTC) FILETIME=[9A9628E0:01CD0C0E] Subject: Re: [Emu] Suggestion for eap-tunnel-method on Phase 1 failure 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, 27 Mar 2012 11:41:55 -0000 Stefan: Actually this is already specified in TEAP. Section 3.6.1, states: If the TEAP peer detects an error at any point in the TLS layer, the TEAP peer should send a TEAP response encapsulating a TLS record containing the appropriate TLS alert message. The server may restart the conversation by sending an TEAP request packet encapsulating the TLS HelloRequest handshake message. The peer may allow the TEAP conversation to be restarted or it may terminate the conversation by sending an TEAP response with an zero-length message. So the peer should send back a TLS alert, like unknown_ca, certificate_unknown, bad_certificate etc to alert the server that the server certificate failed authentication. On 3/27/12 5:25 AM, "Stefan Winter" wrote: > Hello, > > during a discussion yesterday with some folks on EAP-PWD, we hit an > issue which I think is also of relevance for TEAP. > > The issue is: assume an ongoing TEAP tunnel setup, the server sends a > certificate, but it's not the one the client expects. > > With the current tunneled EAP methods (and also PWD in its current > form), the client will recognise that it doesn't like the remote end and > will stop communicating immediately. > > For the client, there is no negative side-effect to that. It can simply > discard all EAP session state and that's it. > > The server side though only sees its last EAP-Request going out to the > EAP peer, and will wait for a response. The response will never come, > but the server needs to keep EAP session state for the conversation > until it hits a (potentially very long) timeout. > > The underlying problem is that the EAP state machine doesn't finish, it > just hangs mid-air. One end knows and discards, the other doesn't. This > means the server will pile up useless state information. It also makes > debugging client problems harder, because there is no final Reject going > out to the client (when doing EAP over RADIUS, often Accepts and Rejects > are logged, but intermediate Access-Challenges aren't). > > If there were a "bailout" trailer to end a failed server ID > verification, things could get much cleaner in that respect. I'm not > sure how exactly to encode it; maybe a EAP-Response with a TLS alert. > Upon receiving the alert, the EAP server could craft its final > EAP-Failure, send it out, and discard session state. > > Of course one argument is: if the ID verification failure is because you > were connecting to a rogue server, you as a client shouldn't be so kind > to help the rogue clean up his state. While that's true, verification > failures are extremely often simply due to user misconfiguration (typo > in expected server name, wrong CA box ticked) or subtle > mis-configuration on the server side (not adding the TLS Web Server OID > as Extended Usage, which the Windows supplicant chokes about). In these > cases, it is quite helpful to make the server actively aware that > something went wrong. > > I wonder if "something like that" could be considered for TEAP. In > eduroam, we sort of miss it in PEAP at least. FreeRADIUS has a heuristic > that "guesses" that it's an ID verification problem, but only does so in > debug mode. And it being a heuristic, sometimes it's just wrong. So > getting a clear "The client didn't like me" message to act upen would be > a good thing IMHO. > > Greetings, > > Stefan Winter > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu From aland@deployingradius.com Tue Mar 27 08:07: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 77AB221F875C for ; Tue, 27 Mar 2012 08:07:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JFnZ8kiNISwI for ; Tue, 27 Mar 2012 08:07:22 -0700 (PDT) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id BF40221F8759 for ; Tue, 27 Mar 2012 08:07:21 -0700 (PDT) Received: from dhcp-5051.meeting.ietf.org (dhcp-5051.meeting.ietf.org [130.129.80.81]) by liberty.deployingradius.com (Postfix) with ESMTPSA id BE1A812340D7; Tue, 27 Mar 2012 17:06:50 +0200 (CEST) Message-ID: <4F71D787.40505@deployingradius.com> Date: Tue, 27 Mar 2012 17:06:47 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Stefan Winter References: <4F718795.4080105@restena.lu> In-Reply-To: <4F718795.4080105@restena.lu> 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] Suggestion for eap-tunnel-method on Phase 1 failure 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, 27 Mar 2012 15:07:23 -0000 Stefan Winter wrote: > If there were a "bailout" trailer to end a failed server ID > verification, things could get much cleaner in that respect. I'm not > sure how exactly to encode it; maybe a EAP-Response with a TLS alert. > Upon receiving the alert, the EAP server could craft its final > EAP-Failure, send it out, and discard session state. This may be more of a TLS issue. There's a provision for an alert in TLS (IIRC). The client could send an alert saying "closed connection". Sending any more information would mean leaking authentication data. I think it's useful to send a pro-active notification. The reason is that I've seen a lot of support questions asking "why is EAP broken". The typical assumption is that the RADIUS server is broken, because they're looking at the logs on the RADIUS server. Being able to prove that the client is responsible for the connection failure would be very beneficial. > I wonder if "something like that" could be considered for TEAP. In > eduroam, we sort of miss it in PEAP at least. FreeRADIUS has a heuristic > that "guesses" that it's an ID verification problem, but only does so in > debug mode. And it being a heuristic, sometimes it's just wrong. So > getting a clear "The client didn't like me" message to act upen would be > a good thing IMHO. That heuristic is simple: An EAP conversation is ongoing, and then pauses for ~10s. Alan DeKok. From stefan.winter@restena.lu Wed Mar 28 00:43: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 5C8CC21F861A for ; Wed, 28 Mar 2012 00:43:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.491 X-Spam-Level: X-Spam-Status: No, score=-2.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599] 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 tG+FgYVqCTVP for ; Wed, 28 Mar 2012 00:43:57 -0700 (PDT) Received: from legolas.restena.lu (legolas.restena.lu [IPv6:2001:a18:1::34]) by ietfa.amsl.com (Postfix) with ESMTP id D0A2F21F87EF for ; Wed, 28 Mar 2012 00:43:43 -0700 (PDT) Received: from legolas.restena.lu (localhost [127.0.0.1]) by legolas.restena.lu (Postfix) with ESMTP id C3AD2DAF87; Wed, 28 Mar 2012 09:43:41 +0200 (CEST) Received: from [IPv6:2001:df8::8:559a:4130:567c:d31c] (unknown [IPv6:2001:df8:0:8:559a:4130:567c:d31c]) by legolas.restena.lu (Postfix) with ESMTPSA id A45B79DD11; Wed, 28 Mar 2012 09:43:41 +0200 (CEST) Message-ID: <4F72C12C.7000708@restena.lu> Date: Wed, 28 Mar 2012 09:43:40 +0200 From: Stefan Winter User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120313 Thunderbird/11.0 MIME-Version: 1.0 To: Hao Zhou References: In-Reply-To: X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV Cc: emu@ietf.org Subject: Re: [Emu] Suggestion for eap-tunnel-method on Phase 1 failure 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, 28 Mar 2012 07:43:58 -0000 Hi, > Stefan: > > Actually this is already specified in TEAP. Section 3.6.1, states: > > If the TEAP peer detects an error at any point in the TLS layer, the > TEAP peer should send a TEAP response encapsulating a TLS record > containing the appropriate TLS alert message. The server may restart > the conversation by sending an TEAP request packet encapsulating the > TLS HelloRequest handshake message. The peer may allow the TEAP > conversation to be restarted or it may terminate the conversation by > sending an TEAP response with an zero-length message. > > So the peer should send back a TLS alert, like unknown_ca, > certificate_unknown, bad_certificate etc to alert the server that the server > certificate failed authentication. D'oh, I only looked in 3.2 "Phase 1" and overlooked that text further down. Sorry for the noise... and a +1 that this is the right response to send! Stefan > > > On 3/27/12 5:25 AM, "Stefan Winter" wrote: > >> Hello, >> >> during a discussion yesterday with some folks on EAP-PWD, we hit an >> issue which I think is also of relevance for TEAP. >> >> The issue is: assume an ongoing TEAP tunnel setup, the server sends a >> certificate, but it's not the one the client expects. >> >> With the current tunneled EAP methods (and also PWD in its current >> form), the client will recognise that it doesn't like the remote end and >> will stop communicating immediately. >> >> For the client, there is no negative side-effect to that. It can simply >> discard all EAP session state and that's it. >> >> The server side though only sees its last EAP-Request going out to the >> EAP peer, and will wait for a response. The response will never come, >> but the server needs to keep EAP session state for the conversation >> until it hits a (potentially very long) timeout. >> >> The underlying problem is that the EAP state machine doesn't finish, it >> just hangs mid-air. One end knows and discards, the other doesn't. This >> means the server will pile up useless state information. It also makes >> debugging client problems harder, because there is no final Reject going >> out to the client (when doing EAP over RADIUS, often Accepts and Rejects >> are logged, but intermediate Access-Challenges aren't). >> >> If there were a "bailout" trailer to end a failed server ID >> verification, things could get much cleaner in that respect. I'm not >> sure how exactly to encode it; maybe a EAP-Response with a TLS alert. >> Upon receiving the alert, the EAP server could craft its final >> EAP-Failure, send it out, and discard session state. >> >> Of course one argument is: if the ID verification failure is because you >> were connecting to a rogue server, you as a client shouldn't be so kind >> to help the rogue clean up his state. While that's true, verification >> failures are extremely often simply due to user misconfiguration (typo >> in expected server name, wrong CA box ticked) or subtle >> mis-configuration on the server side (not adding the TLS Web Server OID >> as Extended Usage, which the Windows supplicant chokes about). In these >> cases, it is quite helpful to make the server actively aware that >> something went wrong. >> >> I wonder if "something like that" could be considered for TEAP. In >> eduroam, we sort of miss it in PEAP at least. FreeRADIUS has a heuristic >> that "guesses" that it's an ID verification problem, but only does so in >> debug mode. And it being a heuristic, sometimes it's just wrong. So >> getting a clear "The client didn't like me" message to act upen would be >> a good thing IMHO. >> >> Greetings, >> >> Stefan Winter >> _______________________________________________ >> Emu mailing list >> Emu@ietf.org >> https://www.ietf.org/mailman/listinfo/emu From hzhou@cisco.com Wed Mar 28 01:06:20 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 CD19421F88CB for ; Wed, 28 Mar 2012 01:06:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.366 X-Spam-Level: X-Spam-Status: No, score=-10.366 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 BI5CJ1bUo+hO for ; Wed, 28 Mar 2012 01:06:19 -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 7626A21F88B7 for ; Wed, 28 Mar 2012 01:06:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=hzhou@cisco.com; l=8058; q=dns/txt; s=iport; t=1332921979; x=1334131579; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=pklNOh7dAh2kWzXVS1cI4K6cxr20j/PQu+cBamVgLKo=; b=OzyjBe2Y7tAWjkjBxJUc7Knx2wmRht8MTOnOA6iC5fWqdJ9rc/K64Bcs VF6R24T9tHPkGpoGhQcxwakGV5XqMmsdpw7lkg9EdjltLwfeyhioqsKUG j7737LQV19s06RvAGZwFX/R0Z3qeQjlF2hTiTQWe3TXc3Oi5aNzeSE5mC 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EADnFck+tJXG+/2dsb2JhbAA8CQ64X4EHggkBAQEDAQEBAQ8BJwIBKwYEDA0BCBIjOCIOAQEEARIbB4djBQubKJ8PBIpvhiMElWGORYFogjBT X-IronPort-AV: E=Sophos;i="4.73,661,1325462400"; d="scan'208";a="70018505" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-3.cisco.com with ESMTP; 28 Mar 2012 08:06:19 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id q2S86Ixd026505; Wed, 28 Mar 2012 08:06:18 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); Wed, 28 Mar 2012 03:06:18 -0500 Received: from 10.81.8.118 ([10.81.8.118]) 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 ; Wed, 28 Mar 2012 08:06:17 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Wed, 28 Mar 2012 04:06:17 -0400 From: Hao Zhou To: Sam Hartman , Message-ID: Thread-Topic: [Emu] Review of draft-ietf-emu-eap-tunnel-method Thread-Index: Ac0MuabEOSTXeP+1FkO2R8YmncIEMw== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 28 Mar 2012 08:06:18.0673 (UTC) FILETIME=[A7C3EA10:01CD0CB9] Subject: Re: [Emu] Review of draft-ietf-emu-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, 28 Mar 2012 08:06:21 -0000 Sam: Thanks for the detailed review and comments. After you, Joe and I got together and discussed your comments, here are what we plan to address these comments, inline below. On 3/25/12 7:50 AM, "Sam Hartman" wrote: > > > 1) TEAP extends TLS RFC 5077 > > In section 2, TEAP discusses using phase 2 TLVs to include a TLS session > ticket and an associated secret key. > RFc 5077 only permits session tickets to be sent using the session > ticket message. I believe that this is an extension to TLS that would > need to go through the TLS working group. > > My preference is to remove TLS tickets sent via a manner other than the > session ticket handshake message. > If support for this is needed a better solution that does not involve > changing TLS would be to provision a key for use with a TLS preshared > key ciphersuite. > [HZ] RFC5077 does have this paragraph in Section 3, which allows another specification to define alternative mechanism to distribute the ticket: " Other specifications can take advantage of the session tickets, perhaps specifying alternative means for distribution or selection. For example, a separate specification may describe an alternate way to distribute a ticket and use the TLS extension in this document to resume the session. This behavior is beyond the scope of the document and would need to be described in a separate specification." Based on that and the fact this alternative mechanism is optional to implement, Sam is ok with the current draft defining this alternative mechanism. Probably worth describing the benefits of this alternative mechanism. > 2) TEAP server is separate architectural element from inner server > > So, in section 2 the document says that the TEAP server and inner > server are separate architectural elements. > However, in section 1 a design goal was avoiding MITM attacks. > > To meet that goal and to have an architecture where these servers are > separate, a lot more clarity is required around what a MITM is and what > is an acceptable intermediate. > I also suspect significant security analysis will be required on this > point. > > Let's start by coming up with a clear definition of what a MITM is for > this protocol and work from there. > Section 7.3 is inadequate. > It does not clearly explain who is involved in the trust relationship. > IN particular, does the peer need to trust the intermediate, or do the > inner servers need to trust the intermediate or both? > > I think it depends for different vulnerabilities. > > In order to understand the architectural implications of this I'd like > to ask those who want to support this architectural separation to go > through every reference to MITM or man-in-the-middle or mutual > authentication in the document. For each reference, answer the following > questions: > > > > A) Who is negatively affected if the attack is possible or the security > claim not maintained? (eap server, peer, intermediate, combination) > > B) for security claims especially those about inner methods. Which > parties need to confirm the claim in order to avoid the harm identified > in A above? > > > I also think we need clarity around mutual authentication and what that > means especially when looking at compositions. > [HZ] We discussed at length the various degrees of mutual authentication security claim as well as resistance to MITM attacks, and agree to have a conference all with Jim Schaad within next couple of weeks to explore and add more descriptions and security considerations to the draft. > > 3) Section 3.2: resistance to MITM attack > > The specification refers to inner methods providing resistance to > man-in-the-middle attacks as if this is an RFC 3748 security claim. > I assume this refers to the discussion in section 7.4 of RFC 3748. > I don't think that claim is strong enough to provide secure composition > of inner methods with anonymous ciphersuites. > This is related and possibly a superset of the problems discussed in > draft-hartman-emu-mutual-crypto-binding). > Clearly checking the certificates is an inadequate solution for > anonymous TLS ciphersuites. [HZ] See above. > 4) Section 3.2.2: overly much detail on TLS workings > > I think that having something called a PAC which is really just a TLS > session ticket is undesirable. I don't think we need a new name for TLS > concepts we're reusing. > I am concerned that we specify so much information about how TLS > session resumption works. What if future versions of TLS change that? > What if our spec is inconsistent with TLS? > > I recommend we remove most of the information about server and client > TLS session resumption and fall back to full vs abbreviated handshakes. > [HZ] We agreed to take look and minimize the TLS inner working description. > > 5) Section 3.3.3: confused > > I'm confused when I read section 3.3.3 on protected negotiation > indication. I don't understand when an intermediate result TLV is or is > not required for the peer and server. > Also, shouldn't the crypto binding TLV always be required here? > [HZ] We will clarify in Section 3.3.3. > > 6) Section 3.3.3: please require peers reject EAP success without > protected negotiation. > > I think it is very important that we mandate peers implementing TEAP > MUST not treat an EAP success packet prior to the peer and server > reaching protected result indication as successful. > When peers do this (as many do with existing methods) it permits several > bid-down attacks. > Se the new text in one of the most recent channel bindings specs for an > example. > [HZ] We will incorporate this suggestion. > 7) Section 3.3.3: How does a peer do channel binding > > What should a peer do if it wishes to perform channel binding and server > sends back a protected success? > > Request-action seems inefficient for this because the first message is > the channel binding request coming from the client to server. > [HZ] Peer can use Request-Action TLV with code 1 - Process TLV along with a Channel-Binding TLV to request channel binding. Will add some descriptions. > > 8) Examples with section 3.3 > > I think that section 3.3 could benefit from several examples: > > > 1) A peer wishes to use a client certificate but wishes to hide its > identity and thus use renegotiation. The server requests some inner > method in the first phase 2 message before the client can start > renegotiation at TLS. > Show an example flow of how this works out and how the parties get back > in sync. > > 2) A peer wishes to use an inner eap method even when the server is > happy to offer success in the first message. Show how many result > indications are required. > > 3) Show how channel bindings interact with the result indications. > [HZ] Agreed that these example would help and will add them in the next rev. > 8) Section 3.4: what is a peer ID? > > Section 3.4 needs a reference to where the concept of peer ID is > defined. > [HZ] Will add reference to RFC5247 EAP keying framework. > 9) Section 3.5: session ID > > First, you need a reference to what an EAP session ID is. > > second, do TLS implementations really make this value available? > > The text is unclear how this interacts with session resumption. I'd > like to start by understanding whether we want the session ID to change > for session resumption. > > I wonder if using something we've already standardized like the > construction in section 3 of RFC 5929 would be a better choice for > something that we can implement here? [HZ] Agreed that we probably need something that is immune for MITM to fabricate. Will look into RFC5929 to see if it can be used. > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu From jsalowey@cisco.com Wed Mar 28 07:46: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 C3BCB21E821C for ; Wed, 28 Mar 2012 07:46:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.532 X-Spam-Level: X-Spam-Status: No, score=-108.532 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067, 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 kfMPckirhmH8 for ; Wed, 28 Mar 2012 07:46:19 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id EE92621E812F for ; Wed, 28 Mar 2012 07:46:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jsalowey@cisco.com; l=89; q=dns/txt; s=iport; t=1332945978; x=1334155578; h=subject:from:message-id:date:to: content-transfer-encoding:mime-version; bh=WRQGFfVbUg40d/n8qFGmbnAuKSw4KbOM0aoTijd/bkQ=; b=Ozo9EOvWQrfxF3Z3QNtY75L1zg9OguCoDM4NdYhIrTwEXHeCmMn6ndT1 7jqvfrQtpJB+hb9UGFI4Bq+Zrggc/oMEPVQG2dEfcU1OlkKb3XWbr8Xvq uE+XhhP7okN2jV1k2uKI4lO49Ind79t1gsVb4UjNcouAJ4lL/EvGPMknG U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqMPABcjc0+rRDoG/2dsb2JhbABDig+tVQOBDQKBB4IFBgEEEgEnUQGBDxcBBDWFJgcBgigRAZ18gSeXNIsogkaCQWMElWGORYFogmk X-IronPort-AV: E=Sophos;i="4.73,661,1325462400"; d="scan'208";a="34918287" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 28 Mar 2012 14:46:18 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q2SEkIjL009252 for ; Wed, 28 Mar 2012 14:46:18 GMT Received: from xmb-sjc-213.amer.cisco.com ([171.70.151.153]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 28 Mar 2012 07:46:18 -0700 Received: from 72.163.43.39 ([72.163.43.39]) by xmb-sjc-213.amer.cisco.com ([171.70.151.153]) with Microsoft Exchange Server HTTP-DAV ; Wed, 28 Mar 2012 14:46:17 +0000 From: "Joseph Salowey (jsalowey)" Content-Type: text/plain; charset="us-ascii" Thread-Topic: Slides please Thread-Index: Ac0M8Yg3gnPHdHPQSsuI4hW348gtmg== Message-ID: <8F33BF63-A761-467A-B71E-509446E102AD@cisco.com> Date: Wed, 28 Mar 2012 16:46:17 +0200 To: Content-Transfer-Encoding: 7bit MIME-Version: 1.0 (1.0) X-OriginalArrivalTime: 28 Mar 2012 14:46:18.0429 (UTC) FILETIME=[88BC0ED0:01CD0CF1] Subject: [Emu] Slides please 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, 28 Mar 2012 14:46:19 -0000 If you are presenting slides tomorrow please send them to the chairs. Thanks, Joe From iesg-secretary@ietf.org Thu Mar 29 07:11: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 5DF1021E812E; Thu, 29 Mar 2012 07:11:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.564 X-Spam-Level: X-Spam-Status: No, score=-102.564 tagged_above=-999 required=5 tests=[AWL=0.035, 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 6Pkw0v11DKSZ; Thu, 29 Mar 2012 07:11:26 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D618F21E8092; Thu, 29 Mar 2012 07:11:26 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120329141126.23894.48187.idtracker@ietfa.amsl.com> Date: Thu, 29 Mar 2012 07:11:26 -0700 Cc: emu@ietf.org Subject: [Emu] Last Call: (Channel Binding Support for EAP Methods) to Proposed Standard X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 14:11:27 -0000 The IESG has received a request from the EAP Method Update WG (emu) to consider the following document: - 'Channel Binding Support for EAP Methods' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-04-12. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines how to implement channel bindings for Extensible Authentication Protocol (EAP) methods to address the lying NAS as well as the lying provider problem. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-emu-chbind/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-emu-chbind/ballot/ No IPR declarations have been submitted directly on this I-D. From jimsch@augustcellars.com Fri Mar 30 00:35: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 A372B21F8786 for ; Fri, 30 Mar 2012 00:35:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.11 X-Spam-Level: X-Spam-Status: No, score=-2.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, 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 ePdGJdeXCoWn for ; Fri, 30 Mar 2012 00:35:07 -0700 (PDT) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) by ietfa.amsl.com (Postfix) with ESMTP id 9C2D021F8611 for ; Fri, 30 Mar 2012 00:34:58 -0700 (PDT) Received: from Tobias (dhcp-10a6.meeting.ietf.org [130.129.16.166]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id A704238EF4; Fri, 30 Mar 2012 00:34:57 -0700 (PDT) From: "Jim Schaad" To: Date: Fri, 30 Mar 2012 09:34:03 +0200 Message-ID: <039301cd0e47$7d7503e0$785f0ba0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: Ac0OR0cl7mX0lVlfRWyk8JUrmizplg== X-Mailman-Approved-At: Sat, 31 Mar 2012 09:50:50 -0700 Cc: emu@ietf.org Subject: [Emu] Multiple Request Action Items 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, 30 Mar 2012 07:35:07 -0000 In the presentation you stated that the plan was to make the TLVs that are requested become a sub TLV of the request TLV items. If that is true, then should it be possible to allow for multiple request TLVs to be present in a message. Thus one could say: Please do A - and if not then fail authentication Please do B - and if not then succeed authentication Jim