From secmech-bounces@lists.ietf.org Tue Aug 02 03:44:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzrSE-0002fZ-VQ; Tue, 02 Aug 2005 03:44:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzrSA-0002c3-An for secmech@megatron.ietf.org; Tue, 02 Aug 2005 03:44:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27413 for ; Tue, 2 Aug 2005 03:44:42 -0400 (EDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzryY-0000Er-DX for secmech@ietf.org; Tue, 02 Aug 2005 04:18:15 -0400 Received: from centralmail2brm.Central.Sun.COM (centralmail2brm.central.sun.com [129.147.62.14]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j727ier3029790 for ; Tue, 2 Aug 2005 01:44:40 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id j727ieq2023674 for ; Tue, 2 Aug 2005 01:44:40 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id j727ieJH013854 for ; Tue, 2 Aug 2005 02:44:40 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id j727idgv013853 for secmech@ietf.org; Tue, 2 Aug 2005 02:44:39 -0500 (CDT) Date: Tue, 2 Aug 2005 02:44:39 -0500 From: Nicolas Williams To: secmech@ietf.org Message-ID: <20050802074439.GC12031@binky.Central.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: Subject: [SECMECH] Presentations for today's BoF X-BeenThere: secmech@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security mechanisms BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: secmech-bounces@lists.ietf.org Errors-To: secmech-bounces@lists.ietf.org Joe's presentation: http://mediacast.sun.com/share/nico/IETF-GUAM.pdf Jari's: http://mediacast.sun.com/share/nico/ietf63_secmech_eapmeths.ppt Mine: http://mediacast.sun.com/share/nico/GUAM-short.pdf Nico -- _______________________________________________ SECMECH mailing list SECMECH@lists.ietf.org https://www1.ietf.org/mailman/listinfo/secmech From secmech-bounces@lists.ietf.org Tue Aug 02 03:46:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzrUG-00048n-MB; Tue, 02 Aug 2005 03:46:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzrUF-00047f-05 for secmech@megatron.ietf.org; Tue, 02 Aug 2005 03:46:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27596 for ; Tue, 2 Aug 2005 03:46:52 -0400 (EDT) Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dzs0f-0000MT-99 for secmech@ietf.org; Tue, 02 Aug 2005 04:20:26 -0400 Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 26A7789832; Tue, 2 Aug 2005 10:46:28 +0300 (EEST) Message-ID: <42EF24E0.5000309@piuha.net> Date: Tue, 02 Aug 2005 10:46:40 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nicolas Williams Subject: Re: [SECMECH] Presentations for today's BoF References: <20050802074439.GC12031@binky.Central.Sun.COM> In-Reply-To: <20050802074439.GC12031@binky.Central.Sun.COM> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit Cc: secmech@ietf.org X-BeenThere: secmech@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security mechanisms BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: secmech-bounces@lists.ietf.org Errors-To: secmech-bounces@lists.ietf.org Nicolas Williams wrote: >Jari's: > >http://mediacast.sun.com/share/nico/ietf63_secmech_eapmeths.ppt > > Slightly updated in http://www.arkko.com/publications/eap/ietf-63/ietf63_secmech_eapmeths.ppt --Jari _______________________________________________ SECMECH mailing list SECMECH@lists.ietf.org https://www1.ietf.org/mailman/listinfo/secmech From secmech-bounces@lists.ietf.org Tue Aug 02 06:07:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dztg4-0003rm-Ac; Tue, 02 Aug 2005 06:07:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dztg3-0003rh-1n for secmech@megatron.ietf.org; Tue, 02 Aug 2005 06:07:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04600 for ; Tue, 2 Aug 2005 06:07:12 -0400 (EDT) From: Pasi.Eronen@nokia.com Received: from mgw-ext04.nokia.com ([131.228.20.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzuCV-0006Wp-Ej for secmech@ietf.org; Tue, 02 Aug 2005 06:40:47 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j72A14hZ032393 for ; Tue, 2 Aug 2005 13:01:05 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 Aug 2005 13:07:09 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 Aug 2005 13:07:09 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 2 Aug 2005 13:07:09 +0300 Message-ID: Thread-Topic: Continuing my rant about EAP vs GSS-API... Thread-Index: AcWXSfE8CSNIJ8A1R7ChkqJp2e5DRw== To: X-OriginalArrivalTime: 02 Aug 2005 10:07:09.0246 (UTC) FILETIME=[F1A50DE0:01C59749] X-Spam-Score: 0.3 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: quoted-printable Cc: Subject: [SECMECH] Continuing my rant about EAP vs GSS-API... X-BeenThere: secmech@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security mechanisms BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: secmech-bounces@lists.ietf.org Errors-To: secmech-bounces@lists.ietf.org (Continuing and clarifying my comment in the BoF today...) GSS-API establishes a "security context" between a client and a server. Depending on the GSS-API mechanism, establishing the security context may use the help of a "trusted third party", either off-line (like CA) or on-line (Kerberos KDC). EAP includes only the communication between the client and "trusted third party" (EAP server), but it does not establish a security context between the client and the service. But that's exactly what people interested in using a security framework (like ISMS or 802.11) would like to do! So just EAP alone is not really a framework you can compare with GSS-API. To make this comparison more accurate, we _have_ to consider the real "EAP+AAA" framework, instead of claiming that they're totally separate. Of course, it's still possible to e.g. analyze an EAP mechanism without considering AAA. The result of this analysis could be e.g. that the mechanism has certain security properties. But from the point of view of applications, what really matters is the security properties of the whole framework (or this EAP mechanism when used within this framework). These don't trivially follow from properties=20 of the building blocks (just like AES being secure doesn't make all EAP methods that use AES secure). In particular, an application like ISMS is really concerned with=20 "ok, I have this security context that I'll use for protecting my application-specific communication. What properties does this context have? Who is the other party I'm sharing this context (and keys contained in it) with?" An analysis of an EAP mechanism, like EAP-TLS, can answer the question "who is the other party I'm sharing the EAP-SA with" (just look at the TLS server certificate). But EAP alone cannot answer the application's real question "who is the other party I'm sharing this context with". Or in other words, GSS-API mechanisms (that do mutual authentication) do mutual authentication (and set up a security context/association)=20 between the client and the service (application endpoint). EAP=20 mechanisms do mutual authentication between the client and the=20 EAP server; and that doesn't automatically mean mutual authentication between the client and the service/application endpoint. This difference is IMHO not an insignificant minor detail, and=20 needs to be taken into account when talking about "bridging" EAP and GSS-API mechanisms, or designing mechanisms that can=20 be used in both frameworks, etc. I'm not saying this deficiency in the EAP+AAA framework is serious problem in all cases. In some environments the authentication requirements in different directions are quite different. For instance, in 802.11 network access the client's/user's identity=20 is usually much more important; for the access point/network side, it=20 may be enough to verify that "this is someone the TTP (EAP server) trusts". This is essentially what EAP+AAA framework today does.=20 Something like ISMS might have a similar situation, authenticating=20 the identity of the SNMP manager might be much more important than=20 the SNMP manager... Best regards, Pasi _______________________________________________ SECMECH mailing list SECMECH@lists.ietf.org https://www1.ietf.org/mailman/listinfo/secmech From secmech-bounces@lists.ietf.org Thu Aug 04 03:28:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0a9t-0004Q4-6x; Thu, 04 Aug 2005 03:28:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0a9r-0004Nj-BW for secmech@megatron.ietf.org; Thu, 04 Aug 2005 03:28:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07486 for ; Thu, 4 Aug 2005 03:28:49 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0agh-0001pp-E1 for secmech@ietf.org; Thu, 04 Aug 2005 04:02:47 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 04 Aug 2005 00:28:39 -0700 X-IronPort-AV: i="3.95,166,1120460400"; d="scan'208"; a="328864260:sNHT29343776" Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j747SY0J001129; Thu, 4 Aug 2005 00:28:34 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 4 Aug 2005 00:33:15 -0700 Message-ID: <7210B31550AC934A8637D6619739CE6905A0DD92@e2k-sea-xch2.sea-alpha.cisco.com> Thread-Topic: Summary of IETF63 secmech BOF Thread-Index: AcWYxiBnZfcMIZFrSQycZGFlV0Dksg== From: "Salowey, Joe" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: quoted-printable Cc: Russ Housley Subject: [SECMECH] Summary of IETF63 secmech BOF X-BeenThere: secmech@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security mechanisms BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: secmech-bounces@lists.ietf.org Errors-To: secmech-bounces@lists.ietf.org The secmech BOF met on Tuesday morning. We had discussion on the standardization of EAP methods and on unifying GSS-API, SASL and EAP mechanism development. =20 We had a discussion on the status and history of EAP method development, which has largely happened outside the IETF. This may lead to a situation where network access interfaces are less open and interoperable than perhaps desired. A concern was also raised that if standards work is started in this space, it may not be good to gate this on EAP, GSS-API, and SASL mechanism development unification. A small set (1-3) of EAP mechanism types should be selected for standardization based on requirements from IETF and external SDO's. The discussion of EAP, SASL, and GSS-API mechanism development unification. There was discussion on several approaches to unifying mechanism development. There was some discussion on how closely EAP needs to be tied in with AAA requirements. There was discussion of bridging vs. alternate approaches to mechanism development. There was no clear preference so more discussion on the list is necessary. =20 The basic results of the BOF were as follows: 1. There was rough consensus that EAP method standardization is important 2. Most people didn't care where the work was done, but there was a preference for doing the work in the security area. 3. There was rough consensus that unifying authentication mechanism development would be good. 4. The current proposals for mechanism development unification need to be more concrete. 5. There was light interest in actually authoring and review drafts in the unifying authentication mechanism area.=20 Next Steps / Action Items -------------------------- 1. Collect the requirements we have for EAP methods and select a (1 - 3) types of mechanisms to support. 2. Better define the GUAM proposal and see if there is more interest in a more focused proposal.=20 3. Submit a charter for a working group if enough document authors and reviewers can be found in the respective areas. =20 _______________________________________________ SECMECH mailing list SECMECH@lists.ietf.org https://www1.ietf.org/mailman/listinfo/secmech From secmech-bounces@lists.ietf.org Thu Aug 04 04:40:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0bHJ-0005zm-95; Thu, 04 Aug 2005 04:40:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0bHG-0005zh-T1 for secmech@megatron.ietf.org; Thu, 04 Aug 2005 04:40:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12404 for ; Thu, 4 Aug 2005 04:40:32 -0400 (EDT) Received: from carrierpigeon.cs.umd.edu ([128.8.129.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0bo5-0005TU-30 for secmech@ietf.org; Thu, 04 Aug 2005 05:14:32 -0400 Received: from ismene (ismene.cs.umd.edu [128.8.126.62]) by carrierpigeon.cs.umd.edu (8.12.10/8.12.5) with ESMTP id j748eIfD005811 for ; Thu, 4 Aug 2005 04:40:18 -0400 (EDT) Date: Thu, 4 Aug 2005 04:35:19 -0400 (EDT) From: Charles Clancy X-X-Sender: clancy@ismene To: secmech@ietf.org Subject: Re: [SECMECH] Summary of IETF63 secmech BOF In-Reply-To: <7210B31550AC934A8637D6619739CE6905A0DD92@e2k-sea-xch2.sea-alpha.cisco.com> Message-ID: References: <7210B31550AC934A8637D6619739CE6905A0DD92@e2k-sea-xch2.sea-alpha.cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: X-BeenThere: secmech@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security mechanisms BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: secmech-bounces@lists.ietf.org Errors-To: secmech-bounces@lists.ietf.org > Next Steps / Action Items > -------------------------- > 1. Collect the requirements we have for EAP methods and select a (1 - 3) > types of mechanisms to support. I'd suggest the so-called "Housley Criteria", as documented by section 6.2 of draft-ietf-eap-keying, and expanded on in section 4 of draft-housley-aaa-key-mgmt as a good set of technical requirements. These are a superset of the WLAN EAP requirements (RFC 4017). These include: * Extensible ciphersuite * Establish strong, fresh session keys * Maintain algorithm independence * Include replay detection mechanism * Authenticate all parties * Maintain confidentiality of authenticator * No plaintext passwords * Perform client and NAS authorization * Maintain confidentiality of session keys * Confirm selection of "best" ciphersuite * Uniquely name session keys * Compromise of a single NAS cannot compromise any other part of the system, including session keys and long-term keys * Bind key to appropriate context As for methods to select, I proposed EAP-PAX (draft-clancy-eap-pax) and EAP-TLS (RFC 2716). EAP-PAX is a non-tunneled, shared-key method supporting key management, provisioning, and identity protection. It satisfies all the aforementioned requirements. EAP-TLS would require some minor updates to meet the requirements, but would make a solid public-key standards-track method. [ t. charles clancy ]--[ tcc@umd.edu ]--[ www.cs.umd.edu/~clancy ] [ computer science ]-----[ university of maryland | college park ] _______________________________________________ SECMECH mailing list SECMECH@lists.ietf.org https://www1.ietf.org/mailman/listinfo/secmech From secmech-bounces@lists.ietf.org Tue Aug 09 02:53:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2NzJ-0007qX-8I; Tue, 09 Aug 2005 02:53:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2NzG-0007nu-VB for secmech@megatron.ietf.org; Tue, 09 Aug 2005 02:53:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15475 for ; Tue, 9 Aug 2005 02:53:19 -0400 (EDT) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2OX4-0004Q2-Jc for secmech@ietf.org; Tue, 09 Aug 2005 03:28:20 -0400 Received: from centralmail2brm.Central.Sun.COM (centralmail2brm.central.sun.com [129.147.62.14]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j796rHvU015793 for ; Tue, 9 Aug 2005 00:53:17 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id j796rGLE006531 for ; Tue, 9 Aug 2005 00:53:17 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id j796rGfv019229; Tue, 9 Aug 2005 01:53:16 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id j796rFTS019228; Tue, 9 Aug 2005 01:53:15 -0500 (CDT) Date: Tue, 9 Aug 2005 01:53:15 -0500 From: Nicolas Williams To: Pasi.Eronen@nokia.com Subject: Re: [SECMECH] Continuing my rant about EAP vs GSS-API... Message-ID: <20050809065315.GR18081@binky.Central.Sun.COM> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Cc: secmech@ietf.org X-BeenThere: secmech@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security mechanisms BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: secmech-bounces@lists.ietf.org Errors-To: secmech-bounces@lists.ietf.org On Tue, Aug 02, 2005 at 01:07:09PM +0300, Pasi.Eronen@nokia.com wrote: > (Continuing and clarifying my comment in the BoF today...) Thanks! > GSS-API establishes a "security context" between a client and a > server. Depending on the GSS-API mechanism, establishing the security > context may use the help of a "trusted third party", either off-line > (like CA) or on-line (Kerberos KDC). The following is an aside. The meat of my reply is further below, though I can summarize it thusly: we're in violent agreement. The GSS-API is, or, rather, has been strictly a two-party framework. But the extensions to the GSS-API being pursued at the KITTEN WG seem to allow for modelling the typical three-party EAP situation. Joe and I have discussed this many a time, here is an outline: - The EAP peer is as to the GSS initiator - Depending on the mechanism the GSS acceptor may be as to the EAP server or as to a NAS, with the GSS mechanism being required to bridge the gap when the GSS acceptor is as to a NAS - Either way there is a third party that can be named and bound into the exchange using GSS naming extensions - EAP key derivation is as to the KITTEN GSS_Pseudo_random() extension - ... > EAP includes only the communication between the client and "trusted > third party" (EAP server), but it does not establish a security > context between the client and the service. But that's exactly what > people interested in using a security framework (like ISMS or 802.11) > would like to do! So just EAP alone is not really a framework you can > compare with GSS-API. I believe that some EAP methods can provide enough facilities to build GSS mechanisms out of them, much like Kerberos V. See below. > To make this comparison more accurate, we _have_ to consider the real > "EAP+AAA" framework, instead of claiming that they're totally ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > separate. ^^^^^^^^ Which neither Joe nor I claim. > Of course, it's still possible to e.g. analyze an EAP mechanism > without considering AAA. The result of this analysis could be e.g. > that the mechanism has certain security properties. But from the > point of view of applications, what really matters is the security > properties of the whole framework (or this EAP mechanism when used > within this framework). These don't trivially follow from properties > of the building blocks (just like AES being secure doesn't make all > EAP methods that use AES secure). Just to be clear, neither Joe nor I nor anyone else (to my knowledge) have put forward any concrete proposal for GUAM that haphazardly mixes off-the-shelf components and claims to have properties that are the sum of the such components. > In particular, an application like ISMS is really concerned with > "ok, I have this security context that I'll use for protecting my > application-specific communication. What properties does this context > have? Who is the other party I'm sharing this context (and keys > contained in it) with?" Right. This makes the GSS-API, SASL, TLS, all good matches for ISMS. The GSS-API and DTLS are better matches if datagram-type transports are desired for ISMS. Unfortunately the GSS-API and [D]TLS have disjoint sets of mechanisms available, thus ISMS' quandary, thus GUAM, thus SECMECH. While we're at fixing the multi-framework mechanism set disjointness problem we notice that EAP mechanisms (decent ones anyways) have fundamental properties that are also required of GSS-API and SASL mechanisms (see below). Thus the GUAM proposal encompasses EAP as well as the GSS-API. > An analysis of an EAP mechanism, like EAP-TLS, can answer the question > "who is the other party I'm sharing the EAP-SA with" (just look at the > TLS server certificate). But EAP alone cannot answer the > application's real question "who is the other party I'm sharing this > context with". Neither can the GSS-API! This is the mechanisms' duty. The GSS-API does come with, well, an API, and this API does allow for such questions to be asked and answered, but note that the answer is allowed to be "dunno," as in GSS_C_NT_ANONYMOUS. Presumably EAP methods can provide mutual authentication, user<->server, user->server + server->NAS + EAP channel binding, ... > Or in other words, GSS-API mechanisms (that do mutual authentication) > do mutual authentication (and set up a security context/association) > between the client and the service (application endpoint). EAP > mechanisms do mutual authentication between the client and the > EAP server; and that doesn't automatically mean mutual authentication > between the client and the service/application endpoint. You've missed the point... Just as EAP consumers can use EAP to establish keys shared between EAP peers and NASes so can GSS mechanisms made from EAP ones establish keys and authentication between GSS initiators and acceptors, even when the GSS acceptor is as to a NAS. You seem to be arguing that the GSS-API and EAP are fundamentally incompatible in ways similar to the GSS-API vis-a-vis Kerberos V. And indeed they are. Yet we have a Kerberos V mechanism for the GSS-API; it doesn't provide certain features that some Kerberos V applications might need, but it does provide a two-party mechanism. > This difference is IMHO not an insignificant minor detail, and > needs to be taken into account when talking about "bridging" > EAP and GSS-API mechanisms, or designing mechanisms that can > be used in both frameworks, etc. So we're in violent agreement :) > I'm not saying this deficiency in the EAP+AAA framework is serious > problem in all cases. In some environments the authentication > requirements in different directions are quite different. > > For instance, in 802.11 network access the client's/user's identity > is usually much more important; for the access point/network side, it > may be enough to verify that "this is someone the TTP (EAP server) > trusts". This is essentially what EAP+AAA framework today does. But surely the NAS wants to authenticate the EAP server -- otherwise one may impersonate EAP servers to NASes. Between authentication of users to EAP+AAA servers (possibly mutual), authentication of EAP servers to NASes, EAP channel bindings and EAP keying there's enough to build GSS mechanisms (names, mutual authentication and shared keys with which to key per-message tokens and the new GSS PRF for established security contexts). Nico -- _______________________________________________ SECMECH mailing list SECMECH@lists.ietf.org https://www1.ietf.org/mailman/listinfo/secmech From secmech-bounces@lists.ietf.org Wed Aug 10 09:51:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2qzM-00040P-RN; Wed, 10 Aug 2005 09:51:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2qzL-0003uk-9h for secmech@megatron.ietf.org; Wed, 10 Aug 2005 09:51:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28610 for ; Wed, 10 Aug 2005 09:51:21 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2rXR-0007EL-Ik for secmech@ietf.org; Wed, 10 Aug 2005 10:26:39 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 10 Aug 2005 06:51:12 -0700 X-IronPort-AV: i="3.96,96,1122879600"; d="scan'208"; a="330794910:sNHT31907140" Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j7ADp90J028707; Wed, 10 Aug 2005 06:51:10 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [SECMECH] Continuing my rant about EAP vs GSS-API... Date: Wed, 10 Aug 2005 06:55:52 -0700 Message-ID: <7210B31550AC934A8637D6619739CE6905AB1CF1@e2k-sea-xch2.sea-alpha.cisco.com> Thread-Topic: [SECMECH] Continuing my rant about EAP vs GSS-API... Thread-Index: AcWXSfE8CSNIJ8A1R7ChkqJp2e5DRwGY7iYg From: "Salowey, Joe" To: , X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: secmech@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security mechanisms BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: secmech-bounces@lists.ietf.org Errors-To: secmech-bounces@lists.ietf.org Hi Pasi, The current goal of GUAM is not to change the applicability of various frameworks. I believe that you are somewhat correct in that the different frameworks are typically used in different systems. However the all have the same goal within each of there systems and that is authentication and establishment of cryptographic state between two entities. This is just a true for EAP as it is for GSS-API. EAP itself is not a three party protocol even when the EAP Sever is located on a AAA server separate from the EAP authenticator. What is needed to create a mechanism that is usable in each of these frameworks is to adhere to the requirements in each of these frameworks, most of which actually are discussed in the EAP RFC. =20 We are not trying to solve all of ISMS problems in this group and in particular we are not trying to make EAP applicable to ISMS. ISMS is working on solutions to their problems. What we are trying to do is to unify mechanism development. However, an additional work item that may be relevant to this group that you focused on is tighter application integration with AAA. I think there are a possible number of ways to approach this and I'd be open to discuss it. I think the GUAM work is necessary to have tighter application integration into AAA. =20 It sounds like you would like to have the AAA server explicitly involved in some sort of three party exchange. I'm not completely convinced that this is a good idea as systems tend to work as they are today without it and making the system more complex does not necessarily solve a problem. In order to explicitly involve AAA in a n application security protocol one could design an extension to the GSS-API framework which covers both an application client exchange with the AAA server (probably using the EAP interface into AAA) and also covers the exchange between the application client and application server based on the AAA conversation. I think this would go a long way to addressing your concerns.=20 I think it would be useful to define what the actual requirements an benefits of such an integrated system are. Is this something you would like to look at? Joe > -----Original Message----- > From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com]=20 > Sent: Tuesday, August 02, 2005 3:07 AM > To: secmech@ietf.org > Subject: [SECMECH] Continuing my rant about EAP vs GSS-API... >=20 >=20 > (Continuing and clarifying my comment in the BoF today...) >=20 > GSS-API establishes a "security context" between a client and=20 > a server. Depending on the GSS-API mechanism, establishing=20 > the security context may use the help of a "trusted third=20 > party", either off-line (like CA) or on-line (Kerberos KDC). >=20 > EAP includes only the communication between the client and=20 > "trusted third party" (EAP server), but it does not establish=20 > a security context between the client and the service. But=20 > that's exactly what people interested in using a security=20 > framework (like ISMS or 802.11) would like to do! So just EAP=20 > alone is not really a framework you can compare with GSS-API. >=20 > To make this comparison more accurate, we _have_ to consider=20 > the real "EAP+AAA" framework, instead of claiming that=20 > they're totally separate. >=20 > Of course, it's still possible to e.g. analyze an EAP=20 > mechanism without considering AAA. The result of this=20 > analysis could be e.g. > that the mechanism has certain security properties. But from=20 > the point of view of applications, what really matters is the=20 > security properties of the whole framework (or this EAP=20 > mechanism when used within this framework). These don't=20 > trivially follow from properties of the building blocks (just=20 > like AES being secure doesn't make all EAP methods that use=20 > AES secure). >=20 > In particular, an application like ISMS is really concerned=20 > with "ok, I have this security context that I'll use for=20 > protecting my application-specific communication. What=20 > properties does this context have? Who is the other party I'm=20 > sharing this context (and keys contained in it) with?" >=20 > An analysis of an EAP mechanism, like EAP-TLS, can answer the=20 > question "who is the other party I'm sharing the EAP-SA with"=20 > (just look at the TLS server certificate). But EAP alone=20 > cannot answer the application's real question "who is the=20 > other party I'm sharing this context with". >=20 > Or in other words, GSS-API mechanisms (that do mutual=20 > authentication) do mutual authentication (and set up a=20 > security context/association) between the client and the=20 > service (application endpoint). EAP mechanisms do mutual=20 > authentication between the client and the EAP server; and=20 > that doesn't automatically mean mutual authentication between=20 > the client and the service/application endpoint. >=20 > This difference is IMHO not an insignificant minor detail,=20 > and needs to be taken into account when talking about "bridging" > EAP and GSS-API mechanisms, or designing mechanisms that can=20 > be used in both frameworks, etc. >=20 > I'm not saying this deficiency in the EAP+AAA framework is=20 > serious problem in all cases. In some environments the=20 > authentication requirements in different directions are quite=20 > different. >=20 > For instance, in 802.11 network access the client's/user's=20 > identity is usually much more important; for the access=20 > point/network side, it may be enough to verify that "this is=20 > someone the TTP (EAP server) trusts". This is essentially=20 > what EAP+AAA framework today does.=20 > Something like ISMS might have a similar situation,=20 > authenticating the identity of the SNMP manager might be much=20 > more important than the SNMP manager... >=20 > Best regards, > Pasi >=20 > _______________________________________________ > SECMECH mailing list > SECMECH@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/secmech >=20 _______________________________________________ SECMECH mailing list SECMECH@lists.ietf.org https://www1.ietf.org/mailman/listinfo/secmech From secmech-bounces@lists.ietf.org Mon Aug 15 19:22:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4oI0-0006rO-6o; Mon, 15 Aug 2005 19:22:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4oHx-0006rA-G9 for secmech@megatron.ietf.org; Mon, 15 Aug 2005 19:22:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12544 for ; Mon, 15 Aug 2005 19:22:38 -0400 (EDT) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E4or8-0007Xm-UL for secmech@ietf.org; Mon, 15 Aug 2005 19:59:05 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-4.cisco.com with ESMTP; 15 Aug 2005 16:22:23 -0700 Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j7FNMDQM011742 for ; Mon, 15 Aug 2005 16:22:13 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 15 Aug 2005 16:27:07 -0700 Message-ID: <7210B31550AC934A8637D6619739CE6905B6165B@e2k-sea-xch2.sea-alpha.cisco.com> Thread-Topic: Preliminary meeting minutes for Secmech BOF Thread-Index: AcWh8C4510i3gM+AQ9yecTCsZeImYQ== From: "Salowey, Joe" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 841b5d6ad57042632519d2198f34cc8d Content-Transfer-Encoding: quoted-printable Cc: Subject: [SECMECH] Preliminary meeting minutes for Secmech BOF X-BeenThere: secmech@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security mechanisms BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: secmech-bounces@lists.ietf.org Errors-To: secmech-bounces@lists.ietf.org Preliminary meeting minutes from the secmech BOF are attached, please = let me know if you have any corrections or additions by Thursday August = 18.=20 Thanks, Joe Secmech BOF IETF 63, Paris Tuesday August 2nd, 10:30 - 12:30 Chair: Joseph Salowey Notes taken by Hank Mauldin and Nancy Cam-Winget, edited by Joseph = Salowey 1. EAP Method Requirements (Jari Arkko) (Presentation - Jari) There are many existing EAP methods. The list is some 40+ methods long = and includes many undocumented and proprietary methods. Some methods = are documented in RFCs or are in the RFC editor queue. It has taken a = long time (4 years) for methods to get from 00 version to editor queue. = Methods listed in the original EAP RFC are no longer applicable in = wireless environments. =20 - Technical requirements for eap methods include=20 o must not break EAP (RFC 3748)=20 o documentation of security properties (mechanism, key hierarchy, = security claims, vulnerabilities) =20 o Address wireless LAN requirements (RFC 4017) o Documentation required to indicate which security claims from the list = defined in the EAP RFC are met o EAP process for new methods requires expert review of method to make = sure it does not break EAP and appropriate documentation is provided.=20 - Need for new EAP methods=20 EAP usage and network access authentication usage is increasing. = Currently we have too many undocumented methods and no standard method = that can be made mandatory to implement. There are requirements from = external standards bodies such as IEEE and 3GPP. One useful item is to = update EAP-TLS (RFC 2617) to bring it to standards track. Another = useful mechanism method class is a pre-shared key mechanism such as = EAP-PAX, EAP-PSK, or EAP-IKEv2. There is interest in password based = mechanisms, although that may be intractable. Methods should generate = keys and support channel bindings=20 - Conclusion It may be too late, but there is industry interest in method = standardization. Network access authentication is increasing so action = is needed now. Flood gates should not be completely opened, work should = be done on a limited number of mechanisms.=20 - Questions and Comments (John Vollbrecht): How does review take place? Who are the reviewers? (Jari): EAP working group has done 10 expert reviews. =20 (John Vollbrecht): Does the security of the mechanism needs review? (Jari) Definitely. The EAP review verifies conformance with 3748 and = claims are appropriately documented. It does not necessarily decide if = the method is a good idea or attempt to verify security claims. = Security review is needed in addition. (from Jabber): Is there an EAP directorate for reviews? =20 (Jari): No (from Jabber): What does it mean that the IETF has refused to address = this? (Jari): IETF has resisted doing this. Initially a working group was = refused from a BOF in the 90's, but then one was created just to work on = basic EAP specifications and not for methods.=20 (Uri Blumenthal): I agree with presentation. A group should be chartered = to work on a small number of methods, preferably 1. Channel bindings = should be included in mechanism requirements. If channel bindings are = not included in a method then it should not be considered for selection = since cryptographically it is broken. Avoid excessive tunneling. (Jari): tend to agree, though there are several usage scenarios so it = may not be possible to adopt just a single method need to accommodate = things like certificates and SIM cards (Uri): It should be possible to accommodate modes for legacy uses=20 (David Perkins): I think this BOF happened because of ISMS. (Sam Hartman): No it did not. (David Perkins): There's a gap between technology, usability and = application, so outcome of whatever happens should be that people can = actually deploy what is defined in this group. 2. Generally usable authentication mechanism (Joe Salowey) (Presentation - Joe Salowey) The idea of defining security mechanism so that they can be used in more = than one framework is not new, it has bee promoted by Sam Hartman and = others. There have been individual attempts at doing this for = individual methods in the past. The mechanism frameworks of SASL = GSS-API and EAP are similar; they focus on authentication and context = establishment. There are differences but they are very few. Convergence = is happening slowly. Examples are GSS-API PRF and channel bindings in = EAP. This leads to slow rate of standardization and duplication of = effort. More significantly we have inconsistent support for security = infrastructure. For example GSS-API primarily supports Kerberos and has = poor support for shared secret and certificates. EAP primarily shared = secrets in AAA but no Kerberos. Customers build and manage a credential = infrastructure, but can not use it for all applications. Frameworks = also have different areas of applicability; SASL for applications and = EAP for network access. =20 The proposed solution is to develop mechanisms that are useful in any = framework. (GUAM - draft-salowey-guam-00.txt). We don't want frameworks = to change so applications stay the same, frameworks could be optionally = enhanced. Any mechanism that is generally useful would be a candidate. (Eric Rescrola): so Kerberos supports everything one wants in TLS, but = has poor integration. What could be done differently? (Joe): Support for Kerberos is out of date for TLS (Nico Williams): The Kerberos cipher suites were bad. It would be nice = if TLS could support GSS, would be nice to look into.=20 (Sam): There is a wide scope which includes TLS. But right now we = should focus on EAP, SASL and GSS (Joe): agree (Glen Zorn): Applicability statements of the frameworks seem to be a = layer 8 problem. (Joe): Since the frameworks are similar it can be hard to understand = applicability. (Glen): It's not clear that the authentication mechanism is the issue, = some frameworks might not fit well with some protocols.=20 (Pasi Eronen): In your draft you say frameworks are similar, but there = is a difference when it comes to EAP. EAP the context is not set up = between the two parties which are communicating which is different than = GSS-API which sets up a context between the communicating parties. The = main difference is that in GSS-API you name the services you are = communicating with and in EAP you do not, so in EAP you don't know who = you are talking to.=20 (Joe): EAP is establishing a context between two parties. This context = is then used external to EAP to establish additional contexts. Lets = focus on what happens in EAP.=20 (Pasi): You can't consider EAP by itself. (Sam): seen why applicability statements are necessary, not just a layer = 8 issue. EAP usage has expanded from PPP to wireless. You can abstract = out the capabilities of GSS and EAP mechanisms, but you cannot abstract = out security analysis of the system.=20 (Jari): It not just about credentials types but being able to use = deployed infrastructure as well. Is this in scope? (Joe): yes=20 (Glen): disagree with area director and Pasi. It is necessary to = abstract EAP from its transport. Much misunderstanding of EAP comes = from a lack of analysis. System components need to be analyzed. Trying = to analyze the whole thing as a unit only leads to disaster and = confusion.=20 (Uri): In the beginning authentication was unidirectional. Capability = has been added for key generation etc. The analysis is now a mess so it = is difficult. People reuse EAP because it is there. Security is a = collateral consideration. (Unknown): good to unify proposals and unify requirements in one = protocol. Will optimizations be difficult in the general case? (John): Good idea to talk about how to figure out how these all are = similar, EAP is one piece. Agrees with Glenn about analysis.=20 (Glen): This discussion about EAP is about layering. Putting them all = together makes it impossible to analyze an EAP based authentication = system.=20 (Joe presentation)=20 There are a small set of requirements that would need to be supported by = a mechanism. (List in presentation). Most difficult may be dealing with = naming.=20 Next steps - create WG=20 (Glen): seems like it would be useful to define authentication methods = to be able to use in all frameworks. Why need a WG or RFC rather than an = OReilly book? 3. GUAM continued (Nico Williams) (Presentation Nico Williams) This group is to define and unify the frameworks and mechanisms that are = currently disjoint sets and there is limited support for mechanisms.=20 Terminology - framework, mechanism, framework-specific mechanism, = framework bindings of a mechanism, framework bridging =09 GUAM focuses on framework-bindings of a mechanism and framework bridging Concrete Proposals: =20 GSS-API DTLS bindings GSS-API plain/AAA (stackable mechanisms) to replace LIPKEY TLS v1.x to support multi-round-trip mechs and have it support GSS-API = ciphersuites EAP-IAKERB It might be a good idea to change some of the frameworks.=20 (Pasi): There is an internet draft that adds multiple round trips to = TLS. TLS inner application extension. =20 (Nico Presentation) One approach is to create bridging between mechanisms, but this may add = round trips. Or you can specify mechanisms definitions for both.=20 (Glen): GSS-API has embarrassingly few mechanisms and EAP has = embarrassingly many. I think this is an indication of sales. No-one = uses GSSAPI. (Nico): A lot of protocols use GSS-API. Many people are happy with = Kerberos, others are not. (Sam): the numbers tell me that SASL has the most success in getting = people to use it. EAP most success in getting people to write = mechanisms for it. This is not good and why we are having this BOF. = What do you mean by bridge? One document that defines both? (Nico): No that would be framework binding. bridging is a SASL <-> GSS = thing (Nico Presentation) I'd like to see a revival of an EAP-GSS bridge. All new EAP mechanisms = should not preclude use in GSS-API. EAP can be modeled as GSS-API = interaction. Kitten work will help make this easier. Perhaps there should be BCPs for mechanism definition. Then the work = can be done in various groups, EAP, Kitten, TLS, ... (Glen): I remember my question. IAKERB does not provide tickets to the = host. (Nico): That would be design error that could be fixed. (Love H=F6rnquist =C5strand): IAKERB did provide with tickets (Jari): Organizational aspects less interesting than what. There is = limited time to make this happen. Lets not delay.=20 4. Next steps (Joe): One work item is a fast track towards standardizing EAP methods (Jari): Have you selected a way to do this GUAM? (Joe): Not yet (Sam): A BCP can be created for guidelines on what is applicable for = various frameworks (Nico): I agree with the charter and BCPs or guidelines would be great.=20 (Joe): coordination from multiple groups is required BOF Questions: How many people think standardization of a small number of fast track = mechanisms is a good thing? (loud Hummmm) How many people think it isn't? (soft Hummmmm) (Glen): Who should do the standardizing? I think its a good idea, I = don't think it is a good idea to do it here. (Jari): Do people care where this happens as long as we get the right = people? Who believes we should standardize in security area? (medium hummm) Who believes it should happen outside security area? (soft hummm) Who doesn't care where? (medium humm) (Russ) I am concerned about the notion of fast track standards in the = EAP space. Standards track mechanisms that don't meet the needs of the = community doesn't help. (Joe) Fast- track refers to standardizing EAP methods in parallel to = GUAM work instead of waiting for GUAM work to complete. We would want = to collect the requirements development methods from the requirements. =20 (Russ) I misunderstood (Uri) None of the existing mechanisms completely fit. Shouldn't be too = hard to modify an existing proposal to work. We have the technology. = Collect requirements and then create a method. (Jari) It is difficult to answer questions on GUAM without knowing more. = =20 Humm if you don't have enough information about GUAM? (medium humm) Should the GUAM guidelines work should be done in the IETF? (medium hum) GUAM work should not be done in the IETF (little or no hum) Raise your hand if you are willing to author about 3=20 Raise you hand if you are willing to review about 10 Any objections to fast track EAP methods and GUAM work? (Unknown): Is this a standardization process? What does fast track mean? (Sam): fast track means just before GUAM work Charter wording needs to = be revised.=20 (Glen): My concern is that moving this into the security area will slow = or stop progress. (Joe) an option could be to add this work to the EAP charter (Sam): Consensus of the group is that standardizing an EAP method before = GUAM guidelines and doing it under the IETF area is acceptable. There are some individuals willing to author a draft and more to review = it. Lack of consensus on the focus of the GUAM guidelines indicated that the = group should first focus on the standardizing of the EAP mechanisms. (Pekka Nikander) Why should they be done in the same area working group? (Sam) My personal opinion is that the GUAM work will be more successful = if the GUAM people are exposed to method standardization process.=20 (Jeff Altman) In general I support the notion behind GUAM. Concerned = about spreading resources too thin across kitten and EAP groups.=20 (Sam) Next step is to track down people to volunteer, especially as = authors. =20 (Joe) That is an action item for me and several others.=20 =20 _______________________________________________ SECMECH mailing list SECMECH@lists.ietf.org https://www1.ietf.org/mailman/listinfo/secmech From secmech-bounces@lists.ietf.org Tue Aug 16 18:46:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5AC9-0008Vq-SX; Tue, 16 Aug 2005 18:46:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5AC8-0008V3-Cu for secmech@megatron.ietf.org; Tue, 16 Aug 2005 18:46:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17960 for ; Tue, 16 Aug 2005 18:46:03 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5AlV-00016Q-HY for secmech@ietf.org; Tue, 16 Aug 2005 19:22:42 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-5.cisco.com with ESMTP; 16 Aug 2005 15:45:55 -0700 X-IronPort-AV: i="3.96,114,1122879600"; d="scan'208"; a="205266882:sNHT29828880" Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j7GMjoQM009585 for ; Tue, 16 Aug 2005 15:45:51 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 16 Aug 2005 15:50:39 -0700 Message-ID: <7210B31550AC934A8637D6619739CE6905B61990@e2k-sea-xch2.sea-alpha.cisco.com> Thread-Topic: Framework Bindings Vs. Mechanism Bridges Thread-Index: AcWitEDgIeymX/peSBuJ+XPDMXNMBQ== From: "Salowey, Joe" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: quoted-printable Cc: Subject: [SECMECH] Framework Bindings Vs. Mechanism Bridges X-BeenThere: secmech@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security mechanisms BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: secmech-bounces@lists.ietf.org Errors-To: secmech-bounces@lists.ietf.org At the secmch BOF Nico introduced the following two approaches towards achieve generally usable authentication mechanisms: Framework Binding and Mechanism bridges. I'd like to see if there is understanding of the two approaches and a consensus on how to approach the problem. Framework Bindings - the framework bindings approach requires that when a mechanism is specified it is specified as a mechanism in the frameworks of GSS-API, SASL and EAP. The specification would have to define functionality to meet a superset of all the requirements for each framework and then define how the mechanism integrates with (or is bound to) each framework. Mechanism Bridges - in the mechanism bridges approach a specialized mechanisms is used to map all mechanisms in one framework into another framework. A example of this exists in SASL where there is a mechanism defined that makes available all GSS-API mechanisms available in the SASL framework. It should be possible to create a bridge mechanism that makes GSS-API mechanisms into EAP mechanisms and vice versa at least for a subset of mechanisms. The bridge mechanism itself may provide some functionality that is not available in a particular framework. For example an EAP to GSS bridge mechanism may provide a generic security layer that uses the EAP master session key (MSK) to establish a security context and provide a security layer between the GSS initiator and GSS acceptor. =20 The answer may lie somewhere between these two approaches. Comments?=20 Joe _______________________________________________ SECMECH mailing list SECMECH@lists.ietf.org https://www1.ietf.org/mailman/listinfo/secmech From secmech-bounces@lists.ietf.org Wed Aug 17 18:20:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5WH1-0001kk-95; Wed, 17 Aug 2005 18:20:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5WGz-0001hX-19 for secmech@megatron.ietf.org; Wed, 17 Aug 2005 18:20:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07213 for ; Wed, 17 Aug 2005 18:20:34 -0400 (EDT) Received: from carrierpigeon.cs.umd.edu ([128.8.129.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5WqY-0008UV-Vx for secmech@ietf.org; Wed, 17 Aug 2005 18:57:26 -0400 Received: from ismene (ismene.cs.umd.edu [128.8.126.62]) by carrierpigeon.cs.umd.edu (8.12.10/8.12.5) with ESMTP id j7HMJIfD009154; Wed, 17 Aug 2005 18:19:18 -0400 (EDT) Date: Wed, 17 Aug 2005 18:14:07 -0400 (EDT) From: Charles Clancy X-X-Sender: clancy@ismene To: "Salowey, Joe" Subject: Re: [SECMECH] Framework Bindings Vs. Mechanism Bridges In-Reply-To: <7210B31550AC934A8637D6619739CE6905B61990@e2k-sea-xch2.sea-alpha.cisco.com> Message-ID: References: <7210B31550AC934A8637D6619739CE6905B61990@e2k-sea-xch2.sea-alpha.cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: secmech@ietf.org X-BeenThere: secmech@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security mechanisms BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: secmech-bounces@lists.ietf.org Errors-To: secmech-bounces@lists.ietf.org Mechanism Bridges sounds like a hack to me. IMHO, Framework Bindings sounds like the way to go. It gives you more control over which mechanisms are used in which frameworks. Each framework has a different threat model, and not all mechanisms from one framework may be good in another. For example, using basic krb5 in 802.11i-EAP is a bad idea because of dictionary attacks. [ t. charles clancy ]--[ tcc@umd.edu ]--[ www.cs.umd.edu/~clancy ] [ computer science ]-----[ university of maryland | college park ] On Tue, 16 Aug 2005, Salowey, Joe wrote: > At the secmch BOF Nico introduced the following two approaches towards > achieve generally usable authentication mechanisms: Framework Binding > and Mechanism bridges. I'd like to see if there is understanding of the > two approaches and a consensus on how to approach the problem. > > Framework Bindings - the framework bindings approach requires that when > a mechanism is specified it is specified as a mechanism in the > frameworks of GSS-API, SASL and EAP. The specification would have to > define functionality to meet a superset of all the requirements for each > framework and then define how the mechanism integrates with (or is bound > to) each framework. > > Mechanism Bridges - in the mechanism bridges approach a specialized > mechanisms is used to map all mechanisms in one framework into another > framework. A example of this exists in SASL where there is a mechanism > defined that makes available all GSS-API mechanisms available in the > SASL framework. It should be possible to create a bridge mechanism that > makes GSS-API mechanisms into EAP mechanisms and vice versa at least for > a subset of mechanisms. The bridge mechanism itself may provide some > functionality that is not available in a particular framework. For > example an EAP to GSS bridge mechanism may provide a generic security > layer that uses the EAP master session key (MSK) to establish a security > context and provide a security layer between the GSS initiator and GSS > acceptor. > > The answer may lie somewhere between these two approaches. Comments? > > Joe > > _______________________________________________ > SECMECH mailing list > SECMECH@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/secmech > _______________________________________________ SECMECH mailing list SECMECH@lists.ietf.org https://www1.ietf.org/mailman/listinfo/secmech From secmech-bounces@lists.ietf.org Wed Aug 17 18:27:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5WNx-00035l-Ho; Wed, 17 Aug 2005 18:27:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5WNu-00035M-FR for secmech@megatron.ietf.org; Wed, 17 Aug 2005 18:27:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08011 for ; Wed, 17 Aug 2005 18:27:41 -0400 (EDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5WxT-0000Il-6D for secmech@ietf.org; Wed, 17 Aug 2005 19:04:33 -0400 Received: from centralmail2brm.Central.Sun.COM (centralmail2brm.central.sun.com [129.147.62.14]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j7HMReTW023914 for ; Wed, 17 Aug 2005 16:27:40 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id j7HMRdLI013620 for ; Wed, 17 Aug 2005 16:27:40 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id j7HMRXjW001868; Wed, 17 Aug 2005 17:27:33 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id j7HMRW54001867; Wed, 17 Aug 2005 17:27:32 -0500 (CDT) Date: Wed, 17 Aug 2005 17:27:32 -0500 From: Nicolas Williams To: Charles Clancy Subject: Re: [SECMECH] Framework Bindings Vs. Mechanism Bridges Message-ID: <20050817222731.GN29416@binky.Central.Sun.COM> References: <7210B31550AC934A8637D6619739CE6905B61990@e2k-sea-xch2.sea-alpha.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: secmech@ietf.org X-BeenThere: secmech@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security mechanisms BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: secmech-bounces@lists.ietf.org Errors-To: secmech-bounces@lists.ietf.org On Wed, Aug 17, 2005 at 06:14:07PM -0400, Charles Clancy wrote: > Mechanism Bridges sounds like a hack to me. > > IMHO, Framework Bindings sounds like the way to go. It gives you more > control over which mechanisms are used in which frameworks. Each > framework has a different threat model, and not all mechanisms from one > framework may be good in another. For example, using basic krb5 in > 802.11i-EAP is a bad idea because of dictionary attacks. Sure, but you could always do krb5-over-TLS-with-cryptographic-bindings. In any case, the addition of a round-trip in the case of any EAP->* or *->EAP bridges is a serious problem in itself... Nico -- _______________________________________________ SECMECH mailing list SECMECH@lists.ietf.org https://www1.ietf.org/mailman/listinfo/secmech From secmech-bounces@lists.ietf.org Fri Aug 19 13:20:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6AXx-0000db-FL; Fri, 19 Aug 2005 13:20:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6AXw-0000dT-Ns for secmech@megatron.ietf.org; Fri, 19 Aug 2005 13:20:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17737 for ; Fri, 19 Aug 2005 13:20:45 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E6B7v-00006i-ET for secmech@ietf.org; Fri, 19 Aug 2005 13:58:00 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 19 Aug 2005 10:20:38 -0700 X-IronPort-AV: i="3.96,126,1122879600"; d="scan'208"; a="655705044:sNHT28811364" Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j7JHKX0J009742; Fri, 19 Aug 2005 10:20:34 -0700 (PDT) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [SECMECH] Framework Bindings Vs. Mechanism Bridges X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Fri, 19 Aug 2005 10:25:24 -0700 Message-ID: <7210B31550AC934A8637D6619739CE6905C06505@e2k-sea-xch2.sea-alpha.cisco.com> Thread-Topic: [SECMECH] Framework Bindings Vs. Mechanism Bridges Thread-Index: AcWjepM/XDjUrH7pQVm0NAFOvROmXgBZziXA From: "Salowey, Joe" To: "Charles Clancy" X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: quoted-printable Cc: secmech@ietf.org X-BeenThere: secmech@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security mechanisms BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: secmech-bounces@lists.ietf.org Errors-To: secmech-bounces@lists.ietf.org > From: Charles Clancy [mailto:clancy@cs.umd.edu]=20 >=20 > IMHO, Framework Bindings sounds like the way to go. It gives=20 > you more control over which mechanisms are used in which=20 > frameworks. Each framework has a different threat model, and=20 > not all mechanisms from one framework may be good in another.=20 > For example, using basic krb5 in 802.11i-EAP is a bad idea=20 > because of dictionary attacks. >=20 [Joe] I tend to agree, however I think that bridge mechanisms or something similar can be useful tools for pulling things together. One example is a "generic" security layer that could use EAP keying material. Another may be a GSS-API mehcnaism that can make use of EAP methods to address some of the concerns Pasi had raised with respect to AAA integration.=20 _______________________________________________ SECMECH mailing list SECMECH@lists.ietf.org https://www1.ietf.org/mailman/listinfo/secmech From secmech-bounces@lists.ietf.org Fri Aug 19 13:27:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6AeC-0002HK-On; Fri, 19 Aug 2005 13:27:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6AeB-0002HC-Al for secmech@megatron.ietf.org; Fri, 19 Aug 2005 13:27:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18133 for ; Fri, 19 Aug 2005 13:27:11 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E6BEA-0000LI-3H for secmech@ietf.org; Fri, 19 Aug 2005 14:04:27 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-1.cisco.com with ESMTP; 19 Aug 2005 10:27:05 -0700 X-IronPort-AV: i="3.96,126,1122879600"; d="scan'208"; a="655707403:sNHT30166544" Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j7JHQuQM009302; Fri, 19 Aug 2005 10:26:57 -0700 (PDT) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [SECMECH] Framework Bindings Vs. Mechanism Bridges X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Fri, 19 Aug 2005 10:31:51 -0700 Message-ID: <7210B31550AC934A8637D6619739CE6905C06510@e2k-sea-xch2.sea-alpha.cisco.com> Thread-Topic: [SECMECH] Framework Bindings Vs. Mechanism Bridges Thread-Index: AcWje5iScRn68V51QMGyCrI9IainzwBZro4A From: "Salowey, Joe" To: "Nicolas Williams" , "Charles Clancy" X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: quoted-printable Cc: secmech@ietf.org X-BeenThere: secmech@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security mechanisms BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: secmech-bounces@lists.ietf.org Errors-To: secmech-bounces@lists.ietf.org =20 > From: Nicolas Williams [mailto:Nicolas.Williams@sun.com]=20 > On Wed, Aug 17, 2005 at 06:14:07PM -0400, Charles Clancy wrote: > > Mechanism Bridges sounds like a hack to me. > >=20 > > IMHO, Framework Bindings sounds like the way to go. It=20 > gives you more=20 > > control over which mechanisms are used in which frameworks. Each=20 > > framework has a different threat model, and not all mechanisms from=20 > > one framework may be good in another. For example, using=20 > basic krb5=20 > > in 802.11i-EAP is a bad idea because of dictionary attacks. >=20 > Sure, but you could always do=20 > krb5-over-TLS-with-cryptographic-bindings. > [Joe] How would this be instantiated? Currently EAP does not run over a specific security layer. There are EAP mechanisms that provide a secure tunnel for running other mechanisms. Would an EAP to GSS bridge have to be a tunneling method? =20 _______________________________________________ SECMECH mailing list SECMECH@lists.ietf.org https://www1.ietf.org/mailman/listinfo/secmech From secmech-bounces@lists.ietf.org Fri Aug 19 14:05:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6BFa-00043B-1n; Fri, 19 Aug 2005 14:05:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6BFY-0003zd-AG for secmech@megatron.ietf.org; Fri, 19 Aug 2005 14:05:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19731 for ; Fri, 19 Aug 2005 14:05:48 -0400 (EDT) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E6BpU-0001Qk-8U for secmech@ietf.org; Fri, 19 Aug 2005 14:43:02 -0400 Received: from centralmail1brm.Central.Sun.COM (centralmail1brm.central.sun.com [129.147.62.1]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j7JI5kWR028611 for ; Fri, 19 Aug 2005 12:05:46 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id j7JI5jfe021503 for ; Fri, 19 Aug 2005 12:05:46 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id j7JI5gSY007277; Fri, 19 Aug 2005 13:05:42 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id j7JI5eWn007276; Fri, 19 Aug 2005 13:05:40 -0500 (CDT) Date: Fri, 19 Aug 2005 13:05:40 -0500 From: Nicolas Williams To: "Salowey, Joe" Subject: Re: [SECMECH] Framework Bindings Vs. Mechanism Bridges Message-ID: <20050819180540.GF6659@binky.Central.Sun.COM> References: <7210B31550AC934A8637D6619739CE6905C06510@e2k-sea-xch2.sea-alpha.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7210B31550AC934A8637D6619739CE6905C06510@e2k-sea-xch2.sea-alpha.cisco.com> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: secmech@ietf.org X-BeenThere: secmech@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security mechanisms BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: secmech-bounces@lists.ietf.org Errors-To: secmech-bounces@lists.ietf.org On Fri, Aug 19, 2005 at 10:31:51AM -0700, Salowey, Joe wrote: > > > From: Nicolas Williams [mailto:Nicolas.Williams@sun.com] > > On Wed, Aug 17, 2005 at 06:14:07PM -0400, Charles Clancy wrote: > > > Mechanism Bridges sounds like a hack to me. > > > > > > IMHO, Framework Bindings sounds like the way to go. It > > gives you more > > > control over which mechanisms are used in which frameworks. Each > > > framework has a different threat model, and not all mechanisms from > > > one framework may be good in another. For example, using > > basic krb5 > > > in 802.11i-EAP is a bad idea because of dictionary attacks. > > > > Sure, but you could always do > > krb5-over-TLS-with-cryptographic-bindings. > > > > [Joe] How would this be instantiated? Aren't there EAP methods for tunnelling over TLS? Also, Kerberos V w/ PKINIT addresses the dictionary attacks issue as well; I should have mentioned that earlier. (Kerberos V pre-auth is extensible; the dictionary attacks on password pre-auth issue is specific to one type of Kerberos V pre-auth, the one standard type, of course, but PKINIT is another type.) > Currently EAP does not run over a > specific security layer. There are EAP mechanisms that provide a secure > tunnel for running other mechanisms. That's what I was referring to. Aren't these mechanisms there precisely to provide protection to other mechanisms that otherwise would be unsafe to use? > Would an EAP to GSS bridge have to > be a tunneling method? No. But if some mechanism for which a bridge is being used requires additional protection then tunnelling it over TLS or what have you would be important. Nico -- _______________________________________________ SECMECH mailing list SECMECH@lists.ietf.org https://www1.ietf.org/mailman/listinfo/secmech From secmech-bounces@lists.ietf.org Fri Aug 19 14:13:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6BLz-0005AU-Pn; Fri, 19 Aug 2005 14:12:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6BLy-0005AP-67 for secmech@megatron.ietf.org; Fri, 19 Aug 2005 14:12:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20051 for ; Fri, 19 Aug 2005 14:12:28 -0400 (EDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E6Bvu-0001e3-Uw for secmech@ietf.org; Fri, 19 Aug 2005 14:49:42 -0400 Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id j7JICP2B006340 for ; Fri, 19 Aug 2005 11:12:25 -0700 (PDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id j7JICNfe025922 for ; Fri, 19 Aug 2005 12:12:24 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id j7JICMID007295; Fri, 19 Aug 2005 13:12:23 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id j7JICMig007294; Fri, 19 Aug 2005 13:12:22 -0500 (CDT) Date: Fri, 19 Aug 2005 13:12:22 -0500 From: Nicolas Williams To: "Salowey, Joe" Subject: Re: [SECMECH] Framework Bindings Vs. Mechanism Bridges Message-ID: <20050819181222.GG6659@binky.Central.Sun.COM> References: <7210B31550AC934A8637D6619739CE6905C06505@e2k-sea-xch2.sea-alpha.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7210B31550AC934A8637D6619739CE6905C06505@e2k-sea-xch2.sea-alpha.cisco.com> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: secmech@ietf.org X-BeenThere: secmech@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security mechanisms BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: secmech-bounces@lists.ietf.org Errors-To: secmech-bounces@lists.ietf.org On Fri, Aug 19, 2005 at 10:25:24AM -0700, Salowey, Joe wrote: > > From: Charles Clancy [mailto:clancy@cs.umd.edu] > > > > IMHO, Framework Bindings sounds like the way to go. It gives > > you more control over which mechanisms are used in which > > frameworks. Each framework has a different threat model, and > > not all mechanisms from one framework may be good in another. > > For example, using basic krb5 in 802.11i-EAP is a bad idea > > because of dictionary attacks. > > > [Joe] I tend to agree, however I think that bridge mechanisms or > something similar can be useful tools for pulling things together. One > example is a "generic" security layer that could use EAP keying > material. Another may be a GSS-API mehcnaism that can make use of EAP > methods to address some of the concerns Pasi had raised with respect to > AAA integration. I too tend to agree. Bridges are clearly feasible, as SASL support for GSS-API mechanisms demonstrates. But bridges between EAP and any client-initiated frameworks will generally cost a round-trip, so for EAP vs. pretty much any other security framework it will be more appealing to develop framework bindings of one framework's mechanisms to the other. Nico -- _______________________________________________ SECMECH mailing list SECMECH@lists.ietf.org https://www1.ietf.org/mailman/listinfo/secmech From secmech-bounces@lists.ietf.org Fri Aug 19 14:14:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6BNw-0005r1-65; Fri, 19 Aug 2005 14:14:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6BNt-0005qk-RZ for secmech@megatron.ietf.org; Fri, 19 Aug 2005 14:14:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20123 for ; Fri, 19 Aug 2005 14:14:28 -0400 (EDT) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E6Bxt-0001hC-Tw for secmech@ietf.org; Fri, 19 Aug 2005 14:51:42 -0400 Received: from centralmail1brm.Central.Sun.COM (centralmail1brm.central.sun.com [129.147.62.1]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j7JIESWR008412 for ; Fri, 19 Aug 2005 12:14:28 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id j7JIERfe027222 for ; Fri, 19 Aug 2005 12:14:28 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id j7JIENAG007304; Fri, 19 Aug 2005 13:14:23 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id j7JIENwI007303; Fri, 19 Aug 2005 13:14:23 -0500 (CDT) Date: Fri, 19 Aug 2005 13:14:23 -0500 From: Nicolas Williams To: "Salowey, Joe" Subject: Re: [SECMECH] Framework Bindings Vs. Mechanism Bridges Message-ID: <20050819181423.GA6658@binky.Central.Sun.COM> References: <7210B31550AC934A8637D6619739CE6905C06505@e2k-sea-xch2.sea-alpha.cisco.com> <20050819181222.GG6659@binky.Central.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050819181222.GG6659@binky.Central.Sun.COM> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: secmech@ietf.org X-BeenThere: secmech@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security mechanisms BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: secmech-bounces@lists.ietf.org Errors-To: secmech-bounces@lists.ietf.org On Fri, Aug 19, 2005 at 01:12:22PM -0500, Nicolas Williams wrote: > On Fri, Aug 19, 2005 at 10:25:24AM -0700, Salowey, Joe wrote: > > > From: Charles Clancy [mailto:clancy@cs.umd.edu] > > > > > > IMHO, Framework Bindings sounds like the way to go. It gives > > > you more control over which mechanisms are used in which > > > frameworks. Each framework has a different threat model, and > > > not all mechanisms from one framework may be good in another. > > > For example, using basic krb5 in 802.11i-EAP is a bad idea > > > because of dictionary attacks. > > > > > [Joe] I tend to agree, however I think that bridge mechanisms or > > something similar can be useful tools for pulling things together. One > > example is a "generic" security layer that could use EAP keying > > material. Another may be a GSS-API mehcnaism that can make use of EAP > > methods to address some of the concerns Pasi had raised with respect to > > AAA integration. > > I too tend to agree. Bridges are clearly feasible, as SASL support for > GSS-API mechanisms demonstrates. But bridges between EAP and any > client-initiated frameworks will generally cost a round-trip, so for EAP > vs. pretty much any other security framework it will be more appealing > to develop framework bindings of one framework's mechanisms to the > other. I forgot to mention the counter-argument, namely that, in the short-term at least, a round-trip is a small price to pay for lowering the cost, in time and effort, of making EAP's or SASL/GSS-API's mechanisms available to the other. Nico -- _______________________________________________ SECMECH mailing list SECMECH@lists.ietf.org https://www1.ietf.org/mailman/listinfo/secmech From secmech-bounces@lists.ietf.org Fri Aug 19 14:57:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6C3t-0000C2-Vz; Fri, 19 Aug 2005 14:57:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6C3t-0000Bx-0n for secmech@megatron.ietf.org; Fri, 19 Aug 2005 14:57:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21468 for ; Fri, 19 Aug 2005 14:57:51 -0400 (EDT) Received: from carrierpigeon.cs.umd.edu ([128.8.129.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E6Cds-0002g7-I4 for secmech@ietf.org; Fri, 19 Aug 2005 15:35:05 -0400 Received: from ismene (ismene.cs.umd.edu [128.8.126.62]) by carrierpigeon.cs.umd.edu (8.12.10/8.12.5) with ESMTP id j7JIvZfD025543; Fri, 19 Aug 2005 14:57:35 -0400 (EDT) Date: Fri, 19 Aug 2005 14:52:22 -0400 (EDT) From: Charles Clancy X-X-Sender: clancy@ismene To: "Salowey, Joe" Subject: RE: [SECMECH] Framework Bindings Vs. Mechanism Bridges In-Reply-To: <7210B31550AC934A8637D6619739CE6905C06510@e2k-sea-xch2.sea-alpha.cisco.com> Message-ID: References: <7210B31550AC934A8637D6619739CE6905C06510@e2k-sea-xch2.sea-alpha.cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: secmech@ietf.org, Nicolas Williams X-BeenThere: secmech@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security mechanisms BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: secmech-bounces@lists.ietf.org Errors-To: secmech-bounces@lists.ietf.org On Fri, 19 Aug 2005, Salowey, Joe wrote: >> From: Nicolas Williams [mailto:Nicolas.Williams@sun.com] >> >> On Wed, Aug 17, 2005 at 06:14:07PM -0400, Charles Clancy wrote: >>> >>> IMHO, Framework Bindings sounds like the way to go. It gives you more >>> control over which mechanisms are used in which frameworks. Each >>> framework has a different threat model, and not all mechanisms from >>> one framework may be good in another. For example, using basic krb5 >>> in 802.11i-EAP is a bad idea because of dictionary attacks. >> >> Sure, but you could always do >> krb5-over-TLS-with-cryptographic-bindings. >> > > [Joe] How would this be instantiated? Currently EAP does not run over a > specific security layer. There are EAP mechanisms that provide a secure > tunnel for running other mechanisms. Would an EAP to GSS bridge have to > be a tunneling method? Whatever happened to EAP-GSS? http://www.drizzle.com/~aboba/IEEE/draft-aboba-pppext-eapgss-12.txt "krb5->GSS-API->EAP-GSS->EAP-TTLS->EAP" would work. Of course, the length of that string should be a motivator for bindings over bridges. [ t. charles clancy ]--[ tcc@umd.edu ]--[ www.cs.umd.edu/~clancy ] [ computer science ]-----[ university of maryland | college park ] _______________________________________________ SECMECH mailing list SECMECH@lists.ietf.org https://www1.ietf.org/mailman/listinfo/secmech From secmech-bounces@lists.ietf.org Fri Aug 19 17:03:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6E1C-0008Mc-Tl; Fri, 19 Aug 2005 17:03:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6E1A-0008Lk-Tp for secmech@megatron.ietf.org; Fri, 19 Aug 2005 17:03:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05074 for ; Fri, 19 Aug 2005 17:03:09 -0400 (EDT) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E6EbA-0008Rd-Uz for secmech@ietf.org; Fri, 19 Aug 2005 17:40:26 -0400 Received: from centralmail2brm.Central.Sun.COM (centralmail2brm.central.sun.com [129.147.62.14]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j7JL39WR029564 for ; Fri, 19 Aug 2005 15:03:09 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id j7JL38LI011443 for ; Fri, 19 Aug 2005 15:03:09 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id j7JL38Lh007379; Fri, 19 Aug 2005 16:03:08 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id j7JL38RY007378; Fri, 19 Aug 2005 16:03:08 -0500 (CDT) Date: Fri, 19 Aug 2005 16:03:08 -0500 From: Nicolas Williams To: Charles Clancy Subject: Re: [SECMECH] Framework Bindings Vs. Mechanism Bridges Message-ID: <20050819210308.GI6659@binky.Central.Sun.COM> References: <7210B31550AC934A8637D6619739CE6905C06510@e2k-sea-xch2.sea-alpha.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: secmech@ietf.org X-BeenThere: secmech@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security mechanisms BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: secmech-bounces@lists.ietf.org Errors-To: secmech-bounces@lists.ietf.org On Fri, Aug 19, 2005 at 02:52:22PM -0400, Charles Clancy wrote: > On Fri, 19 Aug 2005, Salowey, Joe wrote: > > >>From: Nicolas Williams [mailto:Nicolas.Williams@sun.com] > >> > >>On Wed, Aug 17, 2005 at 06:14:07PM -0400, Charles Clancy wrote: > >>> > >>>IMHO, Framework Bindings sounds like the way to go. It gives you more > >>>control over which mechanisms are used in which frameworks. Each > >>>framework has a different threat model, and not all mechanisms from > >>>one framework may be good in another. For example, using basic krb5 > >>>in 802.11i-EAP is a bad idea because of dictionary attacks. > >> > >>Sure, but you could always do > >>krb5-over-TLS-with-cryptographic-bindings. > >> > > > >[Joe] How would this be instantiated? Currently EAP does not run over a > >specific security layer. There are EAP mechanisms that provide a secure > >tunnel for running other mechanisms. Would an EAP to GSS bridge have to > >be a tunneling method? > > Whatever happened to EAP-GSS? Dunno, but as I recall some of the KITTEN WG work is, in part, aimed at making EAP-GSS possible, specifically the GSS_Pseudo_random() extension. > http://www.drizzle.com/~aboba/IEEE/draft-aboba-pppext-eapgss-12.txt > > "krb5->GSS-API->EAP-GSS->EAP-TTLS->EAP" would work. Of course, the length > of that string should be a motivator for bindings over bridges. Yes, but replace 'krb5' with 'IAKERB' or soemthing like it. Using slightly different (clearer?) notation, w/o PKINIT we have these options (and maybe more): EAP{EAP-TLS{EAP-GSS{GSS-API{GSS-IAKERB}}}} or EAP{EAP-GSS{GSS-API{GSS-TUNNEL{GSS-TLS,GSS-IAKERB}}}} Where "GSS-IAKERB" is a GSS-API mechanism that does Kerberos V KDC exchange proxying as necessary in order to establish service tickets for Kerberos AP exchanges. And where GSS-API channel bindings are used in both cases to bind the Kerberos V AP exchanges to the TLS (or whatever) tunnel. Of course, with PKINIT no tunnelling would be necessary: EAP{EAP-GSS{GSS-API{GSS-IAKERB}}} Nico -- _______________________________________________ SECMECH mailing list SECMECH@lists.ietf.org https://www1.ietf.org/mailman/listinfo/secmech From secmech-bounces@lists.ietf.org Fri Aug 19 23:10:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6Jkp-0001Yi-3A; Fri, 19 Aug 2005 23:10:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6Jkn-0001Yd-NC for secmech@megatron.ietf.org; Fri, 19 Aug 2005 23:10:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19522 for ; Fri, 19 Aug 2005 23:10:38 -0400 (EDT) Received: from talkeetna.isc-net.upenn.edu ([128.91.197.188]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E6KKr-0000bU-Br for secmech@ietf.org; Fri, 19 Aug 2005 23:47:58 -0400 Received: by talkeetna.isc-net.upenn.edu (Postfix, from userid 4127) id EF55443F3; Fri, 19 Aug 2005 23:10:35 -0400 (EDT) Date: Fri, 19 Aug 2005 23:10:35 -0400 From: Shumon Huque To: Nicolas Williams Subject: Re: [SECMECH] Framework Bindings Vs. Mechanism Bridges Message-ID: <20050820031035.GA5352@isc.upenn.edu> References: <7210B31550AC934A8637D6619739CE6905C06510@e2k-sea-xch2.sea-alpha.cisco.com> <20050819210308.GI6659@binky.Central.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050819210308.GI6659@binky.Central.Sun.COM> User-Agent: Mutt/1.4.2.1i Organization: University of Pennsylvania X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: secmech@ietf.org X-BeenThere: secmech@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security mechanisms BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: secmech-bounces@lists.ietf.org Errors-To: secmech-bounces@lists.ietf.org On Fri, Aug 19, 2005 at 04:03:08PM -0500, Nicolas Williams wrote: > On Fri, Aug 19, 2005 at 02:52:22PM -0400, Charles Clancy wrote: > > > > Whatever happened to EAP-GSS? > > Dunno, but as I recall some of the KITTEN WG work is, in part, aimed at > making EAP-GSS possible, specifically the GSS_Pseudo_random() extension. > > > http://www.drizzle.com/~aboba/IEEE/draft-aboba-pppext-eapgss-12.txt > > > > "krb5->GSS-API->EAP-GSS->EAP-TTLS->EAP" would work. Of course, the length > > of that string should be a motivator for bindings over bridges. > > Yes, but replace 'krb5' with 'IAKERB' or soemthing like it. > So for a standardized EAP method that supports Kerberos authentication, we are awaiting the following: - an updated GSS-API (for the pseudo random function) - an updated EAP-GSS mechanism that uses it - an updated IAKERB (for the AS and TGS exchanges) And potentially running inside TLS to address the dictionary attack vulnerability of the AS exchange. I am very concerned that Kerberos sites are being pushed to deploy network access authentication today, and there is no suitable option in sight for the forseeable future. Regarding dictionary attack, is it the case that we won't standardize an EAP method that is vulnerable to it? Or is the objection motivated by the fact that EAP is expected to be commonly used for wireless LAN authentication? I hope it isn't the latter, because it is almost as easy to eavesdrop on wired ethernets with ARP spoofing for example. Kerberos has always assumed that the network is completely insecure and the general defense against offline dictionary attack is strong passwords. I agree that perhaps this isn't enough anymore. But then, I think the Kerberos community needs to work on standardizing password based pre-authentication mechanisms invulnerable to dictionary attack (perhaps EKE, AEKE, SPEKE, SRP etc). Hardware pre-authentication mitigates the threat somewhat. But PKINIT isn't really an option for the many sites that don't plan to authenticate users with public key credentials (or deploy PKI). At one time, some of us were talking about an EAP method that transported Kerberos messages directly. It seems to me that putting some effort into completing that work would be immediately useful to Kerberos sites that need to deploy 802.1X or 802.11i soon. --- Shumon Huque 3401 Walnut Street, Suite 221A, Network Engineering Philadelphia, PA 19104-6228, USA. Information Systems & Computing (215)898-2477, (215)898-9348 (Fax) University of Pennsylvania / MAGPI. E-mail: shuque -at- isc.upenn.edu _______________________________________________ SECMECH mailing list SECMECH@lists.ietf.org https://www1.ietf.org/mailman/listinfo/secmech From secmech-bounces@lists.ietf.org Sat Aug 20 02:06:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6MUw-0006Fg-80; Sat, 20 Aug 2005 02:06:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6MUv-0006FY-EX for secmech@megatron.ietf.org; Sat, 20 Aug 2005 02:06:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00402 for ; Sat, 20 Aug 2005 02:06:23 -0400 (EDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E6N4v-000453-BK for secmech@ietf.org; Sat, 20 Aug 2005 02:43:42 -0400 Received: from centralmail2brm.Central.Sun.COM (centralmail2brm.central.sun.com [129.147.62.14]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j7K66LTW003203 for ; Sat, 20 Aug 2005 00:06:21 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id j7K65ULG011830 for ; Sat, 20 Aug 2005 00:06:21 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id j7K635bp007842; Sat, 20 Aug 2005 01:03:20 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id j7K60OrN007804; Sat, 20 Aug 2005 01:00:24 -0500 (CDT) Date: Sat, 20 Aug 2005 00:58:41 -0500 From: Nicolas Williams To: Shumon Huque Subject: Re: [SECMECH] Framework Bindings Vs. Mechanism Bridges Message-ID: <20050820055834.GA7789@binky.Central.Sun.COM> References: <7210B31550AC934A8637D6619739CE6905C06510@e2k-sea-xch2.sea-alpha.cisco.com> <20050819210308.GI6659@binky.Central.Sun.COM> <20050820031035.GA5352@isc.upenn.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050820031035.GA5352@isc.upenn.edu> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: secmech@ietf.org X-BeenThere: secmech@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security mechanisms BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: secmech-bounces@lists.ietf.org Errors-To: secmech-bounces@lists.ietf.org On Fri, Aug 19, 2005 at 11:10:35PM -0400, Shumon Huque wrote: > Kerberos has always assumed that the network is completely insecure > and the general defense against offline dictionary attack is strong > passwords. I agree that perhaps this isn't enough anymore. But then, That's fair for Kerberos IV, but Kerberos V always allowed for new pre-authentication methods, while Kerberos IV lacked even pre-auth. > I think the Kerberos community needs to work on standardizing password > based pre-authentication mechanisms invulnerable to dictionary attack > (perhaps EKE, AEKE, SPEKE, SRP etc). Hardware pre-authentication > mitigates the threat somewhat. But PKINIT isn't really an option for > the many sites that don't plan to authenticate users with public key > credentials (or deploy PKI). Did you attend the SACRED WG meeting at IETF 63? > At one time, some of us were talking about an EAP method that > transported Kerberos messages directly. It seems to me that putting > some effort into completing that work would be immediately useful > to Kerberos sites that need to deploy 802.1X or 802.11i soon. Indeed. That would be an example of framework bindings of a security mechanisms, as opposed to EAP-GSS, which would be a bridge. Nico -- _______________________________________________ SECMECH mailing list SECMECH@lists.ietf.org https://www1.ietf.org/mailman/listinfo/secmech From secmech-bounces@lists.ietf.org Sat Aug 20 11:42:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6VUf-0002TE-5J; Sat, 20 Aug 2005 11:42:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6VUc-0002Ss-V3 for secmech@megatron.ietf.org; Sat, 20 Aug 2005 11:42:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26613 for ; Sat, 20 Aug 2005 11:42:44 -0400 (EDT) Received: from rwcrmhc12.comcast.net ([216.148.227.85]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E6W4n-0007dy-Da for secmech@ietf.org; Sat, 20 Aug 2005 12:20:10 -0400 Received: from [192.168.0.2] (pcp04510339pcs.gambrl01.md.comcast.net[68.49.199.146]) by comcast.net (rwcrmhc12) with ESMTP id <2005082015423501400qds9oe>; Sat, 20 Aug 2005 15:42:36 +0000 Message-ID: <43074F76.8000604@cs.umd.edu> Date: Sat, 20 Aug 2005 11:42:46 -0400 From: Charles Clancy User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Shumon Huque Subject: Re: [SECMECH] Framework Bindings Vs. Mechanism Bridges References: <7210B31550AC934A8637D6619739CE6905C06510@e2k-sea-xch2.sea-alpha.cisco.com> <20050819210308.GI6659@binky.Central.Sun.COM> <20050820031035.GA5352@isc.upenn.edu> In-Reply-To: <20050820031035.GA5352@isc.upenn.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: 7bit Cc: secmech@ietf.org, Nicolas Williams X-BeenThere: secmech@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security mechanisms BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: secmech-bounces@lists.ietf.org Errors-To: secmech-bounces@lists.ietf.org Shumon Huque wrote: > So for a standardized EAP method that supports Kerberos > authentication, we are awaiting the following: > > - an updated GSS-API (for the pseudo random function) > - an updated EAP-GSS mechanism that uses it > - an updated IAKERB (for the AS and TGS exchanges) A standardized tunneling method would be nice too. Or, a generic Kerberos method secured with some KDC certificate, with bindings to EAP. > And potentially running inside TLS to address the dictionary attack > vulnerability of the AS exchange. Right. > I am very concerned that Kerberos sites are being pushed to deploy > network access authentication today, and there is no suitable option > in sight for the forseeable future. There are plenty of provisioning options. For example, EAP-PAX could be bootstrapped by a kerberos password. I've heard that MIT bootstraps PKI creds using a kerberos password -- those could be used for EAP-TLS. Though, I agree no easy, out-of-the-box solution exists. > Regarding dictionary attack, is it the case that we won't standardize > an EAP method that is vulnerable to it? Or is the objection motivated > by the fact that EAP is expected to be commonly used for wireless > LAN authentication? I hope it isn't the latter, because it is almost > as easy to eavesdrop on wired ethernets with ARP spoofing for example. EAP methods vulnerable to dictionary attacks cannot be used with WLAN. See RFC 4017. I don't think people are against standardizing a kerberos method, as long as people know it should be run in a tunnel -- much like EAP-MSCHAPv2. > I think the Kerberos community needs to work on standardizing password > based pre-authentication mechanisms invulnerable to dictionary attack > (perhaps EKE, AEKE, SPEKE, SRP etc). There are many intellectual property problems with these protocols. There are more complex protocols that don't suffer from the IP problems (http://eprint.iacr.org/2001/031.pdf) but they're more theoretical than practical. Everything else requires a server-side certificate. > At one time, some of us were talking about an EAP method that > transported Kerberos messages directly. It seems to me that putting > some effort into completing that work would be immediately useful > to Kerberos sites that need to deploy 802.1X or 802.11i soon. I've heard the same thing from other people as well. Just make sure it runs in a tunneling method, or these directly transported kerberos messages are protected... DTLS maybe? I think this is exactly the sort of thing SECMECH should be working on. [ t. charles clancy ]--[ tcc@umd.edu ]--[ www.cs.umd.edu/~clancy ] [ computer science ]-----[ university of maryland | college park ] _______________________________________________ SECMECH mailing list SECMECH@lists.ietf.org https://www1.ietf.org/mailman/listinfo/secmech From secmech-bounces@lists.ietf.org Mon Aug 22 00:18:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E73lL-0004qc-0h; Mon, 22 Aug 2005 00:18:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E73lG-0004pr-Is for secmech@megatron.ietf.org; Mon, 22 Aug 2005 00:18:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06569 for ; Mon, 22 Aug 2005 00:18:11 -0400 (EDT) Received: from talkeetna.isc-net.upenn.edu ([128.91.197.188]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E74Lj-000231-QK for secmech@ietf.org; Mon, 22 Aug 2005 00:55:57 -0400 Received: by talkeetna.isc-net.upenn.edu (Postfix, from userid 4127) id 8CAD7443B; Mon, 22 Aug 2005 00:18:08 -0400 (EDT) Date: Mon, 22 Aug 2005 00:18:08 -0400 From: Shumon Huque To: Nicolas Williams Subject: Re: [SECMECH] Framework Bindings Vs. Mechanism Bridges Message-ID: <20050822041808.GB27685@isc.upenn.edu> References: <7210B31550AC934A8637D6619739CE6905C06510@e2k-sea-xch2.sea-alpha.cisco.com> <20050819210308.GI6659@binky.Central.Sun.COM> <20050820031035.GA5352@isc.upenn.edu> <20050820055834.GA7789@binky.Central.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050820055834.GA7789@binky.Central.Sun.COM> User-Agent: Mutt/1.4.2.1i Organization: University of Pennsylvania X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: secmech@ietf.org X-BeenThere: secmech@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security mechanisms BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: secmech-bounces@lists.ietf.org Errors-To: secmech-bounces@lists.ietf.org On Sat, Aug 20, 2005 at 12:58:41AM -0500, Nicolas Williams wrote: > On Fri, Aug 19, 2005 at 11:10:35PM -0400, Shumon Huque wrote: > > I think the Kerberos community needs to work on standardizing password > > based pre-authentication mechanisms invulnerable to dictionary attack > > (perhaps EKE, AEKE, SPEKE, SRP etc). Hardware pre-authentication > > mitigates the threat somewhat. But PKINIT isn't really an option for > > the many sites that don't plan to authenticate users with public key > > credentials (or deploy PKI). > > Did you attend the SACRED WG meeting at IETF 63? No, but I just read a summary of their session. The credential mobility stuff isn't really relevant to (non PKINIT) Kerberos sites. So I assume you are referring to the IPR issues with those protocols. It sounds like there might be some hope though! > > At one time, some of us were talking about an EAP method that > > transported Kerberos messages directly. It seems to me that putting > > some effort into completing that work would be immediately useful > > to Kerberos sites that need to deploy 802.1X or 802.11i soon. > > Indeed. That would be an example of framework bindings of a security > mechanisms, as opposed to EAP-GSS, which would be a bridge. Agreed. Some folks at Penn are interested in working on an EAP-Kerberos method. Is there anyone else interested in this? Thanks! --- Shumon Huque 3401 Walnut Street, Suite 221A, Network Engineering Philadelphia, PA 19104-6228, USA. Information Systems & Computing (215)898-2477, (215)898-9348 (Fax) University of Pennsylvania / MAGPI. E-mail: shuque -at- isc.upenn.edu _______________________________________________ SECMECH mailing list SECMECH@lists.ietf.org https://www1.ietf.org/mailman/listinfo/secmech From secmech-bounces@lists.ietf.org Mon Aug 22 00:43:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E749D-0008C8-SL; Mon, 22 Aug 2005 00:42:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E749B-0008C3-GC for secmech@megatron.ietf.org; Mon, 22 Aug 2005 00:42:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07446 for ; Mon, 22 Aug 2005 00:42:54 -0400 (EDT) Received: from talkeetna.isc-net.upenn.edu ([128.91.197.188]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E74jf-0002at-DB for secmech@ietf.org; Mon, 22 Aug 2005 01:20:40 -0400 Received: by talkeetna.isc-net.upenn.edu (Postfix, from userid 4127) id 4E0BE443B; Mon, 22 Aug 2005 00:42:55 -0400 (EDT) Date: Mon, 22 Aug 2005 00:42:55 -0400 From: Shumon Huque To: Charles Clancy Subject: Re: [SECMECH] Framework Bindings Vs. Mechanism Bridges Message-ID: <20050822044255.GC27685@isc.upenn.edu> References: <7210B31550AC934A8637D6619739CE6905C06510@e2k-sea-xch2.sea-alpha.cisco.com> <20050819210308.GI6659@binky.Central.Sun.COM> <20050820031035.GA5352@isc.upenn.edu> <43074F76.8000604@cs.umd.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43074F76.8000604@cs.umd.edu> User-Agent: Mutt/1.4.2.1i Organization: University of Pennsylvania X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: secmech@ietf.org, Nicolas Williams X-BeenThere: secmech@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security mechanisms BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: secmech-bounces@lists.ietf.org Errors-To: secmech-bounces@lists.ietf.org On Sat, Aug 20, 2005 at 11:42:46AM -0400, Charles Clancy wrote: > Shumon Huque wrote: > > >Regarding dictionary attack, is it the case that we won't standardize > >an EAP method that is vulnerable to it? Or is the objection motivated > >by the fact that EAP is expected to be commonly used for wireless > >LAN authentication? I hope it isn't the latter, because it is almost > >as easy to eavesdrop on wired ethernets with ARP spoofing for example. > > EAP methods vulnerable to dictionary attacks cannot be used with WLAN. > See RFC 4017. I don't think people are against standardizing a kerberos > method, as long as people know it should be run in a tunnel -- much like > EAP-MSCHAPv2. I've read RFC 4017. My discomfort comes from the observation that it is at best incomplete to point this out only for wireless LANs, since many of these vulnerabilities are applicable to other link layers too. If I use an EAP method that supports Kerberos on a wired ethernet for example, the dictionary attack threat still exists. I do not find the differential magnitude of the threat a very convincing argument. It makes more sense to design security mechanisms with the uniform assumption that the network is always hostile. This puts us in a position of having to say (whether we're using EAP or not): "use Kerberos normally, except when running over link layers X, Y and Z, in which case you should run it only in a protected, cryptographically bound tunnel". If we need to address the dictionary attack problem, I think we should discuss how to do so in the Kerberos protocol directly. Perhaps that discussion belongs in another group though .. I'm also not a fan of automatically assuming that a tunnel is the right solution for many problems. If we are tunnelling in TLS for example, I now have additional issues to deal with. Such as how to query up-to-date certificate revocation status, and whether my users are properly validating the certificates etc. --- Shumon Huque 3401 Walnut Street, Suite 221A, Network Engineering Philadelphia, PA 19104-6228, USA. Information Systems & Computing (215)898-2477, (215)898-9348 (Fax) University of Pennsylvania / MAGPI. E-mail: shuque -at- isc.upenn.edu _______________________________________________ SECMECH mailing list SECMECH@lists.ietf.org https://www1.ietf.org/mailman/listinfo/secmech From secmech-bounces@lists.ietf.org Mon Aug 22 07:08:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7AA9-0001RE-VF; Mon, 22 Aug 2005 07:08:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7AA9-0001R9-50 for secmech@megatron.ietf.org; Mon, 22 Aug 2005 07:08:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06777 for ; Mon, 22 Aug 2005 07:08:17 -0400 (EDT) From: t.otto@sharevolution.de Received: from moutng.kundenserver.de ([212.227.126.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7Akf-0004hp-Bw for secmech@ietf.org; Mon, 22 Aug 2005 07:46:07 -0400 Received: from [212.227.126.202] (helo=mrvnet.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1E7A9x-000734-00; Mon, 22 Aug 2005 13:08:09 +0200 Received: from [172.23.4.154] (helo=pustefix154.kundenserver.de) by mrvnet.kundenserver.de with esmtp (Exim 3.35 #1) id 1E7A9x-0003gt-00; Mon, 22 Aug 2005 13:08:09 +0200 Message-Id: <5057734.1124708889160.JavaMail.servlet@kundenserver> To: Subject: AW: Re: [SECMECH] Framework Bindings Vs. Mechanism Bridges Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Priority: 3 X-Binford: 6100 (more power) X-Mailer: Webmail X-Originating-From: 6270027 X-Routing: DE X-Message-Id: <6270027$1124708889160172.23.4.15416082936@pustefix154.kundenserver.de--1224873406> X-Received: from pustefix154.kundenserver.de by 192.35.17.24 with HTTP id 6270027 for [shuque@isc.upenn.edu]; Mon, 22 Aug 2005 13:08:09 CEST Date: Mon, 22 Aug 2005 13:08:09 +0200 X-Provags-ID: kundenserver.de abuse@kundenserver.de ident:@172.23.4.154 X-Spam-Score: 0.3 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit Cc: secmech@ietf.org X-BeenThere: secmech@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security mechanisms BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: secmech-bounces@lists.ietf.org Errors-To: secmech-bounces@lists.ietf.org > >On Sat, Aug 20, 2005 at 12:58:41AM -0500, Nicolas Williams wrote: >> On Fri, Aug 19, 2005 at 11:10:35PM -0400, Shumon Huque wrote: >> > I think the Kerberos community needs to work on standardizing password >> > based pre-authentication mechanisms invulnerable to dictionary attack >> > (perhaps EKE, AEKE, SPEKE, SRP etc). Hardware pre-authentication >> > mitigates the threat somewhat. But PKINIT isn't really an option for >> > the many sites that don't plan to authenticate users with public key >> > credentials (or deploy PKI). >> >> Did you attend the SACRED WG meeting at IETF 63? > >No, but I just read a summary of their session. The credential >mobility stuff isn't really relevant to (non PKINIT) Kerberos >sites. So I assume you are referring to the IPR issues with those >protocols. It sounds like there might be some hope though! > >> > At one time, some of us were talking about an EAP method that >> > transported Kerberos messages directly. It seems to me that putting >> > some effort into completing that work would be immediately useful >> > to Kerberos sites that need to deploy 802.1X or 802.11i soon. >> >> Indeed. That would be an example of framework bindings of a security >> mechanisms, as opposed to EAP-GSS, which would be a bridge. > >Agreed. > >Some folks at Penn are interested in working on an EAP-Kerberos >method. Is there anyone else interested in this? Hi Shumon, I`ve also thought about a new EAP method which makes use of Kerberos. When designing a new EAP method, it must extend current available set of EAP methods by a new mechanism. Some weeks ago, I`ve asked publicly in the Kerberos Mailing List what the folks expect from a EAP-Kerberos method. See http://mailman.mit.edu/pipermail/kerberos/2005-July/008131.html Some opinions can be found there. There already exists a Kerberos extension to TLS, RFC 2712 (Oct.99), which can be run in EAP-TLS, so the question is: * Is there need for EAP-Kerberos at all? * So before all, we should investigate in how far EAP-Kerberos improves the TLS-based solution. For instance, the mandatory resistance to dictionary attacks. Thomas Wu has given in his Kerberos paper a hint how to mitigate this, however, even if there is a strong-password protocol without IPR claims, strong password methods suffer in general from heavy computation and thus the EAP method would have worse performance. Any comments are welcome Thomas _______________________________________________ SECMECH mailing list SECMECH@lists.ietf.org https://www1.ietf.org/mailman/listinfo/secmech From secmech-bounces@lists.ietf.org Mon Aug 22 07:41:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7Ag4-0006lh-BA; Mon, 22 Aug 2005 07:41:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7Ag1-0006lZ-SY for secmech@megatron.ietf.org; Mon, 22 Aug 2005 07:41:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08128 for ; Mon, 22 Aug 2005 07:41:16 -0400 (EDT) Received: from talkeetna.isc-net.upenn.edu ([128.91.197.188]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7BGY-0005ia-Bl for secmech@ietf.org; Mon, 22 Aug 2005 08:19:04 -0400 Received: by talkeetna.isc-net.upenn.edu (Postfix, from userid 4127) id A6B34443B; Mon, 22 Aug 2005 07:41:12 -0400 (EDT) Date: Mon, 22 Aug 2005 07:41:12 -0400 From: Shumon Huque To: t.otto@sharevolution.de Subject: Re: Re: [SECMECH] Framework Bindings Vs. Mechanism Bridges Message-ID: <20050822114112.GA343@isc.upenn.edu> References: <5057734.1124708889160.JavaMail.servlet@kundenserver> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5057734.1124708889160.JavaMail.servlet@kundenserver> User-Agent: Mutt/1.4.2.1i Organization: University of Pennsylvania X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: secmech@ietf.org X-BeenThere: secmech@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security mechanisms BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: secmech-bounces@lists.ietf.org Errors-To: secmech-bounces@lists.ietf.org On Mon, Aug 22, 2005 at 01:08:09PM +0200, t.otto@sharevolution.de wrote: > > There already exists a Kerberos extension to TLS, RFC 2712 (Oct.99), > which can be run in EAP-TLS, so the question is: > > * Is there need for EAP-Kerberos at all? * RFC 2712 doesn't provide for initial and service ticket acquisition. So, at the very least an EAP method that allows you to do that needs to be developed. > So before all, we should investigate in how far EAP-Kerberos improves > the TLS-based solution. > > For instance, the mandatory resistance to dictionary attacks. Thomas Wu > has given in his Kerberos paper a hint how to mitigate this, however, > even if there is a strong-password protocol without IPR claims, > strong password methods suffer in general from heavy computation and thus > the EAP method would have worse performance. That's true. But as long as performance is good enough, it might be okay. It's probably certainly an issue for handheld devices needing to use it. --Shumon. _______________________________________________ SECMECH mailing list SECMECH@lists.ietf.org https://www1.ietf.org/mailman/listinfo/secmech From secmech-bounces@lists.ietf.org Mon Aug 22 07:47:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7AlY-0007h0-55; Mon, 22 Aug 2005 07:47:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7AlX-0007gv-2q for secmech@megatron.ietf.org; Mon, 22 Aug 2005 07:46:59 -0400 Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.173]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08265 for ; Mon, 22 Aug 2005 07:46:57 -0400 (EDT) From: t.otto@sharevolution.de Received: from [212.227.126.202] (helo=mrvnet.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1E7AlV-00070e-00 for secmech@lists.ietf.org; Mon, 22 Aug 2005 13:46:57 +0200 Received: from [172.23.4.154] (helo=pustefix154.kundenserver.de) by mrvnet.kundenserver.de with esmtp (Exim 3.35 #1) id 1E7AlV-0006qd-00 for secmech@lists.ietf.org; Mon, 22 Aug 2005 13:46:57 +0200 Message-Id: <17259346.1124711217221.JavaMail.servlet@kundenserver> To: Subject: AW: Re: [SECMECH] Framework Bindings Vs. Mechanism Bridges Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Priority: 3 X-Binford: 6100 (more power) X-Mailer: Webmail X-Originating-From: 6270027 X-Routing: DE X-Message-Id: <6270027$1124711217220172.23.4.15433227011@pustefix154.kundenserver.de-1160564962> X-Received: from pustefix154.kundenserver.de by 192.35.17.24 with HTTP id 6270027 for [secmech@lists.ietf.org]; Mon, 22 Aug 2005 13:46:57 CEST Date: Mon, 22 Aug 2005 13:46:57 +0200 X-Provags-ID: kundenserver.de abuse@kundenserver.de ident:@172.23.4.154 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: secmech@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security mechanisms BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: secmech-bounces@lists.ietf.org Errors-To: secmech-bounces@lists.ietf.org > >> >>On Sat, Aug 20, 2005 at 12:58:41AM -0500, Nicolas Williams wrote: >>> On Fri, Aug 19, 2005 at 11:10:35PM -0400, Shumon Huque wrote: >>> > I think the Kerberos community needs to work on standardizing password >>> > based pre-authentication mechanisms invulnerable to dictionary attack >>> > (perhaps EKE, AEKE, SPEKE, SRP etc). Hardware pre-authentication >>> > mitigates the threat somewhat. But PKINIT isn't really an option for >>> > the many sites that don't plan to authenticate users with public key >>> > credentials (or deploy PKI). >>> >>> Did you attend the SACRED WG meeting at IETF 63? >> >>No, but I just read a summary of their session. The credential >>mobility stuff isn't really relevant to (non PKINIT) Kerberos >>sites. So I assume you are referring to the IPR issues with those >>protocols. It sounds like there might be some hope though! >> >>> > At one time, some of us were talking about an EAP method that >>> > transported Kerberos messages directly. It seems to me that putting >>> > some effort into completing that work would be immediately useful >>> > to Kerberos sites that need to deploy 802.1X or 802.11i soon. >>> >>> Indeed. That would be an example of framework bindings of a security >>> mechanisms, as opposed to EAP-GSS, which would be a bridge. >> >>Agreed. >> >>Some folks at Penn are interested in working on an EAP-Kerberos >>method. Is there anyone else interested in this? > > >Hi Shumon, > >I`ve also thought about a new EAP method which makes use of Kerberos. >When designing a new EAP method, it must extend current available set >of EAP methods by a new mechanism. > >Some weeks ago, I`ve asked publicly in the Kerberos Mailing List what >the folks expect from a EAP-Kerberos method. See href="http://mailman.mit.edu/pipermail/kerberos/2005-July/008131.html">http://m >ailman.mit.edu/pipermail/kerberos/2005-July/008131.html >Some opinions can be found there. > >There already exists a Kerberos extension to TLS, RFC 2712 (Oct.99), >which can be run in EAP-TLS, so the question is: > >* Is there need for EAP-Kerberos at all? * > >So before all, we should investigate in how far EAP-Kerberos improves >the TLS-based solution. > >For instance, the mandatory resistance to dictionary attacks. Thomas Wu >has given in his Kerberos paper a hint how to mitigate this, however, >even if there is a strong-password protocol without IPR claims, >strong password methods suffer in general from heavy computation and thus >the EAP method would have worse performance. > >Any comments are welcome >Thomas > >_______________________________________________ >SECMECH mailing list >SECMECH@lists.ietf.org >href="https://www1.ietf.org/mailman/listinfo/secmech">https://www1.ietf.org/mai >lman/listinfo/secmech _______________________________________________ SECMECH mailing list SECMECH@lists.ietf.org https://www1.ietf.org/mailman/listinfo/secmech From secmech-bounces@lists.ietf.org Mon Aug 22 08:42:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7Bcy-0001bG-PP; Mon, 22 Aug 2005 08:42:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7Bcx-0001bB-2d for secmech@megatron.ietf.org; Mon, 22 Aug 2005 08:42:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12903 for ; Mon, 22 Aug 2005 08:42:09 -0400 (EDT) Received: from carrierpigeon.cs.umd.edu ([128.8.129.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7CDW-0007r3-BG for secmech@ietf.org; Mon, 22 Aug 2005 09:19:58 -0400 Received: from ismene (ismene.cs.umd.edu [128.8.126.62]) by carrierpigeon.cs.umd.edu (8.12.10/8.12.5) with ESMTP id j7MCfxfD016386; Mon, 22 Aug 2005 08:41:59 -0400 (EDT) Date: Mon, 22 Aug 2005 08:36:44 -0400 (EDT) From: Charles Clancy X-X-Sender: clancy@ismene To: Shumon Huque Subject: Re: [SECMECH] Framework Bindings Vs. Mechanism Bridges In-Reply-To: <20050822044255.GC27685@isc.upenn.edu> Message-ID: References: <7210B31550AC934A8637D6619739CE6905C06510@e2k-sea-xch2.sea-alpha.cisco.com> <20050819210308.GI6659@binky.Central.Sun.COM> <20050820031035.GA5352@isc.upenn.edu> <43074F76.8000604@cs.umd.edu> <20050822044255.GC27685@isc.upenn.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: secmech@ietf.org, Nicolas Williams X-BeenThere: secmech@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security mechanisms BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: secmech-bounces@lists.ietf.org Errors-To: secmech-bounces@lists.ietf.org On Mon, 22 Aug 2005, Shumon Huque wrote: > I've read RFC 4017. My discomfort comes from the observation that it is > at best incomplete to point this out only for wireless LANs, since many > of these vulnerabilities are applicable to other link layers too. If I > use an EAP method that supports Kerberos on a wired ethernet for > example, the dictionary attack threat still exists. I do not find the > differential magnitude of the threat a very convincing argument. It > makes more sense to design security mechanisms with the uniform > assumption that the network is always hostile. As a responsible cryptographer, I would never advocate using an authentication protocol vulnerable to dictionary attacks over any PHY. However, I recognize more than just crypto goes into deciding what protocol to deploy. Were this true, everything would be one big PKI, and working groups like BTNS wouldn't exist. If people want to shoot themselves in the foot, it would be nice to minimize the damage. > This puts us in a position of having to say (whether we're using > EAP or not): "use Kerberos normally, except when running over > link layers X, Y and Z, in which case you should run it only in > a protected, cryptographically bound tunnel". If we need to address > the dictionary attack problem, I think we should discuss how to > do so in the Kerberos protocol directly. Perhaps that discussion > belongs in another group though .. I think something like "You SHOULD Kerberos in a cryptographically bound tunnel. If you don't, you're vulnerable to offline dictionary attacks. These types of attacks are significantly easier to execute in some link layers, e.g. X, Y, and Z." > I'm also not a fan of automatically assuming that a tunnel is the > right solution for many problems. If we are tunnelling in TLS for > example, I now have additional issues to deal with. Such as how to > query up-to-date certificate revocation status, and whether my > users are properly validating the certificates etc. I don't think SECMECH should try to change Kerberos, so all we can do is wrap something around it. The two basic ways to fix dictionary attacks is public-key crypto with a server-side cert, or the IPR-riddled EKE/SPEKE/SRP protocols. The latter would require Kerberos protocol changes. Personally, I think a native EAP-Kerberos method that utilizes DTLS is the way to go. In 802.11, it would look something like: STA AP AAA KDC |------------|-------------|-------------| EAP(DTLS(krb5)) krb5 <-------------------------><-------------> 802.1X AAA krb5 <------------><-----------><-------------> As for CRLs, it's likely that one's AAA server and KDC will be of similar configuration, on the same subnet, or even the same machine. If someone compromises your EAP server's private key, your KDC master secret won't be far behind. So, if you're ever at a point where you need to worry about CRLs, you have bigger problems. (Though, this argument doesn't necessarily apply to cross-real authentication, roaming, etc.) [ t. charles clancy ]--[ tcc@umd.edu ]--[ www.cs.umd.edu/~clancy ] [ computer science ]-----[ university of maryland | college park ] _______________________________________________ SECMECH mailing list SECMECH@lists.ietf.org https://www1.ietf.org/mailman/listinfo/secmech From secmech-bounces@lists.ietf.org Mon Aug 22 09:59:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7CpO-0006f7-Aa; Mon, 22 Aug 2005 09:59:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7CpM-0006f2-Ek for secmech@megatron.ietf.org; Mon, 22 Aug 2005 09:59:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16531 for ; Mon, 22 Aug 2005 09:59:02 -0400 (EDT) Received: from dirg.bris.ac.uk ([137.222.10.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7DPu-0001fO-MS for secmech@ietf.org; Mon, 22 Aug 2005 10:36:52 -0400 Received: from isis.bris.ac.uk ([137.222.10.63]) by dirg.bris.ac.uk with esmtp (Exim 4.51) id 1E7Cp1-00002H-Jk; Mon, 22 Aug 2005 14:58:45 +0100 Received: from cumulus.cse.bris.ac.uk ([137.222.12.162]) by isis.bris.ac.uk with esmtp (Exim 4.51) id 1E7Cnw-0000KJ-Qd; Mon, 22 Aug 2005 14:57:40 +0100 Date: Mon, 22 Aug 2005 14:57:35 +0100 From: Josh Howlett To: Charles Clancy , Shumon Huque Subject: Re: [SECMECH] Framework Bindings Vs. Mechanism Bridges Message-ID: <35850EE42DFD2824F0DDBBC8@cumulus> In-Reply-To: References: <7210B31550AC934A8637D6619739CE6905C06510@e2k-sea-xch2.sea-alpha. cisco.com> <20050819210308.GI6659@binky.Central.Sun.COM> <20050820031035.GA5352@isc.upenn.edu> <43074F76.8000604@cs.umd.edu> <20050822044255.GC27685@isc.upenn.edu> Originator-Info: login-token=Mulberry:01FEGtv3a2FyVXqvMeTnWx2jJRuOEYVHlvDzFIteEWREK2GA==; token_authority=postmaster@bristol.ac.uk X-Mailer: Mulberry/3.1.5 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: -2.8 X-Spam-Level: -- X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Cc: secmech@ietf.org, Nicolas Williams X-BeenThere: secmech@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Josh Howlett List-Id: Security mechanisms BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: secmech-bounces@lists.ietf.org Errors-To: secmech-bounces@lists.ietf.org --On Monday, August 22, 2005 08:36:44 -0400 Charles Clancy wrote: > Personally, I think a native EAP-Kerberos method that utilizes > DTLS is the way to go. Why not take something like TTLSv1 and define a Kerberos binding to it? josh. -- ----------------------------------------------------------- Josh Howlett, Networking & Digital Communications, Information Systems & Computing, University of Bristol, U.K. 'phone: 0117 928 7850 email: josh.howlett@bris.ac.uk ------------------------------------------------------------ _______________________________________________ SECMECH mailing list SECMECH@lists.ietf.org https://www1.ietf.org/mailman/listinfo/secmech From secmech-bounces@lists.ietf.org Mon Aug 22 10:25:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7DEy-0003Dt-Ly; Mon, 22 Aug 2005 10:25:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7DEx-0003Dj-Fu for secmech@megatron.ietf.org; Mon, 22 Aug 2005 10:25:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19072 for ; Mon, 22 Aug 2005 10:25:29 -0400 (EDT) Received: from carrierpigeon.cs.umd.edu ([128.8.129.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7DpU-0002VA-NW for secmech@ietf.org; Mon, 22 Aug 2005 11:03:19 -0400 Received: from ismene (ismene.cs.umd.edu [128.8.126.62]) by carrierpigeon.cs.umd.edu (8.12.10/8.12.5) with ESMTP id j7MEP9fD017031; Mon, 22 Aug 2005 10:25:11 -0400 (EDT) Date: Mon, 22 Aug 2005 10:19:53 -0400 (EDT) From: Charles Clancy X-X-Sender: clancy@ismene To: Josh Howlett Subject: Re: [SECMECH] Framework Bindings Vs. Mechanism Bridges In-Reply-To: <35850EE42DFD2824F0DDBBC8@cumulus> Message-ID: References: <7210B31550AC934A8637D6619739CE6905C06510@e2k-sea-xch2.sea-alpha. cisco.com> <20050819210308.GI6659@binky.Central.Sun.COM> <20050820031035.GA5352@isc.upenn.edu> <43074F76.8000604@cs.umd.edu> <20050822044255.GC27685@isc.upenn.edu> <35850EE42DFD2824F0DDBBC8@cumulus> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: secmech@ietf.org, Nicolas Williams X-BeenThere: secmech@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security mechanisms BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: secmech-bounces@lists.ietf.org Errors-To: secmech-bounces@lists.ietf.org On Mon, 22 Aug 2005, Josh Howlett wrote: > On Mon, 22 Aug 2005, Charles Clancy wrote: > >> Personally, I think a native EAP-Kerberos method that utilizes DTLS is >> the way to go. > > Why not take something like TTLSv1 and define a Kerberos binding to it? I guess it's a tradeoff between outside dependencies and reinventing the wheel. TTLS hasn't been on the list of EAP methods seeking standards-track action. Regardless, this is another approach I personally would be willing to support. [ t. charles clancy ]--[ tcc@umd.edu ]--[ www.cs.umd.edu/~clancy ] [ computer science ]-----[ university of maryland | college park ] _______________________________________________ SECMECH mailing list SECMECH@lists.ietf.org https://www1.ietf.org/mailman/listinfo/secmech From secmech-bounces@lists.ietf.org Mon Aug 22 10:50:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7DdS-0007ei-AC; Mon, 22 Aug 2005 10:50:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7DdQ-0007di-BS for secmech@megatron.ietf.org; Mon, 22 Aug 2005 10:50:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20565 for ; Mon, 22 Aug 2005 10:50:46 -0400 (EDT) Received: from dirg.bris.ac.uk ([137.222.10.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7EDz-0003EJ-N6 for secmech@ietf.org; Mon, 22 Aug 2005 11:28:37 -0400 Received: from isis.bris.ac.uk ([137.222.10.63]) by dirg.bris.ac.uk with esmtp (Exim 4.51) id 1E7DdC-0004L7-UI; Mon, 22 Aug 2005 15:50:36 +0100 Received: from cumulus.cse.bris.ac.uk ([137.222.12.162]) by isis.bris.ac.uk with esmtp (Exim 4.51) id 1E7DcN-00017U-Qj; Mon, 22 Aug 2005 15:49:47 +0100 Date: Mon, 22 Aug 2005 15:49:42 +0100 From: Josh Howlett To: Charles Clancy , Josh Howlett Subject: Re: [SECMECH] Framework Bindings Vs. Mechanism Bridges Message-ID: <1DCACCAC04655B3AFE9733A8@cumulus> In-Reply-To: References: <7210B31550AC934A8637D6619739CE6905C06510@e2k-sea-xch2.sea-alpha. cisco.com> <20050819210308.GI6659@binky.Central.Sun.COM> <20050820031035.GA5352@isc.upenn.edu> <43074F76.8000604@cs.umd.edu> <20050822044255.GC27685@isc.upenn.edu> <35850EE42DFD2824F0DDBBC8@cumulus> Originator-Info: login-token=Mulberry:01EGe1K3LcH5FT0PuKSnHX4p5N3umEUHWVF51E2+mCQD7cIA==; token_authority=postmaster@bristol.ac.uk X-Mailer: Mulberry/3.1.5 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: -2.8 X-Spam-Level: -- X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Cc: secmech@ietf.org, Nicolas Williams X-BeenThere: secmech@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Josh Howlett List-Id: Security mechanisms BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: secmech-bounces@lists.ietf.org Errors-To: secmech-bounces@lists.ietf.org --On Monday, August 22, 2005 10:19:53 -0400 Charles Clancy wrote: > On Mon, 22 Aug 2005, Josh Howlett wrote: > >> On Mon, 22 Aug 2005, Charles Clancy wrote: >> >>> Personally, I think a native EAP-Kerberos method that utilizes DTLS is >>> the way to go. >> >> Why not take something like TTLSv1 and define a Kerberos binding to it? > > I guess it's a tradeoff between outside dependencies and reinventing the > wheel. TTLS hasn't been on the list of EAP methods seeking > standards-track action. Regardless, this is another approach I > personally would be willing to support. Out of curiousity, what are the advantages of using native Kerberos, rather than PAP inside a tunneled method which the AAA server verifies against the KDC? (this is how FreeRADIUS currently implements "Kerberos" authentication). Perhaps I'm being a bit dim, but I feel like I'm missing the point. Or is the point simply to define a mechanism that EAP and GSS can share? josh. -- ----------------------------------------------------------- Josh Howlett, Networking & Digital Communications, Information Systems & Computing, University of Bristol, U.K. 'phone: 0117 928 7850 email: josh.howlett@bris.ac.uk ------------------------------------------------------------ _______________________________________________ SECMECH mailing list SECMECH@lists.ietf.org https://www1.ietf.org/mailman/listinfo/secmech From secmech-bounces@lists.ietf.org Mon Aug 22 10:54:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7Dgm-0008GA-26; Mon, 22 Aug 2005 10:54:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7Dgl-0008Fn-CK for secmech@megatron.ietf.org; Mon, 22 Aug 2005 10:54:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20784 for ; Mon, 22 Aug 2005 10:54:13 -0400 (EDT) Received: from carrierpigeon.cs.umd.edu ([128.8.129.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7EHK-0003M5-Jh for secmech@ietf.org; Mon, 22 Aug 2005 11:32:04 -0400 Received: from ismene (ismene.cs.umd.edu [128.8.126.62]) by carrierpigeon.cs.umd.edu (8.12.10/8.12.5) with ESMTP id j7MEs0fD017183; Mon, 22 Aug 2005 10:54:00 -0400 (EDT) Date: Mon, 22 Aug 2005 10:48:45 -0400 (EDT) From: Charles Clancy X-X-Sender: clancy@ismene To: Josh Howlett Subject: Re: [SECMECH] Framework Bindings Vs. Mechanism Bridges In-Reply-To: <1DCACCAC04655B3AFE9733A8@cumulus> Message-ID: References: <7210B31550AC934A8637D6619739CE6905C06510@e2k-sea-xch2.sea-alpha. cisco.com> <20050819210308.GI6659@binky.Central.Sun.COM> <20050820031035.GA5352@isc.upenn.edu> <43074F76.8000604@cs.umd.edu> <20050822044255.GC27685@isc.upenn.edu> <35850EE42DFD2824F0DDBBC8@cumulus> <1DCACCAC04655B3AFE9733A8@cumulus> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: secmech@ietf.org, Nicolas Williams X-BeenThere: secmech@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security mechanisms BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: secmech-bounces@lists.ietf.org Errors-To: secmech-bounces@lists.ietf.org On Mon, 22 Aug 2005, Josh Howlett wrote: > --On Monday, August 22, 2005 10:19:53 -0400 Charles Clancy > wrote: > >> On Mon, 22 Aug 2005, Josh Howlett wrote: >> >>> On Mon, 22 Aug 2005, Charles Clancy wrote: >>> >>>> Personally, I think a native EAP-Kerberos method that utilizes DTLS is >>>> the way to go. >>> >>> Why not take something like TTLSv1 and define a Kerberos binding to it? >> >> I guess it's a tradeoff between outside dependencies and reinventing the >> wheel. TTLS hasn't been on the list of EAP methods seeking >> standards-track action. Regardless, this is another approach I >> personally would be willing to support. > > Out of curiousity, what are the advantages of using native Kerberos, rather > than PAP inside a tunneled method which the AAA server verifies against the > KDC? (this is how FreeRADIUS currently implements "Kerberos" authentication). > > Perhaps I'm being a bit dim, but I feel like I'm missing the point. > > Or is the point simply to define a mechanism that EAP and GSS can share? I'm not very familiar with this mechanism, but it doesn't like like you could get a TGT as a result of your authentication. [ t. charles clancy ]--[ tcc@umd.edu ]--[ www.cs.umd.edu/~clancy ] [ computer science ]-----[ university of maryland | college park ] _______________________________________________ SECMECH mailing list SECMECH@lists.ietf.org https://www1.ietf.org/mailman/listinfo/secmech From secmech-bounces@lists.ietf.org Mon Aug 22 11:02:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7Dp6-0001x7-3E; Mon, 22 Aug 2005 11:02:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7Dp3-0001x2-Qi for secmech@megatron.ietf.org; Mon, 22 Aug 2005 11:02:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21370 for ; Mon, 22 Aug 2005 11:02:47 -0400 (EDT) Received: from dirg.bris.ac.uk ([137.222.10.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7EPd-0003eg-Ao for secmech@ietf.org; Mon, 22 Aug 2005 11:40:38 -0400 Received: from isis.bris.ac.uk ([137.222.10.63]) by dirg.bris.ac.uk with esmtp (Exim 4.51) id 1E7Dop-0005Ov-Vp; Mon, 22 Aug 2005 16:02:38 +0100 Received: from cumulus.cse.bris.ac.uk ([137.222.12.162]) by isis.bris.ac.uk with esmtp (Exim 4.51) id 1E7DnI-0001Gx-89; Mon, 22 Aug 2005 16:01:03 +0100 Date: Mon, 22 Aug 2005 16:00:59 +0100 From: Josh Howlett To: Charles Clancy , Josh Howlett Subject: Re: [SECMECH] Framework Bindings Vs. Mechanism Bridges Message-ID: <1CDADF31BB735C0327BF3EBF@cumulus> In-Reply-To: References: <7210B31550AC934A8637D6619739CE6905C06510@e2k-sea-xch2.sea-alpha. cisco.com> <20050819210308.GI6659@binky.Central.Sun.COM> <20050820031035.GA5352@isc.upenn.edu> <43074F76.8000604@cs.umd.edu> <20050822044255.GC27685@isc.upenn.edu> <35850EE42DFD2824F0DDBBC8@cumulus> <1DCACCAC04655B3AFE9733A8@cumulus> Originator-Info: login-token=Mulberry:015o9BU0gEq7kp+IeyIEf/bsYjBnWsJku9o8UaA3WqFhQErA==; token_authority=postmaster@bristol.ac.uk X-Mailer: Mulberry/3.1.5 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: -2.8 X-Spam-Level: -- X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Cc: secmech@ietf.org, Nicolas Williams X-BeenThere: secmech@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Josh Howlett List-Id: Security mechanisms BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: secmech-bounces@lists.ietf.org Errors-To: secmech-bounces@lists.ietf.org --On Monday, August 22, 2005 10:48:45 -0400 Charles Clancy wrote: > On Mon, 22 Aug 2005, Josh Howlett wrote: >> Perhaps I'm being a bit dim, but I feel like I'm missing the point. >> >> Or is the point simply to define a mechanism that EAP and GSS can share? > > I'm not very familiar with this mechanism, but it doesn't like like you > could get a TGT as a result of your authentication. D'oh. I was being dim :-) thanks, josh. -- ----------------------------------------------------------- Josh Howlett, Networking & Digital Communications, Information Systems & Computing, University of Bristol, U.K. 'phone: 0117 928 7850 email: josh.howlett@bris.ac.uk ------------------------------------------------------------ _______________________________________________ SECMECH mailing list SECMECH@lists.ietf.org https://www1.ietf.org/mailman/listinfo/secmech From secmech-bounces@lists.ietf.org Mon Aug 22 11:06:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7DsH-0002Oh-QO; Mon, 22 Aug 2005 11:06:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7DsG-0002Oc-6w for secmech@megatron.ietf.org; Mon, 22 Aug 2005 11:06:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21487 for ; Mon, 22 Aug 2005 11:06:05 -0400 (EDT) Received: from talkeetna.isc-net.upenn.edu ([128.91.197.188]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7ESo-0003jq-JD for secmech@ietf.org; Mon, 22 Aug 2005 11:43:56 -0400 Received: by talkeetna.isc-net.upenn.edu (Postfix, from userid 4127) id 930E4443F; Mon, 22 Aug 2005 11:06:04 -0400 (EDT) Date: Mon, 22 Aug 2005 11:06:04 -0400 From: Shumon Huque To: Charles Clancy Subject: Re: [SECMECH] Framework Bindings Vs. Mechanism Bridges Message-ID: <20050822150604.GA1725@isc.upenn.edu> References: <20050819210308.GI6659@binky.Central.Sun.COM> <20050820031035.GA5352@isc.upenn.edu> <43074F76.8000604@cs.umd.edu> <20050822044255.GC27685@isc.upenn.edu> <35850EE42DFD2824F0DDBBC8@cumulus> <1DCACCAC04655B3AFE9733A8@cumulus> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Organization: University of Pennsylvania X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: secmech@ietf.org, Nicolas Williams X-BeenThere: secmech@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security mechanisms BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: secmech-bounces@lists.ietf.org Errors-To: secmech-bounces@lists.ietf.org On Mon, Aug 22, 2005 at 10:48:45AM -0400, Charles Clancy wrote: > On Mon, 22 Aug 2005, Josh Howlett wrote: > > >Out of curiousity, what are the advantages of using native Kerberos, > >rather than PAP inside a tunneled method which the AAA server verifies > >against the KDC? (this is how FreeRADIUS currently implements "Kerberos" > >authentication). > > > >Perhaps I'm being a bit dim, but I feel like I'm missing the point. > > > >Or is the point simply to define a mechanism that EAP and GSS can share? > > I'm not very familiar with this mechanism, but it doesn't like like you > could get a TGT as a result of your authentication. That's right. TTLS+PAP used in this way is performing Kerberos password verification via the AAA server. It isn't native Kerberos authentication. I know that it's commonly done, but many consider it to be a misuse of Kerberos. _______________________________________________ SECMECH mailing list SECMECH@lists.ietf.org https://www1.ietf.org/mailman/listinfo/secmech From secmech-bounces@lists.ietf.org Mon Aug 22 11:30:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7EFu-0007li-0d; Mon, 22 Aug 2005 11:30:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7EFs-0007lA-Rf for secmech@megatron.ietf.org; Mon, 22 Aug 2005 11:30:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22918 for ; Mon, 22 Aug 2005 11:30:28 -0400 (EDT) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7EqQ-0004Y8-8J for secmech@ietf.org; Mon, 22 Aug 2005 12:08:19 -0400 Received: from centralmail2brm.Central.Sun.COM (centralmail2brm.central.sun.com [129.147.62.14]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j7MFURWR002388 for ; Mon, 22 Aug 2005 09:30:27 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id j7MFUPLG005838 for ; Mon, 22 Aug 2005 09:30:27 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id j7MFULR1008736; Mon, 22 Aug 2005 10:30:21 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id j7MFUJcN008735; Mon, 22 Aug 2005 10:30:19 -0500 (CDT) Date: Mon, 22 Aug 2005 10:30:19 -0500 From: Nicolas Williams To: Shumon Huque Subject: Re: [SECMECH] Framework Bindings Vs. Mechanism Bridges Message-ID: <20050822153019.GC7789@binky.Central.Sun.COM> References: <7210B31550AC934A8637D6619739CE6905C06510@e2k-sea-xch2.sea-alpha.cisco.com> <20050819210308.GI6659@binky.Central.Sun.COM> <20050820031035.GA5352@isc.upenn.edu> <20050820055834.GA7789@binky.Central.Sun.COM> <20050822041808.GB27685@isc.upenn.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050822041808.GB27685@isc.upenn.edu> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: secmech@ietf.org X-BeenThere: secmech@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security mechanisms BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: secmech-bounces@lists.ietf.org Errors-To: secmech-bounces@lists.ietf.org On Mon, Aug 22, 2005 at 12:18:08AM -0400, Shumon Huque wrote: > On Sat, Aug 20, 2005 at 12:58:41AM -0500, Nicolas Williams wrote: > > On Fri, Aug 19, 2005 at 11:10:35PM -0400, Shumon Huque wrote: > > > I think the Kerberos community needs to work on standardizing password > > > based pre-authentication mechanisms invulnerable to dictionary attack > > > (perhaps EKE, AEKE, SPEKE, SRP etc). Hardware pre-authentication > > > mitigates the threat somewhat. But PKINIT isn't really an option for > > > the many sites that don't plan to authenticate users with public key > > > credentials (or deploy PKI). > > > > Did you attend the SACRED WG meeting at IETF 63? > > No, but I just read a summary of their session. The credential > mobility stuff isn't really relevant to (non PKINIT) Kerberos > sites. So I assume you are referring to the IPR issues with those > protocols. It sounds like there might be some hope though! The SACRED protocol wasn't the centerpiece of the meeting. The issues around strong password protocols, and alternatives, were. > > > At one time, some of us were talking about an EAP method that > > > transported Kerberos messages directly. It seems to me that putting > > > some effort into completing that work would be immediately useful > > > to Kerberos sites that need to deploy 802.1X or 802.11i soon. > > > > Indeed. That would be an example of framework bindings of a security > > mechanisms, as opposed to EAP-GSS, which would be a bridge. > > Agreed. > > Some folks at Penn are interested in working on an EAP-Kerberos > method. Is there anyone else interested in this? I'd help review, of course. _______________________________________________ SECMECH mailing list SECMECH@lists.ietf.org https://www1.ietf.org/mailman/listinfo/secmech From secmech-bounces@lists.ietf.org Mon Aug 22 11:38:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7ENU-0000xS-1w; Mon, 22 Aug 2005 11:38:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7ENS-0000ws-Gx for secmech@megatron.ietf.org; Mon, 22 Aug 2005 11:38:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23278 for ; Mon, 22 Aug 2005 11:38:19 -0400 (EDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7Ey0-0004m0-4Y for secmech@ietf.org; Mon, 22 Aug 2005 12:16:11 -0400 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id j7MFcH2B000617 for ; Mon, 22 Aug 2005 08:38:17 -0700 (PDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id j7MFcGLG011617 for ; Mon, 22 Aug 2005 09:38:17 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id j7MFcGLI008745; Mon, 22 Aug 2005 10:38:16 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id j7MFcG83008744; Mon, 22 Aug 2005 10:38:16 -0500 (CDT) Date: Mon, 22 Aug 2005 10:38:16 -0500 From: Nicolas Williams To: Shumon Huque Subject: Re: [SECMECH] Framework Bindings Vs. Mechanism Bridges Message-ID: <20050822153816.GD7789@binky.Central.Sun.COM> References: <7210B31550AC934A8637D6619739CE6905C06510@e2k-sea-xch2.sea-alpha.cisco.com> <20050819210308.GI6659@binky.Central.Sun.COM> <20050820031035.GA5352@isc.upenn.edu> <43074F76.8000604@cs.umd.edu> <20050822044255.GC27685@isc.upenn.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050822044255.GC27685@isc.upenn.edu> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: secmech@ietf.org X-BeenThere: secmech@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security mechanisms BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: secmech-bounces@lists.ietf.org Errors-To: secmech-bounces@lists.ietf.org On Mon, Aug 22, 2005 at 12:42:55AM -0400, Shumon Huque wrote: > I've read RFC 4017. My discomfort comes from the observation that > it is at best incomplete to point this out only for wireless LANs, > since many of these vulnerabilities are applicable to other link > layers too. If I use an EAP method that supports Kerberos on a > wired ethernet for example, the dictionary attack threat still > exists. I do not find the differential magnitude of the threat a > very convincing argument. It makes more sense to design security > mechanisms with the uniform assumption that the network is always > hostile. > > This puts us in a position of having to say (whether we're using > EAP or not): "use Kerberos normally, except when running over > link layers X, Y and Z, in which case you should run it only in > a protected, cryptographically bound tunnel". If we need to address > the dictionary attack problem, I think we should discuss how to > do so in the Kerberos protocol directly. Perhaps that discussion > belongs in another group though .. BTW, and for the benefit of lurkers and future readers of this list, the password cracking issues, for Kerberos V apply only to the AS KDC exchanges, and only when using PA-ENC-TIMESTAMP pre-auth. And that's relevant to EAP only because we all agree that we'd want to tunnel KDC exchanges through EAP as that would be the only way to reach the KDC for EAP client in many, many cases. > I'm also not a fan of automatically assuming that a tunnel is the > right solution for many problems. If we are tunnelling in TLS for > example, I now have additional issues to deal with. Such as how to > query up-to-date certificate revocation status, and whether my > users are properly validating the certificates etc. Agreed. But you can do other things too. Like: ignore this issue at first and do cryptographic binding between the inner and tunnel layers and, if the result succeeds in real-time (assuming that offline password dictionary attacks can't be done in real-time), "learn" the server cert; the problem is what to do if the password-based mechanism fails... (e.g., tell the user to call his/her helpdesk, which need not be as easy for the user to do, or as likely that the user would actually do it, as one might hope). Nico -- _______________________________________________ SECMECH mailing list SECMECH@lists.ietf.org https://www1.ietf.org/mailman/listinfo/secmech From secmech-bounces@lists.ietf.org Mon Aug 22 11:40:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7EPr-0001J2-DN; Mon, 22 Aug 2005 11:40:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7EPp-0001I2-1n for secmech@megatron.ietf.org; Mon, 22 Aug 2005 11:40:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23386 for ; Mon, 22 Aug 2005 11:40:46 -0400 (EDT) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7F0P-0004pB-Q0 for secmech@ietf.org; Mon, 22 Aug 2005 12:18:38 -0400 Received: from centralmail2brm.Central.Sun.COM (centralmail2brm.central.sun.com [129.147.62.14]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j7MFelWR015125 for ; Mon, 22 Aug 2005 09:40:47 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id j7MFekLI013268 for ; Mon, 22 Aug 2005 09:40:47 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id j7MFeiLd008752; Mon, 22 Aug 2005 10:40:44 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id j7MFeipY008751; Mon, 22 Aug 2005 10:40:44 -0500 (CDT) Date: Mon, 22 Aug 2005 10:40:44 -0500 From: Nicolas Williams To: Charles Clancy Subject: Re: [SECMECH] Framework Bindings Vs. Mechanism Bridges Message-ID: <20050822154044.GE7789@binky.Central.Sun.COM> References: <20050819210308.GI6659@binky.Central.Sun.COM> <20050820031035.GA5352@isc.upenn.edu> <43074F76.8000604@cs.umd.edu> <20050822044255.GC27685@isc.upenn.edu> <35850EE42DFD2824F0DDBBC8@cumulus> <1DCACCAC04655B3AFE9733A8@cumulus> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: secmech@ietf.org X-BeenThere: secmech@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security mechanisms BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: secmech-bounces@lists.ietf.org Errors-To: secmech-bounces@lists.ietf.org On Mon, Aug 22, 2005 at 10:48:45AM -0400, Charles Clancy wrote: > On Mon, 22 Aug 2005, Josh Howlett wrote: > >Out of curiousity, what are the advantages of using native Kerberos, > >rather than PAP inside a tunneled method which the AAA server verifies > >against the KDC? (this is how FreeRADIUS currently implements "Kerberos" > >authentication). > > > >Perhaps I'm being a bit dim, but I feel like I'm missing the point. > > > >Or is the point simply to define a mechanism that EAP and GSS can share? > > I'm not very familiar with this mechanism, but it doesn't like like you > could get a TGT as a result of your authentication. Exactly. Plus, you don't get the benefit of new Kerberos V pre-auth mechanisms, (e.g., PKINIT). Nico -- _______________________________________________ SECMECH mailing list SECMECH@lists.ietf.org https://www1.ietf.org/mailman/listinfo/secmech From secmech-bounces@lists.ietf.org Mon Aug 22 20:12:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7MNa-00058Q-6U; Mon, 22 Aug 2005 20:11:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7MNZ-00058J-Nv for secmech@megatron.ietf.org; Mon, 22 Aug 2005 20:11:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06029 for ; Mon, 22 Aug 2005 20:11:00 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7MNZ-0008CZ-CY for secmech@ietf.org; Mon, 22 Aug 2005 20:11:02 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 22 Aug 2005 17:10:51 -0700 X-IronPort-AV: i="3.96,132,1122879600"; d="scan'208"; a="334642226:sNHT28725492" Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j7N0Anoo023179 for ; Mon, 22 Aug 2005 17:10:49 -0700 (PDT) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Mon, 22 Aug 2005 17:15:40 -0700 Message-ID: <7210B31550AC934A8637D6619739CE6905C06A59@e2k-sea-xch2.sea-alpha.cisco.com> Thread-Topic: Approach to GUAM work Thread-Index: AcWndxyGgs4vM1VaQGqxUPaiEN1CdA== From: "Salowey, Joe" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: quoted-printable Cc: Subject: [SECMECH] Approach to GUAM work X-BeenThere: secmech@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security mechanisms BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: secmech-bounces@lists.ietf.org Errors-To: secmech-bounces@lists.ietf.org We have had some discussion of two different approaches on the list (framework bindings and bridge methods). I think discussion is leaning towards framework bindings as a good basic approach, realizing this could be augmented by bridge mechanism and other tools for achieving bindings.=20 Here is a proposal for moving forward with this: 1. Document the requirements for creating mechanisms that can be bound to any (GSS-API, SASL, EAP) framework 2. Identify tools such as mechanisms bridges that can help facilitate the binding. This could include a GSS-API EAP mechanism, pointers to existing security layers that could be used (ESP, GSS-KRB,...), automatic numbering and naming conventions, perhaps a GSS-API to AAA/EAP bridge, tunneling... 3. Document any new tools (some may already exist) and document a template for specifying a GUAM mechanism. The template document would provide the pointers to tools.=20 Is this a reasonable approach? =20 Who is willing to author/contribute to 1, 2 and 3? =20 Who is willing to review documents from 1 and 3 (I'm not sure that 1 will be published as an RFC, but the requirements definitely need to be reviewed)? Thanks, Joe _______________________________________________ SECMECH mailing list SECMECH@lists.ietf.org https://www1.ietf.org/mailman/listinfo/secmech From secmech-bounces@lists.ietf.org Mon Aug 22 20:50:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7MzQ-0005eY-O1; Mon, 22 Aug 2005 20:50:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7MzO-0005eN-Ok for secmech@megatron.ietf.org; Mon, 22 Aug 2005 20:50:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07430 for ; Mon, 22 Aug 2005 20:50:05 -0400 (EDT) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7MzO-0000hE-O8 for secmech@ietf.org; Mon, 22 Aug 2005 20:50:08 -0400 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-4.cisco.com with ESMTP; 22 Aug 2005 17:49:56 -0700 Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j7N0npZ1014903 for ; Mon, 22 Aug 2005 17:49:51 -0700 (PDT) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Mon, 22 Aug 2005 17:54:45 -0700 Message-ID: <7210B31550AC934A8637D6619739CE6905C06A6B@e2k-sea-xch2.sea-alpha.cisco.com> Thread-Topic: Method work Thread-Index: AcWnfJKy7ng8opthRdeidrD8Zos7SA== From: "Salowey, Joe" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: quoted-printable Cc: Subject: [SECMECH] Method work X-BeenThere: secmech@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security mechanisms BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: secmech-bounces@lists.ietf.org Errors-To: secmech-bounces@lists.ietf.org I would like to identify which mechanism types there is interest in working on. Below is a list of various authentication methods that people have expressed interest in having support for in EAP and other frameworks. It may not be the case that we need a separate mechanism for each of these. I'd like to know who has interest in contributing and reviewing (please indicate either or both) specifications for each of these mechanism types. =20 1. X.509 Certificate credentials - (possible revision of EAP-TLS (RFC2716)) - applicable to EAP, possibly applicable to GSS and SASL. Desired by IEEE 802.11 for EAP. 2. Shared Secret - pre-shared secret method. Applicable to EAP and GSS, possibly SASL. Desired by IEEE 802.11 for EAP. =20 3. Password based - essentially a shared secret mechanism that provides resistance to dictionary attacks. It should support various backend databases of password that use different storage techniques and perhaps support for one time tokens as well. Could use something related to EKE or a tunneling approach. Applicable to EAP, GSS, and SASL. Desired by IEEE 802.11 for EAP.=20 4. Tunneling - a tunneling method is useful to protect weaker authentication mechanisms. Tunneling methods are also used to exchange other types of authentication data. Applicability EAP and GSS possibly SASL.=20 5. Kerberos - Something that provide for initial authentication and a strategy for resisting dictionary attacks. Applicable to EAP, possibly GSS.=20 Thanks, Joe _______________________________________________ SECMECH mailing list SECMECH@lists.ietf.org https://www1.ietf.org/mailman/listinfo/secmech From secmech-bounces@lists.ietf.org Wed Aug 24 12:50:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7ySR-0002Ga-3c; Wed, 24 Aug 2005 12:50:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7ySP-0002Fn-1A for secmech@megatron.ietf.org; Wed, 24 Aug 2005 12:50:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04252 for ; Wed, 24 Aug 2005 12:50:30 -0400 (EDT) Received: from mx5.informatik.uni-tuebingen.de ([134.2.12.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7ySj-0007S4-Kl for secmech@ietf.org; Wed, 24 Aug 2005 12:50:55 -0400 Received: from localhost (loopback [127.0.0.1]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id C73A211A; Wed, 24 Aug 2005 18:50:18 +0200 (MST) Received: from mx5.informatik.uni-tuebingen.de ([127.0.0.1]) by localhost (mx5 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20350-05; Wed, 24 Aug 2005 18:50:16 +0200 (DFT) Received: from [127.0.0.1] (rouen.Informatik.Uni-Tuebingen.De [134.2.11.152]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id B56E6117; Wed, 24 Aug 2005 18:50:15 +0200 (MST) Message-ID: <430CA545.3020109@uni-tuebingen.de> Date: Wed, 24 Aug 2005 18:50:13 +0200 From: Ali Fessi User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: secmech@ietf.org Subject: Re: [SECMECH] Framework Bindings Vs. Mechanism Bridges References: <20050819210308.GI6659@binky.Central.Sun.COM> <20050820031035.GA5352@isc.upenn.edu> <43074F76.8000604@cs.umd.edu> <20050822044255.GC27685@isc.upenn.edu> <35850EE42DFD2824F0DDBBC8@cumulus> <1DCACCAC04655B3AFE9733A8@cumulus> <20050822154044.GE7789@binky.Central.Sun.COM> In-Reply-To: <20050822154044.GE7789@binky.Central.Sun.COM> X-Virus-Scanned: by amavisd-new (McAfee AntiVirus) at informatik.uni-tuebingen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Cc: Bernard Aboba X-BeenThere: secmech@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security mechanisms BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0514063642==" Sender: secmech-bounces@lists.ietf.org Errors-To: secmech-bounces@lists.ietf.org This is a cryptographically signed message in MIME format. --===============0514063642== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020708050000070706060106" This is a cryptographically signed message in MIME format. --------------ms020708050000070706060106 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, I still don't get the point for using Kerberos as EAP method. - What is the benefit of having a TGT as a result of the authentication for EAP?!! With native Kerberos, the TGT is used to get a service ticket from the TGS to access kerberized services. What would be here the kerberized service?! is it just the "network access"?! or is anyone planning to realize different kerberized services at layer 2? Is this a new requirement for 802.11? - What would be the benefit of such a EAP-Kerberos (or EAP-IAKERB) method compared to existing EAP methods that are currently used, e.g. EAP-TTLS+PAP with a radius/diameter server at the end (except that this method might be a "misuse" of kerberos as mentioned earlier in this mailing list). What would be the arguments that would motivate operators to substitute their infrastructure with a new one supporting EAP-Kerberos or EAP-IAKERB? - Would PKINIT really be an advantage for EAP?! The point with PKINIT is that it supports authentication of the client with public key cryptography. But isn't this already covered by EAP-TLS? - Wouldn't be helpful to talk to the authors of the EAP GSS draft (Aboba) and find out why they stopped to work on this document? IMHO, it seems that it makes sense to combine different frameworks with different authentication mechanisms as intended by secmech. But I just would like to have some clarification, why this would be useful. Any comments are welcome! Thanks, Ali. -- Ali Fessi Computer Networks and Internet Wilhelm Schickard Institute for Computer Science University of Tuebingen, Germany Phone: +49 7071 29-70534 / Fax: +49 7071 29-5220 EMail: ali.fessi@uni-tuebingen.de Web: http://net.informatik.uni-tuebingen.de/~fessi/ Nicolas Williams wrote: > On Mon, Aug 22, 2005 at 10:48:45AM -0400, Charles Clancy wrote: > >>On Mon, 22 Aug 2005, Josh Howlett wrote: >> >>>Out of curiousity, what are the advantages of using native Kerberos, >>>rather than PAP inside a tunneled method which the AAA server verifies >>>against the KDC? (this is how FreeRADIUS currently implements "Kerberos" >>>authentication). >>> >>>Perhaps I'm being a bit dim, but I feel like I'm missing the point. >>> >>>Or is the point simply to define a mechanism that EAP and GSS can share? >> >>I'm not very familiar with this mechanism, but it doesn't like like you >>could get a TGT as a result of your authentication. > > > Exactly. Plus, you don't get the benefit of new Kerberos V pre-auth > mechanisms, (e.g., PKINIT). > > Nico --------------ms020708050000070706060106 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGOTCC AvIwggJboAMCAQICAw37QTANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDUwMjA3MTQxOTE3WhcNMDYwMjA3MTQxOTE3 WjBdMQ4wDAYDVQQEEwVGZXNzaTEMMAoGA1UEKhMDQWxpMRIwEAYDVQQDEwlBbGkgRmVzc2kx KTAnBgkqhkiG9w0BCQEWGmFsaS5mZXNzaUB1bmktdHVlYmluZ2VuLmRlMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2SH7H2KK6H3jYVitFjxylVOsL/TRXXnwlqTjUQmPU1yl 0sK3nv5xWD2lHqL/5v+n2YjYqi2kdG6ORyks51/QKVOB0NYCEVlQFWdT5DNNw6RvjGQd715K XXO4b7XRQJFcZc1Qc8L2G/fER9fvWHfCX09KhFqrJRQ2mahZ+sWcoXZlV9k5M1/jPTECR9dC iVdtI4SYdye9Aryu/P5S6mT0XgZ4JDb41qYTlUyYQpqp77VOFG4odh0vrINac0KdlHrhCjDJ PQ1c23a8/s7VbdG44GsGw5SoFJiDXjQrLhsxh62c88qhNiqMtRPvsnxgqUvv0YKEvYCS5O0e nFiUakz/kwIDAQABozcwNTAlBgNVHREEHjAcgRphbGkuZmVzc2lAdW5pLXR1ZWJpbmdlbi5k ZTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAAm748hVdHcNCjCezGHTtFHr7n/K /EnCMrAABvW3oGjM8C9xuzULk7TUubotA1GROGFIcQfDIOqDGirope4asWdEiG9NARtlJkpc JTXv0v1Dl6vEZhXLGF7efTUCI6/mANlQ3sLc22vqceYU/kDSYUijRCz68F0gyiWJ9Z/wR7ic MIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEk MCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxw ZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIz NTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkp IEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGf MA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31 W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV 84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GU MIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50 aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkG A1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUF AAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3h YWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQ Gls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAkQwggJAAgEBMGkwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMN+0EwCQYFKw4DAhoFAKCBsTAYBgkq hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNTA4MjQxNjUwMTNaMCMG CSqGSIb3DQEJBDEWBBTz1av9cullW22hYVsOxXkyfdACqzBSBgkqhkiG9w0BCQ8xRTBDMAoG CCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggq hkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASCAQCiqT+7PGb+PI0R/nnELtIXl55ZlpdwuO5f cN0iS2hzEPFUXcesVoFT5Xzc9wjBCL+q0tywHDtdUuV0JaKEy4ZRfhun5zd3DMo/ehI27WO1 wQ2/MDO1dVTVWf06v2LB8mwDy6xyjrOZTQUyGHSv2kNyj+BPNEih4ekOTHkWsCaUpCjE9jUP s0MqQhrbzJ0lELHxi56nPUi7NM1dugeOCYw9K4jNdkoupaniaweJOBml9W+18YU/YX93sDwk q4Q9IFMzmRlH7CQiwh8pocVeGSherziDCQnYG7/eVX8cBdPvrSFXCR+0YBN8r2g/2EUaKqng /bWgEPYQrpCM0RXh93uhAAAAAAAA --------------ms020708050000070706060106-- --===============0514063642== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ SECMECH mailing list SECMECH@lists.ietf.org https://www1.ietf.org/mailman/listinfo/secmech --===============0514063642==-- From secmech-bounces@lists.ietf.org Wed Aug 24 13:50:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7zOt-00018E-H2; Wed, 24 Aug 2005 13:50:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7zOq-000189-QC for secmech@megatron.ietf.org; Wed, 24 Aug 2005 13:50:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08304 for ; Wed, 24 Aug 2005 13:50:55 -0400 (EDT) Received: from carrierpigeon.cs.umd.edu ([128.8.129.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7zPB-0001LF-Db for secmech@ietf.org; Wed, 24 Aug 2005 13:51:19 -0400 Received: from ismene (ismene.cs.umd.edu [128.8.126.62]) by carrierpigeon.cs.umd.edu (8.12.10/8.12.5) with ESMTP id j7OHobfD008590; Wed, 24 Aug 2005 13:50:37 -0400 (EDT) Date: Wed, 24 Aug 2005 13:45:19 -0400 (EDT) From: Charles Clancy X-X-Sender: clancy@ismene To: Ali Fessi Subject: Re: [SECMECH] Framework Bindings Vs. Mechanism Bridges In-Reply-To: <430CA545.3020109@uni-tuebingen.de> Message-ID: References: <20050819210308.GI6659@binky.Central.Sun.COM> <20050820031035.GA5352@isc.upenn.edu> <43074F76.8000604@cs.umd.edu> <20050822044255.GC27685@isc.upenn.edu> <35850EE42DFD2824F0DDBBC8@cumulus> <1DCACCAC04655B3AFE9733A8@cumulus> <20050822154044.GE7789@binky.Central.Sun.COM> <430CA545.3020109@uni-tuebingen.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: secmech@ietf.org, Bernard Aboba X-BeenThere: secmech@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security mechanisms BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: secmech-bounces@lists.ietf.org Errors-To: secmech-bounces@lists.ietf.org On Wed, 24 Aug 2005, Ali Fessi wrote: > - What is the benefit of having a TGT as a result of the authentication > for EAP?!! With native Kerberos, the TGT is used to get a service ticket > from the TGS to access kerberized services. What would be here the > kerberized service?! is it just the "network access"?! or is anyone > planning to realize different kerberized services at layer 2? Is this a > new requirement for 802.11? Not only would it allow you to obtain a TGT, it would also allow you to use an existing TGT to get a "service ticket" for network access. This is probably the less-likely scenario though, since talking to a KDC requires network access in the first place. Consider the case of Win32 AFS on a laptop. You sign onto the wireless network, and you can get a service ticket for AFS without having to reauthenticate to the KDC. Another interesting idea would be to treat each 802.11i AP as a service, and you could obtain service tickets for them as you roam. > - Would PKINIT really be an advantage for EAP?! The point with PKINIT is > that it supports authentication of the client with public key > cryptography. But isn't this already covered by EAP-TLS? Well it gets you a TGT. As long as you think getting a TGT is a good idea, then PKINIT would seem useful. [ t. charles clancy ]--[ tcc@umd.edu ]--[ www.cs.umd.edu/~clancy ] [ computer science ]-----[ university of maryland | college park ] _______________________________________________ SECMECH mailing list SECMECH@lists.ietf.org https://www1.ietf.org/mailman/listinfo/secmech From secmech-bounces@lists.ietf.org Wed Aug 24 14:27:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7zy5-0004tg-0d; Wed, 24 Aug 2005 14:27:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7zy2-0004tb-QB for secmech@megatron.ietf.org; Wed, 24 Aug 2005 14:27:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10015 for ; Wed, 24 Aug 2005 14:27:17 -0400 (EDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7zyL-0002TI-BT for secmech@ietf.org; Wed, 24 Aug 2005 14:27:42 -0400 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id j7OIR9HT005206 for ; Wed, 24 Aug 2005 11:27:09 -0700 (PDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id j7OIR8LG007409 for ; Wed, 24 Aug 2005 12:27:08 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id j7OIR7W8010279; Wed, 24 Aug 2005 13:27:07 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id j7OIR5t4010278; Wed, 24 Aug 2005 13:27:05 -0500 (CDT) Date: Wed, 24 Aug 2005 13:27:05 -0500 From: Nicolas Williams To: Charles Clancy Subject: Re: [SECMECH] Framework Bindings Vs. Mechanism Bridges Message-ID: <20050824182705.GE10174@binky.Central.Sun.COM> References: <43074F76.8000604@cs.umd.edu> <20050822044255.GC27685@isc.upenn.edu> <35850EE42DFD2824F0DDBBC8@cumulus> <1DCACCAC04655B3AFE9733A8@cumulus> <20050822154044.GE7789@binky.Central.Sun.COM> <430CA545.3020109@uni-tuebingen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: secmech@ietf.org, Bernard Aboba X-BeenThere: secmech@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security mechanisms BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: secmech-bounces@lists.ietf.org Errors-To: secmech-bounces@lists.ietf.org On Wed, Aug 24, 2005 at 01:45:19PM -0400, Charles Clancy wrote: > On Wed, 24 Aug 2005, Ali Fessi wrote: > > >- What is the benefit of having a TGT as a result of the authentication > >for EAP?!! With native Kerberos, the TGT is used to get a service ticket > >from the TGS to access kerberized services. What would be here the > >kerberized service?! is it just the "network access"?! or is anyone > >planning to realize different kerberized services at layer 2? Is this a > >new requirement for 802.11? > > Not only would it allow you to obtain a TGT, it would also allow you to > use an existing TGT to get a "service ticket" for network access. This is > probably the less-likely scenario though, since talking to a KDC requires > network access in the first place. Think fast reconnection... Not such an unlikely scenario, IMO :) But the TGT could, and I expect would be useful after all the EAP business is done. Think of an IPsec VPN client that uses IKEv2 w/ EAP w/ EAP-IAKERB to connect to the SG and which then also needs a TGT for other services in the private network once the tunnel is up. Here Kerberos V credentials are useful for obtaining network access and also for obtaining access to many other services one the network is up. > Another interesting idea would be to treat each 802.11i AP as a service, > and you could obtain service tickets for them as you roam. Again, "fast reconnect." The first connection requires an AS exchange to get a TGT and a TGS exchange to get a service ticket, plus an AP exchange to authenticate with the AP (oops, too many meanings for 'AP'); subsequent connections to the same AP prior to service ticket expiration require only an AP exchange. > >- Would PKINIT really be an advantage for EAP?! The point with PKINIT is > >that it supports authentication of the client with public key > >cryptography. But isn't this already covered by EAP-TLS? > > Well it gets you a TGT. As long as you think getting a TGT is a good > idea, then PKINIT would seem useful. Indeed. Nico -- _______________________________________________ SECMECH mailing list SECMECH@lists.ietf.org https://www1.ietf.org/mailman/listinfo/secmech From secmech-bounces@lists.ietf.org Wed Aug 24 17:22:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E82hi-0006cY-6J; Wed, 24 Aug 2005 17:22:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E80TQ-0005hs-VC for secmech@megatron.ietf.org; Wed, 24 Aug 2005 14:59:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11448 for ; Wed, 24 Aug 2005 14:59:43 -0400 (EDT) Received: from outbound.mailhop.org ([63.208.196.171] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E80Tn-0003Rn-Sx for secmech@ietf.org; Wed, 24 Aug 2005 15:00:08 -0400 Received: from c-67-182-139-247.hsd1.wa.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.51) id 1E80TO-000NJG-Py; Wed, 24 Aug 2005 14:59:43 -0400 Received: by internaut.com (Postfix, from userid 1000) id E38C560DC2; Wed, 24 Aug 2005 11:59:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by internaut.com (Postfix) with ESMTP id D5CC260DAD; Wed, 24 Aug 2005 11:59:41 -0700 (PDT) X-Mail-Handler: MailHop Outbound by DynDNS.org X-Originating-IP: 67.182.139.247 X-Report-Abuse-To: abuse@dyndns.org (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba Date: Wed, 24 Aug 2005 11:59:41 -0700 (PDT) From: Bernard Aboba To: Ali Fessi Subject: Re: [SECMECH] Framework Bindings Vs. Mechanism Bridges In-Reply-To: <430CA545.3020109@uni-tuebingen.de> Message-ID: References: <20050819210308.GI6659@binky.Central.Sun.COM> <20050820031035.GA5352@isc.upenn.edu> <43074F76.8000604@cs.umd.edu> <20050822044255.GC27685@isc.upenn.edu> <35850EE42DFD2824F0DDBBC8@cumulus> <1DCACCAC04655B3AFE9733A8@cumulus> <20050822154044.GE7789@binky.Central.Sun.COM> <430CA545.3020109@uni-tuebingen.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.1 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac X-Mailman-Approved-At: Wed, 24 Aug 2005 17:22:36 -0400 Cc: secmech@ietf.org X-BeenThere: secmech@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security mechanisms BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: secmech-bounces@lists.ietf.org Errors-To: secmech-bounces@lists.ietf.org > - What is the benefit of having a TGT as a result of the authentication for > EAP?!! With native Kerberos, the TGT is used to get a service ticket from the > TGS to access kerberized services. What would be here the kerberized service?! > is it just the "network access"?! or is anyone planning to realize different > kerberized services at layer 2? Is this a new requirement for 802.11? IEEE 802.11i at one point mandated the use of Kerberos for network access using EAP-GSS and IAKERB. The model was for the EAP peer to obtain both a TGT and TGS via EAP-GSS, then for the peer to authenticate to the NAS using the TGS. This required the NAS devices (APs) to support Kerberos. There was some discussion about whether the TGS would apply only to a single NAS, or to the "Network Access Service" in general. That is, whether a TGS obtained for one NAS could be used at another NAS. If the TGS were reusable at multiple NASes, this would imply that those NASes shared a secret with the Kerberos server which represents poor hygene. If the TGS is not reusable, then this implies that the EAP peer would need to obtain a new TGS for each NAS it wished to connect to, requiring a round-trip to the Kerberos server. In any case, after a great deal of investigation and negotiation with the IETF, IEEE 802.11i decided to remove mandatory support for Kerberos. Since this required a 75% vote, very strong sentiment against Kerberos was required for this. As a result, I doubt that you will see 802.11 wishing to revisit Kerberos support in the near future. > - What would be the benefit of such a EAP-Kerberos (or EAP-IAKERB) method > compared to existing EAP methods that are currently used, e.g. EAP-TTLS+PAP > with a radius/diameter server at the end (except that this method might be a > "misuse" of kerberos as mentioned earlier in this mailing list). What would be > the arguments that would motivate operators to substitute their infrastructure > with a new one supporting EAP-Kerberos or EAP-IAKERB? EAP-Kerb/IAKERB/GSS is inherently different other EAP methods because it requires support for the method on the NAS. That is, the NAS needs to support Kerberos for a peer to be able to submit a TGS to the NAS in order to obtain network access. Once an EAP peer has obtained a TGS and authenticated to one NAS, if proper Kerberos hygene is required, then for the EAP peer to do a handoff it needs to obtain TGSes for other NASes in the vicinity. If there were a way to obtain multiple TGSes in an efficient way (as part of the original EAP authentication, or via a single request), then this could be the foundation of an approach to low latency handoff. However at this point, this is all water under the bridge, since Kerberos without PKINIT does not meet the security requirements of RFC 4017, and thus is not permitted within IEEE 802.11i. This leaves vendors with little motivation to support it. > - Would PKINIT really be an advantage for EAP?! The point with PKINIT is that > it supports authentication of the client with public key cryptography. But > isn't this already covered by EAP-TLS? PKINIT is the only acceptable Kerberos usage mode within RFC 4017. However, EAP-GSS with PKINIT requires changes to the NAS, which EAP-TLS does not. > - Wouldn't be helpful to talk to the authors of the EAP GSS draft (Aboba) and > find out why they stopped to work on this document? We stopped work on the document because: a) Kerberos did not meet the security criteria of RFC 4017 without PKINIT. b) IEEE 802.11i did not want to require use of certificates. c) The CAT WG refused to advance IAKERB even after it had been included as an implementation requirement within IEEE 802.11i and had been implemented by at least one vendor. This made it impossible for IEEE 802.l1i to satisfy its IETF dependencies since EAP-GSS depended on IAKERB. d) GSSAPI did not include a PRF function, which made it difficult to generate an MSK/EMSK with the properties required by RFC 3748. > IMHO, it seems that it makes sense to combine different frameworks with > different authentication mechanisms as intended by secmech. But I just would > like to have some clarification, why this would be useful. _______________________________________________ SECMECH mailing list SECMECH@lists.ietf.org https://www1.ietf.org/mailman/listinfo/secmech From secmech-bounces@lists.ietf.org Wed Aug 24 17:22:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E82hi-0006cx-Gu; Wed, 24 Aug 2005 17:22:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E80XL-0007I7-Dd for secmech@megatron.ietf.org; Wed, 24 Aug 2005 15:03:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11792 for ; Wed, 24 Aug 2005 15:03:44 -0400 (EDT) Received: from outbound.mailhop.org ([63.208.196.171] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E80Xg-0003aF-LO for secmech@ietf.org; Wed, 24 Aug 2005 15:04:08 -0400 Received: from c-67-182-139-247.hsd1.wa.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.51) id 1E80XI-000O2a-3p; Wed, 24 Aug 2005 15:03:44 -0400 Received: by internaut.com (Postfix, from userid 1000) id 2414160DC2; Wed, 24 Aug 2005 12:03:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by internaut.com (Postfix) with ESMTP id 1602C60DAD; Wed, 24 Aug 2005 12:03:43 -0700 (PDT) X-Mail-Handler: MailHop Outbound by DynDNS.org X-Originating-IP: 67.182.139.247 X-Report-Abuse-To: abuse@dyndns.org (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba Date: Wed, 24 Aug 2005 12:03:43 -0700 (PDT) From: Bernard Aboba To: Charles Clancy Subject: Re: [SECMECH] Framework Bindings Vs. Mechanism Bridges In-Reply-To: Message-ID: References: <20050819210308.GI6659@binky.Central.Sun.COM> <20050820031035.GA5352@isc.upenn.edu> <43074F76.8000604@cs.umd.edu> <20050822044255.GC27685@isc.upenn.edu> <35850EE42DFD2824F0DDBBC8@cumulus> <1DCACCAC04655B3AFE9733A8@cumulus> <20050822154044.GE7789@binky.Central.Sun.COM> <430CA545.3020109@uni-tuebingen.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.1 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f X-Mailman-Approved-At: Wed, 24 Aug 2005 17:22:36 -0400 Cc: secmech@ietf.org X-BeenThere: secmech@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security mechanisms BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: secmech-bounces@lists.ietf.org Errors-To: secmech-bounces@lists.ietf.org > Not only would it allow you to obtain a TGT, it would also allow you to use an > existing TGT to get a "service ticket" for network access. This is probably > the less-likely scenario though, since talking to a KDC requires network > access in the first place. EAP-GSS permitted an EAP peer to talk to the Kerberos server as part of the process of obtaining network access. > Consider the case of Win32 AFS on a laptop. You sign onto the wireless > network, and you can get a service ticket for AFS without having to > reauthenticate to the KDC. > > Another interesting idea would be to treat each 802.11i AP as a service, and > you could obtain service tickets for them as you roam. That's not a particularly appealing if each NAS requires a distinct TGS and each TGS requires a roundtrip between the peer and KDC. _______________________________________________ SECMECH mailing list SECMECH@lists.ietf.org https://www1.ietf.org/mailman/listinfo/secmech From secmech-bounces@lists.ietf.org Wed Aug 24 17:32:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E82qz-00024d-13; Wed, 24 Aug 2005 17:32:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E82qu-00021J-U8 for secmech@megatron.ietf.org; Wed, 24 Aug 2005 17:32:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22794 for ; Wed, 24 Aug 2005 17:32:06 -0400 (EDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E82rF-0000nR-Je for secmech@ietf.org; Wed, 24 Aug 2005 17:32:33 -0400 Received: from centralmail1brm.Central.Sun.COM (centralmail1brm.central.sun.com [129.147.62.1]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j7OLW4TW007751 for ; Wed, 24 Aug 2005 15:32:04 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id j7OLW3fa019449 for ; Wed, 24 Aug 2005 15:32:03 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id j7OLUE4d010636; Wed, 24 Aug 2005 16:30:14 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id j7OLUBH4010635; Wed, 24 Aug 2005 16:30:11 -0500 (CDT) Date: Wed, 24 Aug 2005 16:30:11 -0500 From: Nicolas Williams To: Bernard Aboba Subject: Re: [SECMECH] Framework Bindings Vs. Mechanism Bridges Message-ID: <20050824213010.GO10174@binky.Central.Sun.COM> References: <43074F76.8000604@cs.umd.edu> <20050822044255.GC27685@isc.upenn.edu> <35850EE42DFD2824F0DDBBC8@cumulus> <1DCACCAC04655B3AFE9733A8@cumulus> <20050822154044.GE7789@binky.Central.Sun.COM> <430CA545.3020109@uni-tuebingen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: secmech@ietf.org X-BeenThere: secmech@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security mechanisms BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: secmech-bounces@lists.ietf.org Errors-To: secmech-bounces@lists.ietf.org On Wed, Aug 24, 2005 at 11:59:41AM -0700, Bernard Aboba wrote: > We stopped work on the document because: > > a) Kerberos did not meet the security criteria of RFC 4017 without PKINIT. Does tunnelling various other weak mechanisms over TLS meet said criteria? > b) IEEE 802.11i did not want to require use of certificates. Certificates != PKI, PKINIT does not require a PKI. > c) The CAT WG refused to advance IAKERB even after it had been included as > an implementation requirement within IEEE 802.11i and had been > implemented by at least one vendor. This made it impossible for > IEEE 802.l1i to satisfy its IETF dependencies since EAP-GSS depended > on IAKERB. CAT WG closed years ago... > d) GSSAPI did not include a PRF function, which made it difficult to > generate an MSK/EMSK with the properties required by RFC 3748. That's almost fixed. Nico -- _______________________________________________ SECMECH mailing list SECMECH@lists.ietf.org https://www1.ietf.org/mailman/listinfo/secmech From secmech-bounces@lists.ietf.org Wed Aug 24 18:17:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E83TM-0006qu-5Y; Wed, 24 Aug 2005 18:11:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E83TJ-0006qT-44 for secmech@megatron.ietf.org; Wed, 24 Aug 2005 18:11:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25010 for ; Wed, 24 Aug 2005 18:11:46 -0400 (EDT) Received: from dirg.bris.ac.uk ([137.222.10.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E83Tf-0001w8-2o for secmech@ietf.org; Wed, 24 Aug 2005 18:12:14 -0400 Received: from ncsb.bris.ac.uk ([137.222.10.100]) by dirg.bris.ac.uk with esmtp (Exim 4.51) id 1E83Sq-0001is-St; Wed, 24 Aug 2005 23:11:23 +0100 Received: from dsl-88-104-35-165.access.as9105.com ([88.104.35.165]) by ncsb.bris.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.51) id 1E83Sq-0005AO-15; Wed, 24 Aug 2005 23:11:20 +0100 Message-ID: <430CF086.4050505@bristol.ac.uk> Date: Wed, 24 Aug 2005 23:11:18 +0100 From: Josh Howlett User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba Subject: Re: [SECMECH] Framework Bindings Vs. Mechanism Bridges References: <20050819210308.GI6659@binky.Central.Sun.COM> <20050820031035.GA5352@isc.upenn.edu> <43074F76.8000604@cs.umd.edu> <20050822044255.GC27685@isc.upenn.edu> <35850EE42DFD2824F0DDBBC8@cumulus> <1DCACCAC04655B3AFE9733A8@cumulus> <20050822154044.GE7789@binky.Central.Sun.COM> <430CA545.3020109@uni-tuebingen.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 2.8 X-Spam-Level: ++ X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: 7bit Cc: secmech@ietf.org X-BeenThere: secmech@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security mechanisms BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: secmech-bounces@lists.ietf.org Errors-To: secmech-bounces@lists.ietf.org Bernard Aboba wrote: >>Another interesting idea would be to treat each 802.11i AP as a service, and >>you could obtain service tickets for them as you roam. > > That's not a particularly appealing if each NAS requires a distinct > TGS and each TGS requires a roundtrip between the peer and KDC. Does this also preclude RADIUS cross-realm roaming, unless there was a corresponding Kerberos cross-realm arrangement as well? josh. _______________________________________________ SECMECH mailing list SECMECH@lists.ietf.org https://www1.ietf.org/mailman/listinfo/secmech From secmech-bounces@lists.ietf.org Wed Aug 24 19:03:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E84HE-0007yQ-Q4; Wed, 24 Aug 2005 19:03:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E83v7-0000S7-80 for secmech@megatron.ietf.org; Wed, 24 Aug 2005 18:40:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27158 for ; Wed, 24 Aug 2005 18:40:28 -0400 (EDT) Received: from outbound.mailhop.org ([63.208.196.171] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E83vT-0002r6-8z for secmech@ietf.org; Wed, 24 Aug 2005 18:40:56 -0400 Received: from c-67-182-139-247.hsd1.wa.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.51) id 1E83v2-0006Ht-DR for secmech@ietf.org; Wed, 24 Aug 2005 18:40:28 -0400 Received: by internaut.com (Postfix, from userid 1000) id 4534160DD8; Wed, 24 Aug 2005 15:40:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by internaut.com (Postfix) with ESMTP id 38C5760DAD for ; Wed, 24 Aug 2005 15:40:17 -0700 (PDT) X-Mail-Handler: MailHop Outbound by DynDNS.org X-Originating-IP: 67.182.139.247 X-Report-Abuse-To: abuse@dyndns.org (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba Date: Wed, 24 Aug 2005 15:40:17 -0700 (PDT) From: Bernard Aboba To: secmech@ietf.org Subject: Re: [SECMECH] Framework Bindings Vs. Mechanism Bridges In-Reply-To: <20050824213010.GO10174@binky.Central.Sun.COM> Message-ID: References: <43074F76.8000604@cs.umd.edu> <20050822044255.GC27685@isc.upenn.edu> <35850EE42DFD2824F0DDBBC8@cumulus> <1DCACCAC04655B3AFE9733A8@cumulus> <20050822154044.GE7789@binky.Central.Sun.COM> <430CA545.3020109@uni-tuebingen.de> <20050824213010.GO10174@binky.Central.Sun.COM> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.1 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c X-Mailman-Approved-At: Wed, 24 Aug 2005 19:03:23 -0400 Cc: X-BeenThere: secmech@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security mechanisms BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: secmech-bounces@lists.ietf.org Errors-To: secmech-bounces@lists.ietf.org > Does tunnelling various other weak mechanisms over TLS meet said > criteria? If "weak" means mechanisms that do not generate a key (e.g. MD5-Challenge), then these would violate RFC 4017 mandatory requirement 6: [6] Protection against man-in-the-middle attacks. This corresponds to the "Cryptographic binding", "Integrity protection", "Replay protection", and "Session independence" security claims defined in [RFC3748], Section 7.2.1. > CAT WG closed years ago... It appears that responsibility for IAKERB transitioned to the Kerberos WG once CAT WG was closed. The last version of IAKERB was submitted in October 2002: http://www.watersprings.org/pub/id/draft-ietf-cat-iakerb-09.txt The last version of EAP GSS was submitted in April 2002: http://www.watersprings.org/pub/id/draft-aboba-pppext-eapgss-12.txt On March 17, 2003 an IESG Draft Tracker entry shows that IAKERB was moved from the "Waiting for Writeup" state to the "AD is watching :: Revised ID Needed" by Russ Housley, who inherited the document from Jeff Schiller. Another entry on March 17, 2003 shows that IAKERB was "Sent back to the WG for revision based on request that was received during the IETF 56 session." Minutes of the IETF 56 Kerberos WG are enclosed below. On February 13, 2004 another entry was entered indicating that "IAKERB is not going to come back to the IESG. There is not any interest in the KRB-WG since the general solution is to use the Kerberos EAP mechanism." On that same date, the status changed to "DEAD" from AD is Watching::ID Needed". ------------------------------------------------------------------------- Minutes of the Kerberos WG at IETF 56 San Francisco The Kerberos WG met on 3/17/2003 for about 1 and a half hours. In attendance where approximately 53 people. I talked on the IAKERB about how it had been before the IESG, for over a year, but there has been some concerns about it. It has being withdrawn, and will be considered again if there is substantial interest. It should be update with regards to Extensions. (Since then I realize I should not have made this statement. I and the AD have been in contact with the author on this, and it is expected the draft will be resubmitted.) Sam further commented: "I don't believe that iakerb is likely to have any issues with clarifications, but the mode of iakerb that has reduced number of round trips is likely to be incompatible with extensions because extensions will integrity-protect the request to make sure no changes are made." "I believe that one of iakerb, EAP krb5, , EAP GSS should actually go forward. Eap krb5 has been sketched out (although not publicly) but does not really exist within the IETF context. EAP GSS has significant security issues and I hope it does not go forward at all. Iakerb has significant esthetic issues that we have discussed to death here. I think we should wait until there is clear interest either from the wireless or dialup community that they want to use Kerberos and then work on one of these mechanisms." _______________________________________________ SECMECH mailing list SECMECH@lists.ietf.org https://www1.ietf.org/mailman/listinfo/secmech From secmech-bounces@lists.ietf.org Wed Aug 24 19:03:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E84HF-0007yp-7R; Wed, 24 Aug 2005 19:03:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E84BQ-0005eJ-53 for secmech@megatron.ietf.org; Wed, 24 Aug 2005 18:57:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28861 for ; Wed, 24 Aug 2005 18:57:21 -0400 (EDT) Received: from outbound.mailhop.org ([63.208.196.171] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E84Bo-0003eT-Hj for secmech@ietf.org; Wed, 24 Aug 2005 18:57:49 -0400 Received: from c-67-182-139-247.hsd1.wa.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.51) id 1E84BN-0008rq-JW; Wed, 24 Aug 2005 18:57:21 -0400 Received: by internaut.com (Postfix, from userid 1000) id C360860DDC; Wed, 24 Aug 2005 15:57:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by internaut.com (Postfix) with ESMTP id B625560DD8; Wed, 24 Aug 2005 15:57:20 -0700 (PDT) X-Mail-Handler: MailHop Outbound by DynDNS.org X-Originating-IP: 67.182.139.247 X-Report-Abuse-To: abuse@dyndns.org (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba Date: Wed, 24 Aug 2005 15:57:20 -0700 (PDT) From: Bernard Aboba To: Josh Howlett Subject: Re: [SECMECH] Framework Bindings Vs. Mechanism Bridges In-Reply-To: <430CF086.4050505@bristol.ac.uk> Message-ID: References: <20050819210308.GI6659@binky.Central.Sun.COM> <20050820031035.GA5352@isc.upenn.edu> <43074F76.8000604@cs.umd.edu> <20050822044255.GC27685@isc.upenn.edu> <35850EE42DFD2824F0DDBBC8@cumulus> <1DCACCAC04655B3AFE9733A8@cumulus> <20050822154044.GE7789@binky.Central.Sun.COM> <430CA545.3020109@uni-tuebingen.de> <430CF086.4050505@bristol.ac.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.1 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed X-Mailman-Approved-At: Wed, 24 Aug 2005 19:03:23 -0400 Cc: secmech@ietf.org X-BeenThere: secmech@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security mechanisms BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: secmech-bounces@lists.ietf.org Errors-To: secmech-bounces@lists.ietf.org > > That's not a particularly appealing if each NAS requires a distinct TGS > > and each TGS requires a roundtrip between the peer and KDC. > > Does this also preclude RADIUS cross-realm roaming, unless there was a > corresponding Kerberos cross-realm arrangement as well? I think that also might be an issue, yes. _______________________________________________ SECMECH mailing list SECMECH@lists.ietf.org https://www1.ietf.org/mailman/listinfo/secmech From secmech-bounces@lists.ietf.org Wed Aug 24 20:15:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E85Ng-00063a-5g; Wed, 24 Aug 2005 20:14:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E85Nd-00060J-Ux for secmech@megatron.ietf.org; Wed, 24 Aug 2005 20:14:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05129 for ; Wed, 24 Aug 2005 20:13:40 -0400 (EDT) Received: from sccrmhc13.comcast.net ([204.127.202.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E85Ne-0006oi-Mh for secmech@ietf.org; Wed, 24 Aug 2005 20:14:07 -0400 Received: from [192.168.0.2] (pcp04510339pcs.gambrl01.md.comcast.net[68.49.199.146]) by comcast.net (sccrmhc13) with ESMTP id <20050825001330013005er85e>; Thu, 25 Aug 2005 00:13:31 +0000 Message-ID: <430D0D2B.8050405@cs.umd.edu> Date: Wed, 24 Aug 2005 20:13:31 -0400 From: Charles Clancy User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba Subject: Re: [SECMECH] Framework Bindings Vs. Mechanism Bridges References: <43074F76.8000604@cs.umd.edu> <20050822044255.GC27685@isc.upenn.edu> <35850EE42DFD2824F0DDBBC8@cumulus> <1DCACCAC04655B3AFE9733A8@cumulus> <20050822154044.GE7789@binky.Central.Sun.COM> <430CA545.3020109@uni-tuebingen.de> <20050824213010.GO10174@binky.Central.Sun.COM> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Cc: secmech@ietf.org X-BeenThere: secmech@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security mechanisms BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: secmech-bounces@lists.ietf.org Errors-To: secmech-bounces@lists.ietf.org Bernard Aboba wrote: >>Does tunnelling various other weak mechanisms over TLS meet said >>criteria? > > > If "weak" means mechanisms that do not generate a key (e.g. > MD5-Challenge), then these would violate RFC 4017 mandatory > requirement 6: > > [6] Protection against man-in-the-middle attacks. This > corresponds > to the "Cryptographic binding", "Integrity protection", > "Replay protection", and "Session independence" security > claims defined in [RFC3748], Section 7.2.1. I guess there are two points of view -- one where the AP is the service, and one where the EAP server is the service. If the EAP server is the service, then it can do a passthrough Kerberos authentication for the EAP client. The client can obtain a TGT and a service ticket for the EAP server, and then authenticate to the EAP server using the service ticket. The key contained within that service ticket is known only by the client and the EAP server, so it could theoretically then be used to bootstrap an EAP key derivation, including the info needed by TTLS to do the crypto binding. TTLS would then augment the security of these keys using its own entropy, and poof. ... or am I missing something? [ t. charles clancy ]--[ tcc@umd.edu ]--[ www.cs.umd.edu/~clancy ] [ computer science ]-----[ university of maryland | college park ] _______________________________________________ SECMECH mailing list SECMECH@lists.ietf.org https://www1.ietf.org/mailman/listinfo/secmech From secmech-bounces@lists.ietf.org Wed Aug 24 21:29:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E86Yy-0005Lw-Cd; Wed, 24 Aug 2005 21:29:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E86Yw-0005Lr-Ka for secmech@megatron.ietf.org; Wed, 24 Aug 2005 21:29:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08220 for ; Wed, 24 Aug 2005 21:29:49 -0400 (EDT) Received: from sccrmhc12.comcast.net ([63.240.76.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E86ZM-0000KX-9O for secmech@ietf.org; Wed, 24 Aug 2005 21:30:17 -0400 Received: from [192.168.0.2] (pcp04510339pcs.gambrl01.md.comcast.net[68.49.199.146]) by comcast.net (sccrmhc12) with ESMTP id <20050825012841012000d7t3e>; Thu, 25 Aug 2005 01:28:42 +0000 Message-ID: <430D1EB5.2040806@cs.umd.edu> Date: Wed, 24 Aug 2005 21:28:21 -0400 From: Charles Clancy User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba Subject: Re: [SECMECH] Framework Bindings Vs. Mechanism Bridges References: <43074F76.8000604@cs.umd.edu> <20050822044255.GC27685@isc.upenn.edu> <35850EE42DFD2824F0DDBBC8@cumulus> <1DCACCAC04655B3AFE9733A8@cumulus> <20050822154044.GE7789@binky.Central.Sun.COM> <430CA545.3020109@uni-tuebingen.de> <20050824213010.GO10174@binky.Central.Sun.COM> <430D0D2B.8050405@cs.umd.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit Cc: secmech@ietf.org X-BeenThere: secmech@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security mechanisms BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: secmech-bounces@lists.ietf.org Errors-To: secmech-bounces@lists.ietf.org Bernard Aboba wrote: >>If the EAP server is the service, then it can do a passthrough Kerberos >>authentication for the EAP client. The client can obtain a TGT and a service >>ticket for the EAP server, and then authenticate to the EAP server using the >>service ticket. The key contained within that service ticket is known only by >>the client and the EAP server, so it could theoretically then be used to >>bootstrap an EAP key derivation, including the info needed by TTLS to do the >>crypto binding. TTLS would then augment the security of these keys using its >>own entropy, and poof. >> >>... or am I missing something? > > > EAP methods need to be "mode independent" which implies that they need to > work the same way regardless of whether an authentication server is > present or not. If an AS is not present, then the EAP server resides on > the NAS, and the EAP peer would be providing a clear text password to the > NAS. > > "AAA Key Management" (draft-housley-aaa-key-mgmt-00.txt) talks about > preventing cascading vulnerabilities. One of the requirements is that > compromise of one NAS not compromise long-term credentials. > > Providing a cleartext password to a NAS seems like it would violate that > requirement. Why would the cleartext password ever end up on a NAS? Maybe a picture would help: EAP Client EAP Server KDC -------------------------------------------- TTLS Negotiation <-----------------------> krb5 authentication (EAP server is passthrough) <------------------------------------------> TGT, service ticket <------------------------------------------- service auth <-----------------------> {MK,MSK} = PRF(service key) [ t. charles clancy ]--[ tcc@umd.edu ]--[ www.cs.umd.edu/~clancy ] [ computer science ]-----[ university of maryland | college park ] _______________________________________________ SECMECH mailing list SECMECH@lists.ietf.org https://www1.ietf.org/mailman/listinfo/secmech From secmech-bounces@lists.ietf.org Wed Aug 24 23:52:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E88mr-0001Nz-Or; Wed, 24 Aug 2005 23:52:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E85dJ-00030w-0n for secmech@megatron.ietf.org; Wed, 24 Aug 2005 20:30:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05913 for ; Wed, 24 Aug 2005 20:30:15 -0400 (EDT) Received: from outbound.mailhop.org ([63.208.196.171] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E85di-0007HS-35 for secmech@ietf.org; Wed, 24 Aug 2005 20:30:43 -0400 Received: from c-67-182-139-247.hsd1.wa.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.51) id 1E85dC-000M6z-9t; Wed, 24 Aug 2005 20:30:10 -0400 Received: by internaut.com (Postfix, from userid 1000) id 7A05860DDC; Wed, 24 Aug 2005 17:30:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by internaut.com (Postfix) with ESMTP id 692A660DD8; Wed, 24 Aug 2005 17:30:09 -0700 (PDT) X-Mail-Handler: MailHop Outbound by DynDNS.org X-Originating-IP: 67.182.139.247 X-Report-Abuse-To: abuse@dyndns.org (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba Date: Wed, 24 Aug 2005 17:30:09 -0700 (PDT) From: Bernard Aboba To: Charles Clancy Subject: Re: [SECMECH] Framework Bindings Vs. Mechanism Bridges In-Reply-To: <430D0D2B.8050405@cs.umd.edu> Message-ID: References: <43074F76.8000604@cs.umd.edu> <20050822044255.GC27685@isc.upenn.edu> <35850EE42DFD2824F0DDBBC8@cumulus> <1DCACCAC04655B3AFE9733A8@cumulus> <20050822154044.GE7789@binky.Central.Sun.COM> <430CA545.3020109@uni-tuebingen.de> <20050824213010.GO10174@binky.Central.Sun.COM> <430D0D2B.8050405@cs.umd.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 X-Mailman-Approved-At: Wed, 24 Aug 2005 23:52:19 -0400 Cc: secmech@ietf.org X-BeenThere: secmech@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security mechanisms BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: secmech-bounces@lists.ietf.org Errors-To: secmech-bounces@lists.ietf.org > If the EAP server is the service, then it can do a passthrough Kerberos > authentication for the EAP client. The client can obtain a TGT and a service > ticket for the EAP server, and then authenticate to the EAP server using the > service ticket. The key contained within that service ticket is known only by > the client and the EAP server, so it could theoretically then be used to > bootstrap an EAP key derivation, including the info needed by TTLS to do the > crypto binding. TTLS would then augment the security of these keys using its > own entropy, and poof. > > ... or am I missing something? EAP methods need to be "mode independent" which implies that they need to work the same way regardless of whether an authentication server is present or not. If an AS is not present, then the EAP server resides on the NAS, and the EAP peer would be providing a clear text password to the NAS. "AAA Key Management" (draft-housley-aaa-key-mgmt-00.txt) talks about preventing cascading vulnerabilities. One of the requirements is that compromise of one NAS not compromise long-term credentials. Providing a cleartext password to a NAS seems like it would violate that requirement. _______________________________________________ SECMECH mailing list SECMECH@lists.ietf.org https://www1.ietf.org/mailman/listinfo/secmech From secmech-bounces@lists.ietf.org Wed Aug 24 23:52:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E88ms-0001Oe-5z; Wed, 24 Aug 2005 23:52:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E875S-0007bA-Nj for secmech@megatron.ietf.org; Wed, 24 Aug 2005 22:03:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09192 for ; Wed, 24 Aug 2005 22:03:24 -0400 (EDT) Received: from outbound.mailhop.org ([63.208.196.171] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E875r-00019L-LP for secmech@ietf.org; Wed, 24 Aug 2005 22:03:53 -0400 Received: from c-67-182-139-247.hsd1.wa.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.51) id 1E875O-0006wQ-Ve; Wed, 24 Aug 2005 22:03:23 -0400 Received: by internaut.com (Postfix, from userid 1000) id CC5E960DDC; Wed, 24 Aug 2005 19:03:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by internaut.com (Postfix) with ESMTP id BE44560DB2; Wed, 24 Aug 2005 19:03:21 -0700 (PDT) X-Mail-Handler: MailHop Outbound by DynDNS.org X-Originating-IP: 67.182.139.247 X-Report-Abuse-To: abuse@dyndns.org (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba Date: Wed, 24 Aug 2005 19:03:21 -0700 (PDT) From: Bernard Aboba To: Charles Clancy Subject: Re: [SECMECH] Framework Bindings Vs. Mechanism Bridges In-Reply-To: <430D1EB5.2040806@cs.umd.edu> Message-ID: References: <43074F76.8000604@cs.umd.edu> <20050822044255.GC27685@isc.upenn.edu> <35850EE42DFD2824F0DDBBC8@cumulus> <1DCACCAC04655B3AFE9733A8@cumulus> <20050822154044.GE7789@binky.Central.Sun.COM> <430CA545.3020109@uni-tuebingen.de> <20050824213010.GO10174@binky.Central.Sun.COM> <430D0D2B.8050405@cs.umd.edu> <430D1EB5.2040806@cs.umd.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 X-Mailman-Approved-At: Wed, 24 Aug 2005 23:52:19 -0400 Cc: secmech@ietf.org X-BeenThere: secmech@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security mechanisms BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: secmech-bounces@lists.ietf.org Errors-To: secmech-bounces@lists.ietf.org > Why would the cleartext password ever end up on a NAS? If the NAS terminates the TTLS tunnel, and PAP is negotiated within TTLS this can happen. > Maybe a picture would help: > > EAP Client EAP Server KDC > -------------------------------------------- > > TTLS Negotiation > <-----------------------> > > krb5 authentication (EAP server is passthrough) > <------------------------------------------> Is the assumption here that an EAP-Kerberos method is run within the TTLS tunnel, thereby protecting the Kerberos exchange? If so, then this mode of interaction protects the Kerberos exchange from dictionary attack. _______________________________________________ SECMECH mailing list SECMECH@lists.ietf.org https://www1.ietf.org/mailman/listinfo/secmech From secmech-bounces@lists.ietf.org Thu Aug 25 00:15:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E897v-0008CG-GQ; Thu, 25 Aug 2005 00:14:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E897t-0008C2-OP for secmech@megatron.ietf.org; Thu, 25 Aug 2005 00:14:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13723 for ; Thu, 25 Aug 2005 00:14:01 -0400 (EDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E898B-0004YO-A3 for secmech@ietf.org; Thu, 25 Aug 2005 00:14:32 -0400 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id j7P4Dr2B020622 for ; Wed, 24 Aug 2005 21:13:53 -0700 (PDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id j7P4DqLG005378 for ; Wed, 24 Aug 2005 22:13:52 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id j7P4DpmU013903; Wed, 24 Aug 2005 23:13:51 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id j7P4DoiX013902; Wed, 24 Aug 2005 23:13:50 -0500 (CDT) Date: Wed, 24 Aug 2005 23:13:50 -0500 From: Nicolas Williams To: Bernard Aboba Subject: Re: [SECMECH] Framework Bindings Vs. Mechanism Bridges Message-ID: <20050825041350.GV10174@binky.Central.Sun.COM> References: <1DCACCAC04655B3AFE9733A8@cumulus> <20050822154044.GE7789@binky.Central.Sun.COM> <430CA545.3020109@uni-tuebingen.de> <20050824213010.GO10174@binky.Central.Sun.COM> <430D0D2B.8050405@cs.umd.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: secmech@ietf.org X-BeenThere: secmech@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security mechanisms BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: secmech-bounces@lists.ietf.org Errors-To: secmech-bounces@lists.ietf.org On Wed, Aug 24, 2005 at 05:30:09PM -0700, Bernard Aboba wrote: > > If the EAP server is the service, then it can do a passthrough Kerberos > > authentication for the EAP client. The client can obtain a TGT and a service > > ticket for the EAP server, and then authenticate to the EAP server using the > > service ticket. The key contained within that service ticket is known only by > > the client and the EAP server, so it could theoretically then be used to > > bootstrap an EAP key derivation, including the info needed by TTLS to do the > > crypto binding. TTLS would then augment the security of these keys using its > > own entropy, and poof. > > > > ... or am I missing something? > > EAP methods need to be "mode independent" which implies that they need to > work the same way regardless of whether an authentication server is > present or not. If an AS is not present, then the EAP server resides on > the NAS, and the EAP peer would be providing a clear text password to the > NAS. So, there could (should?) be a standard framework for transporting key material from the EAP server to the NAS, yes? Is this covered in the EAP key management I-D? Or does every EAP method have to provide its own EAP-server-->NAS key transport protocol? Nico -- _______________________________________________ SECMECH mailing list SECMECH@lists.ietf.org https://www1.ietf.org/mailman/listinfo/secmech From secmech-bounces@lists.ietf.org Thu Aug 25 00:21:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E89El-0002CI-UZ; Thu, 25 Aug 2005 00:21:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E89Ej-0002CD-JO for secmech@megatron.ietf.org; Thu, 25 Aug 2005 00:21:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14027 for ; Thu, 25 Aug 2005 00:21:07 -0400 (EDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E89FA-0004jq-JI for secmech@ietf.org; Thu, 25 Aug 2005 00:21:38 -0400 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id j7P4L6HT014444 for ; Wed, 24 Aug 2005 21:21:06 -0700 (PDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id j7P4L6LE008611 for ; Wed, 24 Aug 2005 22:21:06 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id j7P4L6EN013913; Wed, 24 Aug 2005 23:21:06 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id j7P4L6Yd013912; Wed, 24 Aug 2005 23:21:06 -0500 (CDT) Date: Wed, 24 Aug 2005 23:21:06 -0500 From: Nicolas Williams To: Bernard Aboba Subject: Re: [SECMECH] Framework Bindings Vs. Mechanism Bridges Message-ID: <20050825042105.GW10174@binky.Central.Sun.COM> References: <35850EE42DFD2824F0DDBBC8@cumulus> <1DCACCAC04655B3AFE9733A8@cumulus> <20050822154044.GE7789@binky.Central.Sun.COM> <430CA545.3020109@uni-tuebingen.de> <20050824213010.GO10174@binky.Central.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: secmech@ietf.org X-BeenThere: secmech@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security mechanisms BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: secmech-bounces@lists.ietf.org Errors-To: secmech-bounces@lists.ietf.org On Wed, Aug 24, 2005 at 03:40:17PM -0700, Bernard Aboba wrote: > > Does tunnelling various other weak mechanisms over TLS meet said > > criteria? > > If "weak" means mechanisms that do not generate a key (e.g. > MD5-Challenge), then these would violate RFC 4017 mandatory > requirement 6: No, I used "weak" to mean mechanisms that are subject to off-line dictionary attacks by eavesdroppers or MITMs. > [6] Protection against man-in-the-middle attacks. This corresponds > to the "Cryptographic binding", "Integrity protection", "Replay > protection", and "Session independence" security claims defined > in [RFC3748], Section 7.2.1. > > > CAT WG closed years ago... > > It appears that responsibility for IAKERB transitioned to the Kerberos WG > once CAT WG was closed. > > [...] Summary: IAKERB and EAP-GSS are dead at this time, mostly for lack of people willing to do the work, not for any political or technical reasons. I.e., I'm pretty sure there'd be no opposition from the IETF, the Internet Security Area Directors or the IESG as a whole to a revival of IAKERB and/or EAP-GSS, provided someone does the work. See below. > Sam further commented: > > "I don't believe that iakerb is likely to have any issues with > clarifications, but the mode of iakerb that has reduced number of round > trips is likely to be incompatible with extensions because extensions will > integrity-protect the request to make sure no changes are made." > > "I believe that one of iakerb, EAP krb5, , EAP GSS should actually go > forward. Eap krb5 has been sketched out (although not publicly) but does > not really exist within the IETF context. EAP GSS has significant > security issues and I hope it does not go forward at all. Iakerb has > significant esthetic issues that we have discussed to death here. I think > we should wait until there is clear interest either from the wireless or > dialup community that they want to use Kerberos and then work on one of > these mechanisms." The EAP GSS issues Sam mentions are addressed by KITTEN WG work, namely GSS_Pseudo_random() (which reminds me, I have to update that I-D so we can finish WGLC on that already). The last IAKERB I-D turns out to have problems with Kerberos V extensions exactly as Sam described them way back at IETF 56. But there's no reason that we couldn't fix this. Nico -- _______________________________________________ SECMECH mailing list SECMECH@lists.ietf.org https://www1.ietf.org/mailman/listinfo/secmech From secmech-bounces@lists.ietf.org Thu Aug 25 09:33:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8HrZ-0002Bv-Ec; Thu, 25 Aug 2005 09:33:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8HrX-0002Bp-TE for secmech@megatron.ietf.org; Thu, 25 Aug 2005 09:33:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17648 for ; Thu, 25 Aug 2005 09:33:46 -0400 (EDT) Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8Hs3-0003Nm-Ki for secmech@ietf.org; Thu, 25 Aug 2005 09:34:21 -0400 Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 2D18989852; Thu, 25 Aug 2005 16:33:28 +0300 (EEST) Message-ID: <430DC8B3.9010309@piuha.net> Date: Thu, 25 Aug 2005 16:33:39 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Salowey, Joe" Subject: Re: [SECMECH] Method work References: <7210B31550AC934A8637D6619739CE6905C06A6B@e2k-sea-xch2.sea-alpha.cisco.com> In-Reply-To: <7210B31550AC934A8637D6619739CE6905C06A6B@e2k-sea-xch2.sea-alpha.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Content-Transfer-Encoding: 7bit Cc: secmech@ietf.org X-BeenThere: secmech@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security mechanisms BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: secmech-bounces@lists.ietf.org Errors-To: secmech-bounces@lists.ietf.org Salowey, Joe wrote: >I would like to identify which mechanism types there is interest in >working on. Below is a list of various authentication methods that >people have expressed interest in having support for in EAP and other >frameworks. It may not be the case that we need a separate mechanism >for each of these. I'd like to know who has interest in contributing >and reviewing (please indicate either or both) specifications for each >of these mechanism types. > >1. X.509 Certificate credentials - (possible revision of EAP-TLS >(RFC2716)) - applicable to EAP, possibly applicable to GSS and SASL. >Desired by IEEE 802.11 for EAP. > > I think we should rev EAP-TLS at the minimum, just to make a PS out of it and fix some bugs & provide additional information where necessary. We probably need to resist the urge to add a lot of stuff to EAP-TLS in such a revision. Though I'm kind of interested in adding channel bindings. But I'm not sure if that's doable in a backwards compatible way, without either a major change in EAP-TLS or an extension in TLS. >2. Shared Secret - pre-shared secret method. Applicable to EAP and GSS, >possibly SASL. Desired by IEEE 802.11 for EAP. > > Yes, this is perhaps my top priority item. My current thinking of what we need here is a simple-to-implement method that is really shared secret, not password based, and something that would provide a reasonable candidate for people to implement in their products and reference as a mandatory-to- implement for some link layer. One question is what the value of EAP-TLS + TLS PSK would be in this context. To me this would satisfy the implementation simplicity requirement; most products should be able to take TLS in rather easily. However, there are also other reasons for developing new EAP methods (channel bindings is one reason), so we'd have to look at how to arrange for those other reasons. >3. Password based - essentially a shared secret mechanism that provides >resistance to dictionary attacks. It should support various backend >databases of password that use different storage techniques and perhaps >support for one time tokens as well. Could use something related to EKE >or a tunneling approach. Applicable to EAP, GSS, and SASL. Desired by >IEEE 802.11 for EAP. > > This would also be very useful. Personally I'm a bit more on thin ice here when it comes to the specific methods and whether there are any potential IPR issues etc. But I know this would be very much needed from a customer perspective. >4. Tunneling - a tunneling method is useful to protect weaker >authentication mechanisms. Tunneling methods are also used to exchange >other types of authentication data. Applicability EAP and GSS possibly >SASL. > > This is perhaps the widest class of currently used EAP methods, all proprietary and/or exist only in drafty draft state. One issue here is whether we'd be able to find consensus, or would the folks who have their own tunnel methods be fighting for "their" approach? Another issue is to what extent having a good solution for #3 would lessen the need for #4. >5. Kerberos - Something that provide for initial authentication and a >strategy for resisting dictionary attacks. Applicable to EAP, possibly >GSS. > > I don't currently see a big customer demand for this. But I could be viewing at the wrong "market segment". Other: enrollment, perhaps a la what Rohan Mahy wanted to do in the last EAP WG meeting. --Jari >Thanks, > >Joe > >_______________________________________________ >SECMECH mailing list >SECMECH@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/secmech > > > > _______________________________________________ SECMECH mailing list SECMECH@lists.ietf.org https://www1.ietf.org/mailman/listinfo/secmech From secmech-bounces@lists.ietf.org Thu Aug 25 09:53:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8IAG-00082y-FZ; Thu, 25 Aug 2005 09:53:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8IAF-00082t-TT for secmech@megatron.ietf.org; Thu, 25 Aug 2005 09:53:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18323 for ; Thu, 25 Aug 2005 09:53:05 -0400 (EDT) Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8IAl-0003uY-Np for secmech@ietf.org; Thu, 25 Aug 2005 09:53:41 -0400 Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 05EAF89852; Thu, 25 Aug 2005 16:52:56 +0300 (EEST) Message-ID: <430DCD44.3060703@piuha.net> Date: Thu, 25 Aug 2005 16:53:08 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nicolas Williams Subject: Re: [SECMECH] Framework Bindings Vs. Mechanism Bridges References: <1DCACCAC04655B3AFE9733A8@cumulus> <20050822154044.GE7789@binky.Central.Sun.COM> <430CA545.3020109@uni-tuebingen.de> <20050824213010.GO10174@binky.Central.Sun.COM> <430D0D2B.8050405@cs.umd.edu> <20050825041350.GV10174@binky.Central.Sun.COM> In-Reply-To: <20050825041350.GV10174@binky.Central.Sun.COM> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Cc: secmech@ietf.org, Bernard Aboba X-BeenThere: secmech@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security mechanisms BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: secmech-bounces@lists.ietf.org Errors-To: secmech-bounces@lists.ietf.org Nicolas Williams wrote: >So, there could (should?) be a standard framework for transporting key >material from the EAP server to the NAS, yes? Is this covered in the >EAP key management I-D? Or does every EAP method have to provide its >own EAP-server-->NAS key transport protocol? > > EAP keying framework explains how the system works regarding methods, eap, clients, nases, an authentication servers. It also analyses the security properties. But the actual key transport is defined in the AAA space. There's only one proposed standard for this (Diameter EAP), and one old vendor-specific attribute for RADIUS. So, from the point of view of the methods, they just export a key, and AAA will transport it to the NAS. --Jari _______________________________________________ SECMECH mailing list SECMECH@lists.ietf.org https://www1.ietf.org/mailman/listinfo/secmech From secmech-bounces@lists.ietf.org Thu Aug 25 09:53:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8IAW-00084i-MO; Thu, 25 Aug 2005 09:53:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8IAV-00084V-CN for secmech@megatron.ietf.org; Thu, 25 Aug 2005 09:53:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18328 for ; Thu, 25 Aug 2005 09:53:21 -0400 (EDT) Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8IB2-0003uz-H1 for secmech@ietf.org; Thu, 25 Aug 2005 09:53:56 -0400 Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 2732D89864; Thu, 25 Aug 2005 16:53:13 +0300 (EEST) Message-ID: <430DCD55.5090908@piuha.net> Date: Thu, 25 Aug 2005 16:53:25 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nicolas Williams Subject: Re: [SECMECH] Framework Bindings Vs. Mechanism Bridges References: <7210B31550AC934A8637D6619739CE6905C06505@e2k-sea-xch2.sea-alpha.cisco.com> <20050819181222.GG6659@binky.Central.Sun.COM> <20050819181423.GA6658@binky.Central.Sun.COM> In-Reply-To: <20050819181423.GA6658@binky.Central.Sun.COM> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Cc: secmech@ietf.org X-BeenThere: secmech@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security mechanisms BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: secmech-bounces@lists.ietf.org Errors-To: secmech-bounces@lists.ietf.org >I forgot to mention the counter-argument, namely that, in the short-term >at least, a round-trip is a small price to pay for lowering the cost, in >time and effort, of making EAP's or SASL/GSS-API's mechanisms available >to the other. > > Roundtrips are important, but I don't think anyone expects everything to happen in the minimum number of round trips, in ALL cases. That is, I think we need e.g. shared secret mechanisms with a small number of roundtrips in EAP, and we need some mechanisms that have a small number of roundtrips. But we already have today TLS-based EAP tunneling schemes, some of which are quite chatty. So I think it would be fine to have some additional roundtrips when you using something from another framework. (Nevertheless, I'm in favor of the bindings approach.) --Jari _______________________________________________ SECMECH mailing list SECMECH@lists.ietf.org https://www1.ietf.org/mailman/listinfo/secmech From secmech-bounces@lists.ietf.org Thu Aug 25 09:53:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8IAl-00086G-2U; Thu, 25 Aug 2005 09:53:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8IAh-00086B-Py for secmech@megatron.ietf.org; Thu, 25 Aug 2005 09:53:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18348 for ; Thu, 25 Aug 2005 09:53:34 -0400 (EDT) Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8IBF-0003vK-19 for secmech@ietf.org; Thu, 25 Aug 2005 09:54:09 -0400 Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 9BA9A89852; Thu, 25 Aug 2005 16:53:26 +0300 (EEST) Message-ID: <430DCD61.1090109@piuha.net> Date: Thu, 25 Aug 2005 16:53:37 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Shumon Huque Subject: Re: [SECMECH] Framework Bindings Vs. Mechanism Bridges References: <7210B31550AC934A8637D6619739CE6905C06510@e2k-sea-xch2.sea-alpha.cisco.com> <20050819210308.GI6659@binky.Central.Sun.COM> <20050820031035.GA5352@isc.upenn.edu> <43074F76.8000604@cs.umd.edu> <20050822044255.GC27685@isc.upenn.edu> In-Reply-To: <20050822044255.GC27685@isc.upenn.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Cc: secmech@ietf.org, Nicolas Williams X-BeenThere: secmech@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security mechanisms BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: secmech-bounces@lists.ietf.org Errors-To: secmech-bounces@lists.ietf.org Shumon Huque wrote: >I'm also not a fan of automatically assuming that a tunnel is the >right solution for many problems. If we are tunnelling in TLS for >example, I now have additional issues to deal with. Such as how to >query up-to-date certificate revocation status, and whether my >users are properly validating the certificates etc. > > Given choice, I'd rather have a well-design fully capable mechanisms than a tunnel + a mechanism that needs to run inside the tunnel. --Jari _______________________________________________ SECMECH mailing list SECMECH@lists.ietf.org https://www1.ietf.org/mailman/listinfo/secmech From secmech-bounces@lists.ietf.org Thu Aug 25 09:53:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8IB3-00087s-97; Thu, 25 Aug 2005 09:53:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8IB1-00087k-Rf for secmech@megatron.ietf.org; Thu, 25 Aug 2005 09:53:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18358 for ; Thu, 25 Aug 2005 09:53:54 -0400 (EDT) Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8IBZ-0003vk-3S for secmech@ietf.org; Thu, 25 Aug 2005 09:54:29 -0400 Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 9879189852; Thu, 25 Aug 2005 16:53:46 +0300 (EEST) Message-ID: <430DCD75.5040601@piuha.net> Date: Thu, 25 Aug 2005 16:53:57 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Shumon Huque Subject: Re: [SECMECH] Framework Bindings Vs. Mechanism Bridges References: <5057734.1124708889160.JavaMail.servlet@kundenserver> <20050822114112.GA343@isc.upenn.edu> In-Reply-To: <20050822114112.GA343@isc.upenn.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Cc: secmech@ietf.org X-BeenThere: secmech@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security mechanisms BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: secmech-bounces@lists.ietf.org Errors-To: secmech-bounces@lists.ietf.org Shumon Huque wrote: >On Mon, Aug 22, 2005 at 01:08:09PM +0200, t.otto@sharevolution.de wrote: > > >>There already exists a Kerberos extension to TLS, RFC 2712 (Oct.99), >>which can be run in EAP-TLS, so the question is: >> >>* Is there need for EAP-Kerberos at all? * >> >> > >RFC 2712 doesn't provide for initial and service ticket >acquisition. So, at the very least an EAP method that >allows you to do that needs to be developed. > > Do you need a fix to EAP, or do you a fix to kerberos-in-TLS? The latter might be applicable in a number of other scenarios, too... --Jari _______________________________________________ SECMECH mailing list SECMECH@lists.ietf.org https://www1.ietf.org/mailman/listinfo/secmech From secmech-bounces@lists.ietf.org Thu Aug 25 11:06:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8JJL-0005YL-9J; Thu, 25 Aug 2005 11:06:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8AXK-0002pM-7J for secmech@megatron.ietf.org; Thu, 25 Aug 2005 01:44:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16809 for ; Thu, 25 Aug 2005 01:44:25 -0400 (EDT) Received: from outbound.mailhop.org ([63.208.196.171] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8AXm-0006r1-23 for secmech@ietf.org; Thu, 25 Aug 2005 01:44:55 -0400 Received: from c-67-182-139-247.hsd1.wa.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.51) id 1E8AXH-0007iO-Tc; Thu, 25 Aug 2005 01:44:24 -0400 Received: by internaut.com (Postfix, from userid 1000) id F116760DDC; Wed, 24 Aug 2005 22:44:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by internaut.com (Postfix) with ESMTP id E487A60DD8; Wed, 24 Aug 2005 22:44:22 -0700 (PDT) X-Mail-Handler: MailHop Outbound by DynDNS.org X-Originating-IP: 67.182.139.247 X-Report-Abuse-To: abuse@dyndns.org (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba Date: Wed, 24 Aug 2005 22:44:22 -0700 (PDT) From: Bernard Aboba To: Nicolas Williams Subject: Re: [SECMECH] Framework Bindings Vs. Mechanism Bridges In-Reply-To: <20050825041350.GV10174@binky.Central.Sun.COM> Message-ID: References: <1DCACCAC04655B3AFE9733A8@cumulus> <20050822154044.GE7789@binky.Central.Sun.COM> <430CA545.3020109@uni-tuebingen.de> <20050824213010.GO10174@binky.Central.Sun.COM> <430D0D2B.8050405@cs.umd.edu> <20050825041350.GV10174@binky.Central.Sun.COM> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.1 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad X-Mailman-Approved-At: Thu, 25 Aug 2005 11:06:33 -0400 Cc: secmech@ietf.org X-BeenThere: secmech@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security mechanisms BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: secmech-bounces@lists.ietf.org Errors-To: secmech-bounces@lists.ietf.org > So, there could (should?) be a standard framework for transporting key > material from the EAP server to the NAS, yes? Is this covered in the > EAP key management I-D? Or does every EAP method have to provide its > own EAP-server-->NAS key transport protocol? The mechanisms for transporting EAP keying material from the AAA server to the NAS are described in RFC 4072 (Diameter EAP) and RFC 2548. These former is a Proposed Standard; the latter describes RADIUS VSAs that are in widespread usage. These mechanisms are independent of the EAP method. The principle of method independence (and other EAP key management issues) are described in the EAP Key Management Framework document. _______________________________________________ SECMECH mailing list SECMECH@lists.ietf.org https://www1.ietf.org/mailman/listinfo/secmech From secmech-bounces@lists.ietf.org Thu Aug 25 11:06:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8JJL-0005Yk-Hs; Thu, 25 Aug 2005 11:06:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8BBq-0001UH-53 for secmech@megatron.ietf.org; Thu, 25 Aug 2005 02:26:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01839 for ; Thu, 25 Aug 2005 02:26:17 -0400 (EDT) Received: from outbound.mailhop.org ([63.208.196.171] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8BCJ-0007zY-8V for secmech@ietf.org; Thu, 25 Aug 2005 02:26:47 -0400 Received: from c-67-182-139-247.hsd1.wa.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.51) id 1E8BBo-000CvE-OO; Thu, 25 Aug 2005 02:26:17 -0400 Received: by internaut.com (Postfix, from userid 1000) id 1042060DDD; Wed, 24 Aug 2005 23:26:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by internaut.com (Postfix) with ESMTP id 037E760DDC; Wed, 24 Aug 2005 23:26:16 -0700 (PDT) X-Mail-Handler: MailHop Outbound by DynDNS.org X-Originating-IP: 67.182.139.247 X-Report-Abuse-To: abuse@dyndns.org (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba Date: Wed, 24 Aug 2005 23:26:15 -0700 (PDT) From: Bernard Aboba To: Nicolas Williams Subject: Re: [SECMECH] Framework Bindings Vs. Mechanism Bridges In-Reply-To: <20050825042105.GW10174@binky.Central.Sun.COM> Message-ID: References: <35850EE42DFD2824F0DDBBC8@cumulus> <1DCACCAC04655B3AFE9733A8@cumulus> <20050822154044.GE7789@binky.Central.Sun.COM> <430CA545.3020109@uni-tuebingen.de> <20050824213010.GO10174@binky.Central.Sun.COM> <20050825042105.GW10174@binky.Central.Sun.COM> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.1 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 X-Mailman-Approved-At: Thu, 25 Aug 2005 11:06:33 -0400 Cc: secmech@ietf.org X-BeenThere: secmech@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security mechanisms BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: secmech-bounces@lists.ietf.org Errors-To: secmech-bounces@lists.ietf.org > No, I used "weak" to mean mechanisms that are subject to off-line > dictionary attacks by eavesdroppers or MITMs. If the EAP method generates a key and the tunneling mechanism supports cryptographic binding and satisfies the other RFC 4017 requirements (e.g. key strength, etc.) then I don't think that offline dictionary or MITM attack should be possible. Here is a brief summary of RFC 4017 requirements: MANDATORY [1] Key derivation. [2] Effective Key strength of at least 128-bits. [3] Mutual authentication. [4] Shared state equivalence. See RFC 4017 for details. [5] Resistance to dictionary attacks. [6] Protection against man-in-the-middle attacks. [7] Protected ciphersuite negotiation. RECOMMENDED [8] Fragmentation. [9] End-user identity hiding. OPTIONAL [10] Channel binding. [11] Fast reconnect. My guess is that Kerberos tunneled in TLS should be able to satisfy most if not all of these, assuming that cryptobinding is used. > Summary: IAKERB and EAP-GSS are dead at this time, mostly for lack of > people willing to do the work, not for any political or technical > reasons. >From a technical perspective, there are some challenges to securely providing authentication simultaneously with fast handoff. One issue is how the EAP peer figures out what Kerberos principals it needs to request a ticket for. Remember that EAP operates of a layer 2 protocol such as 802.11, and since the peer doesn't yet have IP connectivity, it may not know the IP Address or name of the NAS it is trying to connect to. In 802.11i, all the station knows is the BSSID of the AP; it doesn't know what NAS that BSSID is associated with, let alone the IP address, service name, etc. In the original IEEE 802.11i documents, it was assumed that the peer would request a ticket to the "Network Access Service" but this required all NAS devices to share a secret with the KDC so that a ticket, once granted, could be reused with any NAS. While this was very convenient for handoff, it was not so great from a shared secret hygene point of view. To enable the peer to figure out what tickets it needs, it seems like the AP would need to advertise its Kerberos Service Name, which might or might not be the same as the NAS-Identifier sent to the AAA server. Also, having to request a new ticket for each NAS, with a roundtrip to the KDC for each attempt, may not meet the stringent timing requirements of VOIP applications (handoff times <50 ms). So I think you'd need to figure out how to optimize the exchange, such as allowing an EAP peer to simultaneously request tickets to multiple NAS devices. However, if you can figure all this out, there could be some tangible benefits -- in particular with Kerberos it is possible to ensure proper key binding, which is not easy to do with current approaches. For example, a Kerberos ticket cannot easily be used by a NAS device other than the one it was created for. > I.e., I'm pretty sure there'd be no opposition from the IETF, the > Internet Security Area Directors or the IESG as a whole to a revival of > IAKERB and/or EAP-GSS, provided someone does the work. See below. Remember that at one time Kerberos was mandatory to implement in IEEE 802.11i. During that period there were lots of people will to work on Kerberos network access issues. However after it became clear that Kerberos by itself could not meet the 802.11 security requirements, and also that work in the IETF was not moving forward at a reasonable pace, IEEE 802.11i voted to remove Kerberos as the mandatory to implement method. At this point, I doubt you will find much interest within the 802.11 vendor community in revisiting Kerberos unless it can be demonstrated that Kerberos can provide some tangible benefit that isn't available with the fast handoff schemes being investigated in IEEE 802.11r. _______________________________________________ SECMECH mailing list SECMECH@lists.ietf.org https://www1.ietf.org/mailman/listinfo/secmech From secmech-bounces@lists.ietf.org Thu Aug 25 11:19:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8JVu-0000aQ-IP; Thu, 25 Aug 2005 11:19:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8JVs-0000aL-Sd for secmech@megatron.ietf.org; Thu, 25 Aug 2005 11:19:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22599 for ; Thu, 25 Aug 2005 11:19:30 -0400 (EDT) Received: from talkeetna.isc-net.upenn.edu ([128.91.197.188]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8JWO-0006D8-JC for secmech@ietf.org; Thu, 25 Aug 2005 11:20:07 -0400 Received: by talkeetna.isc-net.upenn.edu (Postfix, from userid 4127) id 2434E4477; Thu, 25 Aug 2005 11:19:23 -0400 (EDT) Date: Thu, 25 Aug 2005 11:19:23 -0400 From: Shumon Huque To: Jari Arkko Subject: Re: [SECMECH] Framework Bindings Vs. Mechanism Bridges Message-ID: <20050825151922.GA29211@isc.upenn.edu> References: <7210B31550AC934A8637D6619739CE6905C06510@e2k-sea-xch2.sea-alpha.cisco.com> <20050819210308.GI6659@binky.Central.Sun.COM> <20050820031035.GA5352@isc.upenn.edu> <43074F76.8000604@cs.umd.edu> <20050822044255.GC27685@isc.upenn.edu> <430DCD61.1090109@piuha.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <430DCD61.1090109@piuha.net> User-Agent: Mutt/1.4.2.1i Organization: University of Pennsylvania X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: secmech@ietf.org, Nicolas Williams X-BeenThere: secmech@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security mechanisms BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: secmech-bounces@lists.ietf.org Errors-To: secmech-bounces@lists.ietf.org On Thu, Aug 25, 2005 at 04:53:37PM +0300, Jari Arkko wrote: > Shumon Huque wrote: > > >I'm also not a fan of automatically assuming that a tunnel is the > >right solution for many problems. If we are tunnelling in TLS for > >example, I now have additional issues to deal with. Such as how to > >query up-to-date certificate revocation status, and whether my > >users are properly validating the certificates etc. > > > > > Given choice, I'd rather have a well-design fully > capable mechanisms than a tunnel + a mechanism > that needs to run inside the tunnel. > > --Jari I completely agree. However, current options don't look good for Kerberos 5, unless a strong password based pre-authentication mechanism is developed. So, I'm willing to endorse the scheme of running Kerberos inside TLS, at least as an interim measure (ala Tom Clancy's recent diagram). --Shumon. _______________________________________________ SECMECH mailing list SECMECH@lists.ietf.org https://www1.ietf.org/mailman/listinfo/secmech From secmech-bounces@lists.ietf.org Thu Aug 25 11:26:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8JcJ-0002xy-IH; Thu, 25 Aug 2005 11:26:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8JcI-0002xh-Gw for secmech@megatron.ietf.org; Thu, 25 Aug 2005 11:26:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23246 for ; Thu, 25 Aug 2005 11:26:07 -0400 (EDT) Received: from talkeetna.isc-net.upenn.edu ([128.91.197.188]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8Jcq-0006YQ-6W for secmech@ietf.org; Thu, 25 Aug 2005 11:26:44 -0400 Received: by talkeetna.isc-net.upenn.edu (Postfix, from userid 4127) id 577224479; Thu, 25 Aug 2005 11:26:09 -0400 (EDT) Date: Thu, 25 Aug 2005 11:26:09 -0400 From: Shumon Huque To: Jari Arkko Subject: Re: [SECMECH] Framework Bindings Vs. Mechanism Bridges Message-ID: <20050825152609.GB29211@isc.upenn.edu> References: <5057734.1124708889160.JavaMail.servlet@kundenserver> <20050822114112.GA343@isc.upenn.edu> <430DCD75.5040601@piuha.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <430DCD75.5040601@piuha.net> User-Agent: Mutt/1.4.2.1i Organization: University of Pennsylvania X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: secmech@ietf.org X-BeenThere: secmech@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security mechanisms BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: secmech-bounces@lists.ietf.org Errors-To: secmech-bounces@lists.ietf.org On Thu, Aug 25, 2005 at 04:53:57PM +0300, Jari Arkko wrote: > Shumon Huque wrote: > > >On Mon, Aug 22, 2005 at 01:08:09PM +0200, t.otto@sharevolution.de wrote: > > > >>There already exists a Kerberos extension to TLS, RFC 2712 (Oct.99), > >>which can be run in EAP-TLS, so the question is: > >> > >>* Is there need for EAP-Kerberos at all? * > >> > >RFC 2712 doesn't provide for initial and service ticket > >acquisition. So, at the very least an EAP method that > >allows you to do that needs to be developed. > > > > > Do you need a fix to EAP, or do you a fix to kerberos-in-TLS? > The latter might be applicable in a number of other scenarios, > too... > > --Jari Most application protocols that support Kerberos authentication today assume that ticket acquisition is performed out of band. The Kerberos ciphersuite specification for TLS takes the same architectural approach. Although, I realize that TLS itself isn't an application, but a framework. Hence perhaps it should support a way to do ticket acquisition. Any thoughts? With EAP for network access authentication, the ticket acquisition step itself needs to be supported via an EAP method. I don't have any strong opinions about whether there should be a separate ticket acquistion method, or whether it should be part of an integrated Kerberos method that does ticket acquisition and authentication. But the latter seems simpler. One other possibility is for TLS to support GSS-API and then an IAKERB GSS-API mechnism could provide ticket acquisition support. I think Nico may have mentioned this already. Again, this requires updated versions of both those protocols (in addition to TLS) to be usable in EAP, and hence we could be waiting a while :-) --Shumon. _______________________________________________ SECMECH mailing list SECMECH@lists.ietf.org https://www1.ietf.org/mailman/listinfo/secmech From secmech-bounces@lists.ietf.org Thu Aug 25 11:35:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8JlV-0006j1-EL; Thu, 25 Aug 2005 11:35:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8JlT-0006gW-BJ for secmech@megatron.ietf.org; Thu, 25 Aug 2005 11:35:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23917 for ; Thu, 25 Aug 2005 11:35:37 -0400 (EDT) Received: from dirg.bris.ac.uk ([137.222.10.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8Jm0-0006uB-Bt for secmech@ietf.org; Thu, 25 Aug 2005 11:36:13 -0400 Received: from isis.bris.ac.uk ([137.222.10.63]) by dirg.bris.ac.uk with esmtp (Exim 4.51) id 1E8JkT-0005Ms-EZ; Thu, 25 Aug 2005 16:34:39 +0100 Received: from cumulus.cse.bris.ac.uk ([137.222.12.162]) by isis.bris.ac.uk with esmtp (Exim 4.51) id 1E8Jj5-0001XG-E2; Thu, 25 Aug 2005 16:33:14 +0100 Date: Thu, 25 Aug 2005 16:33:11 +0100 From: Josh Howlett To: Shumon Huque , Jari Arkko Subject: Re: [SECMECH] Framework Bindings Vs. Mechanism Bridges Message-ID: In-Reply-To: <20050825151922.GA29211@isc.upenn.edu> References: <7210B31550AC934A8637D6619739CE6905C06510@e2k-sea-xch2.sea-alpha. cisco.com> <20050819210308.GI6659@binky.Central.Sun.COM> <20050820031035.GA5352@isc.upenn.edu> <43074F76.8000604@cs.umd.edu> <20050822044255.GC27685@isc.upenn.edu> <430DCD61.1090109@piuha.net> <20050825151922.GA29211@isc.upenn.edu> Originator-Info: login-token=Mulberry:015adzIEcc3YYoELl/H0YXoJMiHqd5JUrV1ZIZG6d3FRMc3g==; token_authority=postmaster@bristol.ac.uk X-Mailer: Mulberry/3.1.5 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: -2.8 X-Spam-Level: -- X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit Cc: secmech@ietf.org, Nicolas Williams X-BeenThere: secmech@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Josh Howlett List-Id: Security mechanisms BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: secmech-bounces@lists.ietf.org Errors-To: secmech-bounces@lists.ietf.org --On Thursday, August 25, 2005 11:19:23 -0400 Shumon Huque wrote: > On Thu, Aug 25, 2005 at 04:53:37PM +0300, Jari Arkko wrote: >> Shumon Huque wrote: >> >> > I'm also not a fan of automatically assuming that a tunnel is the >> > right solution for many problems. If we are tunnelling in TLS for >> > example, I now have additional issues to deal with. Such as how to >> > query up-to-date certificate revocation status, and whether my >> > users are properly validating the certificates etc. >> > >> > >> Given choice, I'd rather have a well-design fully >> capable mechanisms than a tunnel + a mechanism >> that needs to run inside the tunnel. >> >> --Jari > > I completely agree. However, current options don't look good > for Kerberos 5, unless a strong password based pre-authentication > mechanism is developed. So, I'm willing to endorse the scheme > of running Kerberos inside TLS, at least as an interim measure > (ala Tom Clancy's recent diagram). IIRC, it was inside TTLS. However, it might it still be worth considering an EAP-Kerberos so as not to preclude the option of running it inside PEAP as well (even if native EAP-Kerberos is a Bad Idea over 802.11). It might also provide the basis for a subsequent improved Kerberos EAP method that could be used natively. josh. -- ----------------------------------------------------------- Josh Howlett, Networking & Digital Communications, Information Systems & Computing, University of Bristol, U.K. 'phone: 0117 928 7850 email: josh.howlett@bris.ac.uk ------------------------------------------------------------ _______________________________________________ SECMECH mailing list SECMECH@lists.ietf.org https://www1.ietf.org/mailman/listinfo/secmech From secmech-bounces@lists.ietf.org Thu Aug 25 11:53:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8K2S-0003rj-It; Thu, 25 Aug 2005 11:53:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8K2R-0003re-2P for secmech@megatron.ietf.org; Thu, 25 Aug 2005 11:53:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25639 for ; Thu, 25 Aug 2005 11:53:06 -0400 (EDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8K2t-0007Wl-Gf for secmech@ietf.org; Thu, 25 Aug 2005 11:53:43 -0400 Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id j7PFr3HT020310 for ; Thu, 25 Aug 2005 08:53:04 -0700 (PDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id j7PFr3fa002740 for ; Thu, 25 Aug 2005 09:53:03 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id j7PFr1pD015734; Thu, 25 Aug 2005 10:53:01 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id j7PFr0Kh015733; Thu, 25 Aug 2005 10:53:00 -0500 (CDT) Date: Thu, 25 Aug 2005 10:53:00 -0500 From: Nicolas Williams To: Jari Arkko Subject: Re: [SECMECH] Framework Bindings Vs. Mechanism Bridges Message-ID: <20050825155300.GA15718@binky.Central.Sun.COM> References: <5057734.1124708889160.JavaMail.servlet@kundenserver> <20050822114112.GA343@isc.upenn.edu> <430DCD75.5040601@piuha.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <430DCD75.5040601@piuha.net> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: secmech@ietf.org X-BeenThere: secmech@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security mechanisms BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: secmech-bounces@lists.ietf.org Errors-To: secmech-bounces@lists.ietf.org On Thu, Aug 25, 2005 at 04:53:57PM +0300, Jari Arkko wrote: > Shumon Huque wrote: > >RFC 2712 doesn't provide for initial and service ticket > >acquisition. So, at the very least an EAP method that > >allows you to do that needs to be developed. > > > > > Do you need a fix to EAP, or do you a fix to kerberos-in-TLS? > The latter might be applicable in a number of other scenarios, > too... Fixing RFC2712 so it actually works with Kerberos V extensions (by not unnecessarily making up its own Authenticator and AP exchange messages) is eminently doable. Fixing RFC2712 to provide IAKERB-like features is another story -- TLS has a fixed number of round-trips! (If you'll remember, I mentioned the possibility for "GSS ciphersuites for TLS" at the BoF and mentioned this problem as something that would have to be fixed in TLS). Nico -- _______________________________________________ SECMECH mailing list SECMECH@lists.ietf.org https://www1.ietf.org/mailman/listinfo/secmech From secmech-bounces@lists.ietf.org Thu Aug 25 12:05:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8KEi-0006oD-PK; Thu, 25 Aug 2005 12:05:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8KEi-0006o4-08 for secmech@megatron.ietf.org; Thu, 25 Aug 2005 12:05:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26300 for ; Thu, 25 Aug 2005 12:05:49 -0400 (EDT) Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8KFF-0007u7-CD for secmech@ietf.org; Thu, 25 Aug 2005 12:06:26 -0400 Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 0754A89852; Thu, 25 Aug 2005 19:05:35 +0300 (EEST) Message-ID: <430DEC5A.4000408@piuha.net> Date: Thu, 25 Aug 2005 19:05:46 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nicolas Williams Subject: Re: [SECMECH] Framework Bindings Vs. Mechanism Bridges References: <5057734.1124708889160.JavaMail.servlet@kundenserver> <20050822114112.GA343@isc.upenn.edu> <430DCD75.5040601@piuha.net> <20050825155300.GA15718@binky.Central.Sun.COM> In-Reply-To: <20050825155300.GA15718@binky.Central.Sun.COM> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Cc: secmech@ietf.org X-BeenThere: secmech@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security mechanisms BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: secmech-bounces@lists.ietf.org Errors-To: secmech-bounces@lists.ietf.org Nicolas Williams wrote: >Fixing RFC2712 so it actually works with Kerberos V extensions (by not >unnecessarily making up its own Authenticator and AP exchange messages) >is eminently doable. > >Fixing RFC2712 to provide IAKERB-like features is another story -- TLS >has a fixed number of round-trips! (If you'll remember, I mentioned the >possibility for "GSS ciphersuites for TLS" at the BoF and mentioned this >problem as something that would have to be fixed in TLS). > > Ok. I'm starting to remember this now... --Jari _______________________________________________ SECMECH mailing list SECMECH@lists.ietf.org https://www1.ietf.org/mailman/listinfo/secmech From secmech-bounces@lists.ietf.org Thu Aug 25 23:44:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8V8c-0002zx-JQ; Thu, 25 Aug 2005 23:44:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8V8c-0002zQ-1y for secmech@megatron.ietf.org; Thu, 25 Aug 2005 23:44:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA10961 for ; Thu, 25 Aug 2005 23:44:15 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8V9F-0005sq-IY for secmech@ietf.org; Thu, 25 Aug 2005 23:44:58 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 25 Aug 2005 20:44:07 -0700 X-IronPort-AV: i="3.96,142,1122879600"; d="scan'208"; a="656878423:sNHT29051500" Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j7Q3i4oo014467; Thu, 25 Aug 2005 20:44:04 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [SECMECH] Framework Bindings Vs. Mechanism Bridges Date: Thu, 25 Aug 2005 20:48:57 -0700 Message-ID: <7210B31550AC934A8637D6619739CE6905C8BEEC@e2k-sea-xch2.sea-alpha.cisco.com> Thread-Topic: [SECMECH] Framework Bindings Vs. Mechanism Bridges Thread-Index: AcWo8smOFhG4wmLUT72KpPpe8uFvrQA/E6Mg From: "Salowey, Joe" To: "Bernard Aboba" , "Ali Fessi" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: quoted-printable Cc: secmech@ietf.org X-BeenThere: secmech@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security mechanisms BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: secmech-bounces@lists.ietf.org Errors-To: secmech-bounces@lists.ietf.org > EAP-Kerb/IAKERB/GSS is inherently different other EAP methods=20 > because it requires support for the method on the NAS. That=20 > is, the NAS needs to support Kerberos for a peer to be able=20 > to submit a TGS to the NAS in order to obtain network access.=20 >=20 [Joe] I'm not quite sure what you mean. If a AAA server is not involved then this is not really any different than terminating EAP-TLS on a NAS. It could also be possible to still involve a AAA and have it terminate the method and talk to the KDC. If you are trying to implement a method that is evaluated by both the NAS and the AAA in the same transaction you are really doing something other than EAP.=20 _______________________________________________ SECMECH mailing list SECMECH@lists.ietf.org https://www1.ietf.org/mailman/listinfo/secmech From secmech-bounces@lists.ietf.org Fri Aug 26 00:51:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8WBI-0006Yh-4Z; Fri, 26 Aug 2005 00:51:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8WBG-0006Yc-4q for secmech@megatron.ietf.org; Fri, 26 Aug 2005 00:51:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13197 for ; Fri, 26 Aug 2005 00:51:01 -0400 (EDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8WBq-0007d7-8o for secmech@ietf.org; Fri, 26 Aug 2005 00:51:45 -0400 Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id j7Q4otHT007732 for ; Thu, 25 Aug 2005 21:50:55 -0700 (PDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id j7Q4osfc010307 for ; Thu, 25 Aug 2005 22:50:55 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id j7Q4osxO017245; Thu, 25 Aug 2005 23:50:54 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id j7Q4oqeU017244; Thu, 25 Aug 2005 23:50:52 -0500 (CDT) Date: Thu, 25 Aug 2005 23:50:52 -0500 From: Nicolas Williams To: "Salowey, Joe" Subject: Re: [SECMECH] Framework Bindings Vs. Mechanism Bridges Message-ID: <20050826045052.GI15718@binky.Central.Sun.COM> References: <7210B31550AC934A8637D6619739CE6905C8BEEC@e2k-sea-xch2.sea-alpha.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7210B31550AC934A8637D6619739CE6905C8BEEC@e2k-sea-xch2.sea-alpha.cisco.com> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: secmech@ietf.org, Bernard Aboba X-BeenThere: secmech@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security mechanisms BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: secmech-bounces@lists.ietf.org Errors-To: secmech-bounces@lists.ietf.org On Thu, Aug 25, 2005 at 08:48:57PM -0700, Salowey, Joe wrote: > > > EAP-Kerb/IAKERB/GSS is inherently different other EAP methods > > because it requires support for the method on the NAS. That > > is, the NAS needs to support Kerberos for a peer to be able > > to submit a TGS to the NAS in order to obtain network access. > > > [Joe] I'm not quite sure what you mean. If a AAA server is not involved > then this is not really any different than terminating EAP-TLS on a NAS. > It could also be possible to still involve a AAA and have it terminate > the method and talk to the KDC. If you are trying to implement a method > that is evaluated by both the NAS and the AAA in the same transaction > you are really doing something other than EAP. I agree. It isn't even the case that the peer's realm would have to have a cross-realm Kerberos V path to the NAS's realm; if there was an x-realm path from the EAP peer to the NAS then the NAS could just be the EAP server. And if there be no such x-realm path then the NAS need not even know a thing about Kerberos V. Or am I missing some way in which EAP-Kerb/IAKERB/GSS is fundamentally different from existing EAP methods [in some bad way]? Nico -- _______________________________________________ SECMECH mailing list SECMECH@lists.ietf.org https://www1.ietf.org/mailman/listinfo/secmech From secmech-bounces@lists.ietf.org Fri Aug 26 01:09:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8WSh-0002vb-MP; Fri, 26 Aug 2005 01:09:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8WSf-0002vU-HQ for secmech@megatron.ietf.org; Fri, 26 Aug 2005 01:09:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13951 for ; Fri, 26 Aug 2005 01:09:04 -0400 (EDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8WTJ-00087R-9w for secmech@ietf.org; Fri, 26 Aug 2005 01:09:47 -0400 Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id j7Q5912B010927 for ; Thu, 25 Aug 2005 22:09:01 -0700 (PDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id j7Q590fc016041 for ; Thu, 25 Aug 2005 23:09:01 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id j7Q590ca017265; Fri, 26 Aug 2005 00:09:00 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id j7Q58whV017264; Fri, 26 Aug 2005 00:08:58 -0500 (CDT) Date: Fri, 26 Aug 2005 00:08:58 -0500 From: Nicolas Williams To: Jari Arkko Subject: Re: [SECMECH] Method work Message-ID: <20050826050857.GJ15718@binky.Central.Sun.COM> References: <7210B31550AC934A8637D6619739CE6905C06A6B@e2k-sea-xch2.sea-alpha.cisco.com> <430DC8B3.9010309@piuha.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <430DC8B3.9010309@piuha.net> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: secmech@ietf.org X-BeenThere: secmech@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security mechanisms BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: secmech-bounces@lists.ietf.org Errors-To: secmech-bounces@lists.ietf.org On Thu, Aug 25, 2005 at 04:33:39PM +0300, Jari Arkko wrote: > Salowey, Joe wrote: > >5. Kerberos - Something that provide for initial authentication and a > >strategy for resisting dictionary attacks. Applicable to EAP, possibly > >GSS. > > > > > I don't currently see a big customer demand for this. But > I could be viewing at the wrong "market segment". It seems to me that that organizations with large Kerberos V deployments should find it useful to be able to use Kerberos V for user authentication in EAP applications (wifi, VPN, say). Or do/would organizations with large Kerberos V deployments find this feature unappealing for some reason that escapes me? Perhaps because they might want EAP to authenticate a device more than a user? Or perhaps because they want hardware tokens? But nothing [technically] stops one from using hw tokens to store high-quality long-term Kerberos V secret keys, and then there's PKINIT. Or maybe such organizations are good at user enrollment wherever they can't use Kerberos and so don't have a strong need for it in EAP applications -- they might like it, but they get by without it. But anyways, a GUAM IAKERB mechanism with GSS-API and EAP framework bindings would definitely be useful in GSS contexts; so if we undertake GUAM then the matter of whether EAP-IAKERB is useful seems less relevant (unless it turns out that a GSS IAKERB mechanism is significantly without GUAM and EAP in the picture). > Other: enrollment, perhaps a la what Rohan Mahy wanted > to do in the last EAP WG meeting. Enrollment seems like it would be useful in network access technologies. But for business reasons enrollment needs to be very, er, free form, involving HTML and friends. Nico -- _______________________________________________ SECMECH mailing list SECMECH@lists.ietf.org https://www1.ietf.org/mailman/listinfo/secmech From secmech-bounces@lists.ietf.org Fri Aug 26 10:17:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8f1l-0004Zn-Lp; Fri, 26 Aug 2005 10:17:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8Xsz-0002L5-JW for secmech@megatron.ietf.org; Fri, 26 Aug 2005 02:40:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00642 for ; Fri, 26 Aug 2005 02:40:16 -0400 (EDT) Received: from outbound.mailhop.org ([63.208.196.171] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8Xta-0001zg-Kz for secmech@ietf.org; Fri, 26 Aug 2005 02:40:59 -0400 Received: from c-67-182-139-247.hsd1.wa.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.51) id 1E8Xsj-000GT3-Aq; Fri, 26 Aug 2005 02:40:05 -0400 Received: by internaut.com (Postfix, from userid 1000) id 5F65160D6A; Thu, 25 Aug 2005 23:40:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by internaut.com (Postfix) with ESMTP id 4F2AF60D69; Thu, 25 Aug 2005 23:40:04 -0700 (PDT) X-Mail-Handler: MailHop Outbound by DynDNS.org X-Originating-IP: 67.182.139.247 X-Report-Abuse-To: abuse@dyndns.org (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba Date: Thu, 25 Aug 2005 23:40:04 -0700 (PDT) From: Bernard Aboba To: "Salowey, Joe" Subject: RE: [SECMECH] Framework Bindings Vs. Mechanism Bridges In-Reply-To: <7210B31550AC934A8637D6619739CE6905C8BEEC@e2k-sea-xch2.sea-alpha.cisco.com> Message-ID: References: <7210B31550AC934A8637D6619739CE6905C8BEEC@e2k-sea-xch2.sea-alpha.cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab X-Mailman-Approved-At: Fri, 26 Aug 2005 10:17:44 -0400 Cc: secmech@ietf.org X-BeenThere: secmech@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security mechanisms BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: secmech-bounces@lists.ietf.org Errors-To: secmech-bounces@lists.ietf.org > > EAP-Kerb/IAKERB/GSS is inherently different other EAP methods > > because it requires support for the method on the NAS. That > > is, the NAS needs to support Kerberos for a peer to be able > > to submit a TGS to the NAS in order to obtain network access. > > > [Joe] I'm not quite sure what you mean. If a AAA server is not involved > then this is not really any different than terminating EAP-TLS on a NAS. It's different because the NAS needs to support Kerberos even if it is operating in "Pass-through" mode. In contrast, a NAS operating in pass-through mode for EAP-TLS doesn't need to validate the client certificate. > It could also be possible to still involve a AAA and have it terminate > the method and talk to the KDC. If you are trying to implement a method > that is evaluated by both the NAS and the AAA in the same transaction > you are really doing something other than EAP. In all the EAP Kerberos proposals I've seen the method is terminated on either the NAS or AAA server, but not both. But in any scenario, the NAS still needs to support Kerberos, in order to validate the "network access" service ticket. _______________________________________________ SECMECH mailing list SECMECH@lists.ietf.org https://www1.ietf.org/mailman/listinfo/secmech From secmech-bounces@lists.ietf.org Fri Aug 26 10:32:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8fFt-0000JP-64; Fri, 26 Aug 2005 10:32:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8fFp-0000Gn-D9 for secmech@megatron.ietf.org; Fri, 26 Aug 2005 10:32:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23799 for ; Fri, 26 Aug 2005 10:32:21 -0400 (EDT) Received: from talkeetna.isc-net.upenn.edu ([128.91.197.188]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8fGW-0000DU-MW for secmech@ietf.org; Fri, 26 Aug 2005 10:33:09 -0400 Received: by talkeetna.isc-net.upenn.edu (Postfix, from userid 4127) id ED7B84477; Fri, 26 Aug 2005 10:32:14 -0400 (EDT) Date: Fri, 26 Aug 2005 10:32:14 -0400 From: Shumon Huque To: Bernard Aboba Subject: Re: [SECMECH] Framework Bindings Vs. Mechanism Bridges Message-ID: <20050826143214.GA9194@isc.upenn.edu> References: <7210B31550AC934A8637D6619739CE6905C8BEEC@e2k-sea-xch2.sea-alpha.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Organization: University of Pennsylvania X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: secmech@ietf.org X-BeenThere: secmech@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security mechanisms BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: secmech-bounces@lists.ietf.org Errors-To: secmech-bounces@lists.ietf.org On Thu, Aug 25, 2005 at 11:40:04PM -0700, Bernard Aboba wrote: > > > It could also be possible to still involve a AAA and have it terminate > > the method and talk to the KDC. If you are trying to implement a method > > that is evaluated by both the NAS and the AAA in the same transaction > > you are really doing something other than EAP. > > In all the EAP Kerberos proposals I've seen the method is terminated on > either the NAS or AAA server, but not both. But in any scenario, the > NAS still needs to support Kerberos, in order to validate the "network > access" service ticket. The AAA server could perform the service ticket validation on behalf of the NAS. This requires another round trip with the AAA server, but I don't think this is too much of a problem. If we need the NAS to support Kerberos, then I think the barrier to practical deployment is too high. Or am I missing something? _______________________________________________ SECMECH mailing list SECMECH@lists.ietf.org https://www1.ietf.org/mailman/listinfo/secmech From secmech-bounces@lists.ietf.org Fri Aug 26 10:38:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8fLn-00021z-T3; Fri, 26 Aug 2005 10:38:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8fLm-00021u-Jv for secmech@megatron.ietf.org; Fri, 26 Aug 2005 10:38:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24097 for ; Fri, 26 Aug 2005 10:38:32 -0400 (EDT) Received: from dirg.bris.ac.uk ([137.222.10.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8fMQ-0000OA-7g for secmech@ietf.org; Fri, 26 Aug 2005 10:39:21 -0400 Received: from isis.bris.ac.uk ([137.222.10.63]) by dirg.bris.ac.uk with esmtp (Exim 4.51) id 1E8fJp-0001yG-AS; Fri, 26 Aug 2005 15:36:35 +0100 Received: from cumulus.cse.bris.ac.uk ([137.222.12.162]) by isis.bris.ac.uk with esmtp (Exim 4.51) id 1E8fI4-0002Q5-9v; Fri, 26 Aug 2005 15:34:47 +0100 Date: Fri, 26 Aug 2005 15:34:43 +0100 From: Josh Howlett To: Bernard Aboba , "Salowey, Joe" Subject: RE: [SECMECH] Framework Bindings Vs. Mechanism Bridges Message-ID: <191B6A09CAEEC043419A68E5@cumulus> In-Reply-To: References: <7210B31550AC934A8637D6619739CE6905C8BEEC@e2k-sea-xch2.sea-alpha. cisco.com> Originator-Info: login-token=Mulberry:01S4pTya3/vS+O85kohaz6gDyIAYcii7C4tTt//ocge3n/vg==; token_authority=postmaster@bristol.ac.uk X-Mailer: Mulberry/3.1.5 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: -2.8 X-Spam-Level: -- X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Cc: secmech@ietf.org X-BeenThere: secmech@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Josh Howlett List-Id: Security mechanisms BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: secmech-bounces@lists.ietf.org Errors-To: secmech-bounces@lists.ietf.org --On Thursday, August 25, 2005 23:40:04 -0700 Bernard Aboba wrote: >> It could also be possible to still involve a AAA and have it terminate >> the method and talk to the KDC. If you are trying to implement a method >> that is evaluated by both the NAS and the AAA in the same transaction >> you are really doing something other than EAP. > > In all the EAP Kerberos proposals I've seen the method is terminated on > either the NAS or AAA server, but not both. But in any scenario, the > NAS still needs to support Kerberos, in order to validate the "network > access" service ticket. Just to clarify - it would be possible for the AAA server to authenticate against the KDC and return an EAP-Success to the NAS as per other EAP types, without the NAS needing to understand Kerberos. However, the NAS would need to understand Kerberos in order to allow a service ticket to be used for, ie, fast reconnect (...which is undesirable for secret hygene). Right? josh. -- ----------------------------------------------------------- Josh Howlett, Networking & Digital Communications, Information Systems & Computing, University of Bristol, U.K. 'phone: 0117 928 7850 email: josh.howlett@bris.ac.uk ------------------------------------------------------------ _______________________________________________ SECMECH mailing list SECMECH@lists.ietf.org https://www1.ietf.org/mailman/listinfo/secmech From secmech-bounces@lists.ietf.org Fri Aug 26 10:49:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8fWI-0005EB-BR; Fri, 26 Aug 2005 10:49:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8fWG-0005BX-3B for secmech@megatron.ietf.org; Fri, 26 Aug 2005 10:49:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24655 for ; Fri, 26 Aug 2005 10:49:22 -0400 (EDT) Received: from carrierpigeon.cs.umd.edu ([128.8.129.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8fWz-0000ky-H6 for secmech@ietf.org; Fri, 26 Aug 2005 10:50:10 -0400 Received: from ismene (ismene.cs.umd.edu [128.8.126.62]) by carrierpigeon.cs.umd.edu (8.12.10/8.12.5) with ESMTP id j7QEmkfD026002; Fri, 26 Aug 2005 10:48:56 -0400 (EDT) Date: Fri, 26 Aug 2005 10:43:27 -0400 (EDT) From: Charles Clancy X-X-Sender: clancy@ismene To: Josh Howlett Subject: RE: [SECMECH] Framework Bindings Vs. Mechanism Bridges In-Reply-To: <191B6A09CAEEC043419A68E5@cumulus> Message-ID: References: <7210B31550AC934A8637D6619739CE6905C8BEEC@e2k-sea-xch2.sea-alpha. cisco.com> <191B6A09CAEEC043419A68E5@cumulus> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: secmech@ietf.org, Bernard Aboba X-BeenThere: secmech@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security mechanisms BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: secmech-bounces@lists.ietf.org Errors-To: secmech-bounces@lists.ietf.org On Fri, 26 Aug 2005, Josh Howlett wrote: > --On Thursday, August 25, 2005 23:40:04 -0700 Bernard Aboba > wrote: >> >> In all the EAP Kerberos proposals I've seen the method is terminated on >> either the NAS or AAA server, but not both. But in any scenario, the >> NAS still needs to support Kerberos, in order to validate the "network >> access" service ticket. > > Just to clarify - it would be possible for the AAA server to authenticate > against the KDC and return an EAP-Success to the NAS as per other EAP types, > without the NAS needing to understand Kerberos. However, the NAS would need > to understand Kerberos in order to allow a service ticket to be used for, ie, > fast reconnect (...which is undesirable for secret hygene). Using NAS-terminated Kerberos for fast handoff/reconnect is probably not a good idea due to the round trips, unless the NAS service ticket could be preemptively acquired. I think EAP-Kerberos should be terminated at the AAA server. Your service ticket is for "network access", not a particular NAS. The key contained within the service ticket could be used to bootstrap the traditional EAP keying. If you wanted fast reconnect or fast handoff, you could build it into the method by computing something like: initial key generation: MK = PRF(service key, "master key", nonces) MSK_1 = PRF(MK, "master session key", nonces) handoff: MSK_2 = PRF(MK, "new master session key", MSK_1 + nonces) Then the NAS doesn't need to know anything about Kerberos. [ t. charles clancy ]--[ tcc@umd.edu ]--[ www.cs.umd.edu/~clancy ] [ computer science ]-----[ university of maryland | college park ] _______________________________________________ SECMECH mailing list SECMECH@lists.ietf.org https://www1.ietf.org/mailman/listinfo/secmech From secmech-bounces@lists.ietf.org Fri Aug 26 11:02:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8fid-0008FI-3E; Fri, 26 Aug 2005 11:02:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8fib-0008E5-8S for secmech@megatron.ietf.org; Fri, 26 Aug 2005 11:02:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25219 for ; Fri, 26 Aug 2005 11:02:07 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8fjK-00017V-J5 for secmech@ietf.org; Fri, 26 Aug 2005 11:02:56 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 26 Aug 2005 08:01:58 -0700 Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j7QF1qQM021684; Fri, 26 Aug 2005 08:01:53 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [SECMECH] Framework Bindings Vs. Mechanism Bridges Date: Fri, 26 Aug 2005 08:06:48 -0700 Message-ID: <7210B31550AC934A8637D6619739CE6905C8BF21@e2k-sea-xch2.sea-alpha.cisco.com> Thread-Topic: [SECMECH] Framework Bindings Vs. Mechanism Bridges Thread-Index: AcWqCcdGZ+WYoNU1T9eJ2IHMCl+A1wARDwPQ From: "Salowey, Joe" To: "Bernard Aboba" X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: quoted-printable Cc: secmech@ietf.org X-BeenThere: secmech@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security mechanisms BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: secmech-bounces@lists.ietf.org Errors-To: secmech-bounces@lists.ietf.org =20 > -----Original Message----- > From: Bernard Aboba [mailto:aboba@internaut.com]=20 > Sent: Thursday, August 25, 2005 11:40 PM > To: Salowey, Joe > Cc: Ali Fessi; secmech@ietf.org > Subject: RE: [SECMECH] Framework Bindings Vs. Mechanism Bridges >=20 > > > EAP-Kerb/IAKERB/GSS is inherently different other EAP methods=20 > > > because it requires support for the method on the NAS. =20 > That is, the=20 > > > NAS needs to support Kerberos for a peer to be able to=20 > submit a TGS=20 > > > to the NAS in order to obtain network access. > > >=20 > > [Joe] I'm not quite sure what you mean. If a AAA server is not=20 > > involved then this is not really any different than=20 > terminating EAP-TLS on a NAS. >=20 > It's different because the NAS needs to support Kerberos even=20 > if it is operating in "Pass-through" mode. =20 [Joe] Then its not operating in "Pass-through" mode, it is terminating EAP (acting as an EAP server). > In contrast, a=20 > NAS operating in pass-through mode for EAP-TLS doesn't need=20 > to validate the client certificate.=20 >=20 > > It could also be possible to still involve a AAA and have=20 > it terminate=20 > > the method and talk to the KDC. If you are trying to implement a=20 > > method that is evaluated by both the NAS and the AAA in the same=20 > > transaction you are really doing something other than EAP. >=20 > In all the EAP Kerberos proposals I've seen the method is=20 > terminated on either the NAS or AAA server, but not both. =20 > But in any scenario, the NAS still needs to support Kerberos,=20 > in order to validate the "network access" service ticket.=20 [Joe] If this is done in the same method execution instance it seems problematic to me, because you have in effect two EAP-servers (one in the AAA and one in the NAS) processing the EAP messages. This is not EAP.=20 _______________________________________________ SECMECH mailing list SECMECH@lists.ietf.org https://www1.ietf.org/mailman/listinfo/secmech From secmech-bounces@lists.ietf.org Fri Aug 26 11:08:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8foN-0000Oc-Ej; Fri, 26 Aug 2005 11:08:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8fhF-0007qM-Qc for secmech@megatron.ietf.org; Fri, 26 Aug 2005 11:00:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25157 for ; Fri, 26 Aug 2005 11:00:43 -0400 (EDT) Received: from outbound.mailhop.org ([63.208.196.171] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8fhz-00014F-8M for secmech@ietf.org; Fri, 26 Aug 2005 11:01:32 -0400 Received: from c-67-182-139-247.hsd1.wa.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.51) id 1E8fhC-000O7C-Az; Fri, 26 Aug 2005 11:00:42 -0400 Received: by internaut.com (Postfix, from userid 1000) id A8AE22469D; Fri, 26 Aug 2005 08:00:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by internaut.com (Postfix) with ESMTP id 9E3122469A; Fri, 26 Aug 2005 08:00:41 -0700 (PDT) X-Mail-Handler: MailHop Outbound by DynDNS.org X-Originating-IP: 67.182.139.247 X-Report-Abuse-To: abuse@dyndns.org (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba Date: Fri, 26 Aug 2005 08:00:41 -0700 (PDT) From: Bernard Aboba To: Shumon Huque Subject: Re: [SECMECH] Framework Bindings Vs. Mechanism Bridges In-Reply-To: <20050826143214.GA9194@isc.upenn.edu> Message-ID: References: <7210B31550AC934A8637D6619739CE6905C8BEEC@e2k-sea-xch2.sea-alpha.cisco.com> <20050826143214.GA9194@isc.upenn.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.1 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 X-Mailman-Approved-At: Fri, 26 Aug 2005 11:08:06 -0400 Cc: secmech@ietf.org X-BeenThere: secmech@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security mechanisms BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: secmech-bounces@lists.ietf.org Errors-To: secmech-bounces@lists.ietf.org > The AAA server could perform the service ticket validation on > behalf of the NAS. This requires another round trip with the > AAA server, but I don't think this is too much of a problem. How does the EAP peer figure out the scope of usage of the "network access service" ticket? If each NAS is a separate Kerberos principal, then the peer needs a distinct ticket for each NAS; if the AAA server is the principal, then it can submit the same ticket to any NAS. > If we need the NAS to support Kerberos, then I think the barrier > to practical deployment is too high. Or am I missing something? I think that the NAS needs to be modified even in the case where the AAA server is the Kerberos principal, in order to be able to securely inform the EAP peer of the ticket scope. Otherwise, the EAP peer can't know when it needs to acquire another ticket. _______________________________________________ SECMECH mailing list SECMECH@lists.ietf.org https://www1.ietf.org/mailman/listinfo/secmech From secmech-bounces@lists.ietf.org Fri Aug 26 11:08:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8foN-0000P1-Mk; Fri, 26 Aug 2005 11:08:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8fmd-0000C8-GH for secmech@megatron.ietf.org; Fri, 26 Aug 2005 11:06:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25379 for ; Fri, 26 Aug 2005 11:06:17 -0400 (EDT) Received: from outbound.mailhop.org ([63.208.196.171] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8fnN-0001Eh-1j for secmech@ietf.org; Fri, 26 Aug 2005 11:07:06 -0400 Received: from c-67-182-139-247.hsd1.wa.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.51) id 1E8fmZ-000OoW-Ao; Fri, 26 Aug 2005 11:06:15 -0400 Received: by internaut.com (Postfix, from userid 1000) id 7B1842469D; Fri, 26 Aug 2005 08:06:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by internaut.com (Postfix) with ESMTP id 6CC552469A; Fri, 26 Aug 2005 08:06:14 -0700 (PDT) X-Mail-Handler: MailHop Outbound by DynDNS.org X-Originating-IP: 67.182.139.247 X-Report-Abuse-To: abuse@dyndns.org (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba Date: Fri, 26 Aug 2005 08:06:14 -0700 (PDT) From: Bernard Aboba To: Josh Howlett Subject: RE: [SECMECH] Framework Bindings Vs. Mechanism Bridges In-Reply-To: <191B6A09CAEEC043419A68E5@cumulus> Message-ID: References: <7210B31550AC934A8637D6619739CE6905C8BEEC@e2k-sea-xch2.sea-alpha. cisco.com> <191B6A09CAEEC043419A68E5@cumulus> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.1 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 X-Mailman-Approved-At: Fri, 26 Aug 2005 11:08:06 -0400 Cc: secmech@ietf.org X-BeenThere: secmech@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security mechanisms BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: secmech-bounces@lists.ietf.org Errors-To: secmech-bounces@lists.ietf.org > Just to clarify - it would be possible for the AAA server to authenticate > against the KDC and return an EAP-Success to the NAS as per other EAP types, > without the NAS needing to understand Kerberos. However, the NAS would need to > understand Kerberos in order to allow a service ticket to be used for, ie, > fast reconnect (...which is undesirable for secret hygene). > > Right? Yes, if the NAS needs to act as a Kerberos principal, it needs to support Kerberos. Note that "fast handoff" typically refers to situations in which the AAA server does not need to be contacted during a handoff. If the EAP peer needs to obtain a new ticket for each NAS, and each ticket request requires a round-trip to the KDC, that is not "fast handoff" as the term is normally used. If in addition the NAS needs a round-trip to the AAA server in order to validate each ticket (e.g. the case where the AAA server is the service principal) then an EAP-Kerberos scheme will perform more poorly than existing EAP methods. _______________________________________________ SECMECH mailing list SECMECH@lists.ietf.org https://www1.ietf.org/mailman/listinfo/secmech From secmech-bounces@lists.ietf.org Fri Aug 26 11:15:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8fv2-0003SH-8F; Fri, 26 Aug 2005 11:15:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8fv0-0003S6-Mm for secmech@megatron.ietf.org; Fri, 26 Aug 2005 11:14:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25981 for ; Fri, 26 Aug 2005 11:14:56 -0400 (EDT) Received: from outbound.mailhop.org ([63.208.196.171] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8fvk-0001bQ-AG for secmech@ietf.org; Fri, 26 Aug 2005 11:15:45 -0400 Received: from c-67-182-139-247.hsd1.wa.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.51) id 1E8fux-0000CW-Jh; Fri, 26 Aug 2005 11:14:55 -0400 Received: by internaut.com (Postfix, from userid 1000) id D3A962469D; Fri, 26 Aug 2005 08:14:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by internaut.com (Postfix) with ESMTP id C3DBD2469A; Fri, 26 Aug 2005 08:14:54 -0700 (PDT) X-Mail-Handler: MailHop Outbound by DynDNS.org X-Originating-IP: 67.182.139.247 X-Report-Abuse-To: abuse@dyndns.org (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba Date: Fri, 26 Aug 2005 08:14:54 -0700 (PDT) From: Bernard Aboba To: Charles Clancy Subject: RE: [SECMECH] Framework Bindings Vs. Mechanism Bridges In-Reply-To: Message-ID: References: <7210B31550AC934A8637D6619739CE6905C8BEEC@e2k-sea-xch2.sea-alpha. cisco.com> <191B6A09CAEEC043419A68E5@cumulus> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: secmech@ietf.org X-BeenThere: secmech@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security mechanisms BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: secmech-bounces@lists.ietf.org Errors-To: secmech-bounces@lists.ietf.org > I think EAP-Kerberos should be terminated at the AAA server. Your service > ticket is for "network access", not a particular NAS. The key contained > within the service ticket could be used to bootstrap the traditional EAP > keying. If you wanted fast reconnect or fast handoff, you could build it into > the method by computing something like: > > initial key generation: > MK = PRF(service key, "master key", nonces) > MSK_1 = PRF(MK, "master session key", nonces) > > handoff: > MSK_2 = PRF(MK, "new master session key", MSK_1 + nonces) > > Then the NAS doesn't need to know anything about Kerberos. This scheme allows for reuse of the initial Kerberos ticket, at the expense of a round-trip between the NAS and AAA server on each handoff. However, the Kerberos session key is no longer bound to a particular NAS -- this is the "Key binding" requirement in draft-housley-aaa-key-mgmt-00.txt. Also, the AAA server now needs to keep a cache of Kerberos session keys. _______________________________________________ SECMECH mailing list SECMECH@lists.ietf.org https://www1.ietf.org/mailman/listinfo/secmech From secmech-bounces@lists.ietf.org Fri Aug 26 11:33:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8gCV-0000DM-H4; Fri, 26 Aug 2005 11:33:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8gCU-0000D9-9H for secmech@megatron.ietf.org; Fri, 26 Aug 2005 11:33:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27190 for ; Fri, 26 Aug 2005 11:32:57 -0400 (EDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8gD9-0002Ip-Hw for secmech@ietf.org; Fri, 26 Aug 2005 11:33:47 -0400 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id j7QFWq2B011338 for ; Fri, 26 Aug 2005 08:32:52 -0700 (PDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id j7QFWqLG000419 for ; Fri, 26 Aug 2005 09:32:52 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id j7QFWoOq017469; Fri, 26 Aug 2005 10:32:50 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id j7QFWnr0017468; Fri, 26 Aug 2005 10:32:49 -0500 (CDT) Date: Fri, 26 Aug 2005 10:32:49 -0500 From: Nicolas Williams To: "Salowey, Joe" Subject: Re: [SECMECH] Framework Bindings Vs. Mechanism Bridges Message-ID: <20050826153249.GL15718@binky.Central.Sun.COM> References: <7210B31550AC934A8637D6619739CE6905C8BF21@e2k-sea-xch2.sea-alpha.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7210B31550AC934A8637D6619739CE6905C8BF21@e2k-sea-xch2.sea-alpha.cisco.com> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: secmech@ietf.org, Bernard Aboba X-BeenThere: secmech@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security mechanisms BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: secmech-bounces@lists.ietf.org Errors-To: secmech-bounces@lists.ietf.org On Fri, Aug 26, 2005 at 08:06:48AM -0700, Salowey, Joe wrote: > > From: Bernard Aboba [mailto:aboba@internaut.com] > > Sent: Thursday, August 25, 2005 11:40 PM > > > > It's different because the NAS needs to support Kerberos even > > if it is operating in "Pass-through" mode. > > [Joe] Then its not operating in "Pass-through" mode, it is terminating > EAP (acting as an EAP server). I agree. As for fast reconnect/handoff, which I'd mentioned earlier, the re-use of TGTs and service tickets (within their lifetimes), can save round trips in the IAKERB method, but doesn't really amount to fast reconnect/handoff in pass-through mode in that the method must be used everytime and so the EAP server is involved always. What is the exact definition of "fast reconnect/handoff" anyways? RFC3748's description of "fast reconnect" does not say very much. > > In contrast, a > > NAS operating in pass-through mode for EAP-TLS doesn't need > > to validate the client certificate. > > > > > It could also be possible to still involve a AAA and have > > it terminate > > > the method and talk to the KDC. If you are trying to implement a > > > method that is evaluated by both the NAS and the AAA in the same > > > transaction you are really doing something other than EAP. > > > > In all the EAP Kerberos proposals I've seen the method is > > terminated on either the NAS or AAA server, but not both. > > But in any scenario, the NAS still needs to support Kerberos, > > in order to validate the "network access" service ticket. > > [Joe] If this is done in the same method execution instance it seems > problematic to me, because you have in effect two EAP-servers (one in > the AAA and one in the NAS) processing the EAP messages. This is not > EAP. I agree. If the NAS speaks Kerberos V and, more importantly, if there's a cross-realm path from the peer's principal's realm to the NAS's realm, then NAS is (should be) the EAP server also; if the NAS does not speak Kerberos or there is not such x-realm path then, as far as the NAS is concerned, the EAP Kerberos V method is like any other AAA method. Nico -- _______________________________________________ SECMECH mailing list SECMECH@lists.ietf.org https://www1.ietf.org/mailman/listinfo/secmech From secmech-bounces@lists.ietf.org Fri Aug 26 11:35:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8gEu-00010z-Jw; Fri, 26 Aug 2005 11:35:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8gEr-0000zC-Ny for secmech@megatron.ietf.org; Fri, 26 Aug 2005 11:35:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27328 for ; Fri, 26 Aug 2005 11:35:27 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8gFb-0002Oj-GE for secmech@ietf.org; Fri, 26 Aug 2005 11:36:16 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 26 Aug 2005 08:35:20 -0700 X-IronPort-AV: i="3.96,144,1122879600"; d="scan'208"; a="336080344:sNHT32015388" Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j7QFZHQM009431; Fri, 26 Aug 2005 08:35:17 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [SECMECH] Framework Bindings Vs. Mechanism Bridges Date: Fri, 26 Aug 2005 08:40:10 -0700 Message-ID: <7210B31550AC934A8637D6619739CE6905C8BF3D@e2k-sea-xch2.sea-alpha.cisco.com> Thread-Topic: [SECMECH] Framework Bindings Vs. Mechanism Bridges Thread-Index: AcWqT6gsgxmbX/YDQEiO1EZfHBo1KAAADmGQ From: "Salowey, Joe" To: "Bernard Aboba" , "Shumon Huque" X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: quoted-printable Cc: secmech@ietf.org X-BeenThere: secmech@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security mechanisms BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: secmech-bounces@lists.ietf.org Errors-To: secmech-bounces@lists.ietf.org =20 > -----Original Message----- > From: Bernard Aboba [mailto:aboba@internaut.com]=20 > Sent: Friday, August 26, 2005 8:01 AM > To: Shumon Huque > Cc: Salowey, Joe; secmech@ietf.org > Subject: Re: [SECMECH] Framework Bindings Vs. Mechanism Bridges >=20 > > The AAA server could perform the service ticket validation=20 > on behalf=20 > > of the NAS. This requires another round trip with the AAA=20 > server, but=20 > > I don't think this is too much of a problem. >=20 > How does the EAP peer figure out the scope of usage of the=20 > "network access service" ticket? If each NAS is a separate=20 > Kerberos principal, then the peer needs a distinct ticket for=20 > each NAS; if the AAA server is the principal, then it can=20 > submit the same ticket to any NAS.=20 >=20 [Joe] I don't think there is necessarily a problem service ticket for the AAA. This is how EAP typically works today.=20 > > If we need the NAS to support Kerberos, then I think the barrier to=20 > > practical deployment is too high. Or am I missing something? >=20 > I think that the NAS needs to be modified even in the case=20 > where the AAA server is the Kerberos principal, in order to=20 > be able to securely inform the EAP peer of the ticket scope. =20 > Otherwise, the EAP peer can't know when it needs to acquire=20 > another ticket.=20 [Joe] How would the NAS know anything about the ticket scope? If you are concerned about scope why would you trust the NAS to tell you? It would seem that this information needs to encoded in the ticket. Perhaps scope can be derived from the service principal name.=20 _______________________________________________ SECMECH mailing list SECMECH@lists.ietf.org https://www1.ietf.org/mailman/listinfo/secmech From secmech-bounces@lists.ietf.org Fri Aug 26 14:24:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8isU-0000WV-7t; Fri, 26 Aug 2005 14:24:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8isS-0000WQ-TK for secmech@megatron.ietf.org; Fri, 26 Aug 2005 14:24:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05211 for ; Fri, 26 Aug 2005 14:24:31 -0400 (EDT) Received: from carrierpigeon.cs.umd.edu ([128.8.129.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8itE-0007nS-71 for secmech@ietf.org; Fri, 26 Aug 2005 14:25:21 -0400 Received: from ismene (ismene.cs.umd.edu [128.8.126.62]) by carrierpigeon.cs.umd.edu (8.12.10/8.12.5) with ESMTP id j7QIMBfD027406; Fri, 26 Aug 2005 14:22:11 -0400 (EDT) Date: Fri, 26 Aug 2005 14:16:51 -0400 (EDT) From: Charles Clancy X-X-Sender: clancy@ismene To: Bernard Aboba Subject: RE: [SECMECH] Framework Bindings Vs. Mechanism Bridges In-Reply-To: Message-ID: References: <7210B31550AC934A8637D6619739CE6905C8BEEC@e2k-sea-xch2.sea-alpha. cisco.com> <191B6A09CAEEC043419A68E5@cumulus> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: secmech@ietf.org X-BeenThere: secmech@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security mechanisms BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: secmech-bounces@lists.ietf.org Errors-To: secmech-bounces@lists.ietf.org On Fri, 26 Aug 2005, Bernard Aboba wrote: >> initial key generation: >> MK = PRF(service key, "master key", nonces) >> MSK_1 = PRF(MK, "master session key", nonces) >> >> handoff: >> MSK_2 = PRF(MK, "new master session key", MSK_1 + nonces) > > This scheme allows for reuse of the initial Kerberos ticket, at the > expense of a round-trip between the NAS and AAA server on each handoff. > > However, the Kerberos session key is no longer bound to a > particular NAS -- this is the "Key binding" requirement in > draft-housley-aaa-key-mgmt-00.txt. > > Also, the AAA server now needs to keep a cache of Kerberos session keys. The Kerberos session key and consequently MK is bound to the EAP server, as the Kerberos is terminated at the EAP server, right? It's a service ticket for the EAP server, not a particular NAS, so that would seem logical. The MSKs can be bound to the individual NASes. Should the NAI (or some other identifier) of the NAS be explicitly included in the PRF? Personally, I don't see how this is any different than any other EAP method, once you generate the MK. Fast handoff in an EAP method, and not at the link layer, would have to involve AAA. Otherwise you would need Diffie-Hellman to provide the forward secrecy. Without it, any NAS through which a client roamed would be able to derive their future keys and decrypt their sessions. As for maintaining a cache -- the AAA server would have to maintain a cache of MKs for authenticated clients, presumably with some associated lifetime. I'd think any fast reconnect scheme would require something similar, unless you were going to authenticate from scratch. Or, am I missing the point? [ t. charles clancy ]--[ tcc@umd.edu ]--[ www.cs.umd.edu/~clancy ] [ computer science ]-----[ university of maryland | college park ] _______________________________________________ SECMECH mailing list SECMECH@lists.ietf.org https://www1.ietf.org/mailman/listinfo/secmech From secmech-bounces@lists.ietf.org Fri Aug 26 14:55:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8jLz-0000Yf-Er; Fri, 26 Aug 2005 14:55:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8jLy-0000YH-MH for secmech@megatron.ietf.org; Fri, 26 Aug 2005 14:55:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06594 for ; Fri, 26 Aug 2005 14:55:01 -0400 (EDT) Received: from outbound.mailhop.org ([63.208.196.171] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8jMj-0000E3-4e for secmech@ietf.org; Fri, 26 Aug 2005 14:55:51 -0400 Received: from c-67-182-139-247.hsd1.wa.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.51) id 1E8jLu-000A3L-1O; Fri, 26 Aug 2005 14:54:58 -0400 Received: by internaut.com (Postfix, from userid 1000) id E11AB23523; Fri, 26 Aug 2005 11:54:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by internaut.com (Postfix) with ESMTP id D306F1B2AE; Fri, 26 Aug 2005 11:54:56 -0700 (PDT) X-Mail-Handler: MailHop Outbound by DynDNS.org X-Originating-IP: 67.182.139.247 X-Report-Abuse-To: abuse@dyndns.org (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba Date: Fri, 26 Aug 2005 11:54:56 -0700 (PDT) From: Bernard Aboba To: Charles Clancy Subject: RE: [SECMECH] Framework Bindings Vs. Mechanism Bridges In-Reply-To: Message-ID: References: <7210B31550AC934A8637D6619739CE6905C8BEEC@e2k-sea-xch2.sea-alpha. cisco.com> <191B6A09CAEEC043419A68E5@cumulus> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.1 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: secmech@ietf.org X-BeenThere: secmech@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security mechanisms BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: secmech-bounces@lists.ietf.org Errors-To: secmech-bounces@lists.ietf.org > The Kerberos session key and consequently MK is bound to the EAP server, as > the Kerberos is terminated at the EAP server, right? It's a service ticket > for the EAP server, not a particular NAS, so that would seem logical. The > MSKs can be bound to the individual NASes. Should the NAI (or some other > identifier) of the NAS be explicitly included in the PRF? > > Personally, I don't see how this is any different than any other EAP method, > once you generate the MK. Fast handoff in an EAP method, and not at the link > layer, would have to involve AAA. Otherwise you would need Diffie-Hellman to > provide the forward secrecy. Without it, any NAS through which a client > roamed would be able to derive their future keys and decrypt their sessions. > > As for maintaining a cache -- the AAA server would have to maintain a cache of > MKs for authenticated clients, presumably with some associated lifetime. I'd > think any fast reconnect scheme would require something similar, unless you > were going to authenticate from scratch. > > Or, am I missing the point? As noted in the EAP Key Framework document, the EAP layer does not cache exported EAP keying material, either on the client or the server. Caching is only permitted in the lower layer (AAA is a lower layer from the EAP perspective). Several proposed fast handoff schemes require caching on the AAA server, including pre-emptive handoff and key request. However, AAA servers today do not cache EAP keying parameters -- they discard all EAP keying material (not just the transported keying material) once they send the MSK to the NAS. So asking the AAA server to implement a key cache is a significant change from the existing architecture. This doesn't mean it can't or shouldn't be done -- but a change that substantial shouldn't be done on an adhoc basis. Some open questions: a. How does the peer know what AAA server it is dealing with? The EAP Key Framework has added the Server-ID parameter to enable the peer to know this, but not all EAP methods define this parameter. Do we want fast handoff to only be supported for methods with a defined Server-ID? b. How does the peer request that the NAS contact a particular AAA server (either for requesting a key or validating a ticket)? Does it include the Server-ID in the message? c. How does the AAA server validate that the ticket is being used by the EAP peer that it granted access to? Do we require that the peer NAI be the same as the Kerberos Principal name of the peer? Do we require that the Server-ID be the same as the Kerberos Principal name of the AAA server? d. How does the peer know whether a particular NAS is configured to connect to a AAA server from whom it has received a ticket? _______________________________________________ SECMECH mailing list SECMECH@lists.ietf.org https://www1.ietf.org/mailman/listinfo/secmech From secmech-bounces@lists.ietf.org Fri Aug 26 15:24:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8jox-00076u-Rt; Fri, 26 Aug 2005 15:24:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8jow-00076l-At for secmech@megatron.ietf.org; Fri, 26 Aug 2005 15:24:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09252 for ; Fri, 26 Aug 2005 15:24:56 -0400 (EDT) Received: from carrierpigeon.cs.umd.edu ([128.8.129.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8jpi-00019W-V9 for secmech@ietf.org; Fri, 26 Aug 2005 15:25:47 -0400 Received: from ismene (ismene.cs.umd.edu [128.8.126.62]) by carrierpigeon.cs.umd.edu (8.12.10/8.12.5) with ESMTP id j7QJOZfD027699; Fri, 26 Aug 2005 15:24:35 -0400 (EDT) Date: Fri, 26 Aug 2005 15:19:15 -0400 (EDT) From: Charles Clancy X-X-Sender: clancy@ismene To: Bernard Aboba Subject: RE: [SECMECH] Framework Bindings Vs. Mechanism Bridges In-Reply-To: Message-ID: References: <7210B31550AC934A8637D6619739CE6905C8BEEC@e2k-sea-xch2.sea-alpha. cisco.com> <191B6A09CAEEC043419A68E5@cumulus> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: secmech@ietf.org X-BeenThere: secmech@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security mechanisms BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: secmech-bounces@lists.ietf.org Errors-To: secmech-bounces@lists.ietf.org > As noted in the EAP Key Framework document, the EAP layer does not cache > exported EAP keying material, either on the client or the server. > Caching is only permitted in the lower layer (AAA is a lower layer from > the EAP perspective). Ah, there was the point I missed. > However, AAA servers today do not cache EAP keying parameters -- they > discard all EAP keying material (not just the transported keying > material) once they send the MSK to the NAS. So asking the AAA server > to implement a key cache is a significant change from the existing > architecture. I've implemented fast handoff using PMK caching for EAP-TLS on FreeRADIUS with minimal difficulty. Your points extend beyond the functionality offered by my previous efforts in that it allows for an architecture where a NAS could contact multiple AAA servers. > a. How does the peer know what AAA server it is dealing with? The EAP > Key Framework has added the Server-ID parameter to enable the peer to > know this, but not all EAP methods define this parameter. Do we want > fast handoff to only be supported for methods with a defined Server-ID? Well so far we've been talking about fast handoff in EAP-Kerberos. So, I'd imagine EAP-Kerberos would need to implement the Server-ID field. Although note that my protocol sketch below doesn't require using the Server-ID field. > b. How does the peer request that the NAS contact a particular AAA > server (either for requesting a key or validating a ticket)? Does it > include the Server-ID in the message? The EAP-Response/Identity could be formatted in some way to include the desired AAA server. Personally, I say we shouldn't worry about this case. If someone roams to a NAS that has a different default AAA server, then they should reauthenticate. This functionality could also be added later, if deemed necessary, since it seems outside the scope of the method, and would involve changes in EAP itself. > c. How does the AAA server validate that the ticket is being used by the > EAP peer that it granted access to? Do we require that the peer NAI be > the same as the Kerberos Principal name of the peer? Do we require that > the Server-ID be the same as the Kerberos Principal name of the AAA > server? Assuming the AAA server has cached the MK, I'd imagine something similar to: (Client <- Server) ID Request (Client -> Server) ID Response (Client <- Server) EAP-Krb5(fast reconn available, keyid=hash(MK), A=nonce) Then if client has keyid cached: (Client) {MSK,K} = PRF(A,B,MK) (Client -> Server) EAP-Krb5(fast reconn ACK, B=nonce, hash(A,B,K)) (Server) {MSK,K} = PRF(A,B,MK) (Client <- Server) EAP-Krb5(ACK, hash(B,K)) (Client -> Server) EAP-Krb5(ACK) (Client <- Server) EAP-Success (NAS <- Server) AAA(MSK) Or if keyid is not found: (Client -> Server) EAP-Krb5(fast reconn NACK) (Client <-> Server) EAP-Krb5(full kerberos authentication) > d. How does the peer know whether a particular NAS is configured to > connect to a AAA server from whom it has received a ticket? I say it shouldn't know. If the NAS connects to the right AAA server, then the above will happen. Otherwise it won't. [ t. charles clancy ]--[ tcc@umd.edu ]--[ www.cs.umd.edu/~clancy ] [ computer science ]-----[ university of maryland | college park ] _______________________________________________ SECMECH mailing list SECMECH@lists.ietf.org https://www1.ietf.org/mailman/listinfo/secmech From secmech-bounces@lists.ietf.org Fri Aug 26 15:36:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8k01-0003MB-Hu; Fri, 26 Aug 2005 15:36:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8k00-0003Lm-Jm for secmech@megatron.ietf.org; Fri, 26 Aug 2005 15:36:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10368 for ; Fri, 26 Aug 2005 15:36:22 -0400 (EDT) Received: from outbound.mailhop.org ([63.208.196.171] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8k0m-0001iK-9h for secmech@ietf.org; Fri, 26 Aug 2005 15:37:13 -0400 Received: from c-67-182-139-247.hsd1.wa.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.51) id 1E8jzw-000Fcy-U2; Fri, 26 Aug 2005 15:36:21 -0400 Received: by internaut.com (Postfix, from userid 1000) id E77BB24037; Fri, 26 Aug 2005 12:36:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by internaut.com (Postfix) with ESMTP id D975823523; Fri, 26 Aug 2005 12:36:19 -0700 (PDT) X-Mail-Handler: MailHop Outbound by DynDNS.org X-Originating-IP: 67.182.139.247 X-Report-Abuse-To: abuse@dyndns.org (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba Date: Fri, 26 Aug 2005 12:36:19 -0700 (PDT) From: Bernard Aboba To: Charles Clancy Subject: RE: [SECMECH] Framework Bindings Vs. Mechanism Bridges In-Reply-To: Message-ID: References: <7210B31550AC934A8637D6619739CE6905C8BEEC@e2k-sea-xch2.sea-alpha. cisco.com> <191B6A09CAEEC043419A68E5@cumulus> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.1 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: secmech@ietf.org X-BeenThere: secmech@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security mechanisms BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: secmech-bounces@lists.ietf.org Errors-To: secmech-bounces@lists.ietf.org > I say it shouldn't know. If the NAS connects to the right AAA server, then > the above will happen. Otherwise it won't. In order to minimize handoff times, the EAP peer needs to know which NASes it has a valid key for, so that it can choose to roam to those NASes in preference to ones it has no key for. Having said that, IEEE 802.11r is currently looking at advertising that kind of information (e.g. NAS-Identifer, other scope parameters). So it is conceivable that the EAP peer could know whether a given NAS could talk to a given AAA server before attempting to use a ticket with it. _______________________________________________ SECMECH mailing list SECMECH@lists.ietf.org https://www1.ietf.org/mailman/listinfo/secmech From secmech-bounces@lists.ietf.org Sat Aug 27 15:28:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E96Li-0000Ql-Az; Sat, 27 Aug 2005 15:28:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E96Le-0000Qc-Mk for secmech@megatron.ietf.org; Sat, 27 Aug 2005 15:28:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26746 for ; Sat, 27 Aug 2005 15:28:12 -0400 (EDT) Received: from wproxy.gmail.com ([64.233.184.203]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E96Me-0000LM-0B for secmech@ietf.org; Sat, 27 Aug 2005 15:29:16 -0400 Received: by wproxy.gmail.com with SMTP id 36so137241wra for ; Sat, 27 Aug 2005 12:28:01 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=qexLjdC/+Mfu7px5B/TQmQnkfsSnxRfHEtkeGlCmVkVPQgSKiV52xJ/QbRL30IMvkrB9kn0jWI8hC+AaJS6u6msIOyN7xoV4+U2S6u3y9EwP3Ysyc78a5ra/K4o8XpytesIqd7WobrzV7EzpwOefx/mbbpKC5ecYDsrydZr3ZB0= Received: by 10.54.48.24 with SMTP id v24mr4801216wrv; Sat, 27 Aug 2005 12:28:00 -0700 (PDT) Received: by 10.54.79.3 with HTTP; Sat, 27 Aug 2005 12:28:00 -0700 (PDT) Message-ID: Date: Sat, 27 Aug 2005 12:28:00 -0700 From: Clint Chaplin To: Bernard Aboba Subject: Re: [SECMECH] Framework Bindings Vs. Mechanism Bridges In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <1DCACCAC04655B3AFE9733A8@cumulus> <20050822154044.GE7789@binky.Central.Sun.COM> <430CA545.3020109@uni-tuebingen.de> <20050824213010.GO10174@binky.Central.Sun.COM> <20050825042105.GW10174@binky.Central.Sun.COM> X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Content-Transfer-Encoding: quoted-printable Cc: secmech@ietf.org X-BeenThere: secmech@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security mechanisms BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: secmech-bounces@lists.ietf.org Errors-To: secmech-bounces@lists.ietf.org Boy, does this all sound familiar.... I know of one IEEE 802.11i vendor that developed and sold a Kerberos solution for security/authentication. On 8/24/05, Bernard Aboba wrote: > > No, I used "weak" to mean mechanisms that are subject to off-line > > dictionary attacks by eavesdroppers or MITMs. >=20 > If the EAP method generates a key and the tunneling mechanism supports > cryptographic binding and satisfies the other RFC 4017 > requirements (e.g. key strength, etc.) then I don't think that offline > dictionary or MITM attack should be possible. Here is a brief summary o= f > RFC 4017 requirements: >=20 > MANDATORY >=20 > [1] Key derivation. > [2] Effective Key strength of at least 128-bits. > [3] Mutual authentication. > [4] Shared state equivalence. See RFC 4017 for details. > [5] Resistance to dictionary attacks. > [6] Protection against man-in-the-middle attacks. > [7] Protected ciphersuite negotiation. >=20 > RECOMMENDED >=20 > [8] Fragmentation. > [9] End-user identity hiding. >=20 > OPTIONAL >=20 > [10] Channel binding. > [11] Fast reconnect. >=20 > My guess is that Kerberos tunneled in TLS should be able to satisfy most > if not all of these, assuming that cryptobinding is used. >=20 > > Summary: IAKERB and EAP-GSS are dead at this time, mostly for lack of > > people willing to do the work, not for any political or technical > > reasons. >=20 > >From a technical perspective, there are some challenges > to securely providing authentication simultaneously with fast handoff. >=20 > One issue is how the EAP peer figures out what Kerberos principals > it needs to request a ticket for. Remember that EAP operates of a layer = 2 > protocol such as 802.11, and since the peer doesn't yet have IP connectiv= ity, > it may not know the IP Address or name of the NAS it is trying to connect= to. > In 802.11i, all the station knows is the BSSID of the AP; it doesn't know= what NAS > that BSSID is associated with, let alone the IP address, service name, > etc. >=20 > In the original IEEE 802.11i documents, it was assumed that the peer > would request a ticket to the "Network Access Service" but this required > all NAS devices to share a secret with the KDC so that a ticket, > once granted, could be reused with any NAS. While this was very > convenient for handoff, it was not so great from a shared secret hygene > point of view. >=20 > To enable the peer to figure out what tickets it needs, it seems like the > AP would need to advertise its Kerberos Service Name, which might > or might not be the same as the NAS-Identifier sent to the AAA server. >=20 > Also, having to request a new ticket for each NAS, with a roundtrip to th= e > KDC for each attempt, may not meet the stringent timing requirements of > VOIP applications (handoff times <50 ms). So I think you'd need to figur= e > out how to optimize the exchange, such as allowing an EAP peer to > simultaneously request tickets to multiple NAS devices. >=20 > However, if you can figure all this out, there could be some tangible > benefits -- in particular with Kerberos it is possible to ensure proper > key binding, which is not easy to do with current approaches. For > example, a Kerberos ticket cannot easily be used by a NAS device other > than the one it was created for. >=20 > > I.e., I'm pretty sure there'd be no opposition from the IETF, the > > Internet Security Area Directors or the IESG as a whole to a revival of > > IAKERB and/or EAP-GSS, provided someone does the work. See below. >=20 > Remember that at one time Kerberos was mandatory to implement in IEEE > 802.11i. During that period there were lots of people will to work on > Kerberos network access issues. However after it became clear that > Kerberos by itself could not meet the 802.11 security requirements, and > also that work in the IETF was not moving forward at a reasonable pace, > IEEE 802.11i voted to remove Kerberos as the mandatory to implement > method. >=20 > At this point, I doubt you will find much interest within the 802.11 > vendor community in revisiting Kerberos unless it can be demonstrated tha= t > Kerberos can provide some tangible benefit that isn't available > with the fast handoff schemes being investigated in IEEE 802.11r. >=20 >=20 > _______________________________________________ > SECMECH mailing list > SECMECH@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/secmech >=20 --=20 Clint (JOATMON) Chaplin Wireless Security Technologist Wireless Standards Manager _______________________________________________ SECMECH mailing list SECMECH@lists.ietf.org https://www1.ietf.org/mailman/listinfo/secmech From secmech-bounces@lists.ietf.org Sun Aug 28 06:13:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9K9X-0008MT-Fv; Sun, 28 Aug 2005 06:12:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9K9W-0008MM-Uw for secmech@megatron.ietf.org; Sun, 28 Aug 2005 06:12:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07840 for ; Sun, 28 Aug 2005 06:12:36 -0400 (EDT) Received: from moutng.kundenserver.de ([212.227.126.187]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E9KAa-000720-PW for secmech@ietf.org; Sun, 28 Aug 2005 06:13:48 -0400 Received: from dialin-212-144-148-002.arcor-ip.net [212.144.148.2] (helo=amilo) by mrelayeu.kundenserver.de with ESMTP (Nemesis), id 0MKwtQ-1E9K9L1SVw-0002JL; Sun, 28 Aug 2005 12:12:27 +0200 Message-ID: <001301c5abb9$372ea370$029490d4@amilo> From: "1und1" To: "Clint Chaplin" References: <1DCACCAC04655B3AFE9733A8@cumulus><20050822154044.GE7789@binky.Central.Sun.COM><430CA545.3020109@uni-tuebingen.de><20050824213010.GO10174@binky.Central.Sun.COM><20050825042105.GW10174@binky.Central.Sun.COM> Subject: Re: [SECMECH] Framework Bindings Vs. Mechanism Bridges Date: Sun, 28 Aug 2005 12:14:00 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1506 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Provags-ID: kundenserver.de abuse@kundenserver.de login:3105fcefe481186a11ed9e9de1ccc56f X-Spam-Score: 1.2 (+) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit Cc: secmech@ietf.org X-BeenThere: secmech@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security mechanisms BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: secmech-bounces@lists.ietf.org Errors-To: secmech-bounces@lists.ietf.org > From: "Clint Chaplin" > To: "Bernard Aboba" > Cc: > Sent: Saturday, August 27, 2005 9:28 PM > Subject: Re: [SECMECH] Framework Bindings Vs. Mechanism Bridges > Boy, does this all sound familiar.... > I know of one IEEE 802.11i vendor that developed and sold a Kerberos > solution for security/authentication. Which company is this? Symbol? Symbol.com sells a Kerberos-based solution, but it seems to be proprietary and not compliant with IEEE 802.11i. I asked in Juli sth for EAP-Kerberos, Tim Alsop answered ( http://www.mail-archive.com/kerberos@mit.edu/msg08763.html ) Thomas, Perhaps you need to look at the solution implemented by Symbol (www.symbol.com). Their WLAN products already use kerberos for WLAN authentication and key management as an alternative to WEP. The normal approach with WEP is to share a secret between the AP and WLAN client, but with Kerberos the session key can be used instead. The WLAN connection to the network through the access point should not be accepted until the user has authenticated to the AP. This is the Symbol approach, but they are not using EAP. Instead they have implemented Kerberos in the firmware of their products. I would love to see Kerberos implemented for same solution using EAP-GSS so that more WLAN vendors can take advantage and gain SSO and strong key management for WLAN authentication. Regards, Tim _______________________________________________ SECMECH mailing list SECMECH@lists.ietf.org https://www1.ietf.org/mailman/listinfo/secmech From secmech-bounces@lists.ietf.org Sun Aug 28 14:15:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9Rgu-0007PY-P2; Sun, 28 Aug 2005 14:15:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9Rgs-0007PT-Rh for secmech@megatron.ietf.org; Sun, 28 Aug 2005 14:15:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03076 for ; Sun, 28 Aug 2005 14:15:33 -0400 (EDT) Received: from sccrmhc12.comcast.net ([204.127.202.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E9Ri3-0002aN-8i for secmech@ietf.org; Sun, 28 Aug 2005 14:16:48 -0400 Received: from [192.168.0.2] (pcp04510339pcs.gambrl01.md.comcast.net[68.49.199.146]) by comcast.net (sccrmhc12) with ESMTP id <200508281815180120009qb2e>; Sun, 28 Aug 2005 18:15:24 +0000 Message-ID: <4311FF39.30807@cs.umd.edu> Date: Sun, 28 Aug 2005 14:15:21 -0400 From: Charles Clancy User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: 1und1 Subject: Re: [SECMECH] Framework Bindings Vs. Mechanism Bridges References: <1DCACCAC04655B3AFE9733A8@cumulus><20050822154044.GE7789@binky.Central.Sun.COM><430CA545.3020109@uni-tuebingen.de><20050824213010.GO10174@binky.Central.Sun.COM><20050825042105.GW10174@binky.Central.Sun.COM> <001301c5abb9$372ea370$029490d4@amilo> In-Reply-To: <001301c5abb9$372ea370$029490d4@amilo> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit Cc: secmech@ietf.org X-BeenThere: secmech@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security mechanisms BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: secmech-bounces@lists.ietf.org Errors-To: secmech-bounces@lists.ietf.org 1und1 wrote: >>I know of one IEEE 802.11i vendor that developed and sold a Kerberos >>solution for security/authentication. > > Which company is this? Symbol? > > Symbol.com sells a Kerberos-based solution, but it seems to be proprietary > and not compliant with IEEE 802.11i. > > I asked in Juli sth for EAP-Kerberos, Tim Alsop answered > ( http://www.mail-archive.com/kerberos@mit.edu/msg08763.html ) Hmm... I doubt they're protecting their Kerberos with TLS... proprietary password-based wireless authentication mechanisms likely vulnerable to dictionary attacks... LEAP deja vu? [ t. charles clancy ]--[ tcc@umd.edu ]--[ www.cs.umd.edu/~clancy ] [ computer science ]-----[ university of maryland | college park ] _______________________________________________ SECMECH mailing list SECMECH@lists.ietf.org https://www1.ietf.org/mailman/listinfo/secmech From secmech-bounces@lists.ietf.org Tue Aug 30 16:30:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EACkC-00026a-Df; Tue, 30 Aug 2005 16:30:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EACk8-00023p-Kt for secmech@megatron.ietf.org; Tue, 30 Aug 2005 16:30:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08405 for ; Tue, 30 Aug 2005 16:30:02 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAClk-0005EO-DC for secmech@ietf.org; Tue, 30 Aug 2005 16:31:44 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 30 Aug 2005 13:29:55 -0700 Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j7UKTm0J025880; Tue, 30 Aug 2005 13:29:53 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [SECMECH] Method work Date: Tue, 30 Aug 2005 13:34:44 -0700 Message-ID: <7210B31550AC934A8637D6619739CE6905C8C79A@e2k-sea-xch2.sea-alpha.cisco.com> Thread-Topic: [SECMECH] Method work Thread-Index: AcWpelIHSk7kLixaTdCpX0lZYmHyOQEJfH6A From: "Salowey, Joe" To: "Jari Arkko" X-Spam-Score: 0.0 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Content-Transfer-Encoding: quoted-printable Cc: secmech@ietf.org X-BeenThere: secmech@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security mechanisms BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: secmech-bounces@lists.ietf.org Errors-To: secmech-bounces@lists.ietf.org =20 > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net]=20 > Sent: Thursday, August 25, 2005 6:34 AM > To: Salowey, Joe > Cc: secmech@ietf.org > Subject: Re: [SECMECH] Method work >=20 > Salowey, Joe wrote: >=20 > >I would like to identify which mechanism types there is interest in=20 > >working on. Below is a list of various authentication methods that=20 > >people have expressed interest in having support for in EAP and other > >frameworks. It may not be the case that we need a=20 > separate mechanism > >for each of these. I'd like to know who has interest in=20 > contributing=20 > >and reviewing (please indicate either or both)=20 > specifications for each=20 > >of these mechanism types. > > > >1. X.509 Certificate credentials - (possible revision of EAP-TLS > >(RFC2716)) - applicable to EAP, possibly applicable to GSS and SASL. > >Desired by IEEE 802.11 for EAP. > > =20 > > > I think we should rev EAP-TLS at the minimum, just to make a=20 > PS out of it and fix some bugs & provide additional=20 > information where necessary. >=20 > We probably need to resist the urge to add a lot of stuff to=20 > EAP-TLS in such a revision. Though I'm kind of interested in=20 > adding channel bindings. But I'm not sure if that's doable in=20 > a backwards compatible way, without either a major change in=20 > EAP-TLS or an extension in TLS. >=20 [Joe] I agree with this and I think it can be done independent of GUAM work pretty easily. I would like to get channel bindings in, but I agree this may be a little tricky.=20 > >2. Shared Secret - pre-shared secret method. Applicable to EAP and=20 > >GSS, possibly SASL. Desired by IEEE 802.11 for EAP. > > =20 > > > Yes, this is perhaps my top priority item. My current=20 > thinking of what we need here is a simple-to-implement method=20 > that is really shared secret, not password based, and=20 > something that would provide a reasonable candidate for=20 > people to implement in their products and reference as a=20 > mandatory-to- implement for some link layer. >=20 > One question is what the value of EAP-TLS + TLS PSK would be=20 > in this context. To me this would satisfy the implementation=20 > simplicity requirement; most products should be able to take=20 > TLS in rather easily. However, there are also other reasons=20 > for developing new EAP methods (channel bindings is one=20 > reason), so we'd have to look at how to arrange for those=20 > other reasons. >=20 [Joe] If EAP-TLS with TLS-PSK could satisfy at least the short term needs that would be great. I think it could be possible that a PSK mechanism could be more generally useful that just EAP. =20 > >3. Password based - essentially a shared secret mechanism that=20 > >provides resistance to dictionary attacks. It should support various=20 > >backend databases of password that use different storage=20 > techniques and=20 > >perhaps support for one time tokens as well. Could use something=20 > >related to EKE or a tunneling approach. Applicable to EAP, GSS, and=20 > >SASL. Desired by IEEE 802.11 for EAP. > > =20 > > > This would also be very useful. Personally I'm a bit more on=20 > thin ice here when it comes to the specific methods and=20 > whether there are any potential IPR issues etc. But I know=20 > this would be very much needed from a customer perspective. >=20 [Joe] I think mechanisms of these types should be made applicable to all frameworks.=20 > >4. Tunneling - a tunneling method is useful to protect weaker=20 > >authentication mechanisms. Tunneling methods are also used=20 > to exchange=20 > >other types of authentication data. Applicability EAP and=20 > GSS possibly=20 > >SASL. > > =20 > > > This is perhaps the widest class of currently used EAP=20 > methods, all proprietary and/or exist only in drafty draft state. >=20 > One issue here is whether we'd be able to find consensus, or=20 > would the folks who have their own tunnel methods be fighting=20 > for "their" approach? >=20 > Another issue is to what extent having a good solution for > #3 would lessen the need for #4. >=20 [Joe] Yes I think a good solution to 3 may mitigate the need for 4. Currently there are uses for tunneled methods beyond legacy authentication. These do tend to be proprietary, but perhaps in the future there will be opportunity for convergence.=20 > >5. Kerberos - Something that provide for initial=20 > authentication and a=20 > >strategy for resisting dictionary attacks. Applicable to=20 > EAP, possibly=20 > >GSS. > > =20 > > > I don't currently see a big customer demand for this. But I=20 > could be viewing at the wrong "market segment". >=20 [Joe] I think it depends on your view. It certainly seems like there is interest in this.=20 > Other: enrollment, perhaps a la what Rohan Mahy wanted to do=20 > in the last EAP WG meeting. >=20 [Joe] Enrollment would be good, I feel like that might be more than I would want to chew off immediately. =20 _______________________________________________ SECMECH mailing list SECMECH@lists.ietf.org https://www1.ietf.org/mailman/listinfo/secmech