From emu-bounces@ietf.org Wed Nov 01 23:44:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfURU-0006fP-5h; Wed, 01 Nov 2006 23:44:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfUQD-0003vs-LO for emu@ietf.org; Wed, 01 Nov 2006 23:43:21 -0500 Received: from bay0-omc3-s21.bay0.hotmail.com ([65.54.246.221]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfUCl-0005Zd-4S for emu@ietf.org; Wed, 01 Nov 2006 23:29:30 -0500 Received: from hotmail.com ([207.46.8.110]) by bay0-omc3-s21.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Nov 2006 20:29:26 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 1 Nov 2006 20:29:26 -0800 Message-ID: Received: from 207.46.8.123 by by117fd.bay117.hotmail.msn.com with HTTP; Thu, 02 Nov 2006 04:29:22 GMT X-Originating-IP: [208.54.41.252] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: From: "Bernard Aboba" To: jsalowey@cisco.com, emu@ietf.org Bcc: Subject: RE: [Emu] Review requested: draft-simon-emu-rfc2716bis-03.txt Date: Wed, 01 Nov 2006 20:29:22 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 02 Nov 2006 04:29:26.0456 (UTC) FILETIME=[7ADC6B80:01C6FE37] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org > > A valid EAP-TLS client certificate SHOULD contain an > > extendedKeyUsage > > value indicating support for Client Authentication > > (1.3.6.1.5.5.7.3.2). A valid EAP-TLS server certificate SHOULD > > contain an extendedKeyUsage value indicating support for Server > > Authentication (1.3.6.1.5.5.7.3.1). > > >[Joe] I think I remember that some protocols specify the presence of a >specific EKU or the ANY EKU. Any references I should look at? Other than RFC 3280, the only reference I could find is this: http://www.drizzle.com/~aboba/CPW/Hardjono-IETF55-TLScertProfile.pdf >[Joe] I haven't looked at [He] in a while, but I thought that it wasn't >applications in general, but applications that use a protocol that >bindly signs arbitrary data. Perhaps this should be a bit clearer. Yes, that was the issue. _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Thu Nov 02 00:03:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfUjL-0000BG-IV; Thu, 02 Nov 2006 00:03:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfUjL-0000BB-6h for emu@ietf.org; Thu, 02 Nov 2006 00:03:07 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfUjJ-0005rO-S2 for emu@ietf.org; Thu, 02 Nov 2006 00:03:07 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 01 Nov 2006 21:03:05 -0800 X-IronPort-AV: i="4.09,379,1157353200"; d="scan'208"; a="84090375:sNHT51778170" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA2535Ga005983; Wed, 1 Nov 2006 21:03:05 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id kA2535W4025445; Wed, 1 Nov 2006 21:03:05 -0800 (PST) Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Nov 2006 21:03:05 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Emu] Review requested: draft-simon-emu-rfc2716bis-03.txt Date: Wed, 1 Nov 2006 21:03:03 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] Review requested: draft-simon-emu-rfc2716bis-03.txt Thread-Index: Acb+N3tGm5dnhNdwTveNnJiz5gqcxQAAXknQ From: "Joseph Salowey \(jsalowey\)" To: "Bernard Aboba" , X-OriginalArrivalTime: 02 Nov 2006 05:03:05.0060 (UTC) FILETIME=[2E0AF240:01C6FE3C] DKIM-Signature: a=rsa-sha1; q=dns; l=1610; t=1162443785; x=1163307785; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=22Joseph=20Salowey=20\(jsalowey\)=22=20 |Subject:RE=3A=20[Emu]=20Review=20requested=3A=20draft-simon-emu-rfc2716bis-03.tx t; X=v=3Dcisco.com=3B=20h=3D2AAb+kZJ932TAMgXcwIKUJYY8dc=3D; b=o/ydjYDmwS6/d25hKHPI7RfABRrhMc4TsvG1XAbIyafXEyM++P/jhgeKNiVihn/jPH72agFN QTC+CQuKfhKibaYG0uU2HSyYFq7jepLHb09yExznZUiZ1BNwinq6jtx2; Authentication-Results: sj-dkim-1.cisco.com; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org =20 > -----Original Message----- > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]=20 > Sent: Wednesday, November 01, 2006 8:29 PM > To: Joseph Salowey (jsalowey); emu@ietf.org > Subject: RE: [Emu] Review requested: draft-simon-emu-rfc2716bis-03.txt >=20 > > > A valid EAP-TLS client certificate SHOULD contain an=20 > > > extendedKeyUsage > > > value indicating support for Client Authentication > > > (1.3.6.1.5.5.7.3.2). A valid EAP-TLS server certificate SHOULD > > > contain an extendedKeyUsage value indicating support for Server > > > Authentication (1.3.6.1.5.5.7.3.1). > > > > >[Joe] I think I remember that some protocols specify the=20 > presence of a=20 > >specific EKU or the ANY EKU. >=20 > Any references I should look at? Other than RFC 3280, the=20 > only reference I=20 > could find is this: > http://www.drizzle.com/~aboba/CPW/Hardjono-IETF55-TLScertProfile.pdf >=20 Good question,=20 SMIME (RFC3850) discusses EKU in section 4.4.4 is the only reference I found to anyExtendedKeyUsage.=20 Documents such as RFC4556 (PKINIT) and RFC4334 (WLAN CERTS) use MAY when discussing EKU. =20 There are also examples where a specific EKU is required in RFC3161 (Time stamping protocol). It seems that 3850,4556 and 4334 are more consistent with EAP-TLS usage. > >[Joe] I haven't looked at [He] in a while, but I thought=20 > that it wasn't=20 > >applications in general, but applications that use a protocol that=20 > >bindly signs arbitrary data. Perhaps this should be a bit clearer. >=20 > Yes, that was the issue. >=20 _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Thu Nov 02 21:07:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfoT5-00027z-Sa; Thu, 02 Nov 2006 21:07:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfoT4-00027q-NY for emu@ietf.org; Thu, 02 Nov 2006 21:07:38 -0500 Received: from usaga01-in.huawei.com ([12.129.211.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfoT2-0006St-D5 for emu@ietf.org; Thu, 02 Nov 2006 21:07:38 -0500 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J8400GD6TRHE1@usaga01-in.huawei.com> for emu@ietf.org; Thu, 02 Nov 2006 18:04:30 -0800 (PST) Received: from N737011 (pool-71-112-12-134.sttlwa.dsl-w.verizon.net [71.112.12.134]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J8400CMZTRDED@usaga01-in.huawei.com> for emu@ietf.org; Thu, 02 Nov 2006 18:04:29 -0800 (PST) Date: Thu, 02 Nov 2006 18:07:29 -0800 From: Madjid Nakhjiri Subject: RE: [Emu] Review requested: draft-simon-emu-rfc2716bis-03.txt In-reply-to: To: 'Bernard Aboba' , jsalowey@cisco.com, emu@ietf.org Message-id: <000c01c6feec$d0e98660$2f01a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Acb18evh7ICTjVumTfmHFNQyIbDkewI+kymw X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org I have a question that is somewhat related (at least what I think:)) In the privacy section (2.7) it is stated that when a peer that supports privacy receives a subsequent certificate_request from the server (after the server have received a list with no certs), the peer MUST provide a cert list containing at least one entry in its response to the server. What would the subject name in that entry be, if the peer intends to protect its identity? Is there a part of the draft that explains this and I missed? Thanks, Madjid -----Original Message----- From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] Sent: Sunday, October 22, 2006 8:47 AM To: jsalowey@cisco.com; emu@ietf.org Subject: RE: [Emu] Review requested: draft-simon-emu-rfc2716bis-03.txt >The document should also state in the security considerations section >that the identity in the identity response is not necessarily related to >the identity authenticated in EAP-TLS and should not be relied upon for >any access control or accounting purposes. Here is some proposed new text for Section 2.4: "As noted in [RFC3748] Section 5.1: It is RECOMMENDED that the Identity Response be used primarily for routing purposes and selecting which EAP method to use. EAP Methods SHOULD include a method-specific mechanism for obtaining the identity, so that they do not have to rely on the Identity Response. As part of the TLS negotiation, the server presents a certificate to the peer, and if mutual authentication is requested, the peer presents a certificate to the server. EAP-TLS therefore provides a mechanism for determining both the peer identity (Peer-Id in [KEYFRAME]) and server identity (Server-Id in [KEYFRAME]). Since the identity presented in the Identity Response need not be related to the identity presented in the peer certificate, EAP-TLS implementations SHOULD NOT require that they be identical, and SHOULD NOT use the identity presented in the Identity Response for access control or accounting purposes." _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Mon Nov 06 16:25:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhBxx-0005kP-Ma; Mon, 06 Nov 2006 16:25:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhBxw-0005kJ-8R for emu@ietf.org; Mon, 06 Nov 2006 16:25:12 -0500 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhBxu-0004M5-E2 for emu@ietf.org; Mon, 06 Nov 2006 16:25:12 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext13.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id kA6LP8O9017938 for ; Mon, 6 Nov 2006 23:25:08 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Nov 2006 23:25:07 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Nov 2006 23:25:06 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 6 Nov 2006 23:25:07 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comment on 2716bis: TLS fragmentation Thread-Index: AccB6ggCvUQcs4M7Svm+u95qfJkH0w== From: To: X-OriginalArrivalTime: 06 Nov 2006 21:25:06.0924 (UTC) FILETIME=[07DCE2C0:01C701EA] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::061106232508-41A5DBB0-0B2C2AD5/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Subject: [Emu] Comment on 2716bis: TLS fragmentation X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Section 2.1 contains a lot of text like "encapsulate one or more TLS records in TLS record layer format, containing a TLS client_hello handshake message." RFC 2246 also says that "multiple client messages of the same ContentType may be coalesced into a single TLSPlaintext record,=20 or a single message may be fragmented across several records". However.... in some testing I've done recently, I discovered that fragmenting TLS handshake messages (as opposed to application data)=20 is not really supported by current TLS implementations (I'm going to=20 talk briefly about this in TLS WG on Friday). Given that fragmentation is needed only with very long certificate chains, a sane implementation (that wants to interoperate with others) would not fragment any handshake messages unless they're longer than 2^14 bytes. Maybe 2716bis should explicitly say that TLS handshake messages MUST NOT (or possibly SHOULD NOT) be fragmented into multiple TLS records if they fit in a single TLS record? (Removing unnecessary complexity and unneeded options is in=20 general a good thing, and I don't think we'd have backwards=20 compatibility problems in this area.) Best regards, Pasi=09 _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Mon Nov 06 16:43:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhCFV-0007bH-Sq; Mon, 06 Nov 2006 16:43:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhCFV-0007ar-6R for emu@ietf.org; Mon, 06 Nov 2006 16:43:21 -0500 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhCFT-0007Ku-N5 for emu@ietf.org; Mon, 06 Nov 2006 16:43:21 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext11.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id kA6Lh5jg007817 for ; Mon, 6 Nov 2006 23:43:17 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Nov 2006 23:42:02 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Nov 2006 23:42:05 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 6 Nov 2006 23:42:03 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comment on 2716bis: Examples in Appendix B Thread-Index: AccB7GV/rJs0aJqDTbSnqbTvsTwr/g== From: To: X-OriginalArrivalTime: 06 Nov 2006 21:42:05.0968 (UTC) FILETIME=[6742A900:01C701EC] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Subject: [Emu] Comment on 2716bis: Examples in Appendix B X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org First of all, I'd suggest numbering the examples in Appendix B, or dividing Appendix B to subsections (this would make reading and commenting them easier). 1) 2nd example ("In the case where the peer and server support privacy and mutual authentication, the conversation will appear as follows"): in 6th message, certificate_verify is not sent (as we're not sending a cert either). 2) 2nd example: it looks like there's a "client_hello" missing in/around messages 8/9 (the server can't just send server_hello without receiving client_hello). 3) 2nd example: remove [] around change_cipher_spec (it's not optional here). 4) 5th example ("In the case where server authentication is unsuccessful, the conversation will appear as follows"): client sends=20 change_cipher_spec/finished twice? 5) 8th example ("In the case where a previously established session is being resumed, and the server authentication is unsuccessful, the conversation will appear as follows:") I don't see how this message sequence could ever occur. If the client is not happy with the server's cert anymore, it won't resume the session. If the master_secret is not the same, TLS finished message can't be decrypted, so the conversation will end there. What other possible reasons there are for the server authentication to be "unsuccessful"? (Roughly the same comment applies to the 7th example as well.) Best regards, Pasi _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Mon Nov 06 19:34:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhEvS-0007S9-7f; Mon, 06 Nov 2006 19:34:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhEvR-0007S4-Rk for emu@ietf.org; Mon, 06 Nov 2006 19:34:49 -0500 Received: from bay0-omc3-s31.bay0.hotmail.com ([65.54.246.231]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhEvK-0003At-Gr for emu@ietf.org; Mon, 06 Nov 2006 19:34:49 -0500 Received: from hotmail.com ([207.46.8.100]) by bay0-omc3-s31.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Nov 2006 16:34:42 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 6 Nov 2006 16:34:41 -0800 Message-ID: Received: from 207.46.8.123 by by117fd.bay117.hotmail.msn.com with HTTP; Tue, 07 Nov 2006 00:34:37 GMT X-Originating-IP: [130.129.68.120] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: From: "Bernard Aboba" To: Pasi.Eronen@nokia.com, emu@ietf.org Bcc: Subject: RE: [Emu] Comment on 2716bis: Examples in Appendix B Date: Mon, 06 Nov 2006 16:34:37 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 07 Nov 2006 00:34:41.0753 (UTC) FILETIME=[83CA0C90:01C70204] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org >client sends change_cipher_spec/finished twice? I think the client will send the Alert at that point, no? >I don't see how this message sequence could ever occur. It is possible for a session resume attempt to fail, but if so, it will not look like the example. A client could mistakenly attempt a session resume with a commonly utilized SSID, but then typically the server will not have keying material for the Session-Id so that the session resume attempt will fail quickly. >If the client is not happy with the server's cert anymore, it won't resume >the session. Right. >If the master_secret is not the same, TLS finished message >can't be decrypted, so the conversation will end there. Even getting there assumes that the server has state for the Session-Id proposed by the client. Therefore the failure will typically occur earlier. As far as I can see, examples 7 and 8 could just be deleted without losing anything. _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Mon Nov 06 19:45:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhF5a-0006Hg-Jc; Mon, 06 Nov 2006 19:45:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhF5Y-0006Fd-Vo for emu@ietf.org; Mon, 06 Nov 2006 19:45:16 -0500 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhF5W-0004eS-TL for emu@ietf.org; Mon, 06 Nov 2006 19:45:16 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext12.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id kA70j6Im021274 for ; Tue, 7 Nov 2006 02:45:12 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Nov 2006 02:45:07 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Nov 2006 02:45:07 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Emu] Comment on 2716bis: Examples in Appendix B Date: Tue, 7 Nov 2006 02:45:06 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] Comment on 2716bis: Examples in Appendix B Thread-Index: AccCBJcvIooc0/H3TxmHtuESGro0iwAAGNLw From: To: X-OriginalArrivalTime: 07 Nov 2006 00:45:07.0949 (UTC) FILETIME=[F907F9D0:01C70205] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::061107024512-5136BBB0-32E26BDA/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Bernard Aboba wrote: >=20 >> client sends change_cipher_spec/finished twice? >=20 > I think the client will send the Alert at that point, no? TLS doesn't really specify when the alerts should be sent. For example, if the client doesn't accept the server's certificate, IMHO the most logical sequence would be to reply with Alert immediately: ClientHello --------> ServerHello Certificate* ServerKeyExchange* CertificateRequest* <-------- ServerHelloDone Alert --------> While the example in Appendix B completes the handshake, and only then sends the Alert: ClientHello --------> ServerHello Certificate* ServerKeyExchange* CertificateRequest* <-------- ServerHelloDone Certificate* ClientKeyExchange CertificateVerify* ChangeCipherSpec Finished --------> ChangeCipherSpec <-------- Finished Alert --------> Do you have information about what existing implementations do? > As far as I can see, examples 7 and 8 could just be deleted=20 > without losing anything. I agree. Best regards, Pasi _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Mon Nov 06 20:00:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhFJw-0007Xd-RE; Mon, 06 Nov 2006 20:00:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhFJv-0007Vq-FA for emu@ietf.org; Mon, 06 Nov 2006 20:00:07 -0500 Received: from bay0-omc3-s36.bay0.hotmail.com ([65.54.246.236]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhFJr-0006Kl-3z for emu@ietf.org; Mon, 06 Nov 2006 20:00:07 -0500 Received: from hotmail.com ([207.46.8.102]) by bay0-omc3-s36.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Nov 2006 17:00:02 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 6 Nov 2006 17:00:02 -0800 Message-ID: Received: from 207.46.8.123 by by117fd.bay117.hotmail.msn.com with HTTP; Tue, 07 Nov 2006 01:00:01 GMT X-Originating-IP: [130.129.68.120] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: From: "Bernard Aboba" To: bernard_aboba@hotmail.com, Pasi.Eronen@nokia.com, emu@ietf.org Bcc: Subject: RE: [Emu] Comment on 2716bis: Examples in Appendix B Date: Mon, 06 Nov 2006 17:00:01 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 07 Nov 2006 01:00:02.0424 (UTC) FILETIME=[0E2E0780:01C70208] X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Here is a strawman responding to Pasi's comments: http://www.drizzle.com/~aboba/EMU/draft-simon-emu-rfc2716bis-05.txt >From: "Bernard Aboba" >To: Pasi.Eronen@nokia.com, emu@ietf.org >Subject: RE: [Emu] Comment on 2716bis: Examples in Appendix B >Date: Mon, 06 Nov 2006 16:34:37 -0800 > >>client sends change_cipher_spec/finished twice? > >I think the client will send the Alert at that point, no? > >>I don't see how this message sequence could ever occur. > >It is possible for a session resume attempt to fail, but if so, it will not >look like the example. A client could mistakenly attempt a session resume >with a commonly utilized SSID, but then typically the server will not have >keying material for the Session-Id so that the session resume attempt will >fail quickly. > > >>If the client is not happy with the server's cert anymore, it won't resume >>the session. > >Right. > >>If the master_secret is not the same, TLS finished message >>can't be decrypted, so the conversation will end there. > >Even getting there assumes that the server has state for the Session-Id >proposed by the client. Therefore the failure will typically occur >earlier. > >As far as I can see, examples 7 and 8 could just be deleted without losing >anything. > > > >_______________________________________________ >Emu mailing list >Emu@ietf.org >https://www1.ietf.org/mailman/listinfo/emu _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Tue Nov 07 11:32:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhTs7-0008Px-Ns; Tue, 07 Nov 2006 11:32:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhTs6-0008Pf-5Q for emu@ietf.org; Tue, 07 Nov 2006 11:32:22 -0500 Received: from bay0-omc3-s15.bay0.hotmail.com ([65.54.246.215]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhTs4-0006op-0t for emu@ietf.org; Tue, 07 Nov 2006 11:32:22 -0500 Received: from hotmail.com ([207.46.8.115]) by bay0-omc3-s15.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Nov 2006 08:32:19 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 7 Nov 2006 08:32:19 -0800 Message-ID: Received: from 207.46.8.123 by by117fd.bay117.hotmail.msn.com with HTTP; Tue, 07 Nov 2006 16:32:18 GMT X-Originating-IP: [130.129.68.120] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: From: "Bernard Aboba" To: Pasi.Eronen@nokia.com, emu@ietf.org Bcc: Subject: RE: [Emu] Comment on 2716bis: TLS fragmentation Date: Tue, 07 Nov 2006 08:32:18 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 07 Nov 2006 16:32:19.0270 (UTC) FILETIME=[4B235E60:01C7028A] X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Cc: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org On re-reading Section 2.3 on Fragmentation, I realized that it still contained some PPP-centric material (such as discussion of negotiation of PPP Multilink MRRU). Here is an updated section that hopefully addresses your comment: "2.3. Fragmentation A single TLS record may be up to 16384 octets in length, but a TLS message may span multiple TLS records, and a TLS certificate message may in principle be as long as 16MB. The group of EAP-TLS messages sent in a single round may thus be larger than the MTU size or the maximum RADIUS packet size of 4096 octets. As a result, an EAP-TLS implementation MUST provide its own support for fragmentation and reassembly. However, in order to ensure interoperability with existing implementations, TLS handshake messages SHOULD NOT be fragmented into multiple TLS records if they fit within a single TLS record. In order to protect against reassembly lockup and denial of service attacks, it may be desirable for an implementation to set a maximum size for one such group of TLS messages. Since a single certificate is rarely longer than a few thousand octets, and no other field is likely to be anywhere near as long, a reasonable choice of maximum acceptable message length might be 64 KB. Since EAP is a simple ACK-NAK protocol, fragmentation support can be added in a simple manner. In EAP, fragments that are lost or damaged in transit will be retransmitted, and since sequencing information is provided by the Identifier field in EAP, there is no need for a fragment offset field as is provided in IPv4. EAP-TLS fragmentation support is provided through addition of a flags octet within the EAP-Response and EAP-Request packets, as well as a TLS Message Length field of four octets. Flags include the Length included (L), More fragments (M), and EAP-TLS Start (S) bits. The L flag is set to indicate the presence of the four octet TLS Message Length field, and MUST be set for the first fragment of a fragmented TLS message or set of messages. The M flag is set on all but the last fragment. The S flag is set only within the EAP-TLS start message sent from the EAP server to the peer. The TLS Message Length field is four octets, and provides the total length of the TLS message or set of messages that is being fragmented; this simplifies buffer allocation. When an EAP-TLS peer receives an EAP-Request packet with the M bit set, it MUST respond with an EAP-Response with EAP-Type=EAP-TLS and no data. This serves as a fragment ACK. The EAP server MUST wait until it receives the EAP-Response before sending another fragment. In order to prevent errors in processing of fragments, the EAP server MUST increment the Identifier field for each fragment contained within an EAP-Request, and the peer MUST include this Identifier value in the fragment ACK contained within the EAP-Response. Retransmitted fragments will contain the same Identifier value. Similarly, when the EAP server receives an EAP-Response with the M bit set, it MUST respond with an EAP-Request with EAP-Type=EAP-TLS and no data. This serves as a fragment ACK. The EAP peer MUST wait until it receives the EAP-Request before sending another fragment. In order to prevent errors in the processing of fragments, the EAP server MUST increment the Identifier value for each fragment ACK contained within an EAP-Request, and the peer MUST include this Identifier value in the subsequent fragment contained within an EAP- Response." ------------------------------------------------------------------- >From: >To: >Subject: [Emu] Comment on 2716bis: TLS fragmentation >Date: Mon, 6 Nov 2006 23:25:07 +0200 > > >Section 2.1 contains a lot of text like "encapsulate one or more TLS >records in TLS record layer format, containing a TLS client_hello >handshake message." > >RFC 2246 also says that "multiple client messages of the same >ContentType may be coalesced into a single TLSPlaintext record, >or a single message may be fragmented across several records". > >However.... in some testing I've done recently, I discovered that >fragmenting TLS handshake messages (as opposed to application data) >is not really supported by current TLS implementations (I'm going to >talk briefly about this in TLS WG on Friday). > >Given that fragmentation is needed only with very long certificate >chains, a sane implementation (that wants to interoperate with others) >would not fragment any handshake messages unless they're longer than >2^14 bytes. > >Maybe 2716bis should explicitly say that TLS handshake messages >MUST NOT (or possibly SHOULD NOT) be fragmented into multiple TLS >records if they fit in a single TLS record? > >(Removing unnecessary complexity and unneeded options is in >general a good thing, and I don't think we'd have backwards >compatibility problems in this area.) > >Best regards, >Pasi > >_______________________________________________ >Emu mailing list >Emu@ietf.org >https://www1.ietf.org/mailman/listinfo/emu _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Tue Nov 07 15:50:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhXtY-00070e-GQ; Tue, 07 Nov 2006 15:50:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhXtS-0006xv-5O; Tue, 07 Nov 2006 15:50:02 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhXtR-0002Ma-RU; Tue, 07 Nov 2006 15:50:02 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id C82713288A; Tue, 7 Nov 2006 20:50:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GhXtR-0001fS-Lt; Tue, 07 Nov 2006 15:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 07 Nov 2006 15:50:01 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: emu@ietf.org Subject: [Emu] I-D ACTION:draft-ietf-emu-eap-gpsk-01.txt X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the EAP Method Update Working Group of the IETF. Title : EAP Generalized Pre-Shared Key (EAP-GPSK) Author(s) : C. Clancy, H. Tschofenig Filename : draft-ietf-emu-eap-gpsk-01.txt Pages : 29 Date : 2006-11-7 This Internet Draft defines an Extensible Authentication Protocol method called EAP Generalized Pre-Shared Key (EAP-GPSK). This method is a lightweight shared-key authentication protocol supporting mutual authentication and key derivation. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-emu-eap-gpsk-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-emu-eap-gpsk-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-emu-eap-gpsk-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-11-7143239.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-emu-eap-gpsk-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-emu-eap-gpsk-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-11-7143239.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu --NextPart-- From emu-bounces@ietf.org Tue Nov 07 19:58:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhblH-0004G4-Lc; Tue, 07 Nov 2006 19:57:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhblH-0004Fw-7D for emu@ietf.org; Tue, 07 Nov 2006 19:57:51 -0500 Received: from bay0-omc1-s12.bay0.hotmail.com ([65.54.246.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhblF-0001uy-Pj for emu@ietf.org; Tue, 07 Nov 2006 19:57:51 -0500 Received: from hotmail.com ([207.46.8.110]) by bay0-omc1-s12.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Nov 2006 16:57:48 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 7 Nov 2006 16:57:48 -0800 Message-ID: Received: from 207.46.8.123 by by117fd.bay117.hotmail.msn.com with HTTP; Wed, 08 Nov 2006 00:57:47 GMT X-Originating-IP: [130.129.68.120] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: <000c01c6feec$d0e98660$2f01a8c0@china.huawei.com> From: "Bernard Aboba" To: mnakhjiri@huawei.com, jsalowey@cisco.com, emu@ietf.org Bcc: Subject: RE: [Emu] Review requested: draft-simon-emu-rfc2716bis-03.txt Date: Tue, 07 Nov 2006 16:57:47 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 08 Nov 2006 00:57:48.0994 (UTC) FILETIME=[E90FFA20:01C702D0] X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Here the goal of privacy is to protect the identity from exposure over the wire (e.g. wireless network), and possibly exposure to the local operator. There is no goal to hide the user identity from the EAP server, if only because if that were done authentication would be difficult. >From: Madjid Nakhjiri >To: 'Bernard Aboba' , >jsalowey@cisco.com,emu@ietf.org >Subject: RE: [Emu] Review requested: draft-simon-emu-rfc2716bis-03.txt >Date: Thu, 02 Nov 2006 18:07:29 -0800 > >I have a question that is somewhat related (at least what I think:)) > >In the privacy section (2.7) it is stated that when a peer that supports >privacy receives a subsequent certificate_request from the server (after >the >server have received a list with no certs), the peer MUST provide a cert >list containing at least one entry in its response to the server. >What would the subject name in that entry be, if the peer intends to >protect >its identity? Is there a part of the draft that explains this and I missed? > >Thanks, > >Madjid > >-----Original Message----- >From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] >Sent: Sunday, October 22, 2006 8:47 AM >To: jsalowey@cisco.com; emu@ietf.org >Subject: RE: [Emu] Review requested: draft-simon-emu-rfc2716bis-03.txt > > >The document should also state in the security considerations section > >that the identity in the identity response is not necessarily related to > >the identity authenticated in EAP-TLS and should not be relied upon for > >any access control or accounting purposes. > >Here is some proposed new text for Section 2.4: > >"As noted in [RFC3748] Section 5.1: > > It is RECOMMENDED that the Identity Response be used primarily for > routing purposes and selecting which EAP method to use. EAP > Methods SHOULD include a method-specific mechanism for obtaining > the identity, so that they do not have to rely on the Identity > Response. > >As part of the TLS negotiation, the server presents a certificate to >the peer, and if mutual authentication is requested, the peer >presents a certificate to the server. EAP-TLS therefore provides >a mechanism for determining both the peer identity (Peer-Id in [KEYFRAME]) >and server identity (Server-Id in [KEYFRAME]). >Since the identity presented in the Identity Response need >not be related to the identity presented in the peer certificate, >EAP-TLS implementations SHOULD NOT require that they be identical, >and SHOULD NOT use the identity presented in the Identity Response >for access control or accounting purposes." > > > >_______________________________________________ >Emu mailing list >Emu@ietf.org >https://www1.ietf.org/mailman/listinfo/emu > > > >_______________________________________________ >Emu mailing list >Emu@ietf.org >https://www1.ietf.org/mailman/listinfo/emu _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Wed Nov 08 00:23:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhfuK-0006oj-7K; Wed, 08 Nov 2006 00:23:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhfuK-0006oe-06 for emu@ietf.org; Wed, 08 Nov 2006 00:23:28 -0500 Received: from mail2.genealogia.fi ([194.100.116.229]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhfuI-0004Dc-Ml for emu@ietf.org; Wed, 08 Nov 2006 00:23:27 -0500 Received: from dsl017-049-110.sfo4.dsl.speakeasy.net ([69.17.49.110] helo=jm) by mail2.genealogia.fi with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.50) id 1GhfuB-0006qy-QA for emu@ietf.org; Wed, 08 Nov 2006 07:23:21 +0200 Received: by jm (sSMTP sendmail emulation); Tue, 7 Nov 2006 21:21:47 -0800 Date: Tue, 7 Nov 2006 21:21:47 -0800 From: Jouni Malinen To: emu@ietf.org Subject: Re: [Emu] I-D ACTION:draft-ietf-emu-eap-gpsk-01.txt Message-ID: <20061108052120.GA6121@jm.kir.nu> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.11 X-Spam-Score: -2.6 (--) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org This version of EAP-GPSK draft seems to resolve the key derivation questions I had apart from one detail: how is PL to be represented in the "PL || PSK || CSuite_Sel || ..." construction? As a single octet? As two octets in network byte order? For now, I just assumed it is only a single octet. In addition, I noticed that chapter 2 is defined CSuite_Sel incorrectly: CSuite_Sel: Ciphersuite selected by the client (1 octet or 7 octets) This should be replaced with Ciphersuite selected by the client (6 octets) to match with chapter 7.2 ("Ciphersuites are encoded as 6-octet arrays"). In addition, CSuite_SEL in 6.1.3 and 6.2.3 should have been CSuite_Sel to remain consistent with the spelling in rest of the draft. -- Jouni Malinen PGP id EFC895FA _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Wed Nov 08 17:46:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhwBO-00028X-Np; Wed, 08 Nov 2006 17:46:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhwBM-000285-Rz for emu@ietf.org; Wed, 08 Nov 2006 17:46:08 -0500 Received: from dispatch.cs.umd.edu ([128.8.128.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhwBK-0005vY-HG for emu@ietf.org; Wed, 08 Nov 2006 17:46:08 -0500 Received: from delegate.pc.cs.umd.edu (exchange.cs.umd.edu [128.8.130.248]) by dispatch.cs.umd.edu (8.13.1/8.12.5) with ESMTP id kA8Mjul5008331; Wed, 8 Nov 2006 17:45:56 -0500 Received: from [127.0.0.1] ([130.129.65.170]) by delegate.pc.cs.umd.edu with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Nov 2006 17:45:50 -0500 Message-ID: <45525E1F.8010007@cs.umd.edu> Date: Wed, 08 Nov 2006 17:45:51 -0500 From: Charles Clancy User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Jouni Malinen Subject: Re: [Emu] I-D ACTION:draft-ietf-emu-eap-gpsk-01.txt References: <20061108052120.GA6121@jm.kir.nu> In-Reply-To: <20061108052120.GA6121@jm.kir.nu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Nov 2006 22:45:50.0922 (UTC) FILETIME=[A3EFD2A0:01C70387] X-CSD-MailScanner-Information: Please email staff@cs.umd.edu for more information X-CSD-MailScanner: Found to be clean X-CSD-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=0, required 5) X-CSD-MailScanner-From: clancy@cs.umd.edu X-Spam-Status: No X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Jouni, PL is two octets. Specifying that will be in the next revision. The 1/7 octets is left over from a previous revision -- we'll definitely fix that in the next revision too. Thanks for all your work implementing EAP methods. Your efforts are very helpful for bringing out bugs like these in the drafts. -- t. charles clancy, ph.d. <> tcc@umd.edu <> www.cs.umd.edu/~clancy Jouni Malinen wrote: > This version of EAP-GPSK draft seems to resolve the key derivation > questions I had apart from one detail: how is PL to be represented in > the "PL || PSK || CSuite_Sel || ..." construction? As a single octet? As > two octets in network byte order? For now, I just assumed it is only a > single octet. > > In addition, I noticed that chapter 2 is defined CSuite_Sel incorrectly: > > CSuite_Sel: > Ciphersuite selected by the client (1 octet or 7 octets) > > This should be replaced with > Ciphersuite selected by the client (6 octets) > > to match with chapter 7.2 ("Ciphersuites are encoded as 6-octet > arrays"). > > > In addition, CSuite_SEL in 6.1.3 and 6.2.3 should have been CSuite_Sel > to remain consistent with the spelling in rest of the draft. > _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Thu Nov 09 13:11:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiENL-0007ez-FM; Thu, 09 Nov 2006 13:11:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiENJ-0007el-A3 for emu@ietf.org; Thu, 09 Nov 2006 13:11:41 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiENG-0008PP-BO for emu@ietf.org; Thu, 09 Nov 2006 13:11:41 -0500 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-4.cisco.com with ESMTP; 09 Nov 2006 10:02:29 -0800 X-IronPort-AV: i="4.09,406,1157353200"; d="scan'208"; a="1863471863:sNHT1218119048" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id kA9I2Too016832; Thu, 9 Nov 2006 10:02:29 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id kA9I27Oh000864; Thu, 9 Nov 2006 10:02:29 -0800 (PST) Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Nov 2006 10:02:21 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 9 Nov 2006 10:02:20 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: EMU Summary Thread-Index: AccEKTL3cNbl+AwxTTeNY2WoSCiEYA== From: "Joseph Salowey \(jsalowey\)" To: , , "Sam Hartman" , "Russ Housley" X-OriginalArrivalTime: 09 Nov 2006 18:02:21.0606 (UTC) FILETIME=[3401EC60:01C70429] DKIM-Signature: a=rsa-sha1; q=dns; l=1119; t=1163095349; x=1163959349; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=22Joseph=20Salowey=20\(jsalowey\)=22=20 |Subject:EMU=20Summary |Sender:; X=v=3Dcisco.com=3B=20h=3DIlEGhB7IIR30pnlTGmVy50fRnMY=3D; b=hOGutkcJ7+NCAHEpQchbRriNl/WNWoT0z0xmtRk1SgE8/rRwRzGqcyiPlQIU8pQXzl/zj8LF ttSjgPYXPPR2+tWqNKUFRPHtcoeG1FM33yl4E4+Spqk+zDPCsN0C8ytq; Authentication-Results: sj-dkim-7; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim7002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Subject: [Emu] EMU Summary X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org EMU working group Summary EMU met on Monday afternoon. Our first agenda item was RFC2716bis (EAP-TLS) where much of the discussion of open items centered around certificate handling. This document is almost ready for WG Last Call, which should be started later this month. Our second item was GPSK (generalized pre-shared key) where we had some discussion of key derivation and NIST requirements for key derivation. This document is also close to WG group last call which should occur before the next IETF. For the third agenda item we discussed approaches for a password based method that works with existing password databases. This discussion centered around the choice of reusing existing methods or trying to develop something new. There was a general feeling that we should avoid doing something new. We will be forming a design team shortly after this IETF meeting to work on this method type. Finally we had lengthy discussion on enhanced EAP-TLS and how negotiation should be performed. There were some good ideas uncovered in this discussion which will be discussed on the list. =20 _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Thu Nov 09 18:50:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiJez-00037P-22; Thu, 09 Nov 2006 18:50:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiJek-00030e-Q3; Thu, 09 Nov 2006 18:50:02 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiJek-0007Tc-FE; Thu, 09 Nov 2006 18:50:02 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 5F683328C3; Thu, 9 Nov 2006 23:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GiJek-0004MR-81; Thu, 09 Nov 2006 18:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 09 Nov 2006 18:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: emu@ietf.org Subject: [Emu] I-D ACTION:draft-simon-emu-rfc2716bis-05.txt X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the EAP Method Update Working Group of the IETF. Title : The EAP TLS Authentication Protocol Author(s) : D. Simon, B. Aboba Filename : draft-simon-emu-rfc2716bis-05.txt Pages : 34 Date : 2006-11-9 The Extensible Authentication Protocol (EAP), defined in RFC 3748, provides support for multiple authentication methods. Transport Level Security (TLS) provides for mutual authentication, integrity- protected ciphersuite negotiation and key exchange between two endpoints. This document defines EAP-TLS, which includes support for certificate-based mutual authentication and key derivation. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-simon-emu-rfc2716bis-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-simon-emu-rfc2716bis-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-simon-emu-rfc2716bis-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-11-9162246.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-simon-emu-rfc2716bis-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-simon-emu-rfc2716bis-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-11-9162246.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu --NextPart-- From emu-bounces@ietf.org Thu Nov 16 03:54:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gkd0v-0002oI-Sx; Thu, 16 Nov 2006 03:54:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gkd0u-0002oD-Ih for emu@ietf.org; Thu, 16 Nov 2006 03:54:28 -0500 Received: from lizzard.sbs.de ([194.138.37.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gkd0t-0006j3-2Y for emu@ietf.org; Thu, 16 Nov 2006 03:54:28 -0500 Received: from mail2.sbs.de (localhost [127.0.0.1]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id kAG8sNgR025627 for ; Thu, 16 Nov 2006 09:54:24 +0100 Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net [157.163.133.222]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id kAG8sElk007227 for ; Thu, 16 Nov 2006 09:54:23 +0100 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.146]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Nov 2006 09:54:22 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 16 Nov 2006 09:54:15 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: NIST KDF & EAP-GPSK Thread-Index: AccJXMtReYcEAQ8PQmqG+yecPo9DAw== From: "Tschofenig, Hannes" To: X-OriginalArrivalTime: 16 Nov 2006 08:54:22.0680 (UTC) FILETIME=[CF883580:01C7095C] X-Spam-Score: 0.4 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Subject: [Emu] NIST KDF & EAP-GPSK X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1607382811==" Errors-To: emu-bounces@ietf.org This is a multi-part message in MIME format. --===============1607382811== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7095C.CF63E688" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7095C.CF63E688 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi all,=20 at the EMU working group meeting we received some feedback regarding the usage of the NIST KDF in EAP-GPSK.=20 In order to make progress with the document we would like to get some more information about the suggested change to the document.=20 Some NIST documents have been mentioned. Could someone point us to them? Ciao Hannes ------_=_NextPart_001_01C7095C.CF63E688 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable NIST KDF & EAP-GPSK

Hi all,

at the EMU working group meeting we = received some feedback regarding the usage of the NIST KDF in EAP-GPSK. =
In order to make progress with the = document we would like to get some more information about the suggested = change to the document.

Some NIST documents have been = mentioned. Could someone point us to them?

Ciao
Hannes

------_=_NextPart_001_01C7095C.CF63E688-- --===============1607382811== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu --===============1607382811==-- From emu-bounces@ietf.org Thu Nov 16 09:29:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkiEy-00032x-VE; Thu, 16 Nov 2006 09:29:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkiEx-00032m-L1 for emu@ietf.org; Thu, 16 Nov 2006 09:29:19 -0500 Received: from mgw.toshibaamericaresearch.com ([165.254.55.12] helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkiEt-0002eR-Cn for emu@ietf.org; Thu, 16 Nov 2006 09:29:19 -0500 Received: from localhost (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id kAGERsh0027438; Thu, 16 Nov 2006 09:27:54 -0500 (EST) (envelope-from yohba@tari.toshiba.com) Date: Thu, 16 Nov 2006 09:27:58 -0500 To: Alper Yegin Message-ID: <20061116142758.GA2413@steelhead> References: <0MKoyl-1Gkd7Y1I0a-00041D@mrelay.perfora.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <0MKoyl-1Gkd7Y1I0a-00041D@mrelay.perfora.net> User-Agent: Mutt/1.5.13 (2006-08-11) From: Yoshihiro Ohba X-Dispatcher: imput version 20050308(IM148) Lines: 29 X-Spam-Score: 0.1 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: hokeyp@opendiameter.org, emu@ietf.org Subject: [Emu] Re: [Hokeyp] MSK but no EMSK X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org I made one comment around this in the HOKEY session. The intent of my comment was that use of EMSK is optional. There would be an interoperability issue if peer and server do not negotiate on the use of EMSK before actually using it. Yoshihiro Ohba On Thu, Nov 16, 2006 at 11:01:15AM +0200, Alper Yegin wrote: > > I remember someone in Hokey WG meeting mentioned that not all methods > generate EMSK (even though they generate MSK). Is that accurate? > > Despite this RFC 3748 text? > > In order to provide keying material for use in a > subsequently negotiated ciphersuite, an EAP method supporting key > derivation MUST export a Master Session Key (MSK) of at least 64 > octets, and an Extended Master Session Key (EMSK) of at least 64 > octets. > > Alper > > > _______________________________________________ > Hokeyp mailing list > Hokeyp@opendiameter.org > http://www.opendiameter.org/mailman/listinfo/hokeyp > _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Thu Nov 16 09:42:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkiRq-0000xc-JJ; Thu, 16 Nov 2006 09:42:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkiRp-0000xX-R4 for emu@ietf.org; Thu, 16 Nov 2006 09:42:37 -0500 Received: from [65.160.252.132] (helo=your.mail.server.name.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GkiRo-0004gp-GL for emu@ietf.org; Thu, 16 Nov 2006 09:42:37 -0500 Received: (qmail 28590 invoked from network); 16 Nov 2006 01:43:51 -0000 Received: from unknown (HELO ?127.0.0.1?) (10.71.1.201) by 0 with SMTP; 16 Nov 2006 01:43:51 -0000 Message-ID: <455C78D8.3060605@cs.umd.edu> Date: Thu, 16 Nov 2006 09:42:32 -0500 From: Charles Clancy User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: "Tschofenig, Hannes" Subject: Re: [Emu] NIST KDF & EAP-GPSK References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org The one mentioned during the session was SP 800-56A, if I recall correctly. See: http://csrc.nist.gov/publications/nistpubs/800-56A/sp800-56A_May-3-06.pdf The title, "Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography", seems to indicate applicability might be limited; however, section 5.8 addresses KDFs based on shared secrets. Two KDFs are presented in the document, along with some requirements on how keys are handled and how a keying hierarchy should be implemented. I think the KDF in section 5.8.1 seems appropriate. It requires the use of a hash function, and not a MAC function, so only our HMAC-SHA256 ciphersuite would be compliant, provided we tweaked the KDF. For the AES ciphersuite, we could always define the KDF as a "key push" distribution system using AES keywrap, if we were super-worried about FIPS 140-2 compliance. (I think this is a bad idea, but I'm just throwing it out there.) -- t. charles clancy, ph.d. <> tcc@umd.edu <> www.cs.umd.edu/~clancy Tschofenig, Hannes wrote: > Hi all, > > at the EMU working group meeting we received some feedback regarding the > usage of the NIST KDF in EAP-GPSK. > In order to make progress with the document we would like to get some > more information about the suggested change to the document. > > Some NIST documents have been mentioned. Could someone point us to them? > > Ciao > Hannes > > > ------------------------------------------------------------------------ > > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www1.ietf.org/mailman/listinfo/emu _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Thu Nov 16 12:38:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GklBt-0004wC-2m; Thu, 16 Nov 2006 12:38:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GklBr-0004w7-Lw for emu@ietf.org; Thu, 16 Nov 2006 12:38:19 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GklBn-00043a-9j for emu@ietf.org; Thu, 16 Nov 2006 12:38:19 -0500 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id kAGHcD6f002038 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 16 Nov 2006 09:38:14 -0800 Received: from LDONDETI.qualcomm.com (qconnect-10-50-64-122.qualcomm.com [10.50.64.122]) by magus.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id kAGHcBaX025357 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 16 Nov 2006 09:38:12 -0800 (PST) Message-Id: <7.0.1.0.2.20061116093449.04453d20@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Thu, 16 Nov 2006 09:38:10 -0800 To: Yoshihiro Ohba , Alper Yegin From: Lakshminath Dondeti Subject: Re: [Emu] Re: [Hokeyp] MSK but no EMSK In-Reply-To: <20061116142758.GA2413@steelhead> References: <0MKoyl-1Gkd7Y1I0a-00041D@mrelay.perfora.net> <20061116142758.GA2413@steelhead> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: hokeyp@opendiameter.org, emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org At 06:27 AM 11/16/2006, Yoshihiro Ohba wrote: >I made one comment around this in the HOKEY session. The intent of my >comment was that use of EMSK is optional. Hi Yoshi, Which document says that the "use" of EMSK is optional? >There would be an >interoperability issue if peer and server do not negotiate on the use >of EMSK before actually using it. The interoperability issue would only come up if there is ambiguity or options. Lakshminath >Yoshihiro Ohba > > >On Thu, Nov 16, 2006 at 11:01:15AM +0200, Alper Yegin wrote: > > > > I remember someone in Hokey WG meeting mentioned that not all methods > > generate EMSK (even though they generate MSK). Is that accurate? > > > > Despite this RFC 3748 text? > > > > In order to provide keying material for use in a > > subsequently negotiated ciphersuite, an EAP method supporting key > > derivation MUST export a Master Session Key (MSK) of at least 64 > > octets, and an Extended Master Session Key (EMSK) of at least 64 > > octets. > > > > Alper > > > > > > _______________________________________________ > > Hokeyp mailing list > > Hokeyp@opendiameter.org > > http://www.opendiameter.org/mailman/listinfo/hokeyp > > > >_______________________________________________ >Emu mailing list >Emu@ietf.org >https://www1.ietf.org/mailman/listinfo/emu _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Thu Nov 16 12:56:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GklT2-0006eX-Ah; Thu, 16 Nov 2006 12:56:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GklT1-0006eO-0R for emu@ietf.org; Thu, 16 Nov 2006 12:56:03 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GklSx-0006PA-Jd for emu@ietf.org; Thu, 16 Nov 2006 12:56:02 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 16 Nov 2006 09:55:59 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id kAGHtwxr024300; Thu, 16 Nov 2006 09:55:58 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kAGHtwio007220; Thu, 16 Nov 2006 09:55:58 -0800 (PST) Received: from xmb-rtp-212.amer.cisco.com ([64.102.31.111]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Nov 2006 12:55:57 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Emu] Re: [Hokeyp] MSK but no EMSK Date: Thu, 16 Nov 2006 12:55:55 -0500 Message-ID: <9958B444368E884DBB215F3FEF36F5B703441DC7@xmb-rtp-212.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] Re: [Hokeyp] MSK but no EMSK Thread-Index: AccJpghOqp7fZl+8QJyjbc1uMbXJFQAAbOHg From: "Hao Zhou \(hzhou\)" To: "Lakshminath Dondeti" , "Yoshihiro Ohba" , "Alper Yegin" X-OriginalArrivalTime: 16 Nov 2006 17:55:57.0999 (UTC) FILETIME=[784063F0:01C709A8] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2427; t=1163699758; x=1164563758; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=hzhou@cisco.com; z=From:=20=22Hao=20Zhou=20\(hzhou\)=22=20 |Subject:=20RE=3A=20[Emu]=20Re=3A=20[Hokeyp]=20MSK=20but=20no=20EMSK |Sender:=20; bh=ucP0V9WcSS48bsIeztrxHJ1ElCK4FsHwqE4BYiUUKfA=; b=rn6Sw16GoYLbZ0ig4vFjOKkm7nZ34LLvbbE+kKRM8wDjmMwiZcvqqpWKa50cW4EFPqlqx+5s l3rYdbtCQfB4xbnB/psz2gXSo+1n+8k2o4JkT+hpGf3Be5BjX6T+PlVZ; Authentication-Results: sj-dkim-4; header.From=hzhou@cisco.com; dkim=pass (s ig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: hokeyp@opendiameter.org, emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org I pointed in the meeting that even EAP RFC mandates EMSK, however I don't know any existing EAP implementation actually generates and exports EMSK (especially the popular ones, like EAP-TLS, PEAP, EAP-FAST, EAP-TTLS, etc.) So if we build our key hierarchy on top of EMSK, we will require replacing all existing EAP implementations, both from the server and client side. If we cold use MSK, then we only need to replace EAP lower layer that wants to support handover. > -----Original Message----- > From: Lakshminath Dondeti [mailto:ldondeti@qualcomm.com]=20 > Sent: Thursday, November 16, 2006 12:38 PM > To: Yoshihiro Ohba; Alper Yegin > Cc: hokeyp@opendiameter.org; emu@ietf.org > Subject: Re: [Emu] Re: [Hokeyp] MSK but no EMSK >=20 > At 06:27 AM 11/16/2006, Yoshihiro Ohba wrote: > >I made one comment around this in the HOKEY session. The=20 > intent of my=20 > >comment was that use of EMSK is optional. >=20 > Hi Yoshi, >=20 > Which document says that the "use" of EMSK is optional? >=20 > >There would be an > >interoperability issue if peer and server do not negotiate=20 > on the use=20 > >of EMSK before actually using it. >=20 > The interoperability issue would only come up if there is=20 > ambiguity or options. >=20 > Lakshminath >=20 >=20 > >Yoshihiro Ohba > > > > > >On Thu, Nov 16, 2006 at 11:01:15AM +0200, Alper Yegin wrote: > > > > > > I remember someone in Hokey WG meeting mentioned that not all=20 > > > methods generate EMSK (even though they generate MSK). Is=20 > that accurate? > > > > > > Despite this RFC 3748 text? > > > > > > In order to provide keying material for use in a > > > subsequently negotiated ciphersuite, an EAP method=20 > supporting key > > > derivation MUST export a Master Session Key (MSK) of=20 > at least 64 > > > octets, and an Extended Master Session Key (EMSK) of=20 > at least 64 > > > octets. > > > > > > Alper > > > > > > > > > _______________________________________________ > > > Hokeyp mailing list > > > Hokeyp@opendiameter.org > > > http://www.opendiameter.org/mailman/listinfo/hokeyp > > > > > > >_______________________________________________ > >Emu mailing list > >Emu@ietf.org > >https://www1.ietf.org/mailman/listinfo/emu >=20 >=20 > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www1.ietf.org/mailman/listinfo/emu >=20 _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Thu Nov 16 13:07:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkleY-0005Ps-65; Thu, 16 Nov 2006 13:07:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkleX-0005Lx-5K for emu@ietf.org; Thu, 16 Nov 2006 13:07:57 -0500 Received: from [65.160.252.132] (helo=your.mail.server.name.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GkleU-0007xg-Oc for emu@ietf.org; Thu, 16 Nov 2006 13:07:57 -0500 Received: (qmail 18401 invoked from network); 16 Nov 2006 05:09:11 -0000 Received: from unknown (HELO ?10.71.1.201?) (10.71.1.201) by 0 with SMTP; 16 Nov 2006 05:09:11 -0000 Message-ID: <455CA8F4.10600@cs.umd.edu> Date: Thu, 16 Nov 2006 13:07:48 -0500 From: Charles Clancy User-Agent: Thunderbird 1.5.0.4 (X11/20060516) MIME-Version: 1.0 To: "Hao Zhou (hzhou)" Subject: Re: [Emu] Re: [Hokeyp] MSK but no EMSK References: <9958B444368E884DBB215F3FEF36F5B703441DC7@xmb-rtp-212.amer.cisco.com> In-Reply-To: <9958B444368E884DBB215F3FEF36F5B703441DC7@xmb-rtp-212.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: Alper Yegin , hokeyp@opendiameter.org, emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Hao, I think you meant to say it would require replacing all existing EAP *method* implementations. EAP implementations will have to change anyway to support derivation of keys within the hierarchy. If you're updating clients and servers already, rev-ing the method implementations to bring them up to spec seems like a reasonable thing to do. Engineering new standards around broken implementations of old standards seems like a bad set of design constraints. -- t. charles clancy, ph.d. | tcc@umd.edu | www.cs.umd.edu/~clancy Hao Zhou (hzhou) wrote: > I pointed in the meeting that even EAP RFC mandates EMSK, however I > don't know any existing EAP implementation actually generates and > exports EMSK (especially the popular ones, like EAP-TLS, PEAP, EAP-FAST, > EAP-TTLS, etc.) So if we build our key hierarchy on top of EMSK, we will > require replacing all existing EAP implementations, both from the server > and client side. If we cold use MSK, then we only need to replace EAP > lower layer that wants to support handover. > >> -----Original Message----- >> From: Lakshminath Dondeti [mailto:ldondeti@qualcomm.com] >> Sent: Thursday, November 16, 2006 12:38 PM >> To: Yoshihiro Ohba; Alper Yegin >> Cc: hokeyp@opendiameter.org; emu@ietf.org >> Subject: Re: [Emu] Re: [Hokeyp] MSK but no EMSK >> >> At 06:27 AM 11/16/2006, Yoshihiro Ohba wrote: >>> I made one comment around this in the HOKEY session. The >> intent of my >>> comment was that use of EMSK is optional. >> Hi Yoshi, >> >> Which document says that the "use" of EMSK is optional? >> >>> There would be an >>> interoperability issue if peer and server do not negotiate >> on the use >>> of EMSK before actually using it. >> The interoperability issue would only come up if there is >> ambiguity or options. >> >> Lakshminath >> >> >>> Yoshihiro Ohba >>> >>> >>> On Thu, Nov 16, 2006 at 11:01:15AM +0200, Alper Yegin wrote: >>>> I remember someone in Hokey WG meeting mentioned that not all >>>> methods generate EMSK (even though they generate MSK). Is >> that accurate? >>>> Despite this RFC 3748 text? >>>> >>>> In order to provide keying material for use in a >>>> subsequently negotiated ciphersuite, an EAP method >> supporting key >>>> derivation MUST export a Master Session Key (MSK) of >> at least 64 >>>> octets, and an Extended Master Session Key (EMSK) of >> at least 64 >>>> octets. >>>> >>>> Alper >>>> >>>> >>>> _______________________________________________ >>>> Hokeyp mailing list >>>> Hokeyp@opendiameter.org >>>> http://www.opendiameter.org/mailman/listinfo/hokeyp >>>> >>> _______________________________________________ >>> Emu mailing list >>> Emu@ietf.org >>> https://www1.ietf.org/mailman/listinfo/emu >> >> _______________________________________________ >> Emu mailing list >> Emu@ietf.org >> https://www1.ietf.org/mailman/listinfo/emu >> > > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www1.ietf.org/mailman/listinfo/emu _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Thu Nov 16 13:31:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gkm14-0007n9-9J; Thu, 16 Nov 2006 13:31:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gkm13-0007mi-0a for emu@ietf.org; Thu, 16 Nov 2006 13:31:13 -0500 Received: from [2001:418:1403:0:212:17ff:fe52:7811] (helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gkm11-0001vX-J1 for emu@ietf.org; Thu, 16 Nov 2006 13:31:12 -0500 Received: from localhost (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id kAGIUTp3028985; Thu, 16 Nov 2006 13:30:29 -0500 (EST) (envelope-from yohba@tari.toshiba.com) Date: Thu, 16 Nov 2006 13:30:36 -0500 To: Lakshminath Dondeti Subject: Re: [Hokeyp] [Emu] Re: MSK but no EMSK Message-ID: <20061116183036.GE5961@steelhead> References: <0MKoyl-1Gkd7Y1I0a-00041D@mrelay.perfora.net> <20061116142758.GA2413@steelhead> <7.0.1.0.2.20061116093449.04453d20@qualcomm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <7.0.1.0.2.20061116093449.04453d20@qualcomm.com> User-Agent: Mutt/1.5.13 (2006-08-11) From: Yoshihiro Ohba X-Dispatcher: imput version 20050308(IM148) Lines: 77 X-Spam-Score: -2.4 (--) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: Alper Yegin , hokeyp@opendiameter.org, emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Hi Lakshminath, RFC 3748 says: " Extended Master Session Key (EMSK) Additional keying material derived between the EAP client and server that is exported by the EAP method. The EMSK is at least 64 octets in length. The EMSK is not shared with the authenticator or any other third party. The EMSK is reserved for future uses that are not defined yet. " Since EMSK usage is not defined yet, the use of EMSK is virtually optional at this momement. Since it was not mandated in the beginning, it is not possible to change it mandatory for a particular use in a future without loss of interoperability with the existing deployment. Am I missing something? Yoshihiro Ohba On Thu, Nov 16, 2006 at 09:38:10AM -0800, Lakshminath Dondeti wrote: > At 06:27 AM 11/16/2006, Yoshihiro Ohba wrote: > >I made one comment around this in the HOKEY session. The intent of my > >comment was that use of EMSK is optional. > > Hi Yoshi, > > Which document says that the "use" of EMSK is optional? > > >There would be an > >interoperability issue if peer and server do not negotiate on the use > >of EMSK before actually using it. > > The interoperability issue would only come up if there is ambiguity or options. > > Lakshminath > > > >Yoshihiro Ohba > > > > > >On Thu, Nov 16, 2006 at 11:01:15AM +0200, Alper Yegin wrote: > > > > > > I remember someone in Hokey WG meeting mentioned that not all methods > > > generate EMSK (even though they generate MSK). Is that accurate? > > > > > > Despite this RFC 3748 text? > > > > > > In order to provide keying material for use in a > > > subsequently negotiated ciphersuite, an EAP method supporting key > > > derivation MUST export a Master Session Key (MSK) of at least 64 > > > octets, and an Extended Master Session Key (EMSK) of at least 64 > > > octets. > > > > > > Alper > > > > > > > > > _______________________________________________ > > > Hokeyp mailing list > > > Hokeyp@opendiameter.org > > > http://www.opendiameter.org/mailman/listinfo/hokeyp > > > > > > >_______________________________________________ > >Emu mailing list > >Emu@ietf.org > >https://www1.ietf.org/mailman/listinfo/emu > > _______________________________________________ > Hokeyp mailing list > Hokeyp@opendiameter.org > http://www.opendiameter.org/mailman/listinfo/hokeyp > _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Thu Nov 16 13:54:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkmNc-0003y4-6T; Thu, 16 Nov 2006 13:54:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkmNa-0003xw-HL for emu@ietf.org; Thu, 16 Nov 2006 13:54:30 -0500 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkmNW-0004Ma-32 for emu@ietf.org; Thu, 16 Nov 2006 13:54:30 -0500 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id kAGIsOoR005071 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 16 Nov 2006 10:54:24 -0800 Received: from LDONDETI.qualcomm.com (qconnect-10-50-64-122.qualcomm.com [10.50.64.122]) by magus.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id kAGIsMhs027130 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 16 Nov 2006 10:54:22 -0800 (PST) Message-Id: <7.0.1.0.2.20061116104958.06ad1ce0@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Thu, 16 Nov 2006 10:54:20 -0800 To: Yoshihiro Ohba From: Lakshminath Dondeti Subject: Re: [Hokeyp] [Emu] Re: MSK but no EMSK In-Reply-To: <20061116183036.GE5961@steelhead> References: <0MKoyl-1Gkd7Y1I0a-00041D@mrelay.perfora.net> <20061116142758.GA2413@steelhead> <7.0.1.0.2.20061116093449.04453d20@qualcomm.com> <20061116183036.GE5961@steelhead> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: Alper Yegin , hokeyp@opendiameter.org, emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org At 10:30 AM 11/16/2006, Yoshihiro Ohba wrote: >Hi Lakshminath, > >RFC 3748 says: > >" > Extended Master Session Key (EMSK) > Additional keying material derived between the EAP client and > server that is exported by the EAP method. The EMSK is at least > 64 octets in length. The EMSK is not shared with the > authenticator or any other third party. The EMSK is reserved for > future uses that are not defined yet. >" > >Since EMSK usage is not defined yet, the use of EMSK is virtually >optional at this momement. Since it was not mandated in the >beginning, it is not possible to change it mandatory for a particular >use in a future without loss of interoperability with the existing >deployment. I read it differently. The EMSK is reserved for future uses. It is of course mandatory to derive the EMSK, but the use of it is simply not defined. It is not optional to use. It is not mandatory either, it simply is unused. When the EMSK is defined for a specific use case, then the question of whether the use is optional, recommended or mandatory comes up. Lakshminath >Am I missing something? > >Yoshihiro Ohba > > >On Thu, Nov 16, 2006 at 09:38:10AM -0800, Lakshminath Dondeti wrote: > > At 06:27 AM 11/16/2006, Yoshihiro Ohba wrote: > > >I made one comment around this in the HOKEY session. The intent of my > > >comment was that use of EMSK is optional. > > > > Hi Yoshi, > > > > Which document says that the "use" of EMSK is optional? > > > > >There would be an > > >interoperability issue if peer and server do not negotiate on the use > > >of EMSK before actually using it. > > > > The interoperability issue would only come up if there is > ambiguity or options. > > > > Lakshminath > > > > > > >Yoshihiro Ohba > > > > > > > > >On Thu, Nov 16, 2006 at 11:01:15AM +0200, Alper Yegin wrote: > > > > > > > > I remember someone in Hokey WG meeting mentioned that not all methods > > > > generate EMSK (even though they generate MSK). Is that accurate? > > > > > > > > Despite this RFC 3748 text? > > > > > > > > In order to provide keying material for use in a > > > > subsequently negotiated ciphersuite, an EAP method supporting key > > > > derivation MUST export a Master Session Key (MSK) of at least 64 > > > > octets, and an Extended Master Session Key (EMSK) of at least 64 > > > > octets. > > > > > > > > Alper > > > > > > > > > > > > _______________________________________________ > > > > Hokeyp mailing list > > > > Hokeyp@opendiameter.org > > > > http://www.opendiameter.org/mailman/listinfo/hokeyp > > > > > > > > > >_______________________________________________ > > >Emu mailing list > > >Emu@ietf.org > > >https://www1.ietf.org/mailman/listinfo/emu > > > > _______________________________________________ > > Hokeyp mailing list > > Hokeyp@opendiameter.org > > http://www.opendiameter.org/mailman/listinfo/hokeyp > > >_______________________________________________ >Hokeyp mailing list >Hokeyp@opendiameter.org >http://www.opendiameter.org/mailman/listinfo/hokeyp _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Thu Nov 16 14:18:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gkmkc-0007nM-Jg; Thu, 16 Nov 2006 14:18:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gkmkc-0007nH-8s for emu@ietf.org; Thu, 16 Nov 2006 14:18:18 -0500 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkmkW-0000pQ-QJ for emu@ietf.org; Thu, 16 Nov 2006 14:18:18 -0500 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id kAGJIBpe009212 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 16 Nov 2006 11:18:11 -0800 Received: from NAEXBR04.na.qualcomm.com (naexbr04.qualcomm.com [10.46.141.42]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id kAGJHBxe032479; Thu, 16 Nov 2006 11:18:07 -0800 Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by NAEXBR04.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Nov 2006 11:18:04 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Hokeyp] [Emu] Re: MSK but no EMSK Date: Thu, 16 Nov 2006 11:18:05 -0800 Message-ID: In-Reply-To: <20061116183036.GE5961@steelhead> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Hokeyp] [Emu] Re: MSK but no EMSK Thread-Index: AccJrX27KB99Hdr0TJyXbyrIIKqDIAAAWF+w From: "Narayanan, Vidya" To: "Yoshihiro Ohba" , "Dondeti, Lakshminath" X-OriginalArrivalTime: 16 Nov 2006 19:18:04.0581 (UTC) FILETIME=[F0B92550:01C709B3] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: hokeyp@opendiameter.org, Alper Yegin , emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Hi Yoshi, As Alper pointed out in the text from RFC3748, it is not optional to produce an EMSK. Its usage is undefined at the moment, but, a compliant implementation should be producing the EMSK, nevertheless.=20 Regards, Vidya > -----Original Message----- > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com]=20 > Sent: Thursday, November 16, 2006 10:31 AM > To: Dondeti, Lakshminath > Cc: Alper Yegin; hokeyp@opendiameter.org; emu@ietf.org > Subject: Re: [Hokeyp] [Emu] Re: MSK but no EMSK >=20 > Hi Lakshminath, >=20 > RFC 3748 says: >=20 > " > Extended Master Session Key (EMSK) > Additional keying material derived between the EAP client and > server that is exported by the EAP method. The EMSK is at least > 64 octets in length. The EMSK is not shared with the > authenticator or any other third party. The EMSK is=20 > reserved for > future uses that are not defined yet. > " >=20 > Since EMSK usage is not defined yet, the use of EMSK is=20 > virtually optional at this momement. Since it was not=20 > mandated in the beginning, it is not possible to change it=20 > mandatory for a particular use in a future without loss of=20 > interoperability with the existing deployment. >=20 > Am I missing something? >=20 > Yoshihiro Ohba >=20 >=20 > On Thu, Nov 16, 2006 at 09:38:10AM -0800, Lakshminath Dondeti wrote: > > At 06:27 AM 11/16/2006, Yoshihiro Ohba wrote: > > >I made one comment around this in the HOKEY session. The=20 > intent of=20 > > >my comment was that use of EMSK is optional. > >=20 > > Hi Yoshi, > >=20 > > Which document says that the "use" of EMSK is optional? > >=20 > > >There would be an > > >interoperability issue if peer and server do not negotiate=20 > on the use=20 > > >of EMSK before actually using it. > >=20 > > The interoperability issue would only come up if there is=20 > ambiguity or options. > >=20 > > Lakshminath > >=20 > >=20 > > >Yoshihiro Ohba > > > > > > > > >On Thu, Nov 16, 2006 at 11:01:15AM +0200, Alper Yegin wrote: > > > > > > > > I remember someone in Hokey WG meeting mentioned that not all=20 > > > > methods generate EMSK (even though they generate MSK).=20 > Is that accurate? > > > > > > > > Despite this RFC 3748 text? > > > > > > > > In order to provide keying material for use in a > > > > subsequently negotiated ciphersuite, an EAP method=20 > supporting key > > > > derivation MUST export a Master Session Key (MSK) of=20 > at least 64 > > > > octets, and an Extended Master Session Key (EMSK) of=20 > at least 64 > > > > octets. > > > > > > > > Alper > > > > > > > > > > > > _______________________________________________ > > > > Hokeyp mailing list > > > > Hokeyp@opendiameter.org > > > > http://www.opendiameter.org/mailman/listinfo/hokeyp > > > > > > > > > >_______________________________________________ > > >Emu mailing list > > >Emu@ietf.org > > >https://www1.ietf.org/mailman/listinfo/emu > >=20 > > _______________________________________________ > > Hokeyp mailing list > > Hokeyp@opendiameter.org > > http://www.opendiameter.org/mailman/listinfo/hokeyp > >=20 >=20 > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www1.ietf.org/mailman/listinfo/emu >=20 _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Thu Nov 16 17:26:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gkpgd-0001F4-Pv; Thu, 16 Nov 2006 17:26:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gkpgc-0001Ey-2t for emu@ietf.org; Thu, 16 Nov 2006 17:26:22 -0500 Received: from bay0-omc3-s4.bay0.hotmail.com ([65.54.246.204]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gkpga-0003Yj-Pg for emu@ietf.org; Thu, 16 Nov 2006 17:26:22 -0500 Received: from hotmail.com ([207.46.8.92]) by bay0-omc3-s4.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Nov 2006 14:26:20 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 16 Nov 2006 14:26:19 -0800 Message-ID: Received: from 207.46.8.123 by by117fd.bay117.hotmail.msn.com with HTTP; Thu, 16 Nov 2006 22:26:14 GMT X-Originating-IP: [131.107.0.105] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: From: "Bernard Aboba" To: hokeyp@opendiameter.org, emu@ietf.org Bcc: Subject: RE: [Hokeyp] [Emu] Re: MSK but no EMSK Date: Thu, 16 Nov 2006 14:26:14 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 16 Nov 2006 22:26:19.0879 (UTC) FILETIME=[3D3ED770:01C709CE] X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org >Hi Yoshi, >As Alper pointed out in the text from RFC3748, it is not optional to >produce an EMSK. Its usage is undefined at the moment, but, a compliant >implementation should be producing the EMSK, nevertheless. It's worth keeping in mind that there are very few existing RFC 3748-compliant EAP implementations. So most existing EAP method implementations do not generate an EMSK, and most existing EAP implementations would not do anything with the EMSK if it were to be generated. _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Thu Nov 16 17:58:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkqBL-0004Mu-6k; Thu, 16 Nov 2006 17:58:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkqBJ-0004I0-FA for emu@ietf.org; Thu, 16 Nov 2006 17:58:05 -0500 Received: from [2001:418:1403:0:212:17ff:fe52:7811] (helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkqBB-0008KW-W3 for emu@ietf.org; Thu, 16 Nov 2006 17:58:05 -0500 Received: from localhost (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id kAGMv5qx030200; Thu, 16 Nov 2006 17:57:06 -0500 (EST) (envelope-from yohba@tari.toshiba.com) Date: Thu, 16 Nov 2006 17:57:09 -0500 To: Lakshminath Dondeti Subject: Re: [Hokeyp] [Emu] Re: MSK but no EMSK Message-ID: <20061116225709.GF5961@steelhead> References: <0MKoyl-1Gkd7Y1I0a-00041D@mrelay.perfora.net> <20061116142758.GA2413@steelhead> <7.0.1.0.2.20061116093449.04453d20@qualcomm.com> <20061116183036.GE5961@steelhead> <7.0.1.0.2.20061116104958.06ad1ce0@qualcomm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <7.0.1.0.2.20061116104958.06ad1ce0@qualcomm.com> User-Agent: Mutt/1.5.13 (2006-08-11) From: Yoshihiro Ohba X-Dispatcher: imput version 20050308(IM148) Lines: 108 X-Spam-Score: -2.4 (--) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: Alper Yegin , hokeyp@opendiameter.org, emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org On Thu, Nov 16, 2006 at 10:54:20AM -0800, Lakshminath Dondeti wrote: > At 10:30 AM 11/16/2006, Yoshihiro Ohba wrote: > >Hi Lakshminath, > > > >RFC 3748 says: > > > >" > > Extended Master Session Key (EMSK) > > Additional keying material derived between the EAP client and > > server that is exported by the EAP method. The EMSK is at least > > 64 octets in length. The EMSK is not shared with the > > authenticator or any other third party. The EMSK is reserved for > > future uses that are not defined yet. > >" > > > >Since EMSK usage is not defined yet, the use of EMSK is virtually > >optional at this momement. Since it was not mandated in the > >beginning, it is not possible to change it mandatory for a particular > >use in a future without loss of interoperability with the existing > >deployment. > > I read it differently. The EMSK is reserved for future uses. It is > of course mandatory to derive the EMSK, but the use of it is simply > not defined. It is not optional to use. It is not mandatory either, > it simply is unused. When the EMSK is defined for a specific use > case, then the question of whether the use is optional, recommended > or mandatory comes up. I agree that this is more precise reading. However, even after defining a usage of EMSK, it is difficult to assume that all peers and servers will always support the usage of EMSK unless we can upgrade the existing EAP implementations which do not use EMSK to the new ones *at one time*. Thus, as a proactive answer to the question, I don't really believe that a specific use of EMSK can be mandated without breaking interoperability with existing EAP implementations. Yoshihiro Ohba > > Lakshminath > > > >Am I missing something? > > > >Yoshihiro Ohba > > > > > >On Thu, Nov 16, 2006 at 09:38:10AM -0800, Lakshminath Dondeti wrote: > >> At 06:27 AM 11/16/2006, Yoshihiro Ohba wrote: > >> >I made one comment around this in the HOKEY session. The intent of my > >> >comment was that use of EMSK is optional. > >> > >> Hi Yoshi, > >> > >> Which document says that the "use" of EMSK is optional? > >> > >> >There would be an > >> >interoperability issue if peer and server do not negotiate on the use > >> >of EMSK before actually using it. > >> > >> The interoperability issue would only come up if there is > >ambiguity or options. > >> > >> Lakshminath > >> > >> > >> >Yoshihiro Ohba > >> > > >> > > >> >On Thu, Nov 16, 2006 at 11:01:15AM +0200, Alper Yegin wrote: > >> > > > >> > > I remember someone in Hokey WG meeting mentioned that not all methods > >> > > generate EMSK (even though they generate MSK). Is that accurate? > >> > > > >> > > Despite this RFC 3748 text? > >> > > > >> > > In order to provide keying material for use in a > >> > > subsequently negotiated ciphersuite, an EAP method supporting key > >> > > derivation MUST export a Master Session Key (MSK) of at least 64 > >> > > octets, and an Extended Master Session Key (EMSK) of at least 64 > >> > > octets. > >> > > > >> > > Alper > >> > > > >> > > > >> > > _______________________________________________ > >> > > Hokeyp mailing list > >> > > Hokeyp@opendiameter.org > >> > > http://www.opendiameter.org/mailman/listinfo/hokeyp > >> > > > >> > > >> >_______________________________________________ > >> >Emu mailing list > >> >Emu@ietf.org > >> >https://www1.ietf.org/mailman/listinfo/emu > >> > >> _______________________________________________ > >> Hokeyp mailing list > >> Hokeyp@opendiameter.org > >> http://www.opendiameter.org/mailman/listinfo/hokeyp > >> > >_______________________________________________ > >Hokeyp mailing list > >Hokeyp@opendiameter.org > >http://www.opendiameter.org/mailman/listinfo/hokeyp > > _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Thu Nov 16 21:35:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GktZj-0001m5-9S; Thu, 16 Nov 2006 21:35:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GktZh-0001lr-S0 for emu@ietf.org; Thu, 16 Nov 2006 21:35:29 -0500 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GktZg-0005po-Gb for emu@ietf.org; Thu, 16 Nov 2006 21:35:29 -0500 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id kAH2ZP3w025728 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 16 Nov 2006 18:35:26 -0800 Received: from NAEXBR04.na.qualcomm.com (naexbr04.qualcomm.com [10.46.141.42]) by magus.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id kAH2ZOaB028379; Thu, 16 Nov 2006 18:35:25 -0800 (PST) Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by NAEXBR04.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Nov 2006 18:35:23 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Hokeyp] [Emu] Re: MSK but no EMSK Date: Thu, 16 Nov 2006 18:35:25 -0800 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Hokeyp] [Emu] Re: MSK but no EMSK Thread-Index: AccJzklxPwF5M9khTom054JMBfhApwAFuvaw From: "Narayanan, Vidya" To: "Bernard Aboba" , , X-OriginalArrivalTime: 17 Nov 2006 02:35:23.0875 (UTC) FILETIME=[088FAB30:01C709F1] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org >=20 > It's worth keeping in mind that there are very few existing=20 > RFC 3748-compliant EAP implementations. So most existing EAP=20 > method implementations do not generate an EMSK, and most=20 > existing EAP implementations would not do anything with the=20 > EMSK if it were to be generated. >=20 Well, the question is this - is the requirement to interoperate with existing standards or existing implementations? Given that we have a spec that says what it does, it seems to make sense to interoperate with that. If we are going by existing implementations, there is probably more than one flavor and then there is the question of when the MSK is directly delivered to the authenticator and when it isn't and how the peer knows that.=20 In this case, I tend to agree with Charles that it is better to have to fix non-compliant implementations than try to design around them. Also, if we choose to ignore the standard and use the implementations that don't produce an EMSK as a data point, the standard doesn't seem to be serving a purpose then - perhaps, we should then consider revising RFC3748 to reflect what we want to use as a starting point for requirements?=20 Vidya _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Fri Nov 17 13:01:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl81w-0004i6-E4; Fri, 17 Nov 2006 13:01:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl81v-0004i1-IE for emu@ietf.org; Fri, 17 Nov 2006 13:01:35 -0500 Received: from mcfeely.cs.umd.edu ([128.8.128.218]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gl81m-0003k0-K2 for emu@ietf.org; Fri, 17 Nov 2006 13:01:35 -0500 Received: from mcfeely.cs.umd.edu (localhost [127.0.0.1]) by mcfeely.cs.umd.edu (8.12.11.20060308/8.12.5) with ESMTP id kAHI1PXx017029; Fri, 17 Nov 2006 13:01:26 -0500 Received: (from apache@localhost) by mcfeely.cs.umd.edu (8.12.11.20060308/8.12.11/Submit) id kAHI1PD6017026; Fri, 17 Nov 2006 13:01:25 -0500 X-Authentication-Warning: mcfeely.cs.umd.edu: apache set sender to clancy@cs.umd.edu using -f Received: from 63.239.69.1 (SquirrelMail authenticated user clancy) by webmail.cs.umd.edu with HTTP; Fri, 17 Nov 2006 13:01:25 -0500 (EST) Message-ID: <63277.63.239.69.1.1163786485.squirrel@webmail.cs.umd.edu> Date: Fri, 17 Nov 2006 13:01:25 -0500 (EST) From: "Charles Clancy" To: hokeyp@opendiameter.org, emu@ietf.org User-Agent: SquirrelMail/1.4.5 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: Subject: [Emu] CAPWAP and HOKEY interim meetings X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org CAPWAP and HOKEY WGs, The chairs of both CAPWAP and HOKEY feel an interim meeting between IETF 67 and 68 is necessary in order to meet their respective milestones. Due to a likely overlap in some participants, consecutive, co-located meetings are suggested. The chairs propose to hold a 3-day event (1 day for HOKEY followed by 2 days for CAPWAP) in the San Francisco Bay area the week of January 22. Due to a preference of not traveling on weekends, meeting Tue-Thu (Jan 23-25) is suggested. Please send comments to the lists on the proposed schedule, area, preference on dates, and which meeting(s) you're likely to attend. Also please indicate any possible overlooked conflicts with conferences and other events. If your organization would be interested in providing a venue to host the event, please let us know. In particular, we are interested in your site's space availability, accessibility to visitors, guest Internet connectivity, ability to provide lunch, and proximity to a major airport and reasonably-priced hotels. Thanks! -- t. charles clancy, ph.d. <> tcc@umd.edu <> www.cs.umd.edu/~clancy _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Fri Nov 17 13:18:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl8IQ-0006Fy-1F; Fri, 17 Nov 2006 13:18:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl8IO-0006FR-EW for emu@ietf.org; Fri, 17 Nov 2006 13:18:36 -0500 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gl8I1-0005v3-Fc for emu@ietf.org; Fri, 17 Nov 2006 13:18:36 -0500 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id kAHII4lK030825 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 17 Nov 2006 10:18:05 -0800 Received: from LDONDETI.qualcomm.com (qconnect-10-50-64-57.qualcomm.com [10.50.64.57]) by crowley.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id kAHII1NC023092 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 17 Nov 2006 10:18:03 -0800 (PST) Message-Id: <7.0.1.0.2.20061117101459.07385580@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Fri, 17 Nov 2006 10:17:58 -0800 To: "Charles Clancy" , hokeyp@opendiameter.org, emu@ietf.org From: Lakshminath Dondeti Subject: Re: [Emu] CAPWAP and HOKEY interim meetings In-Reply-To: <63277.63.239.69.1.1163786485.squirrel@webmail.cs.umd.edu> References: <63277.63.239.69.1.1163786485.squirrel@webmail.cs.umd.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Not sure how the flight schedules work, but it would be good to have 2 days for HOKEY too. The evening between the first and the second days of the meeting can be used for offline discussions to come to consensus. On hosting, does one have to host both meetings? :) I can make a case for a HOKEY meeting in QUALCOMM. regards, Lakshminath At 10:01 AM 11/17/2006, Charles Clancy wrote: >CAPWAP and HOKEY WGs, > >The chairs of both CAPWAP and HOKEY feel an interim meeting between IETF >67 and 68 is necessary in order to meet their respective milestones. Due >to a likely overlap in some participants, consecutive, co-located meetings >are suggested. > >The chairs propose to hold a 3-day event (1 day for HOKEY followed by 2 >days for CAPWAP) in the San Francisco Bay area the week of January 22. Due >to a preference of not traveling on weekends, meeting Tue-Thu (Jan 23-25) >is suggested. Please send comments to the lists on the proposed schedule, >area, preference on dates, and which meeting(s) you're likely to attend. >Also please indicate any possible overlooked conflicts with conferences >and other events. > >If your organization would be interested in providing a venue to host the >event, please let us know. In particular, we are interested in your >site's space availability, accessibility to visitors, guest Internet >connectivity, ability to provide lunch, and proximity to a major airport >and reasonably-priced hotels. > >Thanks! > >-- >t. charles clancy, ph.d. <> tcc@umd.edu <> www.cs.umd.edu/~clancy > > >_______________________________________________ >Emu mailing list >Emu@ietf.org >https://www1.ietf.org/mailman/listinfo/emu _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Fri Nov 17 13:49:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl8mk-0005li-81; Fri, 17 Nov 2006 13:49:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl8mi-0005jv-EV for emu@ietf.org; Fri, 17 Nov 2006 13:49:56 -0500 Received: from [2001:418:1403:0:212:17ff:fe52:7811] (helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gl8mb-0001u7-53 for emu@ietf.org; Fri, 17 Nov 2006 13:49:56 -0500 Received: from localhost (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id kAHImsCE034056; Fri, 17 Nov 2006 13:48:55 -0500 (EST) (envelope-from yohba@tari.toshiba.com) Date: Fri, 17 Nov 2006 13:48:54 -0500 To: "Narayanan, Vidya" Subject: Re: [Hokeyp] [Emu] Re: MSK but no EMSK Message-ID: <20061117184854.GB11636@steelhead> References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.13 (2006-08-11) From: Yoshihiro Ohba X-Dispatcher: imput version 20050308(IM148) Lines: 43 X-Spam-Score: -2.4 (--) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: Bernard Aboba , hokeyp@opendiameter.org, emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org On Thu, Nov 16, 2006 at 06:35:25PM -0800, Narayanan, Vidya wrote: > > > > It's worth keeping in mind that there are very few existing > > RFC 3748-compliant EAP implementations. So most existing EAP > > method implementations do not generate an EMSK, and most > > existing EAP implementations would not do anything with the > > EMSK if it were to be generated. > > > > Well, the question is this - is the requirement to interoperate with > existing standards or existing implementations? Given that we have a > spec that says what it does, it seems to make sense to interoperate with > that. If we are going by existing implementations, there is probably > more than one flavor and then there is the question of when the MSK is > directly delivered to the authenticator and when it isn't and how the > peer knows that. > > In this case, I tend to agree with Charles that it is better to have to > fix non-compliant implementations than try to design around them. Also, > if we choose to ignore the standard and use the implementations that > don't produce an EMSK as a data point, the standard doesn't seem to be > serving a purpose then - perhaps, we should then consider revising > RFC3748 to reflect what we want to use as a starting point for > requirements? Revising RFC 3748 to add a mandatory usage of EMSK would break interoperability with existing EAP implementations, because EAP does not define a *version* field used for distinguishing old and new specifications. Yoshihiro Ohba > > Vidya > > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www1.ietf.org/mailman/listinfo/emu > > _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Fri Nov 17 14:08:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl94h-0005FW-Pb; Fri, 17 Nov 2006 14:08:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl94h-0005FP-3U for emu@ietf.org; Fri, 17 Nov 2006 14:08:31 -0500 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gl94d-00046P-LC for emu@ietf.org; Fri, 17 Nov 2006 14:08:31 -0500 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id kAHJ5GHV003516 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 17 Nov 2006 11:05:17 -0800 Received: from NAEXBR04.na.qualcomm.com (naexbr04.qualcomm.com [10.46.141.42]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id kAHJ4UTH005243; Fri, 17 Nov 2006 11:05:07 -0800 Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by NAEXBR04.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Nov 2006 11:04:29 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Hokeyp] [Emu] Re: MSK but no EMSK Date: Fri, 17 Nov 2006 11:04:29 -0800 Message-ID: In-Reply-To: <20061117184854.GB11636@steelhead> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Hokeyp] [Emu] Re: MSK but no EMSK Thread-Index: AccKeeGENo5oObOvTjuhIGxO7D7xnAAAUEfw From: "Narayanan, Vidya" To: "Yoshihiro Ohba" X-OriginalArrivalTime: 17 Nov 2006 19:04:29.0777 (UTC) FILETIME=[3579AC10:01C70A7B] X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: Bernard Aboba , hokeyp@opendiameter.org, emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Yoshi, I am NOT suggesting any revisions.=20 Regards, Vidya=20 > -----Original Message----- > From: hokeyp-bounces@opendiameter.org=20 > [mailto:hokeyp-bounces@opendiameter.org] On Behalf Of Yoshihiro Ohba > Sent: Friday, November 17, 2006 10:49 AM > To: Narayanan, Vidya > Cc: Bernard Aboba; hokeyp@opendiameter.org; emu@ietf.org > Subject: Re: [Hokeyp] [Emu] Re: MSK but no EMSK >=20 > On Thu, Nov 16, 2006 at 06:35:25PM -0800, Narayanan, Vidya wrote: > > >=20 > > > It's worth keeping in mind that there are very few existing RFC=20 > > > 3748-compliant EAP implementations. So most existing EAP method=20 > > > implementations do not generate an EMSK, and most existing EAP=20 > > > implementations would not do anything with the EMSK if it=20 > were to be=20 > > > generated. > > >=20 > >=20 > > Well, the question is this - is the requirement to=20 > interoperate with=20 > > existing standards or existing implementations? Given that=20 > we have a=20 > > spec that says what it does, it seems to make sense to interoperate=20 > > with that. If we are going by existing implementations, there is=20 > > probably more than one flavor and then there is the=20 > question of when=20 > > the MSK is directly delivered to the authenticator and when=20 > it isn't=20 > > and how the peer knows that. > >=20 > > In this case, I tend to agree with Charles that it is=20 > better to have=20 > > to fix non-compliant implementations than try to design=20 > around them.=20 > > Also, if we choose to ignore the standard and use the=20 > implementations=20 > > that don't produce an EMSK as a data point, the standard=20 > doesn't seem=20 > > to be serving a purpose then - perhaps, we should then consider=20 > > revising > > RFC3748 to reflect what we want to use as a starting point for=20 > > requirements? >=20 > Revising RFC 3748 to add a mandatory usage of EMSK would=20 > break interoperability with existing EAP implementations,=20 > because EAP does not define a *version* field used for=20 > distinguishing old and new specifications. >=20 > Yoshihiro Ohba >=20 >=20 >=20 > >=20 > > Vidya > >=20 > > _______________________________________________ > > Emu mailing list > > Emu@ietf.org > > https://www1.ietf.org/mailman/listinfo/emu > >=20 > >=20 > _______________________________________________ > Hokeyp mailing list > Hokeyp@opendiameter.org > http://www.opendiameter.org/mailman/listinfo/hokeyp >=20 _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Fri Nov 17 14:36:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl9VV-0002QC-K9; Fri, 17 Nov 2006 14:36:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl9VU-0002Q7-Hl for emu@ietf.org; Fri, 17 Nov 2006 14:36:12 -0500 Received: from [2001:418:1403:0:212:17ff:fe52:7811] (helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gl9VR-00085J-9G for emu@ietf.org; Fri, 17 Nov 2006 14:36:12 -0500 Received: from localhost (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id kAHJZS2q034303; Fri, 17 Nov 2006 14:35:29 -0500 (EST) (envelope-from yohba@tari.toshiba.com) Date: Fri, 17 Nov 2006 14:35:30 -0500 To: "Blumenthal, Uri" Subject: Re: [Hokeyp] [Emu] Re: MSK but no EMSK Message-ID: <20061117193530.GC11636@steelhead> References: <279DDDAFA85EC74C9300A0598E704056F915FE@hdsmsx412.amr.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <279DDDAFA85EC74C9300A0598E704056F915FE@hdsmsx412.amr.corp.intel.com> User-Agent: Mutt/1.5.13 (2006-08-11) From: Yoshihiro Ohba X-Dispatcher: imput version 20050308(IM148) Lines: 44 X-Spam-Score: -2.4 (--) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: hokeyp@opendiameter.org, emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Hi Uri, I have a different view. Mandating generation of EMSK without having defined its usage *when it was introduced* seems not much different from not having defining it at all. It looks like selling a key without a lock, make the lock later and say "You MUST use this key and lock for your car." Make sense?? Yoshihiro Ohba On Fri, Nov 17, 2006 at 09:22:04AM -0500, Blumenthal, Uri wrote: > >The discussion focuses on the problem EMSK is optional or mandatory. > > I don't think this is a problem - GENERATION of EMSK is compulsoty as > spelled out in RFC 3578. > > The problem is non-compliance. Some, er, people seem to think "the > standard says do A, but since I don't use A at the moment - I won't > bother." > > >RFC3578 defined EMSK is mandatory, > > And that should be the end of discussion. > > > but it is not used at all. > > First - do you know all the applications that use key-generating EAP > methods? But really - who cares? > > >If EMSK must be used, it is mandatory. if no, I think, > >it may be better that it is optional. > > VERY strongly disagree. Mandatory is what is explicitly specified as > mandatory, period. Otherwise many would implement just those pieces and > features of the standard that his particular product needs today. > > (I'm proud of my restraint - not even once using a term "B*S*" :-) > _______________________________________________ > Hokeyp mailing list > Hokeyp@opendiameter.org > http://www.opendiameter.org/mailman/listinfo/hokeyp > _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Fri Nov 17 15:36:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlARq-0008BI-Hn; Fri, 17 Nov 2006 15:36:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlARp-0008BD-U3 for emu@ietf.org; Fri, 17 Nov 2006 15:36:29 -0500 Received: from [2001:418:1403:0:212:17ff:fe52:7811] (helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GlARo-0008AZ-KM for emu@ietf.org; Fri, 17 Nov 2006 15:36:29 -0500 Received: from localhost (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id kAHKZfBh034543; Fri, 17 Nov 2006 15:35:42 -0500 (EST) (envelope-from yohba@tari.toshiba.com) Date: Fri, 17 Nov 2006 15:35:39 -0500 To: "Blumenthal, Uri" Subject: Re: [Hokeyp] [Emu] Re: MSK but no EMSK Message-ID: <20061117203539.GE11636@steelhead> References: <279DDDAFA85EC74C9300A0598E704056F918B6@hdsmsx412.amr.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <279DDDAFA85EC74C9300A0598E704056F918B6@hdsmsx412.amr.corp.intel.com> User-Agent: Mutt/1.5.13 (2006-08-11) From: Yoshihiro Ohba X-Dispatcher: imput version 20050308(IM148) Lines: 16 X-Spam-Score: -2.4 (--) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: hokeyp@opendiameter.org, emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org On Fri, Nov 17, 2006 at 03:15:46PM -0500, Blumenthal, Uri wrote: (snip) > Let's dispense with flawed analogies and stick to the point. Which is: > the WG decided that the way EAP evolves it needs two cryptographically > indpendent "generator keys" MSK and EMSK, with usage model for the 2nd > one still being considered. It is obvious however that it is much better > to have a key and not need to use it than the other way around - having > a need for a cryptographically independent key and not having a source > for it. Agreed. Yoshihiro Ohba _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Fri Nov 17 18:53:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlDWo-0001l7-N6; Fri, 17 Nov 2006 18:53:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlDW6-0001AH-4D for emu@ietf.org; Fri, 17 Nov 2006 18:53:06 -0500 Received: from usaga01-in.huawei.com ([12.129.211.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GlDSj-0004BP-CE for emu@ietf.org; Fri, 17 Nov 2006 18:49:40 -0500 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J8W00KXPFIKV2@usaga01-in.huawei.com> for emu@ietf.org; Fri, 17 Nov 2006 15:49:32 -0800 (PST) Received: from N737011 (pool-71-112-12-134.sttlwa.dsl-w.verizon.net [71.112.12.134]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J8W00H64FIFD0@usaga01-in.huawei.com> for emu@ietf.org; Fri, 17 Nov 2006 15:49:32 -0800 (PST) Date: Fri, 17 Nov 2006 15:49:28 -0800 From: Madjid Nakhjiri In-reply-to: <63277.63.239.69.1.1163786485.squirrel@webmail.cs.umd.edu> To: 'Charles Clancy' , hokeyp@opendiameter.org, emu@ietf.org Message-id: <001001c70aa3$05a847d0$2f01a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AccKcqEtXuOHyb+7Sb2EWIQLUZmXdwALKuAw X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: capwap@frascone.com Subject: [Emu] RE: [Hokeyp] CAPWAP and HOKEY interim meetings X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Hi Charles, Not sure why EMU is cced:) So I cc CAPWAP. I appreciate the sense of urgency. Given that some of hokey deadlines are in January, it was a bit unfortunate that we did not get to discuss hokey future steps, but can we please specify what we want to achieve in this meeting and possibly even more important define specific action items to be completed before we start the meeting, since some of hokey deadlines are actually right around the time of this meeting and the "meeting" itself might hinder us from meeting the deadlines (I think I used as many double meaning as I could:)) The hokey community has generated problem statements that have gone multiple revisions and presented many times. I hope we don't want to go through those presentations AGAIN. I personally think a quick rewrite/merging of the existing documents will help us meet some of the deadlines we are facing without the travel. I personally have travel restrictions and would rather not do this trip and we need to think about the effect of people not being able to show up given that this meeting is an interim outside IETF schedule and whether we can do conference calling instead. That said, if we are still planning to meet, and if there is a discussion in CAPWAP that relates to hokey, then I suggest that such CAPWAP session is as close in time to the hokey day, so we can minimize travel needs. If the first is true and there is a need to coordination, I would suggest to have the CAPWAP-hokey meeting on a half day next to hokey meeting day next to day, e.g. if hokey is on Thursday, the CAPWAP-hokey meeting would be on Wednesday afternoon. Regards, Madjid -----Original Message----- From: hokeyp-bounces@opendiameter.org [mailto:hokeyp-bounces@opendiameter.org] On Behalf Of Charles Clancy Sent: Friday, November 17, 2006 10:01 AM To: hokeyp@opendiameter.org; emu@ietf.org Subject: [Hokeyp] CAPWAP and HOKEY interim meetings CAPWAP and HOKEY WGs, The chairs of both CAPWAP and HOKEY feel an interim meeting between IETF 67 and 68 is necessary in order to meet their respective milestones. Due to a likely overlap in some participants, consecutive, co-located meetings are suggested. The chairs propose to hold a 3-day event (1 day for HOKEY followed by 2 days for CAPWAP) in the San Francisco Bay area the week of January 22. Due to a preference of not traveling on weekends, meeting Tue-Thu (Jan 23-25) is suggested. Please send comments to the lists on the proposed schedule, area, preference on dates, and which meeting(s) you're likely to attend. Also please indicate any possible overlooked conflicts with conferences and other events. If your organization would be interested in providing a venue to host the event, please let us know. In particular, we are interested in your site's space availability, accessibility to visitors, guest Internet connectivity, ability to provide lunch, and proximity to a major airport and reasonably-priced hotels. Thanks! -- t. charles clancy, ph.d. <> tcc@umd.edu <> www.cs.umd.edu/~clancy _______________________________________________ Hokeyp mailing list Hokeyp@opendiameter.org http://www.opendiameter.org/mailman/listinfo/hokeyp _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Sat Nov 18 12:43:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlUED-0001QU-Ok; Sat, 18 Nov 2006 12:43:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlUEC-0001QH-NG for emu@ietf.org; Sat, 18 Nov 2006 12:43:44 -0500 Received: from bay0-omc3-s35.bay0.hotmail.com ([65.54.246.235]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GlUEA-0003jc-D0 for emu@ietf.org; Sat, 18 Nov 2006 12:43:44 -0500 Received: from hotmail.com ([207.46.8.120]) by bay0-omc3-s35.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 18 Nov 2006 09:43:41 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 18 Nov 2006 09:43:41 -0800 Message-ID: Received: from 207.46.8.123 by by117fd.bay117.hotmail.msn.com with HTTP; Sat, 18 Nov 2006 17:43:40 GMT X-Originating-IP: [71.222.85.189] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: From: "Bernard Aboba" To: vidyan@qualcomm.com, hokeyp@opendiameter.org, emu@ietf.org Bcc: Subject: RE: [Hokeyp] [Emu] Re: MSK but no EMSK Date: Sat, 18 Nov 2006 09:43:40 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 18 Nov 2006 17:43:41.0615 (UTC) FILETIME=[16289BF0:01C70B39] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org >If we are going by existing implementations, there is probably >more than one flavor and then there is the question of when the MSK is >directly delivered to the authenticator and when it isn't and how the >peer knows that. The Wifi Alliance (WFA) WPA2 certification includes EAP interoperability testing. Quite a few implementations have passed certification, including most of the major ones. The WFA EAP certification requires that EAP implementations support the generation of the MSK as specified in RFC 2716. Authenticators/APs are required to support transport of the MSK as described in RFC 2548. Existing EAP lower layers that utilize EAP keying (802.11i, IKEv2, PPP, 802.16e) base their key hierarchies on the MSK. Since the key hierarchy is based on the MSK, if it were not delivered to the authenticator, the exchange of data frames between the peer and authenticator would not be possible. >In this case, I tend to agree with Charles that it is better to have to >fix non-compliant implementations than try to design around them. RFC 2284 was approved in March 1998; the first widely available implementation shipped in December 1999. Major interoperability and security issues were being resolved as late as 2003; testing and certification began in 2005. So it took 7 years to go from initial specification to certified interoperable implementations. While I would expect that RFC 3748-compliant implementations will take less than 7 years to appear, we are still only at the beginning of the road. For example, there are no RFC 3748-compliant implementations shipping yet; we have not had an RFC 3748 bakeoff demonstrating interoperability between two distinct implementations with respect to new RFC 3748 features (including the EMSK); no open source RFC 3748-compliant implementations exist yet. _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Sat Nov 18 13:11:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlUfO-0004oX-BY; Sat, 18 Nov 2006 13:11:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlUfM-0004oQ-GF for emu@ietf.org; Sat, 18 Nov 2006 13:11:48 -0500 Received: from mail2.genealogia.fi ([194.100.116.229]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GlUfL-0007tl-4r for emu@ietf.org; Sat, 18 Nov 2006 13:11:48 -0500 Received: from dsl017-049-110.sfo4.dsl.speakeasy.net ([69.17.49.110] helo=jm) by mail2.genealogia.fi with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.50) id 1GlUfE-0000tS-8F; Sat, 18 Nov 2006 20:11:41 +0200 Received: by jm (sSMTP sendmail emulation); Sat, 18 Nov 2006 10:10:04 -0800 Date: Sat, 18 Nov 2006 10:10:04 -0800 From: Jouni Malinen To: Bernard Aboba Subject: Re: [Hokeyp] [Emu] Re: MSK but no EMSK Message-ID: <20061118181004.GA8778@jm.kir.nu> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.11 X-Spam-Score: -2.6 (--) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: hokeyp@opendiameter.org, emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org (sorry for the duplicate; I sent this first with incorrect email address which did not go through to the mailing list) On Sat, Nov 18, 2006 at 09:43:40AM -0800, Bernard Aboba wrote: > While I would expect that RFC 3748-compliant implementations will take less > than 7 years to appear, we are still only at the beginning of the road. > For example, there are no RFC 3748-compliant implementations shipping yet; > we have not had an RFC 3748 bakeoff demonstrating interoperability between > two distinct implementations with respect to new RFC 3748 features > (including the EMSK); no open source RFC 3748-compliant implementations > exist yet. The current development branch for wpa_supplicant (EAP peer) and hostapd (EAP server) includes support for most of RFC 3748, including EMSK derivation in many of the EAP methods and use of expanded types. Sure, EMSK is not currently used for anything, but at least it is included in the EAP method interface and the programs are ready to start using it once suitable use of EMSK is specified. I would be interested in running interoperability tests for RFC 3748 features with other implementations. I haven't tested EMSK derivation with another implementation, but expanded types have been tested with other implementations. -- Jouni Malinen PGP id EFC895FA _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Sat Nov 18 17:23:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlYak-0003nV-RC; Sat, 18 Nov 2006 17:23:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlYak-0003nO-67 for emu@ietf.org; Sat, 18 Nov 2006 17:23:18 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GlYaf-0001Zp-A5 for emu@ietf.org; Sat, 18 Nov 2006 17:23:18 -0500 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 18 Nov 2006 14:23:13 -0800 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id kAIMNCBx026006 for ; Sat, 18 Nov 2006 14:23:12 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id kAIMNCOV028144 for ; Sat, 18 Nov 2006 14:23:12 -0800 (PST) Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 18 Nov 2006 14:23:12 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Sat, 18 Nov 2006 14:23:08 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft minutes for EMU working group Thread-Index: AccLYB/DM6FG0LS+SbmHoiQ9mXfoIQ== From: "Joseph Salowey \(jsalowey\)" To: X-OriginalArrivalTime: 18 Nov 2006 22:23:12.0507 (UTC) FILETIME=[2263A4B0:01C70B60] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=7977; t=1163888592; x=1164752592; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20\(jsalowey\)=22=20 |Subject:=20Draft=20minutes=20=20for=20EMU=20working=20group |Sender:=20; bh=uukiL7Qudg/f7sQUVUeZTRwRQ0KwEqh9GczSLW/lfFw=; b=lbFBbz2VU3K/X/EpYfhPi5vqcmVUGdexo7CKhHAWrJUZ3G35MHIX5HFSYaKosZ1uF0oxv7eR 1iUzI8B8S4ptrZ9Zm1EZtHk6vAlW8qubZLzBsIJCjJuSSmmJrSfaLTNn; Authentication-Results: sj-dkim-6; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim6002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: ff0adf256e4dd459cc25215cfa732ac1 Subject: [Emu] Draft minutes for EMU working group X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Here are draft minutes from the EMU minutes. Thanks to Donald and Hao for taking excellent notes.=20 EAP Method Update (EMU) working Group=20 -------------------------------------- IETF 67 11/06/2006 13:00=20 -------------------------------------- Chair: Joe Salowey Note Takers: Donald Eastlake Hao Zhou -------------------------------------- Agenda 1. Administrative 2. RFC2716bis (EAP-TLS) 3. EAP-GPSK 4. Password based 5. Enhanced-TLS --------------------------------------- Administrative - Current Drafts EAP-TLS draft-simon-emu-rfc-2716bis-04.txt close to last call EAP-GPSK Draft-ietf-emu-eap-gpsk-00.txt close to WGLC, but needs some more revision ---------------------------------------- RFC2716bis (EAP-TLS) Presenter: Bernard Aboba Draft: draft-simon-emu-rfc-2716bis-04.txt Changes from RFC 2716, two draft revisions since last IETF=20 - Open Issues =09 What if EKU (extended key usage) is present or ANY? What if more than one altSubjectName? Is result dependent on the order of altSubjectName fields? Russ: Your description is accurate, any of EKU will work. If you want to assign one, we can assign one. Bernard: I would like to have a reference to point to=20 Joe: I would like to avoid mandating a particular EKU Bernard: The question is how to address that so existing implementation is compatible.=20 - EAP-TLS certificate profile different from TLS certificate profile? RFC 4334 seems to assume yes. But implementations typically just rely on TLS for cert handling. Dave Johnston: are we going to specify an EAP-TLS profile? The IEEE802.16 standards assume it exists and refers to it. Bernard Aboba: No. Maybe we need to specifically say there isn't such a thing. Other people shouldn't be changing EAP-TLS by requiring OIDs, etc., that will break existing implementation. Joe: How is that? Bernard: 802 has forked 3 version incompatible with existing implementation. Existing implementation don't look for any EKU Oids. Bernard: There is no such thing of EAP-TLS profile, if you create a new profile,=20 Joe: Existing implementations already has issue with dealing with CN and SAN. Bernard: At least they can look at RFC3280. Question is where do we go from here. Look at 3280 to specify what people are doing today. Russ: Two aspects: application needs to make authorization decision on top of TLS, SIP RFC3269 is an example on how to deal with two SANs. Bernard: Will look into it to modify. Chair: target for working group last call at the end of November beginning of December -------------------------------------------- EAP-GPSK Presenter: Charles Clancy Draft: Draft-ietf-emu-eap-gpsk-00.txt (-01 submitted, should be on site soon) Issue tracker: www.tschofenig.com:8080/eap-gpsk/=20 - Issues believed closed: #4 delimiters in KDF (Key Derivation Function), swapped two items for more self delimiting Russ Housley: Doesn't conform to NIST 800-56A and should. Hannes: What do we need to do? Tim Polk: 800-56A is key establishment algorithms. This document has requirements for KDFs. Specifies two functions with some mandatory and optional fields. One is ASN.1 and one is byte string. Sam Hartman: Is 800-56A a key hierarchy or for turning stuff into a symmetric key? Tim Polk: Not for hierarchy where you derive one key from another. We are working on that but document is just an internal draft right now. #3 KDF data, way to include arbitrary data has been taken out. #5 cipher suites, AES-EAX-128 changed to AES-CBC-128. #2 channel binding, has been removed but could be added back. Minor KDF inconsistency. Now allows arbitrary length input but one case where it says truncate is still there.=20 Need to take out truncation. - Issues still open: =09 #5 error handling: what to do if there is a MAC error? Return en error or just drop the packet? How long till user finds out about the error? Bernard Aboba: There is now an error message you can send back that doesn't change state. Lakshminath: maybe it's not DOS, but guessing the key Charles: with strong key, we shouldn't worry about Glen: It would be good to get some result back, knowing the reason. Bernard: Radius client will try to retransmit, if message is discarded.=20 Vidya: not just a radius problem, EAP problem as well. User experience an issue=20 Hannes: what do other EAP method uses Bernard: EAP-TLS uses TLS-alert Lakshminath: ok with EAP-failure as long as we put some user guidance on how to deal with it Vidya: Is EAP or radius failure? Joe: They are linked, EAP-failure implies RADIUS reject Bernard: RFC 3589 describe retry within the method Charles: PSK is a strong key, we don't have to worry about offline and online dictionary attack. #1 Protected Results Indication Define PRI within document, rather than as something that could be added later. Hannes: different than the first issue Hao: Agree with Hannes, two different issues. This is to protect the clear text result. may include additional errors with result indication. Glen: Not useful in failure case, especially in the case of mismatch key. Might be useful in authorization failure, indicating failed reason Target: Working group last call before next IETF --------------------------------------------- Password Based Mechanism Presenter: Charles Clancy Draft: none, design team forming - Goals Simplicity, Wide Applicability, Efficiency, Flexibility, Extensibility=20 - 1st approach, client ->password-> EAP-server ->password->pwdatabase=20 - 2nd approach, send hash of pw back from database, more limited, not what is in charter. Sam: charter in scope is to support #1(sending clear text over), wider clear text password support. - Problem is dictionary attacks:=20 on-line protected by locking account after invalid attempts. Protection again off-line dictionary attack requires some sort of public key crypto. EKE style approach - IPR covered, expiring soon tunneling approach=20 - Choices:=20 write our own PKI-based protocol,=20 use tunneling method=20 write inner method or with an existing inner method. Russ Housley: Starting from scratch is hard. Frequently one party has a certificate and the other does not. Could make use CMS building blocks. Glenn Zorn: I thought there was an EAP method that just sent the password under raw RSA using the servers public key. --------------------------------------------- Enhanced TLS Based Mechanism Presenter: Chair Draft: none - New Type Code (and Name) Perhaps one for each cipher suite class. - Channel Binding - Protected Results Indication Bernard Aboba: Didn't mean to suggest a new type code for each cipher suite class. Sam Hartman: Don't want to commit to an EAP type code until you know you can succeed. If later we allow multiple layers of negotiation, this becomes much more complex. For example, you might want to ack or nack EAP-TLS EAP method depending on what cipher suite it is going to be offered in later stages. Various: Long discussion of multi-level of EAP methods, authentication methods, cipher suites a la TLS, ... Sam: Can EAP send data with the first packet? Room: yes Sam: Then why are we having this discussion? Question: are there any asymmetric methods, that is with radically different credential on the two sides? Pasi: Only one with pre-shared key on one side and certificate on the other side. Hao: Looking at the password-based requirements and enhanced-TLS requirements, a lot of them are similar. I wonder if we can come up with a single method, especially we are using a tunneling method. -------------------------------------------- Additional Rohan: Time for Enrollment to be considered? ADs (Sam and Russ): Not until we complete more of our goals and recharter! Rohan: I'll be back with this question at the next IETF _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Sat Nov 18 18:05:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlZFA-0002Jd-Dq; Sat, 18 Nov 2006 18:05:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlZF8-0002JV-TV for emu@ietf.org; Sat, 18 Nov 2006 18:05:02 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GlZF6-0002aU-GQ for emu@ietf.org; Sat, 18 Nov 2006 18:05:02 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-4.cisco.com with ESMTP; 18 Nov 2006 15:05:00 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id kAIN4xKO018699; Sat, 18 Nov 2006 15:04:59 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id kAIN4vW4015847; Sat, 18 Nov 2006 15:04:57 -0800 (PST) Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 18 Nov 2006 15:04:57 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Emu] CAPWAP and HOKEY interim meetings Date: Sat, 18 Nov 2006 15:04:54 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] CAPWAP and HOKEY interim meetings Thread-Index: AccKcod0dEATuK/3QYSrEGZOzDzFwgA8rMHQ From: "Joseph Salowey \(jsalowey\)" To: "Charles Clancy" , , X-OriginalArrivalTime: 18 Nov 2006 23:04:57.0271 (UTC) FILETIME=[F7584C70:01C70B65] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1844; t=1163891099; x=1164755099; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20\(jsalowey\)=22=20 |Subject:=20RE=3A=20[Emu]=20CAPWAP=20and=20HOKEY=20interim=20meetings |Sender:=20; bh=YmKTzVAg/uP0HCDywzR3KKxZRi3w/12npK3+aXOr50Q=; b=EcDtZwUY2JaOnEnYX4YyXo5EXe8ZM5LddbThidxGsilJ8hbAGBMIiNJ6QxKkVnP4DagO9U+D xya1jKFE/pxoMrSr7oixrCcgCVng1iOqIUyAhlq013HC485/oDE37M03; Authentication-Results: sj-dkim-1; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org There is an IEEE 802.1 interim in Monterey, CA 1/22 - 1/26 (most of the rest of 802 is in London the week before). I may attend Hokey if it doesn't conflict with 802.1 sessions I need to attend.=20 > -----Original Message----- > From: Charles Clancy [mailto:clancy@cs.umd.edu]=20 > Sent: Friday, November 17, 2006 10:01 AM > To: hokeyp@opendiameter.org; emu@ietf.org > Subject: [Emu] CAPWAP and HOKEY interim meetings >=20 > CAPWAP and HOKEY WGs, >=20 > The chairs of both CAPWAP and HOKEY feel an interim meeting=20 > between IETF > 67 and 68 is necessary in order to meet their respective=20 > milestones. Due to a likely overlap in some participants,=20 > consecutive, co-located meetings are suggested. >=20 > The chairs propose to hold a 3-day event (1 day for HOKEY=20 > followed by 2 days for CAPWAP) in the San Francisco Bay area=20 > the week of January 22. Due to a preference of not traveling=20 > on weekends, meeting Tue-Thu (Jan 23-25) is suggested. =20 > Please send comments to the lists on the proposed schedule,=20 > area, preference on dates, and which meeting(s) you're likely=20 > to attend.=20 > Also please indicate any possible overlooked conflicts with=20 > conferences and other events. >=20 > If your organization would be interested in providing a venue=20 > to host the event, please let us know. In particular, we are=20 > interested in your site's space availability, accessibility=20 > to visitors, guest Internet connectivity, ability to provide=20 > lunch, and proximity to a major airport and reasonably-priced hotels. >=20 > Thanks! >=20 > -- > t. charles clancy, ph.d. <> tcc@umd.edu <> www.cs.umd.edu/~clancy >=20 >=20 > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www1.ietf.org/mailman/listinfo/emu >=20 _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Sat Nov 18 18:26:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlZZC-0001JH-30; Sat, 18 Nov 2006 18:25:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl8TO-0003TR-Ru for emu@ietf.org; Fri, 17 Nov 2006 13:29:58 -0500 Received: from nj300815-ier2.net.avaya.com ([198.152.12.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gl8T7-0007aO-9N for emu@ietf.org; Fri, 17 Nov 2006 13:29:58 -0500 Received: from cof110avexu1.global.avaya.com (h135-9-6-16.avaya.com [135.9.6.16]) by nj300815-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id kAHITWja029094 for ; Fri, 17 Nov 2006 13:29:32 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.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: [Hokeyp] [Emu] CAPWAP and HOKEY interim meetings Date: Fri, 17 Nov 2006 11:29:32 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Hokeyp] [Emu] CAPWAP and HOKEY interim meetings Thread-Index: AccKdRmo9VD8JhrEQKuoAedqt3qyCgAANzSQ From: "Mani, Mahalingam \(Mani\)" To: "Lakshminath Dondeti" , "Charles Clancy" , , X-Scanner: InterScan AntiVirus for Sendmail X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d X-Mailman-Approved-At: Sat, 18 Nov 2006 18:25:43 -0500 Cc: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org My feeling is that between an offer to host both vs. one; the former offer is likely to be looked upon more favorably for reasons of logistics and in consideration for those who would likely wish to attend both (maybe a handful). That should not stop anyone from making what offer they can/willing to. -mani -----Original Message----- From: hokeyp-bounces@opendiameter.org [mailto:hokeyp-bounces@opendiameter.org] On Behalf Of Lakshminath Dondeti Sent: Friday, November 17, 2006 10:18 AM To: Charles Clancy; hokeyp@opendiameter.org; emu@ietf.org Subject: Re: [Hokeyp] [Emu] CAPWAP and HOKEY interim meetings Not sure how the flight schedules work, but it would be good to have=20 2 days for HOKEY too. The evening between the first and the second=20 days of the meeting can be used for offline discussions to come to consensus. On hosting, does one have to host both meetings? :) I can make a=20 case for a HOKEY meeting in QUALCOMM. regards, Lakshminath At 10:01 AM 11/17/2006, Charles Clancy wrote: >CAPWAP and HOKEY WGs, > >The chairs of both CAPWAP and HOKEY feel an interim meeting between IETF >67 and 68 is necessary in order to meet their respective milestones. Due >to a likely overlap in some participants, consecutive, co-located meetings >are suggested. > >The chairs propose to hold a 3-day event (1 day for HOKEY followed by 2 >days for CAPWAP) in the San Francisco Bay area the week of January 22. Due >to a preference of not traveling on weekends, meeting Tue-Thu (Jan 23-25) >is suggested. Please send comments to the lists on the proposed schedule, >area, preference on dates, and which meeting(s) you're likely to attend. >Also please indicate any possible overlooked conflicts with conferences >and other events. > >If your organization would be interested in providing a venue to host the >event, please let us know. In particular, we are interested in your >site's space availability, accessibility to visitors, guest Internet >connectivity, ability to provide lunch, and proximity to a major airport >and reasonably-priced hotels. > >Thanks! > >-- >t. charles clancy, ph.d. <> tcc@umd.edu <> www.cs.umd.edu/~clancy > > >_______________________________________________ >Emu mailing list >Emu@ietf.org >https://www1.ietf.org/mailman/listinfo/emu _______________________________________________ Hokeyp mailing list Hokeyp@opendiameter.org http://www.opendiameter.org/mailman/listinfo/hokeyp _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Sat Nov 18 18:26:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlZZB-0001J7-Ty; Sat, 18 Nov 2006 18:25:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl4gK-0005vc-CI for emu@ietf.org; Fri, 17 Nov 2006 09:27:04 -0500 Received: from mga02.intel.com ([134.134.136.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gl4gJ-0003Qb-3b for emu@ietf.org; Fri, 17 Nov 2006 09:27:04 -0500 Received: from orsmga001.jf.intel.com ([10.7.209.18]) by mga02.intel.com with ESMTP; 17 Nov 2006 06:27:02 -0800 Received: from fmsmsx333.amr.corp.intel.com ([132.233.42.2]) by orsmga001.jf.intel.com with ESMTP; 17 Nov 2006 06:27:02 -0800 X-ExtLoop1: 1 X-IronPort-AV: i="4.09,435,1157353200"; d="gif'147?scan'147,208,217,147"; a="163064091:sNHT56662249" Received: from hdsmsx412.amr.corp.intel.com ([10.127.2.72]) by fmsmsx333.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Nov 2006 06:27:02 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 17 Nov 2006 09:26:50 -0500 Message-ID: <279DDDAFA85EC74C9300A0598E704056F91609@hdsmsx412.amr.corp.intel.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Message to the Moderator thread-index: AccKVGutXqswfLRuTFuajOJhLGfjww== From: "Blumenthal, Uri" To: X-OriginalArrivalTime: 17 Nov 2006 14:27:02.0843 (UTC) FILETIME=[732120B0:01C70A54] X-Spam-Score: 0.2 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 X-Mailman-Approved-At: Sat, 18 Nov 2006 18:25:43 -0500 Subject: [Emu] Message to the Moderator X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0460449024==" Errors-To: emu-bounces@ietf.org This is a multi-part message in MIME format. --===============0460449024== Content-class: urn:content-classes:message Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01C70A54.7216D320" This is a multi-part message in MIME format. ------_=_NextPart_001_01C70A54.7216D320 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C70A54.7216D320" ------_=_NextPart_002_01C70A54.7216D320 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Dear Moderator, =20 As I'm a member of the EMU group, perhaps my status should be changed to "unmoderated"? =20 No strong insistence either way. :-) =20 Tnx! =20 Regards, Uri Blumenthal Opinions in this e-mail are strictly my personal ones, and not Intel's. =20 ------_=_NextPart_002_01C70A54.7216D320 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Blank
Dear Moderator,
 
As I'm a member of the EMU group, = perhaps my=20 status should be changed to "unmoderated"?
 
No strong insistence either = way. =20 :-)
 
Tnx!
 
Regards,
Uri = Blumenthal
<Disclaimer> Opinions in this e-mail are = strictly my=20 personal ones, and not Intel's.

 

------_=_NextPart_002_01C70A54.7216D320-- ------_=_NextPart_001_01C70A54.7216D320 Content-Type: image/gif; name="Blank Bkgrd.gif" Content-Transfer-Encoding: base64 Content-ID: <313412514@17112006-3392> Content-Description: Blank Bkgrd.gif Content-Location: Blank%20Bkgrd.gif R0lGODlhLQAtAID/AP////f39ywAAAAALQAtAEACcAxup8vtvxKQsFon6d02898pGkgiYoCm6sq2 7iqWcmzOsmeXeA7uPJd5CYdD2g9oPF58ygqz+XhCG9JpJGmlYrPXGlfr/Yo/VW45e7amp2tou/lW xo/zX513z+Vt+1n/tiX2pxP4NUhy2FM4xtjIUQAAOw== ------_=_NextPart_001_01C70A54.7216D320-- --===============0460449024== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu --===============0460449024==-- From emu-bounces@ietf.org Sat Nov 18 18:26:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlZZB-0001In-LW; Sat, 18 Nov 2006 18:25:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gkyvd-0003nC-TC for emu@ietf.org; Fri, 17 Nov 2006 03:18:29 -0500 Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkyvX-0003nk-B4 for emu@ietf.org; Fri, 17 Nov 2006 03:18:29 -0500 Received: from mail2.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id kAH8IBJW028999; Fri, 17 Nov 2006 09:18:12 +0100 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id kAH8I7OX006907; Fri, 17 Nov 2006 09:18:10 +0100 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.146]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Nov 2006 09:18:07 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: [Hokeyp] [Emu] Re: MSK but no EMSK Date: Fri, 17 Nov 2006 09:18:06 +0100 Message-ID: <098B8E8384157645B6025978DB7EF75501867B6E@MCHP7IEA.ww002.siemens.net> In-Reply-To: <001101c709fa$b226cdf0$4005a40a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Hokeyp] [Emu] Re: MSK but no EMSK Thread-Index: AccJzklxPwF5M9khTom054JMBfhApwAFuvawAAOTFmAAAIoXQAAKTX8g From: "Kroeselberg, Dirk" To: "Michael Ye" , "Blumenthal, Uri" , , X-OriginalArrivalTime: 17 Nov 2006 08:18:07.0550 (UTC) FILETIME=[E97775E0:01C70A20] X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 X-Mailman-Approved-At: Sat, 18 Nov 2006 18:25:43 -0500 Cc: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Hi all,=20 the hokey charter under 3) seems to be clearly based on the current RFC = 3748 text (mandating EMSK generation). So one effort is to think about = the hierarchy below EMSK (and not whether EMSK is there at all), take = into account existing uses of EMSK etc., right? Possibly, another effort may focus on 'legacy methods' not (or not = fully) describing EMSK generation (i.e. not compliant to 3748). The remainder are implementations that - although the method spec = specifies how EMSK generation happens - do not implement this. I would = expect this to be out-of-scope for standardization. Dirk -----Urspr=FCngliche Nachricht----- Von: hokeyp-bounces@opendiameter.org = [mailto:hokeyp-bounces@opendiameter.org] Im Auftrag von Michael Ye Gesendet: Freitag, 17. November 2006 04:45 An: 'Blumenthal, Uri'; hokeyp@opendiameter.org; emu@ietf.org Betreff: Re: [Hokeyp] [Emu] Re: MSK but no EMSK The discussion focuses on the problem EMSK is optional or mandatory. RFC3578 defined EMSK is mandatory, but it is not used at all. If EMSK = must be used, it is mandatory . if no, I think, it may be better that it is optional. If EMSK is necessary for some "applications" in the future, = we may still use it by option. If RFC3578 don't be taken into account , I prefer to that it is optional. Michael =20 > -----Original Message----- > From: hokeyp-bounces@opendiameter.org=20 > [mailto:hokeyp-bounces@opendiameter.org] On Behalf Of Blumenthal, Uri > Sent: Friday, November 17, 2006 10:58 AM > To: hokeyp@opendiameter.orgFrom emu-bounces@ietf.org Sat Nov 18 18:26:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlZZB-0001In-LW; Sat, 18 Nov 2006 18:25:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gkyvd-0003nC-TC for emu@ietf.org; Fri, 17 Nov 2006 03:18:29 -0500 Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkyvX-0003nk-B4 for emu@ietf.org; Fri, 17 Nov 2006 03:18:29 -0500 Received: from mail2.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id kAH8IBJW028999; Fri, 17 Nov 2006 09:18:12 +0100 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id kAH8I7OX006907; Fri, 17 Nov 2006 09:18:10 +0100 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.146]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Nov 2006 09:18:07 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: [Hokeyp] [Emu] Re: MSK but no EMSK Date: Fri, 17 Nov 2006 09:18:06 +0100 Message-ID: <098B8E8384157645B6025978DB7EF75501867B6E@MCHP7IEA.ww002.siemens.net> In-Reply-To: <001101c709fa$b226cdf0$4005a40a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Hokeyp] [Emu] Re: MSK but no EMSK Thread-Index: AccJzklxPwF5M9khTom054JMBfhApwAFuvawAAOTFmAAAIoXQAAKTX8g From: "Kroeselberg, Dirk" To: "Michael Ye" , "Blumenthal, Uri" , , X-OriginalArrivalTime: 17 Nov 2006 08:18:07.0550 (UTC) FILETIME=[E97775E0:01C70A20] X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 X-Mailman-Approved-At: Sat, 18 Nov 2006 18:25:43 -0500 Cc: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Hi all,=20 the hokey charter under 3) seems to be clearly based on the current RFC = 3748 text (mandating EMSK generation). So one effort is to think about = the hierarchy below EMSK (and not whether EMSK is there at all), take = into account existing uses of EMSK etc., right? Possibly, another effort may focus on 'legacy methods' not (or not = fully) describing EMSK generation (i.e. not compliant to 3748). The remainder are implementations that - although the method spec = specifies how EMSK generation happens - do not implement this. I would = expect this to be out-of-scope for standardization. Dirk -----Urspr=FCngliche Nachricht----- Von: hokeyp-bounces@opendiameter.org = [mailto:hokeyp-bounces@opendiameter.org] Im Auftrag von Michael Ye Gesendet: Freitag, 17. November 2006 04:45 An: 'Blumenthal, Uri'; hokeyp@opendiameter.org; emu@ietf.org Betreff: Re: [Hokeyp] [Emu] Re: MSK but no EMSK The discussion focuses on the problem EMSK is optional or mandatory. RFC3578 defined EMSK is mandatory, but it is not used at all. If EMSK = must be used, it is mandatory . if no, I think, it may be better that it is optional. If EMSK is necessary for some "applications" in the future, = we may still use it by option. If RFC3578 don't be taken into account , I prefer to that it is optional. Michael =20 > -----Original Message----- > From: hokeyp-bounces@opendiameter.org=20 > [mailto:hokeyp-bounces@opendiameter.org] On Behalf Of Blumenthal, Uri > Sent: Friday, November 17, 2006 10:58 AM > To: hokeyp@opendiameter.org; emu@ietf.org > Subject: Re: [Hokeyp] [Emu] Re: MSK but no EMSK >=20 > I happen to agree with Vidya on this. >=20 > It is not optional for new EAP methods to produce EMSK.=20 > Whether EMSK gets used or not is totally besides the point. =20 > (If we can conceive that EMSK would serve a need in some=20 > distant future - we have to enforce its generation now. And=20 > it is required by RFC 3748 :-) >=20 > What to do with the existing _old_ methods that aren't=20 > compliant - I leave it for the group to decide. >=20 > -----Original Message----- > From: hokeyp-bounces@opendiameter.org > [mailto:hokeyp-bounces@opendiameter.org] On Behalf Of Narayanan, Vidya > Sent: Thursday, November 16, 2006 9:35 PM > To: Bernard Aboba; hokeyp@opendiameter.org; emu@ietf.org > Subject: Re: [Hokeyp] [Emu] Re: MSK but no EMSK >=20 > >=20 > > It's worth keeping in mind that there are very few existing RFC=20 > > 3748-compliant EAP implementations. So most existing EAP method=20 > > implementations do not generate an EMSK, and most existing EAP=20 > > implementations would not do anything with the EMSK if it=20 > were to be=20 > > generated. > >=20 >=20 > Well, the question is this - is the requirement to=20 > interoperate with existing standards or existing=20 > implementations? Given that we have a spec that says what it=20 > does, it seems to make sense to interoperate with that. If we=20 > are going by existing implementations, there is probably more=20 > than one flavor and then there is the question of when the=20 > MSK is directly delivered to the authenticator and when it=20 > isn't and how the peer knows that.=20 >=20 > In this case, I tend to agree with Charles that it is better=20 > to have to fix non-compliant implementations than try to=20 > design around them. Also, if we choose to ignore the standard=20 > and use the implementations that don't produce an EMSK as a=20 > data point, the standard doesn't seem to be serving a purpose=20 > then - perhaps, we should then consider revising > RFC3748 to reflect what we want to use as a starting point=20 > for requirements?=20 >=20 > Vidya > _______________________________________________ > Hokeyp mailing list > Hokeyp@opendiameter.org > http://www.opendiameter.org/mailman/listinfo/hokeyp > _______________________________________________ > Hokeyp mailing list > Hokeyp@opendiameter.org > http://www.opendiameter.org/mailman/listinfo/hokeyp >=20 _______________________________________________ Hokeyp mailing list Hokeyp@opendiameter.org http://www.opendiameter.org/mailman/listinfo/hokeyp _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Sat Nov 18 18:26:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlZZC-0001JQ-8I; Sat, 18 Nov 2006 18:25:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlA88-0005pl-5e for emu@ietf.org; Fri, 17 Nov 2006 15:16:08 -0500 Received: from mga01.intel.com ([192.55.52.88]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GlA7z-00051C-P8 for emu@ietf.org; Fri, 17 Nov 2006 15:16:08 -0500 Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by mga01.intel.com with ESMTP; 17 Nov 2006 12:15:54 -0800 Received: from fmsmsx333.amr.corp.intel.com ([132.233.42.2]) by fmsmga002.fm.intel.com with ESMTP; 17 Nov 2006 12:15:54 -0800 X-ExtLoop1: 1 X-IronPort-AV: i="4.09,435,1157353200"; d="scan'208"; a="17111629:sNHT21062889" Received: from hdsmsx412.amr.corp.intel.com ([10.127.2.72]) by fmsmsx333.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Nov 2006 12:15:54 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Hokeyp] [Emu] Re: MSK but no EMSK Date: Fri, 17 Nov 2006 15:15:46 -0500 Message-ID: <279DDDAFA85EC74C9300A0598E704056F918B6@hdsmsx412.amr.corp.intel; emu@ietf.org > Subject: Re: [Hokeyp] [Emu] Re: MSK but no EMSK >=20 > I happen to agree with Vidya on this. >=20 > It is not optional for new EAP methods to produce EMSK.=20 > Whether EMSK gets used or not is totally besides the point. =20 > (If we can conceive that EMSK would serve a need in some=20 > distant future - we have to enforce its generation now. And=20 > it is required by RFC 3748 :-) >=20 > What to do with the existing _old_ methods that aren't=20 > compliant - I leave it for the group to decide. >=20 > -----Original Message----- > From: hokeyp-bounces@opendiameter.org > [mailto:hokeyp-bounces@opendiameter.org] On Behalf Of Narayanan, Vidya > Sent: Thursday, November 16, 2006 9:35 PM > To: Bernard Aboba; hokeyp@opendiameter.org; emu@ietf.org > Subject: Re: [Hokeyp] [Emu] Re: MSK but no EMSK >=20 > >=20 > > It's worth keeping in mind that there are very few existing RFC=20 > > 3748-compliant EAP implementations. So most existing EAP method=20 > > implementations do not generate an EMSK, and most existing EAP=20 > > implementations would not do anything with the EMSK if it=20 > were to be=20 > > generated. > >=20 >=20 > Well, the question is this - is the requirement to=20 > interoperate with existing standards or existing=20 > implementations? Given that we have a spec that says what it=20 > does, it seems to make sense to interoperate with that. If we=20 > are going by existing implementations, there is probably more=20 > than one flavor and then there is the question of when the=20 > MSK is directly delivered to the authenticator and when it=20 > isn't and how the peer knows that.=20 >=20 > In this case, I tend to agree with Charles that it is better=20 > to have to fix non-compliant implementations than try to=20 > design around them. Also, if we choose to ignore the standard=20 > and use the implementations that don't produce an EMSK as a=20 > data point, the standard doesn't seem to be serving a purpose=20 > then - perhaps, we should then consider revising > RFC3748 to reflect what we want to use as a starting point=20 > for requirements?=20 >=20 > Vidya > _______________________________________________ > Hokeyp mailing list > Hokeyp@opendiameter.org > http://www.opendiameter.org/mailman/listinfo/hokeyp > _______________________________________________ > Hokeyp mailing list > Hokeyp@opendiameter.org > http://www.opendiameter.org/mailman/listinfo/hokeyp >=20 _______________________________________________ Hokeyp mailing list Hokeyp@opendiameter.org http://www.opendiameter.org/mailman/listinfo/hokeyp _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Sat Nov 18 18:26:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlZZC-0001JQ-8I; Sat, 18 Nov 2006 18:25:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlA88-0005pl-5e for emu@ietf.org; Fri, 17 Nov 2006 15:16:08 -0500 Received: from mga01.intel.com ([192.55.52.88]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GlA7z-00051C-P8 for emu@ietf.org; Fri, 17 Nov 2006 15:16:08 -0500 Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by mga01.intel.com with ESMTP; 17 Nov 2006 12:15:54 -0800 Received: from fmsmsx333.amr.corp.intel.com ([132.233.42.2]) by fmsmga002.fm.intel.com with ESMTP; 17 Nov 2006 12:15:54 -0800 X-ExtLoop1: 1 X-IronPort-AV: i="4.09,435,1157353200"; d="scan'208"; a="17111629:sNHT21062889" Received: from hdsmsx412.amr.corp.intel.com ([10.127.2.72]) by fmsmsx333.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Nov 2006 12:15:54 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Hokeyp] [Emu] Re: MSK but no EMSK Date: Fri, 17 Nov 2006 15:15:46 -0500 Message-ID: <279DDDAFA85EC74C9300A0598E704056F918B6@hdsmsx412.amr.corp.intel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Hokeyp] [Emu] Re: MSK but no EMSK thread-index: AccKf75AK/U4IpvfSQiyB6o0NwUwrgABGVgQ From: "Blumenthal, Uri" To: "Yoshihiro Ohba" X-OriginalArrivalTime: 17 Nov 2006 20:15:54.0439 (UTC) FILETIME=[2F553570:01C70A85] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 X-Mailman-Approved-At: Sat, 18 Nov 2006 18:25:43 -0500 Cc: hokeyp@opendiameter.org, emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org >Mandating generation of EMSK without having >defined its usage *when it was introduced* seems not much different >from not having defining it at all. It looks like selling a key >without a lock, make the lock later and say "You MUST use this key and >lock for your car." Make sense?? Not it does not make sense. To me it's like saying you must make your house doors such that they accept two locks, even though now people either put no lock at all or are satisfied with just one. Let's dispense with flawed analogies and stick to the point. Which is: the WG decided that the way EAP evolves it needs two cryptographically indpendent "generator keys" MSK and EMSK, with usage model for the 2nd one still being considered. It is obvious however that it is much better to have a key and not need to use it than the other way around - having a need for a cryptographically independent key and not having a source for it. On Fri, Nov 17, 2006 at 09:22:04AM -0500, Blumenthal, Uri wrote: > >The discussion focuses on the problem EMSK is optional or mandatory. >=20 > I don't think this is a problem - GENERATION of EMSK is compulsoty as > spelled out in RFC 3578. >=20 > The problem is non-compliance. Some, er, people seem to think "the > standard says do A, but since I don't use A at the moment - I won't > bother." >=20 > >RFC3578 defined EMSK is mandatory,=20 >=20 > And that should be the end of discussion. >=20 > > but it is not used at all.=20 >=20 > First - do you know all the applications that use key-generating EAP > methods? But really - who cares?=20 >=20 > >If EMSK must be used, it is mandatory. if no, I think,=20 > >it may be better that it is optional. >=20 > VERY strongly disagree. Mandatory is what is explicitly specified as > mandatory, period. Otherwise many would implement just those pieces and > features of the standard that his particular product needs today. >=20 > (I'm proud of my restraint - not even once using a term "B*S*" :-) > _______________________________________________ > Hokeyp mailing list > Hokeyp@opendiameter.org > http://www.opendiameter.org/mailman/listinfo/hokeyp >=20 _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu .com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Hokeyp] [Emu] Re: MSK but no EMSK thread-index: AccKf75AK/U4IpvfSQiyB6o0NwUwrgABGVgQ From: "Blumenthal, Uri" To: "Yoshihiro Ohba" X-OriginalArrivalTime: 17 Nov 2006 20:15:54.0439 (UTC) FILETIME=[2F553570:01C70A85] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 X-Mailman-Approved-At: Sat, 18 Nov 2006 18:25:43 -0500 Cc: hokeyp@opendiameter.org, emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org >Mandating generation of EMSK without having >defined its usage *when it was introduced* seems not much different >from not having defining it at all. It looks like selling a key >without a lock, make the lock later and say "You MUST use this key and >lock for your car." Make sense?? Not it does not make sense. To me it's like saying you must make your house doors such that they accept two locks, even though now people either put no lock at all or are satisfied with just one. Let's dispense with flawed analogies and stick to the point. Which is: the WG decided that the way EAP evolves it needs two cryptographically indpendent "generator keys" MSK and EMSK, with usage model for the 2nd one still being considered. It is obvious however that it is much better to have a key and not need to use it than the other way around - having a need for a cryptographically independent key and not having a source for it. On Fri, Nov 17, 2006 at 09:22:04AM -0500, Blumenthal, Uri wrote: > >The discussion focuses on the problem EMSK is optional or mandatory. >=20 > I don't think this is a problem - GENERATION of EMSK is compulsoty as > spelled out in RFC 3578. >=20 > The problem is non-compliance. Some, er, people seem to think "the > standard says do A, but since I don't use A at the moment - I won't > bother." >=20 > >RFC3578 defined EMSK is mandatory,=20 >=20 > And that should be the end of discussion. >=20 > > but it is not used at all.=20 >=20 > First - do you know all the applications that use key-generating EAP > methods? But really - who cares?=20 >=20 > >If EMSK must be used, it is mandatory. if no, I think,=20 > >it may be better that it is optional. >=20 > VERY strongly disagree. Mandatory is what is explicitly specified as > mandatory, period. Otherwise many would implement just those pieces and > features of the standard that his particular product needs today. >=20 > (I'm proud of my restraint - not even once using a term "B*S*" :-) > _______________________________________________ > Hokeyp mailing list > Hokeyp@opendiameter.org > http://www.opendiameter.org/mailman/listinfo/hokeyp >=20 _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Sat Nov 18 18:26:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlZZB-0001Ix-PO; Sat, 18 Nov 2006 18:25:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl4bs-0005TO-G2 for emu@ietf.org; Fri, 17 Nov 2006 09:22:28 -0500 Received: from mga02.intel.com ([134.134.136.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gl4bq-0002r7-R3 for emu@ietf.org; Fri, 17 Nov 2006 09:22:28 -0500 Received: from orsmga001.jf.intel.com ([10.7.209.18]) by mga02.intel.com with ESMTP; 17 Nov 2006 06:22:26 -0800 Received: from fmsmsx333.amr.corp.intel.com ([132.233.42.2]) by orsmga001.jf.intel.com with ESMTP; 17 Nov 2006 06:22:26 -0800 X-ExtLoop1: 1 X-IronPort-AV: i="4.09,435,1157353200"; d="scan'208"; a="163062775:sNHT23983743" Received: from hdsmsx412.amr.corp.intel.com ([10.127.2.72]) by fmsmsx333.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Nov 2006 06:22:17 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Hokeyp] [Emu] Re: MSK but no EMSK Date: Fri, 17 Nov 2006 09:22:04 -0500 Message-ID: <279DDDAFA85EC74C9300A0598E704056F915FE@hdsmsx412.amr.corp.intel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Hokeyp] [Emu] Re: MSK but no EMSK thread-index: AccJzklxPwF5M9khTom054JMBfhApwAFuvawAAOTFmAAAIoXQAAWFnow From: "Blumenthal, Uri" To: , X-OriginalArrivalTime: 17 Nov 2006 14:22:17.0852 (UTC) FILETIME=[C942F3C0:01C70A53] X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 X-Mailman-Approved-At: Sat, 18 Nov 2006 18:25:43 -0500 Cc: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org >The discussion focuses on the problem EMSK is optional or mandatory. I don't think this is a problem - GENERATION of EMSK is compulsoty as spelled out in RFC 3578. The problem is non-compliance. Some, er, people seem to think "the standard says do A, but since I don't use A at the moment - I won't bother." >RFC3578 defined EMSK is mandatory,=20 And that should be the end of discussion. > but it is not used at all.=20 First - do you know all the applications that use key-generating EAP methods? But really - who cares?=20 >If EMSK must be used, it is mandatory. if no, I think,=20 >it may be better that it is optional. VERY strongly disagree. Mandatory is what is explicitly specified as mandatory, period. Otherwise many would implement just those pieces and features of the standard that his particular product needs today. (I'm proud of my restraint - not even once using a term "B*S*" :-) _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Sat Nov 18 18:26:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlZZB-0001IJ-9h; Sat, 18 Nov 2006 18:25:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gktvb-0003bM-1X for emu@ietf.org; Thu, 16 Nov 2006 21:58:07 -0500 Received: from mga01.intel.com ([192.55.52.88]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GktvV-0000OG-Ss for emu@ietf.org; Thu, 16 Nov 2006 21:58:07 -0500 Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by mga01.intel.com with ESMTP; 16 NFrom emu-bounces@ietf.org Sat Nov 18 18:26:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlZZB-0001Ix-PO; Sat, 18 Nov 2006 18:25:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl4bs-0005TO-G2 for emu@ietf.org; Fri, 17 Nov 2006 09:22:28 -0500 Received: from mga02.intel.com ([134.134.136.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gl4bq-0002r7-R3 for emu@ietf.org; Fri, 17 Nov 2006 09:22:28 -0500 Received: from orsmga001.jf.intel.com ([10.7.209.18]) by mga02.intel.com with ESMTP; 17 Nov 2006 06:22:26 -0800 Received: from fmsmsx333.amr.corp.intel.com ([132.233.42.2]) by orsmga001.jf.intel.com with ESMTP; 17 Nov 2006 06:22:26 -0800 X-ExtLoop1: 1 X-IronPort-AV: i="4.09,435,1157353200"; d="scan'208"; a="163062775:sNHT23983743" Received: from hdsmsx412.amr.corp.intel.com ([10.127.2.72]) by fmsmsx333.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Nov 2006 06:22:17 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Hokeyp] [Emu] Re: MSK but no EMSK Date: Fri, 17 Nov 2006 09:22:04 -0500 Message-ID: <279DDDAFA85EC74C9300A0598E704056F915FE@hdsmsx412.amr.corp.intel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Hokeyp] [Emu] Re: MSK but no EMSK thread-index: AccJzklxPwF5M9khTom054JMBfhApwAFuvawAAOTFmAAAIoXQAAWFnow From: "Blumenthal, Uri" To: , X-OriginalArrivalTime: 17 Nov 2006 14:22:17.0852 (UTC) FILETIME=[C942F3C0:01C70A53] X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 X-Mailman-Approved-At: Sat, 18 Nov 2006 18:25:43 -0500 Cc: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org >The discussion focuses on the problem EMSK is optional or mandatory. I don't think this is a problem - GENERATION of EMSK is compulsoty as spelled out in RFC 3578. The problem is non-compliance. Some, er, people seem to think "the standard says do A, but since I don't use A at the moment - I won't bother." >RFC3578 defined EMSK is mandatory,=20 And that should be the end of discussion. > but it is not used at all.=20 First - do you know all the applications that use key-generating EAP methods? But really - who cares?=20 >If EMSK must be used, it is mandatory. if no, I think,=20 >it may be better that it is optional. VERY strongly disagree. Mandatory is what is explicitly specified as mandatory, period. Otherwise many would implement just those pieces and features of the standard that his particular product needs today. (I'm proud of my restraint - not even once using a term "B*S*" :-) _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Sat Nov 18 18:26:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlZZB-0001IJ-9h; Sat, 18 Nov 2006 18:25:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gktvb-0003bM-1X for emu@ietf.org; Thu, 16 Nov 2006 21:58:07 -0500 Received: from mga01.intel.com ([192.55.52.88]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GktvV-0000OG-Ss for emu@ietf.org; Thu, 16 Nov 2006 21:58:07 -0500 Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by mga01.intel.com with ESMTP; 16 Nov 2006 18:58:01 -0800 Received: from fmsmsx334.amr.corp.intel.com ([132.233.42.1]) by fmsmga001.fm.intel.com with ESMTP; 16 Nov 2006 18:57:57 -0800 X-ExtLoop1: 1 X-IronPort-AV: i="4.09,431,1157353200"; d="scan'208"; a="165222249:sNHT32163817" Received: from hdsmsx412.amr.corp.intel.com ([10.127.2.72]) by fmsmsx334.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Nov 2006 18:57:57 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Hokeyp] [Emu] Re: MSK but no EMSK Date: Thu, 16 Nov 2006 21:57:45 -0500 Message-ID: <279DDDAFA85EC74C9300A0598E704056F91552@hdsmsx412.amr.corp.intel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Hokeyp] [Emu] Re: MSK but no EMSK thread-index: AccJzklxPwF5M9khTom054JMBfhApwAFuvawAAOTFmA= From: "Blumenthal, Uri" To: , X-OriginalArrivalTime: 17 Nov 2006 02:57:57.0463 (UTC) FILETIME=[2F5CCE70:01C709F4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa X-Mailman-Approved-At: Sat, 18 Nov 2006 18:25:43 -0500 Cc: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org I happen to agree with Vidya on this. It is not optional for new EAP methods to produce EMSK. Whether EMSK gets used or not is totally besides the point. (If we can conceive that EMSK would serve a need in some distant future - we have to enforce its generation now. And it is required by RFC 3748 :-) What to do with the existing _old_ methods that aren't compliant - I leave it for the group to decide. -----Original Message----- From: hokeyp-bounces@opendiameter.org [mailto:hokeyp-bounces@opendiameter.org] On Behalf Of Narayanan, Vidya Sent: Thursday, November 16, 2006 9:35 PM To: Bernard Aboba; hokeyp@opendiameter.org; emu@ietf.org Subject: Re: [Hokeyp] [Emu] Re: MSK but no EMSK >=20 > It's worth keeping in mind that there are very few existing=20 > RFC 3748-compliant EAP implementations. So most existing EAP=20 > method implementations do not generate an EMSK, and most=20 > existing EAP implementations would not do anything with the=20 > EMSK if it were to be generated. >=20 Well, the question is this - is the requirement to interoperate with existing standards or existing implementations? Given that we have a spec that says what it does, it seems to make sense to interoperate with that. If we are going by existing implementations, there is probably more than one flavor and then there is the question of when the MSK is directly delivered to the authenticator and when it isn't and how the peer knows that.=20 In this case, I tend to agree with Charles that it is better to have to fix non-compliant implementations than try to design around them. Also, if we choose to ignore the standard and use the implementations that don't produce an EMSK as a data point, the standard doesn't seem to be serving a purpose then - perhaps, we should then consider revising RFC3748 to reflect what we want to use as a starting point for requirements?=20 Vidya _______________________________________________ Hokeyp mailing list Hokeyp@opendiameter.org http://www.opendiameter.org/mailman/listinfo/hokeyp _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu ov 2006 18:58:01 -0800 Received: from fmsmsx334.amr.corp.intel.com ([132.233.42.1]) by fmsmga001.fm.intel.com with ESMTP; 16 Nov 2006 18:57:57 -0800 X-ExtLoop1: 1 X-IronPort-AV: i="4.09,431,1157353200"; d="scan'208"; a="165222249:sNHT32163817" Received: from hdsmsx412.amr.corp.intel.com ([10.127.2.72]) by fmsmsx334.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Nov 2006 18:57:57 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Hokeyp] [Emu] Re: MSK but no EMSK Date: Thu, 16 Nov 2006 21:57:45 -0500 Message-ID: <279DDDAFA85EC74C9300A0598E704056F91552@hdsmsx412.amr.corp.intel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Hokeyp] [Emu] Re: MSK but no EMSK thread-index: AccJzklxPwF5M9khTom054JMBfhApwAFuvawAAOTFmA= From: "Blumenthal, Uri" To: , X-OriginalArrivalTime: 17 Nov 2006 02:57:57.0463 (UTC) FILETIME=[2F5CCE70:01C709F4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa X-Mailman-Approved-At: Sat, 18 Nov 2006 18:25:43 -0500 Cc: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org I happen to agree with Vidya on this. It is not optional for new EAP methods to produce EMSK. Whether EMSK gets used or not is totally besides the point. (If we can conceive that EMSK would serve a need in some distant future - we have to enforce its generation now. And it is required by RFC 3748 :-) What to do with the existing _old_ methods that aren't compliant - I leave it for the group to decide. -----Original Message----- From: hokeyp-bounces@opendiameter.org [mailto:hokeyp-bounces@opendiameter.org] On Behalf Of Narayanan, Vidya Sent: Thursday, November 16, 2006 9:35 PM To: Bernard Aboba; hokeyp@opendiameter.org; emu@ietf.org Subject: Re: [Hokeyp] [Emu] Re: MSK but no EMSK >=20 > It's worth keeping in mind that there are very few existing=20 > RFC 3748-compliant EAP implementations. So most existing EAP=20 > method implementations do not generate an EMSK, and most=20 > existing EAP implementations would not do anything with the=20 > EMSK if it were to be generated. >=20 Well, the question is this - is the requirement to interoperate with existing standards or existing implementations? Given that we have a spec that says what it does, it seems to make sense to interoperate with that. If we are going by existing implementations, there is probably more than one flavor and then there is the question of when the MSK is directly delivered to the authenticator and when it isn't and how the peer knows that.=20 In this case, I tend to agree with Charles that it is better to have to fix non-compliant implementations than try to design around them. Also, if we choose to ignore the standard and use the implementations that don't produce an EMSK as a data point, the standard doesn't seem to be serving a purpose then - perhaps, we should then consider revising RFC3748 to reflect what we want to use as a starting point for requirements?=20 Vidya _______________________________________________ Hokeyp mailing list Hokeyp@opendiameter.org http://www.opendiameter.org/mailman/listinfo/hokeyp _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Sat Nov 18 18:26:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlZZB-0001I9-2u; Sat, 18 Nov 2006 18:25:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gkd7g-0006Hq-Ui for emu@ietf.org; Thu, 16 Nov 2006 04:01:28 -0500 Received: from mout.perfora.net ([217.160.230.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gkd7d-0007eR-N6 for emu@ietf.org; Thu, 16 Nov 2006 04:01:28 -0500 Received: from [85.101.22.228] (helo=IBM52A5038A94F) by mrelay.perfora.net (node=mrelayus0) with ESMTP (Nemesis), id 0MKoyl-1Gkd7Y1I0a-00041D; Thu, 16 Nov 2006 04:01:23 -0500 From: "Alper Yegin" To: Date: Thu, 16 Nov 2006 11:01:15 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AccJXcWlB6da8ib5Txi4GIlDHG8X3Q== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Message-ID: <0MKoyl-1Gkd7Y1I0a-00041D@mrelay.perfora.net> X-Provags-ID: perfora.net abuse@perfora.net login:abf7a4bb310ea4dfc9b6841113e2970f X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c X-Mailman-Approved-At: Sat, 18 Nov 2006 18:25:43 -0500 Cc: emu@ietf.org Subject: [Emu] MSK but no EMSK X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org I remember someone in Hokey WG meeting mentioned that not all methods generate EMSK (even though they generate MSK). Is that accurate? Despite this RFC 3748 text? In order to provide keying material for use in a subsequently negotiated ciphersuite, an EAP method supporting key derivation MUST export a Master Session Key (MSK) of at least 64 octets, and an Extended Master Session Key (EMSK) of at least 64 octets. Alper _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Sat Nov 18 18:26:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlZZB-0001Id-DV; Sat, 18 Nov 2006 18:25:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gkuls-0002MC-UF for emu@ietf.org; Thu, 16 Nov 2006 22:52:08 -0500 Received: from szxga01-in.huawei.com ([61.144.161.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gkulq-0006Vz-NX for emu@ietf.org; Thu, 16 Nov 2006 22:52:08 -0500 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J8U00J7YVQDM1@szxga01-in.huawei.com> for emu@ietf.org; Fri, 17 Nov 2006 11:44:37 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J8U00EYBVQC7B@szxga01-in.huawei.com> for emu@ietf.org; Fri, 17 Nov 2006 11:44:37 +0800 (CST) Received: from y52774 ([10.164.5.64]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J8U00IAVVQ9LM@szxml03-in.huawei.com> for emu@ietf.org; Fri, 17 Nov 2006 11:44:36 +0800 (CST) Date: Fri, 17 Nov 2006 11:44:33 +0800 From: Michael Ye Subject: RE: [Hokeyp] [Emu] Re: MSK but no EMSK In-reply-to: <279DDDAFA85EC74C9300A0598E704056F91552@hdsmsx412.amr.corp.intel.com> To: "'Blumenthal, Uri'" , hokeyp@opendiameter.org, emu@ietf.org Message-id: <001101c709fa$b226cdf0$4005a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AccJzklxPwF5M9khTom054JMBfhApwAFuvawAAOTFmAAAIoXQA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 X-Mailman-Approved-At: Sat, 18 Nov 2006 18:25:43 -0500 Cc: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org The discussion focuses on the problem EMSK is optional or mandatory. RFC3578 defined EMSK is mandatory, but it is not used at all. If EMSK must be used, it is mandatory . if no, I think, it may be better that it is optional. If EMSK is necessary for some "applications" in the future, we may still use it by option. If RFC3578 don't be taken into account , I prefer to that it is optional. Michael > -----Original Message----- > From: hokeyp-bounces@opendiameter.org > [mailto:hokeyp-bounces@opendiameter.org] On Behalf Of Blumenthal, Uri > Sent: Friday, November 17, 2006 10:58 AM > To: hokeyp@opendiameter.org; emu@ietf.org > Subject: Re: [Hokeyp] [Emu] Re: MSK but no EMSK > > I happen to agree with Vidya on this. > > It is not optional for new EAP methods to produce EMSK. > Whether EMSK gets used or not is totally besides the point. > (If we can conceive that EMSK would serve a need in some > distant future - we have to enforce its generation now. And > it is required by RFC 3748 :-) > > What to do with the existing _old_ methods that aren't > compliant - I leave it for the group to decide. > > -----Original Message----- > From: hokeyp-bounces@opendiameter.org > [mailto:hokeyp-bounces@opendiameter.org] On Behalf Of Narayanan, Vidya > Sent: Thursday, November 16, 2006 9:35 PM > To: Bernard Aboba; hokeyp@opendiameter.org; emu@ietf.org > Subject: Re: [Hokeyp] [Emu] Re: MSK but no EMSK > > > > > It's worth keeping in mind that there are very few existing RFC > > 3748-compliant EAP implementations. So most existing EAP method > > implementations do not generate an EMSK, and most existing EAP > > implementations would not do anything with the EMSK if it > were to be > > generated. > > > > Well, the question is this - is the requirement to > interoperate with existing standards or existing > implementations? Given that we have a spec that says what it > does, it seems to make sense to interoperate with that. If we > are going by existing implementations, there is probably more > than one flavor and then there is the question of when the > MSK is directly delivered to the authenticator and when it > isn't and how the peer knows that. > > In this case, I tend to agree with Charles that it is better > to have to fix non-compliant implementations than try to > design around them. Also, if we choose to ignore the standard > and use the implementations that don't produce an EMSK as a > data point, the standard doesn't seem to be serving a purpose > then - perhaps, we should then consider revising > RFC3748 to reflect what we want to use as a starting point > for requirements? > > Vidya > _______________________________________________ > Hokeyp mailing list > Hokeyp@opendiameter.org > http://www.opendiameter.org/mailman/listinfo/hokeyp > _______________________________________________ > Hokeyp mailing list > Hokeyp@opendiameter.org > http://www.opendiameter.org/mailman/listinfo/hokeyp > _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Sat Nov 18 18:26:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlZZB-0001IE-6L; Sat, 18 Nov 2006 18:25:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GksGH-0003zm-Pt for emu@ietf.org; Thu, 16 Nov 2006 20:11:21 -0500 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GksG7-0002vP-79 for emu@ietf.org; Thu, 16 Nov 2006 20:11:21 -0500 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J8U0064YOCJ7Q@szxga02-in.huawei.com> for emu@ietf.org; Fri, 17 Nov 2006 09:05:07 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J8U008OFOCIRL@szxga02-in.huawei.com> for emu@ietf.org; Fri, 17 Nov 2006 09:05:07 +0800 (CST) Received: from y52774 ([10.164.5.64]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J8U00FGKOCFVP@szxml04-in.huawei.com> for emu@ietf.org; Fri, 17 Nov 2006 09:05:06 +0800 (CST) Date: Fri, 17 Nov 2006 09:05:12 +0800 From: Michael Ye Subject: RE: [Hokeyp] [Emu] Re: MSK but no EMSK In-reply-to: <20061116225709.GF5961@steelhead> To: 'Yoshihiro Ohba' , 'Lakshminath Dondeti' Message-id: <000401c709e4$6f726570$4005a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AccJ0t5CUCAJasQMQgab0M824PuFcgAERuwg X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 X-Mailman-Approved-At: Sat, 18 Nov 2006 18:25:43 -0500 Cc: hokeyp@opendiameter.org, 'Alper Yegin' , emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org I don't understand why was a unused key defined in advance ? Michael > -----Original Message----- > From: hokeyp-bounces@opendiameter.org > [mailto:hokeyp-bounces@opendiameter.org] On Behalf Of Yoshihiro Ohba > Sent: Friday, November 17, 2006 6:57 AM > To: Lakshminath Dondeti > Cc: Yoshihiro Ohba; Alper Yegin; hokeyp@opendiameter.org; emu@ietf.org > Subject: Re: [Hokeyp] [Emu] Re: MSK but no EMSK > > On Thu, Nov 16, 2006 at 10:54:20AM -0800, Lakshminath Dondeti wrote: > > At 10:30 AM 11/16/2006, Yoshihiro Ohba wrote: > > >Hi Lakshminath, > > > > > >RFC 3748 says: > > > > > >" > > > Extended Master Session Key (EMSK) > > > Additional keying material derived between the EAP client and > > > server that is exported by the EAP method. The EMSK > is at least > > > 64 octets in length. The EMSK is not shared with the > > > authenticator or any other third party. The EMSK is > reserved for > > > future uses that are not defined yet. > > >" > > > > > >Since EMSK usage is not defined yet, the use of EMSK is virtually > > >optional at this momement. Since it was not mandated in the > > >beginning, it is not possible to change it mandatory for a > particular > > >use in a future without loss of interoperability with the existing > > >deployment. > > > > I read it differently. The EMSK is reserved for future > uses. It is > > of course mandatory to derive the EMSK, but the use of it is simply > > not defined. It is not optional to use. It is not > mandatory either, > > it simply is unused. When the EMSK is defined for a specific use > > case, then the question of whether the use is optional, > recommended or > > mandatory comes up. > > I agree that this is more precise reading. However, even > after defining a usage of EMSK, it is difficult to assume > that all peers and servers will always support the usage of > EMSK unless we can upgrade the existing EAP implementations > which do not use EMSK to the new ones *at one time*. Thus, > as a proactive answer to the question, I don't really believe > that a specific use of EMSK can be mandated without breaking > interoperability with existing EAP implementations. > > Yoshihiro Ohba > > > > > > Lakshminath > > > > > > >Am I missing something? > > > > > >Yoshihiro Ohba > > > > > > > > >On Thu, Nov 16, 2006 at 09:38:10AM -0800, Lakshminath > Dondeti wrote: > > >> At 06:27 AM 11/16/2006, Yoshihiro Ohba wrote: > > >> >I made one comment around this in the HOKEY session. > The intent > > >> >of my comment was that use of EMSK is optional. > > >> > > >> Hi Yoshi, > > >> > > >> Which document says that the "use" of EMSK is optional? > > >> > > >> >There would be an > > >> >interoperability issue if peer and server do not > negotiate on the > > >> >use of EMSK before actually using it. > > >> > > >> The interoperability issue would only come up if there is > > >ambiguity or options. > > >> > > >> Lakshminath > > >> > > >> > > >> >Yoshihiro Ohba > > >> > > > >> > > > >> >On Thu, Nov 16, 2006 at 11:01:15AM +0200, Alper Yegin wrote: > > >> > > > > >> > > I remember someone in Hokey WG meeting mentioned > that not all > > >> > > methods generate EMSK (even though they generate > MSK). Is that accurate? > > >> > > > > >> > > Despite this RFC 3748 text? > > >> > > > > >> > > In order to provide keying material for use in a > > >> > > subsequently negotiated ciphersuite, an EAP > method supporting key > > >> > > derivation MUST export a Master Session Key (MSK) > of at least 64 > > >> > > octets, and an Extended Master Session Key (EMSK) > of at least 64 > > >> > > octets. > > >> > > > > >> > > Alper > > >> > > > > >> > > > > >> > > _______________________________________________ > > >> > > Hokeyp mailing list > > >> > > Hokeyp@opendiameter.org > > >> > > http://www.opendiameter.org/mailman/listinfo/hokeyp > > >> > > > > >> > > > >> >_______________________________________________ > > >> >Emu mailing list > > >> >Emu@ietf.org > > >> >https://www1.ietf.org/mailman/listinfo/emu > > >> > > >> _______________________________________________ > > >> Hokeyp mailing list > > >> Hokeyp@opendiameter.org > > >> http://www.opendiameter.org/mailman/listinfo/hokeyp > > >> > > >_______________________________________________ > > >Hokeyp mailing list > > >Hokeyp@opendiameter.org > > >http://www.opendiameter.org/mailman/listinfo/hokeyp > > > > > _______________________________________________ > Hokeyp mailing list > Hokeyp@opendiameter.org > http://www.opendiameter.org/mailman/listinfo/hokeyp > _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Sat Nov 18 18:26:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlZZB-0001Id-DV; Sat, 18 Nov 2006 18:25:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gkuls-0002MC-UF for emu@ietf.org; Thu, 16 Nov 2006 22:52:08 -0500 Received: from szxga01-in.huawei.com ([61.144.161.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gkulq-0006Vz-NX for emu@ietf.org; Thu, 16 Nov 2006 22:52:08 -0500 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J8U00J7YVQDM1@szxga01-in.huawei.com> for emu@ietf.org; Fri, 17 Nov 2006 11:44:37 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J8U00EYBVQC7B@szxga01-in.huawei.com> for emu@ietf.org; Fri, 17 Nov 2006 11:44:37 +0800 (CST) Received: from y52774 ([10.164.5.64]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J8U00IAVVQ9LM@szxml03-in.huawei.com> for emu@ietf.org; Fri, 17 Nov 2006 11:44:36 +0800 (CST) Date: Fri, 17 Nov 2006 11:44:33 +0800 From: Michael Ye Subject: RE: [Hokeyp] [Emu] Re: MSK but no EMSK In-reply-to: <279DDDAFA85EC74C9300A0598E704056F91552@hdsmsx412.amr.corp.intel.com> To: "'Blumenthal, Uri'" , hokeyp@opendiameter.org, emu@ietf.org Message-id: <001101c709fa$b226cdf0$4005a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AccJzklxPwF5M9khTom054JMBfhApwAFuvawAAOTFmAAAIoXQA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 X-Mailman-Approved-At: Sat, 18 Nov 2006 18:25:43 -0500 Cc: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org The discussion focuses on the problem EMSK is optional or mandatory. RFC3578 defined EMSK is mandatory, but it is not used at all. If EMSK must be used, it is mandatory . if no, I think, it may be better that it is optional. If EMSK is necessary for some "applications" in the future, we may still use it by option. If RFC3578 don't be taken into account , I prefer to that it is optional. Michael > -----Original Message----- > From: hokeyp-bounces@opendiameter.org > [mailto:hokeyp-bounces@opendiameter.org] On Behalf Of Blumenthal, Uri > Sent: Friday, November 17, 2006 10:58 AM > To: hokeyp@opendiameter.org; emu@ietf.org > Subject: Re: [Hokeyp] [Emu] Re: MSK but no EMSK > > I happen to agree with Vidya on this. > > It is not optional for new EAP methods to produce EMSK. > Whether EMSK gets used or not is totally besides the point. > (If we can conceive that EMSK would serve a need in some > distant future - we have to enforce its generation now. And > it is required by RFC 3748 :-) > > What to do with the existing _old_ methods that aren't > compliant - I leave it for the group to decide. > > -----Original Message----- > From: hokeyp-bounces@opendiameter.org > [mailto:hokeyp-bounces@opendiameter.org] On Behalf Of Narayanan, Vidya > Sent: Thursday, November 16, 2006 9:35 PM > To: Bernard Aboba; hokeyp@opendiameter.org; emu@ietf.org > Subject: Re: [Hokeyp] [Emu] Re: MSK but no EMSK > > > > > It's worth keeping in mind that there are very few existing RFC > > 3748-compliant EAP implementations. So most existing EAP method > > implementations do not generate an EMSK, and most existing EAP > > implementations would not do anything with the EMSK if it > were to be > > generated. > > > > Well, the question is this - is the requirement to > interoperate with existing standards or existing > implementations? Given that we have a spec that says what it > does, it seems to make sense to interoperate with that. If we > are going by existing implementations, there is probably more > than one flavor and then there is the question of when the > MSK is directly delivered to the authenticator and when it > isn't and how the peer knows that. > > In this case, I tend to agree with Charles that it is better > to have to fix non-compliant implementations than try to > design around them. Also, if we choose to ignore the standard > and use the implementations that don't produce an EMSK as a > data point, the standard doesn't seem to be serving a purpose > then - perhaps, we should then consider revising > RFC3748 to reflect what we want to use as a starting point > for requirements? > > Vidya > _______________________________________________ > Hokeyp mailing list > Hokeyp@opendiameter.org > http://www.opendiameter.org/mailman/listinfo/hokeyp > _______________________________________________ > Hokeyp mailing list > Hokeyp@opendiameter.org > http://www.opendiameter.org/mailman/listinfo/hokeyp > _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Sat Nov 18 18:26:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlZZB-0001IE-6L; Sat, 18 Nov 2006 18:25:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GksGH-0003zm-Pt for emu@ietf.org; Thu, 16 Nov 2006 20:11:21 -0500 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GksG7-0002vP-79 for emu@ietf.org; Thu, 16 Nov 2006 20:11:21 -0500 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J8U0064YOCJ7Q@szxga02-in.huawei.com> for emu@ietf.org; Fri, 17 Nov 2006 09:05:07 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J8U008OFOCIRL@szxga02-in.huawei.com> for emu@ietf.org; Fri, 17 Nov 2006 09:05:07 +0800 (CST) Received: from y52774 ([10.164.5.64]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J8U00FGKOCFVP@szxml04-in.huawei.com> for emu@ietf.org; Fri, 17 Nov 2006 09:05:06 +0800 (CST) Date: Fri, 17 Nov 2006 09:05:12 +0800 From: Michael Ye Subject: RE: [Hokeyp] [Emu] Re: MSK but no EMSK In-reply-to: <20061116225709.GF5961@steelhead> To: 'Yoshihiro Ohba' , 'Lakshminath Dondeti' Message-id: <000401c709e4$6f726570$4005a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AccJ0t5CUCAJasQMQgab0M824PuFcgAERuwg X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 X-Mailman-Approved-At: Sat, 18 Nov 2006 18:25:43 -0500 Cc: hokeyp@opendiameter.org, 'Alper Yegin' , emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org I don't understand why was a unused key defined in advance ? Michael > -----Original Message----- > From: hokeyp-bounces@opendiameter.org > [mailto:hokeyp-bounces@opendiameter.org] On Behalf Of Yoshihiro Ohba > Sent: Friday, November 17, 2006 6:57 AM > To: Lakshminath Dondeti > Cc: Yoshihiro Ohba; Alper Yegin; hokeyp@opendiameter.org; emu@ietf.org > Subject: Re: [Hokeyp] [Emu] Re: MSK but no EMSK > > On Thu, Nov 16, 2006 at 10:54:20AM -0800, Lakshminath Dondeti wrote: > > At 10:30 AM 11/16/2006, Yoshihiro Ohba wrote: > > >Hi Lakshminath, > > > > > >RFC 3748 says: > > > > > >" > > > Extended Master Session Key (EMSK) > > > Additional keying material derived between the EAP client and > > > server that is exported by the EAP method. The EMSK > is at least > > > 64 octets in length. The EMSK is not shared with the > > > authenticator or any other third party. The EMSK is > reserved for > > > future uses that are not defined yet. > > >" > > > > > >Since EMSK usage is not defined yet, the use of EMSK is virtually > > >optional at this momement. Since it was not mandated in the > > >beginning, it is not possible to change it mandatory for a > particular > > >use in a future without loss of interoperability with the existing > > >deployment. > > > > I read it differently. The EMSK is reserved for future > uses. It is > > of course mandatory to derive the EMSK, but the use of it is simply > > not defined. It is not optional to use. It is not > mandatory either, > > it simply is unused. When the EMSK is defined for a specific use > > case, then the question of whether the use is optional, > recommended or > > mandatory comes up. > > I agree that this is more precise reading. However, even > after defining a usage of EMSK, it is difficult to assume > that all peers and servers will always support the usage of > EMSK unless we can upgrade the existing EAP implementations > which do not use EMSK to the new ones *at one time*. Thus, > as a proactive answer to the question, I don't really believe > that a specific use of EMSK can be mandated without breaking > interoperability with existing EAP implementations. > > Yoshihiro Ohba > > > > > > Lakshminath > > > > > > >Am I missing something? > > > > > >Yoshihiro Ohba > > > > > > > > >On Thu, Nov 16, 2006 at 09:38:10AM -0800, Lakshminath > Dondeti wrote: > > >> At 06:27 AM 11/16/2006, Yoshihiro Ohba wrote: > > >> >I made one comment around this in the HOKEY session. > The intent > > >> >of my comment was that use of EMSK is optional. > > >> > > >> Hi Yoshi, > > >> > > >> Which document says that the "use" of EMSK is optional? > > >> > > >> >There would be an > > >> >interoperability issue if peer and server do not > negotiate on the > > >> >use of EMSK before actually using it. > > >> > > >> The interoperability issue would only come up if there is > > >ambiguity or options. > > >> > > >> Lakshminath > > >> > > >> > > >> >Yoshihiro Ohba > > >> > > > >> > > > >> >On Thu, Nov 16, 2006 at 11:01:15AM +0200, Alper Yegin wrote: > > >> > > > > >> > > I remember someone in Hokey WG meeting mentioned > that not all > > >> > > methods generate EMSK (even though they generate > MSK). Is that accurate? > > >> > > > > >> > > Despite this RFC 3748 text? > > >> > > > > >> > > In order to provide keying material for use in a > > >> > > subsequently negotiated ciphersuite, an EAP > method supporting key > > >> > > derivation MUST export a Master Session Key (MSK) > of at least 64 > > >> > > octets, and an Extended Master Session Key (EMSK) > of at least 64 > > >> > > octets. > > >> > > > > >> > > Alper > > >> > > > > >> > > > > >> > > _______________________________________________ > > >> > > Hokeyp mailing list > > >> > > Hokeyp@opendiameter.org > > >> > > http://www.opendiameter.org/mailman/listinfo/hokeyp > > >> > > > > >> > > > >> >_______________________________________________ > > >> >Emu mailing list > > >> >Emu@ietf.org > > >> >https://www1.ietf.org/mailman/listinfo/emu > > >> > > >> _______________________________________________ > > >> Hokeyp mailing list > > >> Hokeyp@opendiameter.org > > >> http://www.opendiameter.org/mailman/listinfo/hokeyp > > >> > > >_______________________________________________ > > >Hokeyp mailing list > > >Hokeyp@opendiameter.org > > >http://www.opendiameter.org/mailman/listinfo/hokeyp > > > > > _______________________________________________ > Hokeyp mailing list > Hokeyp@opendiameter.org > http://www.opendiameter.org/mailman/listinfo/hokeyp > _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Sun Nov 19 13:44:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Glreb-0003w1-PU; Sun, 19 Nov 2006 13:44:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Glrea-0003vw-QU for emu@ietf.org; Sun, 19 Nov 2006 13:44:33 -0500 Received: from bay0-omc3-s30.bay0.hotmail.com ([65.54.246.230]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GlreY-0003nf-VZ for emu@ietf.org; Sun, 19 Nov 2006 13:44:32 -0500 Received: from hotmail.com ([207.46.8.102]) by bay0-omc3-s30.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 19 Nov 2006 10:44:30 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 19 Nov 2006 10:44:30 -0800 Message-ID: Received: from 207.46.8.123 by by117fd.bay117.hotmail.msn.com with HTTP; Sun, 19 Nov 2006 18:44:25 GMT X-Originating-IP: [71.222.85.189] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: <0MKoyl-1Gkd7Y1I0a-00041D@mrelay.perfora.net> From: "Bernard Aboba" To: alper.yegin@yegin.org, hokeyp@opendiameter.org Bcc: Subject: RE: [Emu] MSK but no EMSK Date: Sun, 19 Nov 2006 10:44:25 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 19 Nov 2006 18:44:30.0275 (UTC) FILETIME=[BF57B130:01C70C0A] X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org >I remember someone in Hokey WG meeting mentioned that not all methods >generate EMSK (even though they generate MSK). Is that accurate? The simple answer is "we don't know" because prior to RFC 3748, EAP Type Codes could be allocated without a specification. However, for methods published as RFCs or in the RFC Editor Queue, we know the following: a) None of the RFC 3748-specified EAP methods generate keys (EAP MD5, OTP, GTC). b) All of the key generating EAP methods published as RFCs specify how to derive the MSK and EMSK. This includes EAP TLS (RFC 2716), EAP SIM (RFC 4186), and EAP AKA (RFC 4817). The generation of the Session-Id, Peer-Id and Server-Id is also specified for these methods in the Key Management Framework document. c) All of the key generating EAP methods currently in the RFC Editor queue specify how to derive both the MSK and EMSK. This includes EAP PSK (draft-bersani-eap-psk-11.txt), EAP SAKE (draft-vanderveen-eap-sake-02.txt), EAP PAX (draft-clancy-eap-pax-11.txt), EAP POTP (draft-nystrom-eap-potp-07.txt). None of these methods specify how to derive the Peer-Id, Server-Id and Session-Id (e.g. they are non-compliant with the EAP Key Management Framework). d) Allocation of an EAP Type Code requires specification of the MSK, EMSK, and Session-Id and Peer-Id/Server-Id if known. _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Mon Nov 20 00:23:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gm1d3-0001PG-Av; Mon, 20 Nov 2006 00:23:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlzBg-0003bD-9W for emu@ietf.org; Sun, 19 Nov 2006 21:47:12 -0500 Received: from szxga03-in.huawei.com ([61.144.161.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GlzBY-0003OA-Q7 for emu@ietf.org; Sun, 19 Nov 2006 21:47:12 -0500 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J90002R4CVQ5G@szxga03-in.huawei.com> for emu@ietf.org; Mon, 20 Nov 2006 10:43:02 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J9000M00CVPWG@szxga03-in.huawei.com> for emu@ietf.org; Mon, 20 Nov 2006 10:43:02 +0800 (CST) Received: from y52774 ([10.164.5.64]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J900004XCVMGK@szxml04-in.huawei.com> for emu@ietf.org; Mon, 20 Nov 2006 10:43:01 +0800 (CST) Date: Mon, 20 Nov 2006 10:42:58 +0800 From: Michael Ye Subject: RE: [Hokeyp] [Emu] Re: MSK but no EMSK In-reply-to: <279DDDAFA85EC74C9300A0598E704056F915FE@hdsmsx412.amr.corp.intel.com> To: "'Blumenthal, Uri'" , hokeyp@opendiameter.org, emu@ietf.org Message-id: <002501c70c4d$97063510$4005a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AccJzklxPwF5M9khTom054JMBfhApwAFuvawAAOTFmAAAIoXQAAWFnowAH8DyGA= X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 X-Mailman-Approved-At: Mon, 20 Nov 2006 00:23:35 -0500 Cc: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Hi Blumenthal, see below, BR, Michael > -----Original Message----- > From: hokeyp-bounces@opendiameter.org > [mailto:hokeyp-bounces@opendiameter.org] On Behalf Of Blumenthal, Uri > Sent: Friday, November 17, 2006 10:22 PM > To: hokeyp@opendiameter.org; emu@ietf.org > Subject: Re: [Hokeyp] [Emu] Re: MSK but no EMSK > > >The discussion focuses on the problem EMSK is optional or mandatory. > > I don't think this is a problem - GENERATION of EMSK is > compulsoty as spelled out in RFC 3578. Michael=>>Really, people were talking about it. Yes, it is compulsory in RFC3578. > > The problem is non-compliance. Some, er, people seem to think > "the standard says do A, but since I don't use A at the > moment - I won't bother." > > >RFC3578 defined EMSK is mandatory, > > And that should be the end of discussion. Michael=>> I agree. > > > but it is not used at all. > > First - do you know all the applications that use > key-generating EAP methods? But really - who cares? Michael=>> As far as know, it is so. > > >If EMSK must be used, it is mandatory. if no, I think, it > may be better > >that it is optional. > > VERY strongly disagree. Mandatory is what is explicitly > specified as mandatory, period. Otherwise many would > implement just those pieces and features of the standard that > his particular product needs today. Michael=>>Blumenthal, I think, it is discussions'intention that some upcoming solutions become better. people express themselive opinions here, so different opinions are common. > > (I'm proud of my restraint - not even once using a term > "B*S*" :-) _______________________________________________ > Hokeyp mailing list > Hokeyp@opendiameter.org > http://www.opendiameter.org/mailman/listinfo/hokeyp > _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Mon Nov 20 01:21:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gm2XL-0006Kt-Hd; Mon, 20 Nov 2006 01:21:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gm2XK-0006KW-N2 for emu@ietf.org; Mon, 20 Nov 2006 01:21:46 -0500 Received: from bay0-omc2-s9.bay0.hotmail.com ([65.54.246.145]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gm2XJ-0002oe-9y for emu@ietf.org; Mon, 20 Nov 2006 01:21:46 -0500 Received: from hotmail.com ([207.46.8.101]) by bay0-omc2-s9.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 19 Nov 2006 22:20:02 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 19 Nov 2006 22:20:02 -0800 Message-ID: Received: from 207.46.8.123 by by117fd.bay117.hotmail.msn.com with HTTP; Mon, 20 Nov 2006 06:19:57 GMT X-Originating-IP: [67.88.206.98] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com From: "Bernard Aboba" To: emu@ietf.org Bcc: Date: Sun, 19 Nov 2006 22:19:57 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 20 Nov 2006 06:20:02.0669 (UTC) FILETIME=[E9C9A9D0:01C70C6B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Subject: [Emu] Issue: Definition of Session-Id, Peer-Id, Server-Id for EAP GPSK X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org EAP GPSK defines the Method-Id as follows: " o MID = KDF_Zero-String ("Method ID" || EAP_Method_Type || CSuite_Sel || inputString)[0..15]" The inclusion of the EAP_Method_Type doesn't seem quite right, because the Method-Id only needs to be globally and temporally unique for a given EAP method; since Session-Id = Type Code || Method-Id, the Session-Id's are guaranteed not to colide between EAP methods. Note that in this case inputString = 'RAND_Client || ID_Client || RAND_Server || ID_Server' so that the identities are included. I think that this is a good idea since it should guarantee a unique Method-Id even if the same client and server RAND values are chosen by a different (peer, server) set. In reading the document, it would appear that Peer-Id (ID_Client) is authenticated in this protocol, whereas the Server-Id is not (e.g. ID_Server is asserted, but not really authenticated). Therefore, I would suggest addition of some text discussing this. For example: The EAP-GPSK Session-Id is the concatenation of the EAP Type Code (TBD) with the contents of the Method-Id defined in Section X. The Peer-Id is the contents of the ID_Client field. Note that the contents are used as they are transmitted. The Server-Id is an empty string. _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Mon Nov 20 20:54:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmKq0-0002yc-RX; Mon, 20 Nov 2006 20:54:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmKpz-0002yR-Ok for emu@ietf.org; Mon, 20 Nov 2006 20:54:15 -0500 Received: from sccrmhc13.comcast.net ([204.127.200.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmKpy-0001DX-Ik for emu@ietf.org; Mon, 20 Nov 2006 20:54:15 -0500 Received: from [192.168.0.52] (c-68-49-199-146.hsd1.md.comcast.net[68.49.199.146]) by comcast.net (sccrmhc13) with ESMTP id <2006112101541401300b0a5ke>; Tue, 21 Nov 2006 01:54:14 +0000 Message-ID: <45625C46.8060500@cs.umd.edu> Date: Mon, 20 Nov 2006 20:54:14 -0500 From: Charles Clancy User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Bernard Aboba Subject: Re: [Emu] MSK but no EMSK References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: hokeyp@opendiameter.org, alper.yegin@yegin.org, emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org > None of these methods specify how to > derive the Peer-Id, Server-Id and Session-Id (e.g. they are > non-compliant with the EAP Key Management Framework). EAP-PAX does indeed specify the Peer-ID, Server-ID, and Session-ID. Section 2.4 states: The EAP Key Management Framework [I-D.ietf-eap-keying] recommends specification of key names and scope. The EAP-PAX Method-ID is the MID value computed as described above. The EAP peer name is the CID value exchanged in PAX_STD-2 and PAX_SEC-2. The EAP server name is an empty string. -- t. charles clancy, ph.d. | tcc@umd.edu | www.cs.umd.edu/~clancy _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Mon Nov 20 21:01:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmKxO-0006wh-Bm; Mon, 20 Nov 2006 21:01:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmKxO-0006wc-2g for emu@ietf.org; Mon, 20 Nov 2006 21:01:54 -0500 Received: from sccrmhc13.comcast.net ([63.240.77.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmKxM-0002hR-Qw for emu@ietf.org; Mon, 20 Nov 2006 21:01:54 -0500 Received: from [192.168.0.52] (c-68-49-199-146.hsd1.md.comcast.net[68.49.199.146]) by comcast.net (sccrmhc13) with ESMTP id <2006112102015201300asvd2e>; Tue, 21 Nov 2006 02:01:52 +0000 Message-ID: <45625E10.8060405@cs.umd.edu> Date: Mon, 20 Nov 2006 21:01:52 -0500 From: Charles Clancy User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Bernard Aboba Subject: Re: [Emu] Issue: Definition of Session-Id, Peer-Id, Server-Id for EAP GPSK References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Sounds reasonable, but I'm not entirely sure I'd call the ID_Server unauthenticated. It's authenticated in GPSK-3 when the server includes it in the key derivation to compute SK. If the value was changed by an attacker, the authentication would fail. -- t. charles clancy, ph.d. | tcc@umd.edu | www.cs.umd.edu/~clancy Bernard Aboba wrote: > EAP GPSK defines the Method-Id as follows: > > " o MID = KDF_Zero-String ("Method ID" || EAP_Method_Type || > CSuite_Sel || inputString)[0..15]" > > The inclusion of the EAP_Method_Type doesn't seem quite right, because > the Method-Id only needs to be globally and temporally unique for a > given EAP method; since Session-Id = Type Code || Method-Id, the > Session-Id's are guaranteed not to colide between EAP methods. > > Note that in this case inputString = 'RAND_Client || ID_Client || > RAND_Server || ID_Server' so that the identities are included. I think > that this is a good idea since it should guarantee a unique Method-Id > even if the same client and server RAND values are chosen by a different > (peer, server) set. > > In reading the document, it would appear that Peer-Id (ID_Client) is > authenticated in this protocol, whereas the Server-Id is not (e.g. > ID_Server is asserted, but not really authenticated). Therefore, I > would suggest addition of some text discussing this. For example: > > The EAP-GPSK Session-Id is the concatenation of the EAP Type Code (TBD) > with the contents of the Method-Id defined in Section X. > > The Peer-Id is the contents of the ID_Client field. Note that the > contents are used as they > are transmitted. The Server-Id is an empty string. > > > > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www1.ietf.org/mailman/listinfo/emu _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Tue Nov 21 00:34:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmOHD-0000Oa-Gz; Tue, 21 Nov 2006 00:34:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmOHC-0000OV-6S for emu@ietf.org; Tue, 21 Nov 2006 00:34:34 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmOHA-0004B8-RZ for emu@ietf.org; Tue, 21 Nov 2006 00:34:34 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-4.cisco.com with ESMTP; 20 Nov 2006 21:34:32 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id kAL5YVcP004889; Mon, 20 Nov 2006 21:34:31 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kAL5YVin029525; Mon, 20 Nov 2006 21:34:31 -0800 (PST) Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Nov 2006 21:34:31 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Emu] Issue: Definition of Session-Id, Peer-Id, Server-Id for EAP GPSK Date: Mon, 20 Nov 2006 21:34:30 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] Issue: Definition of Session-Id, Peer-Id, Server-Id for EAP GPSK Thread-Index: AccMbCm38rGRwY5wSj+n8HHiFlbiUAAwd4hQ From: "Joseph Salowey \(jsalowey\)" To: "Bernard Aboba" , X-OriginalArrivalTime: 21 Nov 2006 05:34:31.0557 (UTC) FILETIME=[B854CB50:01C70D2E] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2163; t=1164087271; x=1164951271; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20\(jsalowey\)=22=20 |Subject:=20RE=3A=20[Emu]=20Issue=3A=20Definition=20of=20Session-Id, =20Pe er-Id,Server-Id=20for=20EAP=20GPSK |Sender:=20; bh=EQ5lBFnlxmCYk7rXeVAe1WcZ1/LAywJrMzfBJ8fJuVw=; b=HX+nJNWu0xPta5W2OM1q+1TBj5HOXp2dECwZNv04UY3WYDqtmsDg+BVUHpnWnIcyXKVS+TZL 8juIarXVcgB7EDtbfdhsDm/0w+VoD/wLw8NUOMnDFSMrxIWrLJpnRuhf; Authentication-Results: sj-dkim-3; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org =20 > -----Original Message----- > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]=20 > Sent: Sunday, November 19, 2006 10:20 PM > To: emu@ietf.org > Subject: [Emu] Issue: Definition of Session-Id,=20 > Peer-Id,Server-Id for EAP GPSK >=20 > EAP GPSK defines the Method-Id as follows: >=20 > " o MID =3D KDF_Zero-String ("Method ID" || EAP_Method_Type=20 > || CSuite_Sel=20 > || inputString)[0..15]" >=20 > The inclusion of the EAP_Method_Type doesn't seem quite=20 > right, because the Method-Id only needs to be globally and=20 > temporally unique for a given EAP method; since Session-Id =3D=20 > Type Code || Method-Id, the Session-Id's are guaranteed not=20 > to colide between EAP methods. >=20 [Joe] Is there a problem with including the method type? =20 > Note that in this case inputString =3D 'RAND_Client ||=20 > ID_Client || RAND_Server || ID_Server' so that the=20 > identities are included. I think that this is a good idea=20 > since it should guarantee a unique Method-Id even if the same=20 > client and server RAND values are chosen by a different (peer, > server) set. >=20 > In reading the document, it would appear that Peer-Id=20 > (ID_Client) is authenticated in this protocol, whereas the=20 > Server-Id is not (e.g. ID_Server is asserted, but not really=20 > authenticated). Therefore, I would suggest addition of some=20 > text discussing this. For example: >=20 [Joe] It seems that the server ID is as authenticated as the client ID. The server ID and client ID are associated with the shared key. If a different identity is asserted a different key would be selected and the protocol should fail.=20 > The EAP-GPSK Session-Id is the concatenation of the EAP=20 > Type Code (TBD) > with the contents of the Method-Id defined in Section X. >=20 > The Peer-Id is the contents of the ID_Client field. Note=20 > that the contents are used as they > are transmitted. The Server-Id is an empty string. >=20 >=20 >=20 > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www1.ietf.org/mailman/listinfo/emu >=20 _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Tue Nov 21 11:43:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmYiU-00076B-7U; Tue, 21 Nov 2006 11:43:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmYiS-000765-Fo for emu@ietf.org; Tue, 21 Nov 2006 11:43:24 -0500 Received: from usaga01-in.huawei.com ([12.129.211.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmYiK-0001iM-JB for emu@ietf.org; Tue, 21 Nov 2006 11:43:24 -0500 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J9300GC5AFYUM@usaga01-in.huawei.com> for emu@ietf.org; Tue, 21 Nov 2006 08:43:10 -0800 (PST) Received: from N737011 (c-24-17-254-79.hsd1.mn.comcast.net [24.17.254.79]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J9300FDBAFTKP@usaga01-in.huawei.com> for emu@ietf.org; Tue, 21 Nov 2006 08:43:10 -0800 (PST) Date: Tue, 21 Nov 2006 08:43:06 -0800 From: Madjid Nakhjiri Subject: RE: [Hokeyp] [Emu] Re: MSK but no EMSK In-reply-to: <279DDDAFA85EC74C9300A0598E704056F915FE@hdsmsx412.amr.corp.intel.com> To: "'Blumenthal, Uri'" , hokeyp@opendiameter.org, emu@ietf.org Message-id: <000001c70d8c$1ef39190$02fda8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AccJzklxPwF5M9khTom054JMBfhApwAFuvawAAOTFmAAAIoXQAAWFnowAM7jfiA= X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org I agree with Uri, We should not worry about non-compliant implementations, that is the implementor's problem. 3748 and EAP keying did not define use of EMSK, but they did forbid export of EMSK last time I read the keying spec. Fortunately, Hokey is now chartered to define usage of EMSK through deliverable 2 (generation of USRK). So if there is a place where people are to use EMSK is supposed to use, I guess the place to go get the spec is hokey. I have kind of lost track of what this thread was trying to do, but as far as use in Hokey, I think we can assume that the EAP method generates the EMSK. The question in hokey is whether we use MSK or EMSK? And why? Or maybe that was not the intention of the thread. R, Madjid -----Original Message----- From: hokeyp-bounces@opendiameter.org [mailto:hokeyp-bounces@opendiameter.org] On Behalf Of Blumenthal, Uri Sent: Friday, November 17, 2006 6:22 AM To: hokeyp@opendiameter.org; emu@ietf.org Subject: Re: [Hokeyp] [Emu] Re: MSK but no EMSK >The discussion focuses on the problem EMSK is optional or mandatory. I don't think this is a problem - GENERATION of EMSK is compulsoty as spelled out in RFC 3578. The problem is non-compliance. Some, er, people seem to think "the standard says do A, but since I don't use A at the moment - I won't bother." >RFC3578 defined EMSK is mandatory, And that should be the end of discussion. > but it is not used at all. First - do you know all the applications that use key-generating EAP methods? But really - who cares? >If EMSK must be used, it is mandatory. if no, I think, >it may be better that it is optional. VERY strongly disagree. Mandatory is what is explicitly specified as mandatory, period. Otherwise many would implement just those pieces and features of the standard that his particular product needs today. (I'm proud of my restraint - not even once using a term "B*S*" :-) _______________________________________________ Hokeyp mailing list Hokeyp@opendiameter.org http://www.opendiameter.org/mailman/listinfo/hokeyp _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Tue Nov 21 11:50:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmYpl-0003Ta-Hv; Tue, 21 Nov 2006 11:50:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmYpj-0003QP-Vq for emu@ietf.org; Tue, 21 Nov 2006 11:50:55 -0500 Received: from usaga01-in.huawei.com ([12.129.211.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmYpg-0002hr-K4 for emu@ietf.org; Tue, 21 Nov 2006 11:50:55 -0500 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J9300G3CASSUM@usaga01-in.huawei.com> for emu@ietf.org; Tue, 21 Nov 2006 08:50:52 -0800 (PST) Received: from N737011 (c-24-17-254-79.hsd1.wa.comcast.net [24.17.254.79]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J9300DHKASMUO@usaga01-in.huawei.com> for emu@ietf.org; Tue, 21 Nov 2006 08:50:51 -0800 (PST) Date: Tue, 21 Nov 2006 08:50:46 -0800 From: Madjid Nakhjiri Subject: RE: [Hokeyp] [Emu] Re: MSK but no EMSK In-reply-to: <20061117193530.GC11636@steelhead> To: 'Yoshihiro Ohba' , "'Blumenthal, Uri'" Message-id: <000101c70d8d$31698fe0$02fda8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AccKf64ERekmWocHQWuZUyTKnALeHQDDOytw X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: hokeyp@opendiameter.org, emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Hi Yoshi, I don't quite agree with this. Defining the full functionality of a new EAP method (including how it spits out MSK and EMSK) should be the job the EAP method designer. 3748, EAP keying framework and hokey specs then define how MSK or EMSK is used. This is modular design. People who use EMSK then do not have to worry about the crypto behind EMSK generation. Using your analogy is "go buy the key and lock" but then wait to see which door you want to install it on:) I as a home owner do not need to know how to make locks. R, Madjid -----Original Message----- From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] Sent: Friday, November 17, 2006 11:36 AM To: Blumenthal, Uri Cc: hokeyp@opendiameter.org; emu@ietf.org Subject: Re: [Hokeyp] [Emu] Re: MSK but no EMSK Hi Uri, I have a different view. Mandating generation of EMSK without having defined its usage *when it was introduced* seems not much different from not having defining it at all. It looks like selling a key without a lock, make the lock later and say "You MUST use this key and lock for your car." Make sense?? Yoshihiro Ohba On Fri, Nov 17, 2006 at 09:22:04AM -0500, Blumenthal, Uri wrote: > >The discussion focuses on the problem EMSK is optional or mandatory. > > I don't think this is a problem - GENERATION of EMSK is compulsoty as > spelled out in RFC 3578. > > The problem is non-compliance. Some, er, people seem to think "the > standard says do A, but since I don't use A at the moment - I won't > bother." > > >RFC3578 defined EMSK is mandatory, > > And that should be the end of discussion. > > > but it is not used at all. > > First - do you know all the applications that use key-generating EAP > methods? But really - who cares? > > >If EMSK must be used, it is mandatory. if no, I think, > >it may be better that it is optional. > > VERY strongly disagree. Mandatory is what is explicitly specified as > mandatory, period. Otherwise many would implement just those pieces and > features of the standard that his particular product needs today. > > (I'm proud of my restraint - not even once using a term "B*S*" :-) > _______________________________________________ > Hokeyp mailing list > Hokeyp@opendiameter.org > http://www.opendiameter.org/mailman/listinfo/hokeyp > _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Tue Nov 21 22:19:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gmidi-0001hg-4g; Tue, 21 Nov 2006 22:19:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gmidh-0001hZ-8a for emu@ietf.org; Tue, 21 Nov 2006 22:19:09 -0500 Received: from imx12.toshiba.co.jp ([61.202.160.132]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmidY-00086o-HN for emu@ietf.org; Tue, 21 Nov 2006 22:19:09 -0500 Received: from wall11.toshiba.co.jp (wall11 [133.199.90.149]) by imx12.toshiba.co.jp with ESMTP id kAM3ItEW022023; Wed, 22 Nov 2006 12:18:55 +0900 (JST) Received: (from root@localhost) by wall11.toshiba.co.jp id kAM3Itl2009891; Wed, 22 Nov 2006 12:18:55 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by wall11.toshiba.co.jp with ESMTP id NAA09883; Wed, 22 Nov 2006 12:18:54 +0900 Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id kAM3IsJW011378; Wed, 22 Nov 2006 12:18:54 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id kAM3IrQi006606; Wed, 22 Nov 2006 12:18:53 +0900 (JST) Received: from steelhead ([133.196.16.93]) by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 (built Apr 28 2004)) with ESMTPSA id <0J9400AVC3VHY2G0@mail.po.toshiba.co.jp>; Wed, 22 Nov 2006 12:18:53 +0900 (JST) Received: from ohba by steelhead with local (Exim 4.63) (envelope-from ) id 1GlmqQ-0001nU-3E; Sun, 19 Nov 2006 05:36:26 -0800 Date: Sun, 19 Nov 2006 08:36:25 -0500 From: Yoshihiro Ohba Subject: Re: [Hokeyp] [Emu] Re: MSK but no EMSK In-reply-to: <000101c70d8d$31698fe0$02fda8c0@china.huawei.com> To: Madjid Nakhjiri Message-id: <20061119133625.GA6626@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline References: <20061117193530.GC11636@steelhead> <000101c70d8d$31698fe0$02fda8c0@china.huawei.com> User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: emu@ietf.org, hokeyp@opendiameter.org, "'Blumenthal, Uri'" X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Hi Madjid, The problem we are facing with EMSK is that the key and its usage were not defined *at one time". For this reason, I don't agree with mandating the use of EMSK for all implementations. Only making use of EMSK optional makes sense to me, regardless of how it is going to be used. Yoshihiro Ohba On Tue, Nov 21, 2006 at 08:50:46AM -0800, Madjid Nakhjiri wrote: > Hi Yoshi, > > I don't quite agree with this. Defining the full functionality of a new EAP > method (including how it spits out MSK and EMSK) should be the job the EAP > method designer. 3748, EAP keying framework and hokey specs then define how > MSK or EMSK is used. This is modular design. People who use EMSK then do not > have to worry about the crypto behind EMSK generation. > Using your analogy is "go buy the key and lock" but then wait to see which > door you want to install it on:) > I as a home owner do not need to know how to make locks. > > R, > > Madjid > > -----Original Message----- > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > Sent: Friday, November 17, 2006 11:36 AM > To: Blumenthal, Uri > Cc: hokeyp@opendiameter.org; emu@ietf.org > Subject: Re: [Hokeyp] [Emu] Re: MSK but no EMSK > > Hi Uri, > > I have a different view. Mandating generation of EMSK without having > defined its usage *when it was introduced* seems not much different > from not having defining it at all. It looks like selling a key > without a lock, make the lock later and say "You MUST use this key and > lock for your car." Make sense?? > > Yoshihiro Ohba > > > > On Fri, Nov 17, 2006 at 09:22:04AM -0500, Blumenthal, Uri wrote: > > >The discussion focuses on the problem EMSK is optional or mandatory. > > > > I don't think this is a problem - GENERATION of EMSK is compulsoty as > > spelled out in RFC 3578. > > > > The problem is non-compliance. Some, er, people seem to think "the > > standard says do A, but since I don't use A at the moment - I won't > > bother." > > > > >RFC3578 defined EMSK is mandatory, > > > > And that should be the end of discussion. > > > > > but it is not used at all. > > > > First - do you know all the applications that use key-generating EAP > > methods? But really - who cares? > > > > >If EMSK must be used, it is mandatory. if no, I think, > > >it may be better that it is optional. > > > > VERY strongly disagree. Mandatory is what is explicitly specified as > > mandatory, period. Otherwise many would implement just those pieces and > > features of the standard that his particular product needs today. > > > > (I'm proud of my restraint - not even once using a term "B*S*" :-) > > _______________________________________________ > > Hokeyp mailing list > > Hokeyp@opendiameter.org > > http://www.opendiameter.org/mailman/listinfo/hokeyp > > > > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www1.ietf.org/mailman/listinfo/emu > > _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Wed Nov 22 10:30:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gmu3v-0002MC-Fp; Wed, 22 Nov 2006 10:30:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gmu3u-0002M7-Av for emu@ietf.org; Wed, 22 Nov 2006 10:30:58 -0500 Received: from [2001:418:1403:0:212:17ff:fe52:7811] (helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gmu3q-0006RD-PW for emu@ietf.org; Wed, 22 Nov 2006 10:30:58 -0500 Received: from localhost (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id kAMFTwXT007396; Wed, 22 Nov 2006 10:29:59 -0500 (EST) (envelope-from yohba@tari.toshiba.com) Date: Wed, 22 Nov 2006 06:46:56 -0500 To: "Blumenthal, Uri" Subject: Re: [Hokeyp] [Emu] Re: MSK but no EMSK Message-ID: <20061122114656.GC10177@steelhead> References: <279DDDAFA85EC74C9300A0598E704056FE6D70@hdsmsx412.amr.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <279DDDAFA85EC74C9300A0598E704056FE6D70@hdsmsx412.amr.corp.intel.com> User-Agent: Mutt/1.5.13 (2006-08-11) From: Yoshihiro Ohba X-Dispatcher: imput version 20050308(IM148) Lines: 139 X-Spam-Score: -2.4 (--) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 Cc: emu@ietf.org, hokeyp@opendiameter.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Hi Uri, On Wed, Nov 22, 2006 at 09:41:03AM -0500, Blumenthal, Uri wrote: > >The problem we are facing with EMSK is that the key and its usage were > >not defined *at one time". > > True, definition of EMSK has been done in advance, PRIOR to its usage - > so that by the time EMSK usage is defined, all the compliant methods > already have implemented EMSK generation and have it available. This is > not a problem. > > Especially since it is likely that most real-life implementations are > modular enough to allow component upgrades. For any method, how a compliant implementation and a non-compliant implementation can be distinguished? If they are indistinguishable, then there will be an interoperability problem. For a future method that will be defined after we define an EMSK usage, I agree that we can definetly mandate use of EMSK. But ignoring the existing implementations does not make sense, considering the fact that some of them are already part of Wi-Fi certificate. Yoshihiro Ohba > > The problem is shortsightedness of some implementors, whose logic is "if > I don't need this feature NOW, no way I'll spend resources implementing > it". > > >For this reason, I don't agree with > >mandating the use of EMSK for all implementations. > > We cannot mandate what has not been defined yet. This is why we have > mandated only EMSK generation, not EMSK usage. > > Note the grammatic form of the verb: it IS a done deal, RFC 3578 IS a > standard. > > > Only making use of > >EMSK optional makes sense to me, regardless of how it is going to be > >used. > > There is no use of EMSK currently defined, neither optional nor > mandatory. So no need to make it anything. > > It is mandatory to generate EMSK and make it available for applications. > > How many times does is this dead horse going to be beaten? > > > Yoshihiro Ohba > > On Tue, Nov 21, 2006 at 08:50:46AM -0800, Madjid Nakhjiri wrote: > > Hi Yoshi, > > > > I don't quite agree with this. Defining the full functionality of a > new EAP > > method (including how it spits out MSK and EMSK) should be the job the > EAP > > method designer. 3748, EAP keying framework and hokey specs then > define how > > MSK or EMSK is used. This is modular design. People who use EMSK then > do not > > have to worry about the crypto behind EMSK generation. > > Using your analogy is "go buy the key and lock" but then wait to see > which > > door you want to install it on:) > > > I as a home owner do not need to know how to make locks. > > > > R, > > > > Madjid > > > > -----Original Message----- > > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > > Sent: Friday, November 17, 2006 11:36 AM > > To: Blumenthal, Uri > > Cc: hokeyp@opendiameter.org; emu@ietf.org > > Subject: Re: [Hokeyp] [Emu] Re: MSK but no EMSK > > > > Hi Uri, > > > > I have a different view. Mandating generation of EMSK without having > > defined its usage *when it was introduced* seems not much different > > from not having defining it at all. It looks like selling a key > > without a lock, make the lock later and say "You MUST use this key and > > lock for your car." Make sense?? > > > > Yoshihiro Ohba > > > > > > > > On Fri, Nov 17, 2006 at 09:22:04AM -0500, Blumenthal, Uri wrote: > > > >The discussion focuses on the problem EMSK is optional or > mandatory. > > > > > > I don't think this is a problem - GENERATION of EMSK is compulsoty > as > > > spelled out in RFC 3578. > > > > > > The problem is non-compliance. Some, er, people seem to think "the > > > standard says do A, but since I don't use A at the moment - I won't > > > bother." > > > > > > >RFC3578 defined EMSK is mandatory, > > > > > > And that should be the end of discussion. > > > > > > > but it is not used at all. > > > > > > First - do you know all the applications that use key-generating EAP > > > methods? But really - who cares? > > > > > > >If EMSK must be used, it is mandatory. if no, I think, > > > >it may be better that it is optional. > > > > > > VERY strongly disagree. Mandatory is what is explicitly specified as > > > mandatory, period. Otherwise many would implement just those pieces > and > > > features of the standard that his particular product needs today. > > > > > > (I'm proud of my restraint - not even once using a term "B*S*" :-) > > > _______________________________________________ > > > Hokeyp mailing list > > > Hokeyp@opendiameter.org > > > http://www.opendiameter.org/mailman/listinfo/hokeyp > > > > > > > _______________________________________________ > > Emu mailing list > > Emu@ietf.org > > https://www1.ietf.org/mailman/listinfo/emu > > > > > > _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Wed Nov 22 11:17:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmumZ-0002oD-VE; Wed, 22 Nov 2006 11:17:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmumY-0002o1-NK for emu@ietf.org; Wed, 22 Nov 2006 11:17:06 -0500 Received: from bay0-omc1-s27.bay0.hotmail.com ([65.54.246.99]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmumW-0005vk-DG for emu@ietf.org; Wed, 22 Nov 2006 11:17:06 -0500 Received: from hotmail.com ([207.46.8.103]) by bay0-omc1-s27.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Nov 2006 08:17:03 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 22 Nov 2006 08:17:03 -0800 Message-ID: Received: from 207.46.8.123 by by117fd.bay117.hotmail.msn.com with HTTP; Wed, 22 Nov 2006 16:17:02 GMT X-Originating-IP: [67.22.11.168] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: <0MKp2t-1GmYN531ua-0003rd@mrelay.perfora.net> From: "Bernard Aboba" To: alper.yegin@yegin.org, hokeyp@opendiameter.org Bcc: Subject: RE: [Emu] MSK but no EMSK Date: Wed, 22 Nov 2006 08:17:02 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 22 Nov 2006 16:17:03.0616 (UTC) FILETIME=[A58FE800:01C70E51] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Cc: emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org >One question though. I couldn't find any mention of "MSK" or "EMSK" in RFC >2716. Can you tell us how to get those keys out of that spec? RFC 2716bis explains how the send and receive keys map to the MSK/EMSK: http://www.ietf.org/internet-drafts/draft-simon-emu-rfc2716bis-05.txt _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Wed Nov 22 11:48:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmvGj-0000KQ-42; Wed, 22 Nov 2006 11:48:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmvGi-0000KL-EB for emu@ietf.org; Wed, 22 Nov 2006 11:48:16 -0500 Received: from bay0-omc3-s9.bay0.hotmail.com ([65.54.246.209]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmvGh-0001Tb-4o for emu@ietf.org; Wed, 22 Nov 2006 11:48:16 -0500 Received: from hotmail.com ([207.46.8.114]) by bay0-omc3-s9.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Nov 2006 08:48:14 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 22 Nov 2006 08:48:14 -0800 Message-ID: Received: from 207.46.8.123 by by117fd.bay117.hotmail.msn.com with HTTP; Wed, 22 Nov 2006 16:48:10 GMT X-Originating-IP: [67.22.11.168] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: From: "Bernard Aboba" To: jsalowey@cisco.com, emu@ietf.org Bcc: Subject: RE: [Emu] Issue: Definition of Session-Id, Peer-Id, Server-Id for EAP GPSK Date: Wed, 22 Nov 2006 08:48:10 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 22 Nov 2006 16:48:14.0342 (UTC) FILETIME=[009A0A60:01C70E56] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org >[Joe] It seems that the server ID is as authenticated as the client ID. >The server ID and client ID are associated with the shared key. If a >different identity is asserted a different key would be selected and the >protocol should fail. Since more than one AAA server can have access to the credentials, I don't see how the client can verify which server it is talking to. It only knows that the server has access to the PSK, not which server it is. _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Wed Nov 22 11:51:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmvKE-0000nN-M3; Wed, 22 Nov 2006 11:51:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmvKD-0000nI-Jn for emu@ietf.org; Wed, 22 Nov 2006 11:51:53 -0500 Received: from bay0-omc1-s17.bay0.hotmail.com ([65.54.246.89]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmvKC-00024W-Aw for emu@ietf.org; Wed, 22 Nov 2006 11:51:53 -0500 Received: from hotmail.com ([207.46.8.91]) by bay0-omc1-s17.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Nov 2006 08:51:51 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 22 Nov 2006 08:51:50 -0800 Message-ID: Received: from 207.46.8.123 by by117fd.bay117.hotmail.msn.com with HTTP; Wed, 22 Nov 2006 16:51:47 GMT X-Originating-IP: [67.22.11.168] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: <45625E10.8060405@cs.umd.edu> From: "Bernard Aboba" To: clancy@cs.umd.edu Bcc: Subject: Re: [Emu] Issue: Definition of Session-Id, Peer-Id, Server-Id forEAP GPSK Date: Wed, 22 Nov 2006 08:51:47 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 22 Nov 2006 16:51:50.0907 (UTC) FILETIME=[81AF3CB0:01C70E56] X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org >Sounds reasonable, but I'm not entirely sure I'd call the ID_Server >unauthenticated. It's authenticated in GPSK-3 when the server includes it >in the key derivation to compute SK. If the value was changed by an >attacker, the authentication would fail. The client only confirms that the server has access to the PSK, but it doesn't confirm the specific server identity. This is different from TLS-based EAP methods where the client can verify a certificate issued to a specific server. _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Wed Nov 22 12:18:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmvjV-00061y-HA; Wed, 22 Nov 2006 12:18:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmvjU-00061o-3t for emu@ietf.org; Wed, 22 Nov 2006 12:18:00 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmvjS-000745-Pw for emu@ietf.org; Wed, 22 Nov 2006 12:18:00 -0500 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 22 Nov 2006 09:17:57 -0800 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id kAMHHwko012133; Wed, 22 Nov 2006 09:17:58 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id kAMHHrOZ012462; Wed, 22 Nov 2006 09:17:58 -0800 (PST) Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Nov 2006 09:17:56 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Emu] Issue: Definition of Session-Id, Peer-Id, Server-Id for EAP GPSK Date: Wed, 22 Nov 2006 09:17:55 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] Issue: Definition of Session-Id, Peer-Id, Server-Id for EAP GPSK Thread-Index: AccOVgFyH2V6qXxvQoetrKrZ6v9G3AAA6n3A From: "Joseph Salowey \(jsalowey\)" To: "Bernard Aboba" , X-OriginalArrivalTime: 22 Nov 2006 17:17:56.0428 (UTC) FILETIME=[26CEC8C0:01C70E5A] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1045; t=1164215878; x=1165079878; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20\(jsalowey\)=22=20 |Subject:=20RE=3A=20[Emu]=20Issue=3A=20Definition=20of=20Session-Id, =20Pe er-Id,Server-Id=20for=20EAP=20GPSK |Sender:=20; bh=4t4Q5pB+ryC+ZTu0aRKhTOjdNXRJZ6Bq0YQkGTf+sNI=; b=WuZIxv566+3VqoBYg0Ycc36mtHXp5m/VdHCX3E7MW7oOMp+BfV5YP7BBKSB+lqvkKK/1DFgr GTgVLCHEp9I5u4z2TFvQKljr7CkK/mS8cgcmG2B1FSxBA3XDzQ7cVrpl; Authentication-Results: sj-dkim-6; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim6002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org =20 > -----Original Message----- > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]=20 > Sent: Wednesday, November 22, 2006 8:48 AM > To: Joseph Salowey (jsalowey); emu@ietf.org > Subject: RE: [Emu] Issue: Definition of Session-Id,=20 > Peer-Id,Server-Id for EAP GPSK >=20 > >[Joe] It seems that the server ID is as authenticated as the=20 > client ID. > >The server ID and client ID are associated with the shared=20 > key. If a=20 > >different identity is asserted a different key would be selected and=20 > >the protocol should fail. >=20 > Since more than one AAA server can have access to the=20 > credentials, I don't see how the client can verify which=20 > server it is talking to. It only knows that the server has=20 > access to the PSK, not which server it is. >=20 [Joe] Whether this identity belongs to an individual or a group depends upon deployment. A deployment could assign a separate identity for each server with a different key, although I'm not sure what adavantage that would bring. =20 _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Wed Nov 22 12:21:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmvmY-0008Lg-I7; Wed, 22 Nov 2006 12:21:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmvmX-0008La-BQ for emu@ietf.org; Wed, 22 Nov 2006 12:21:09 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmvmV-0007r1-Vw for emu@ietf.org; Wed, 22 Nov 2006 12:21:09 -0500 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 22 Nov 2006 09:21:06 -0800 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id kAMHL67F001166; Wed, 22 Nov 2006 09:21:06 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id kAMHL5OV014634; Wed, 22 Nov 2006 09:21:05 -0800 (PST) Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Nov 2006 09:21:05 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Emu] Issue: Definition of Session-Id, Peer-Id, Server-Id forEAP GPSK Date: Wed, 22 Nov 2006 09:21:05 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] Issue: Definition of Session-Id, Peer-Id, Server-Id forEAP GPSK Thread-Index: AccOVpvUQp/IfEDbRlCJ0pEtLtpymgAA8BHg From: "Joseph Salowey \(jsalowey\)" To: "Bernard Aboba" , X-OriginalArrivalTime: 22 Nov 2006 17:21:05.0734 (UTC) FILETIME=[97A49660:01C70E5A] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1182; t=1164216066; x=1165080066; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20\(jsalowey\)=22=20 |Subject:=20RE=3A=20[Emu]=20Issue=3A=20Definition=20of=20Session-Id, =20Pe er-Id,Server-Id=20forEAP=20GPSK |Sender:=20; bh=P97JxVmIvQAeFjw1f/D8ehpoPnrElMbVMAPp0QbofAg=; b=LKU7I1iwyGWDWqJQ0XoHPfs9r/Ds9qBl0wWYatlaJV3vrAOuojLpbOuL1iSLWgscRa+8f/Pz BNiH+qGR0mrHxlSMEc2nhABYtHaQJGH3yRHUhBmAu5CxL5AanZf6yBgB; Authentication-Results: sj-dkim-7; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim7002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org =20 > -----Original Message----- > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]=20 > Sent: Wednesday, November 22, 2006 8:52 AM > To: clancy@cs.umd.edu > Cc: emu@ietf.org > Subject: Re: [Emu] Issue: Definition of Session-Id,=20 > Peer-Id,Server-Id forEAP GPSK >=20 > >Sounds reasonable, but I'm not entirely sure I'd call the ID_Server=20 > >unauthenticated. It's authenticated in GPSK-3 when the=20 > server includes=20 > >it in the key derivation to compute SK. If the value was=20 > changed by an=20 > >attacker, the authentication would fail. >=20 > The client only confirms that the server has access to the=20 > PSK, but it doesn't confirm the specific server identity. =20 > This is different from TLS-based EAP methods where the client=20 > can verify a certificate issued to a specific server. >=20 [Joe] Yes, by it's nature symmetric authentication is different than asymmetric authentication, but that doesn't mean that an identity is not authenticated in the symmetric case. =20 >=20 >=20 > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www1.ietf.org/mailman/listinfo/emu >=20 _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Wed Nov 22 12:36:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gmw0y-0005jf-4i; Wed, 22 Nov 2006 12:36:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gmw0w-0005jG-4p for emu@ietf.org; Wed, 22 Nov 2006 12:36:02 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gmw0r-0001ML-Bx for emu@ietf.org; Wed, 22 Nov 2006 12:36:02 -0500 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id kAMHZswY012720 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 22 Nov 2006 09:35:55 -0800 Received: from LDONDETI.qualcomm.com (qconnect-10-50-68-71.qualcomm.com [10.50.68.71]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id kAMHZnHU018569 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 22 Nov 2006 09:35:52 -0800 Message-Id: <7.0.1.0.2.20061122092631.06f3dd58@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Wed, 22 Nov 2006 09:35:46 -0800 To: Yoshihiro Ohba , "Blumenthal, Uri" From: Lakshminath Dondeti Subject: Re: [Hokeyp] [Emu] Re: MSK but no EMSK In-Reply-To: <20061122114656.GC10177@steelhead> References: <279DDDAFA85EC74C9300A0598E704056FE6D70@hdsmsx412.amr.corp.intel.com> <20061122114656.GC10177@steelhead> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba Cc: hokeyp@opendiameter.org, emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org At 03:46 AM 11/22/2006, Yoshihiro Ohba wrote: >Hi Uri, > >On Wed, Nov 22, 2006 at 09:41:03AM -0500, Blumenthal, Uri wrote: > > >The problem we are facing with EMSK is that the key and its usage were > > >not defined *at one time". > > > > True, definition of EMSK has been done in advance, PRIOR to its usage - > > so that by the time EMSK usage is defined, all the compliant methods > > already have implemented EMSK generation and have it available. This is > > not a problem. > > > > Especially since it is likely that most real-life implementations are > > modular enough to allow component upgrades. > >For any method, how a compliant implementation and a non-compliant >implementation can be distinguished? If they are indistinguishable, >then there will be an interoperability problem. This is not rocket science! I have some second-hand experience with IPsec interoperability; if implementation X does not interoperate with implementation Y, people then figure out which one is non-compliant and have that implementation fixed. >For a future method that will be defined after we define an EMSK >usage, I agree that we can definetly mandate use of EMSK. This is moot. EMSK derivation is already defined as mandatory. Are you proposing something stronger than a MUST? Lakshminath >But >ignoring the existing implementations does not make sense, considering >the fact that some of them are already part of Wi-Fi certificate. > >Yoshihiro Ohba > > > > > > The problem is shortsightedness of some implementors, whose logic is "if > > I don't need this feature NOW, no way I'll spend resources implementing > > it". > > > > >For this reason, I don't agree with > > >mandating the use of EMSK for all implementations. > > > > We cannot mandate what has not been defined yet. This is why we have > > mandated only EMSK generation, not EMSK usage. > > > > Note the grammatic form of the verb: it IS a done deal, RFC 3578 IS a > > standard. > > > > > Only making use of > > >EMSK optional makes sense to me, regardless of how it is going to be > > >used. > > > > There is no use of EMSK currently defined, neither optional nor > > mandatory. So no need to make it anything. > > > > It is mandatory to generate EMSK and make it available for applications. > > > > How many times does is this dead horse going to be beaten? > > > > > > Yoshihiro Ohba > > > > On Tue, Nov 21, 2006 at 08:50:46AM -0800, Madjid Nakhjiri wrote: > > > Hi Yoshi, > > > > > > I don't quite agree with this. Defining the full functionality of a > > new EAP > > > method (including how it spits out MSK and EMSK) should be the job the > > EAP > > > method designer. 3748, EAP keying framework and hokey specs then > > define how > > > MSK or EMSK is used. This is modular design. People who use EMSK then > > do not > > > have to worry about the crypto behind EMSK generation. > > > Using your analogy is "go buy the key and lock" but then wait to see > > which > > > door you want to install it on:) > > > > > I as a home owner do not need to know how to make locks. > > > > > > R, > > > > > > Madjid > > > > > > -----Original Message----- > > > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > > > Sent: Friday, November 17, 2006 11:36 AM > > > To: Blumenthal, Uri > > > Cc: hokeyp@opendiameter.org; emu@ietf.org > > > Subject: Re: [Hokeyp] [Emu] Re: MSK but no EMSK > > > > > > Hi Uri, > > > > > > I have a different view. Mandating generation of EMSK without having > > > defined its usage *when it was introduced* seems not much different > > > from not having defining it at all. It looks like selling a key > > > without a lock, make the lock later and say "You MUST use this key and > > > lock for your car." Make sense?? > > > > > > Yoshihiro Ohba > > > > > > > > > > > > On Fri, Nov 17, 2006 at 09:22:04AM -0500, Blumenthal, Uri wrote: > > > > >The discussion focuses on the problem EMSK is optional or > > mandatory. > > > > > > > > I don't think this is a problem - GENERATION of EMSK is compulsoty > > as > > > > spelled out in RFC 3578. > > > > > > > > The problem is non-compliance. Some, er, people seem to think "the > > > > standard says do A, but since I don't use A at the moment - I won't > > > > bother." > > > > > > > > >RFC3578 defined EMSK is mandatory, > > > > > > > > And that should be the end of discussion. > > > > > > > > > but it is not used at all. > > > > > > > > First - do you know all the applications that use key-generating EAP > > > > methods? But really - who cares? > > > > > > > > >If EMSK must be used, it is mandatory. if no, I think, > > > > >it may be better that it is optional. > > > > > > > > VERY strongly disagree. Mandatory is what is explicitly specified as > > > > mandatory, period. Otherwise many would implement just those pieces > > and > > > > features of the standard that his particular product needs today. > > > > > > > > (I'm proud of my restraint - not even once using a term "B*S*" :-) > > > > _______________________________________________ > > > > Hokeyp mailing list > > > > Hokeyp@opendiameter.org > > > > http://www.opendiameter.org/mailman/listinfo/hokeyp > > > > > > > > > > _______________________________________________ > > > Emu mailing list > > > Emu@ietf.org > > > https://www1.ietf.org/mailman/listinfo/emu > > > > > > > > > > > >_______________________________________________ >Emu mailing list >Emu@ietf.org >https://www1.ietf.org/mailman/listinfo/emu _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Wed Nov 22 20:06:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gn32T-0007e4-Ak; Wed, 22 Nov 2006 20:06:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gn32S-0007dt-LM for emu@ietf.org; Wed, 22 Nov 2006 20:06:04 -0500 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gn32J-0002j9-OU for emu@ietf.org; Wed, 22 Nov 2006 20:06:04 -0500 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J9500LENSCFHO@szxga02-in.huawei.com> for emu@ietf.org; Thu, 23 Nov 2006 09:05:04 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J9500LZUSCESN@szxga02-in.huawei.com> for emu@ietf.org; Thu, 23 Nov 2006 09:05:03 +0800 (CST) Received: from w50392 ([10.164.5.52]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J95007CSSCD95@szxml04-in.huawei.com> for emu@ietf.org; Thu, 23 Nov 2006 09:05:02 +0800 (CST) Date: Thu, 23 Nov 2006 09:05:01 +0800 From: Tom Wan Subject: Re: [Hokeyp] [Emu] Re: MSK but no EMSK To: Yoshihiro Ohba , "Blumenthal, Uri" Message-id: <001b01c70e9b$672b01e0$3405a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset=iso-2022-jp; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <279DDDAFA85EC74C9300A0598E704056FE6D70@hdsmsx412.amr.corp.intel.com> <20061122114656.GC10177@steelhead> X-Spam-Score: 0.0 (/) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 Cc: hokeyp@opendiameter.org, emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Hi,Yoshi: I am new to this topic. So if I ask some naive questions, forgive me please. I would like to know whether the implementations you told us are widely deployed or not? Are they prototypes or widely deployed by the operators? Thank you very much. You answer is appreciated. BR Tom ----- Original Message ----- From: "Yoshihiro Ohba" To: "Blumenthal, Uri" Cc: ; Sent: Wednesday, November 22, 2006 7:46 PM Subject: Re: [Hokeyp] [Emu] Re: MSK but no EMSK > Hi Uri, > > On Wed, Nov 22, 2006 at 09:41:03AM -0500, Blumenthal, Uri wrote: >> >The problem we are facing with EMSK is that the key and its usage were >> >not defined *at one time". >> >> True, definition of EMSK has been done in advance, PRIOR to its usage - >> so that by the time EMSK usage is defined, all the compliant methods >> already have implemented EMSK generation and have it available. This is >> not a problem. >> >> Especially since it is likely that most real-life implementations are >> modular enough to allow component upgrades. > > For any method, how a compliant implementation and a non-compliant > implementation can be distinguished? If they are indistinguishable, > then there will be an interoperability problem. > > For a future method that will be defined after we define an EMSK > usage, I agree that we can definetly mandate use of EMSK. But > ignoring the existing implementations does not make sense, considering > the fact that some of them are already part of Wi-Fi certificate. > > Yoshihiro Ohba > > >> >> The problem is shortsightedness of some implementors, whose logic is "if >> I don't need this feature NOW, no way I'll spend resources implementing >> it". >> >> >For this reason, I don't agree with >> >mandating the use of EMSK for all implementations. >> >> We cannot mandate what has not been defined yet. This is why we have >> mandated only EMSK generation, not EMSK usage. >> >> Note the grammatic form of the verb: it IS a done deal, RFC 3578 IS a >> standard. >> >> > Only making use of >> >EMSK optional makes sense to me, regardless of how it is going to be >> >used. >> >> There is no use of EMSK currently defined, neither optional nor >> mandatory. So no need to make it anything. >> >> It is mandatory to generate EMSK and make it available for applications. >> >> How many times does is this dead horse going to be beaten? >> >> >> Yoshihiro Ohba >> >> On Tue, Nov 21, 2006 at 08:50:46AM -0800, Madjid Nakhjiri wrote: >> > Hi Yoshi, >> > >> > I don't quite agree with this. Defining the full functionality of a >> new EAP >> > method (including how it spits out MSK and EMSK) should be the job the >> EAP >> > method designer. 3748, EAP keying framework and hokey specs then >> define how >> > MSK or EMSK is used. This is modular design. People who use EMSK then >> do not >> > have to worry about the crypto behind EMSK generation. >> > Using your analogy is "go buy the key and lock" but then wait to see >> which >> > door you want to install it on:) >> >> > I as a home owner do not need to know how to make locks. >> > >> > R, >> > >> > Madjid >> > >> > -----Original Message----- >> > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] >> > Sent: Friday, November 17, 2006 11:36 AM >> > To: Blumenthal, Uri >> > Cc: hokeyp@opendiameter.org; emu@ietf.org >> > Subject: Re: [Hokeyp] [Emu] Re: MSK but no EMSK >> > >> > Hi Uri, >> > >> > I have a different view. Mandating generation of EMSK without having >> > defined its usage *when it was introduced* seems not much different >> > from not having defining it at all. It looks like selling a key >> > without a lock, make the lock later and say "You MUST use this key and >> > lock for your car." Make sense?? >> > >> > Yoshihiro Ohba >> > >> > >> > >> > On Fri, Nov 17, 2006 at 09:22:04AM -0500, Blumenthal, Uri wrote: >> > > >The discussion focuses on the problem EMSK is optional or >> mandatory. >> > > >> > > I don't think this is a problem - GENERATION of EMSK is compulsoty >> as >> > > spelled out in RFC 3578. >> > > >> > > The problem is non-compliance. Some, er, people seem to think "the >> > > standard says do A, but since I don't use A at the moment - I won't >> > > bother." >> > > >> > > >RFC3578 defined EMSK is mandatory, >> > > >> > > And that should be the end of discussion. >> > > >> > > > but it is not used at all. >> > > >> > > First - do you know all the applications that use key-generating EAP >> > > methods? But really - who cares? >> > > >> > > >If EMSK must be used, it is mandatory. if no, I think, >> > > >it may be better that it is optional. >> > > >> > > VERY strongly disagree. Mandatory is what is explicitly specified as >> > > mandatory, period. Otherwise many would implement just those pieces >> and >> > > features of the standard that his particular product needs today. >> > > >> > > (I'm proud of my restraint - not even once using a term "B*S*" :-) >> > > _______________________________________________ >> > > Hokeyp mailing list >> > > Hokeyp@opendiameter.org >> > > http://www.opendiameter.org/mailman/listinfo/hokeyp >> > > >> > >> > _______________________________________________ >> > Emu mailing list >> > Emu@ietf.org >> > https://www1.ietf.org/mailman/listinfo/emu >> > >> > >> >> > > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www1.ietf.org/mailman/listinfo/emu > _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Wed Nov 22 20:34:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gn3U0-0003db-Q5; Wed, 22 Nov 2006 20:34:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gn3U0-0003dW-77 for emu@ietf.org; Wed, 22 Nov 2006 20:34:32 -0500 Received: from [2001:418:1403:0:212:17ff:fe52:7811] (helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gn3Ty-0006rq-Ky for emu@ietf.org; Wed, 22 Nov 2006 20:34:32 -0500 Received: from localhost (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id kAN1XkeV009678; Wed, 22 Nov 2006 20:33:47 -0500 (EST) (envelope-from yohba@tari.toshiba.com) Date: Wed, 22 Nov 2006 09:07:09 -0500 To: Lakshminath Dondeti Subject: Re: [Hokeyp] [Emu] Re: MSK but no EMSK Message-ID: <20061122140709.GF10177@steelhead> References: <279DDDAFA85EC74C9300A0598E704056FE6D70@hdsmsx412.amr.corp.intel.com> <20061122114656.GC10177@steelhead> <7.0.1.0.2.20061122092631.06f3dd58@qualcomm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <7.0.1.0.2.20061122092631.06f3dd58@qualcomm.com> User-Agent: Mutt/1.5.13 (2006-08-11) From: Yoshihiro Ohba X-Dispatcher: imput version 20050308(IM148) Lines: 176 X-Spam-Score: -2.2 (--) X-Scan-Signature: 0e9ebc0cbd700a87c0637ad0e2c91610 Cc: hokeyp@opendiameter.org, emu@ietf.org, "Blumenthal, Uri" X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org On Wed, Nov 22, 2006 at 09:35:46AM -0800, Lakshminath Dondeti wrote: > At 03:46 AM 11/22/2006, Yoshihiro Ohba wrote: > >Hi Uri, > > > >On Wed, Nov 22, 2006 at 09:41:03AM -0500, Blumenthal, Uri wrote: > >> >The problem we are facing with EMSK is that the key and its usage were > >> >not defined *at one time". > >> > >> True, definition of EMSK has been done in advance, PRIOR to its usage - > >> so that by the time EMSK usage is defined, all the compliant methods > >> already have implemented EMSK generation and have it available. This is > >> not a problem. > >> > >> Especially since it is likely that most real-life implementations are > >> modular enough to allow component upgrades. > > > >For any method, how a compliant implementation and a non-compliant > >implementation can be distinguished? If they are indistinguishable, > >then there will be an interoperability problem. > > This is not rocket science! I have some second-hand experience with > IPsec interoperability; if implementation X does not interoperate > with implementation Y, people then figure out which one is > non-compliant and have that implementation fixed. A HOKEY compliant implementation should be able to revert to the legacy mode of operation (i.e., use of MSK in the current way) so that it still interoperates with a HOKEY non-compliant implementation without ending up with a communication failure or changing the HOKEY non-compliant implementation. Note that a HOKEY non-compliant implementation is still RFC3748 compliant as long as it generates MSK and EMSK even if it does not use EMSK. > > > >For a future method that will be defined after we define an EMSK > >usage, I agree that we can definetly mandate use of EMSK. > > This is moot. EMSK derivation is already defined as mandatory. Are > you proposing something stronger than a MUST? "EMSK derivation is a MUST" does not mean that "use of EMSK is MUST". Yoshihiro Ohba > > Lakshminath > > >But > >ignoring the existing implementations does not make sense, considering > >the fact that some of them are already part of Wi-Fi certificate. > > > >Yoshihiro Ohba > > > > > >> > >> The problem is shortsightedness of some implementors, whose logic is "if > >> I don't need this feature NOW, no way I'll spend resources implementing > >> it". > >> > >> >For this reason, I don't agree with > >> >mandating the use of EMSK for all implementations. > >> > >> We cannot mandate what has not been defined yet. This is why we have > >> mandated only EMSK generation, not EMSK usage. > >> > >> Note the grammatic form of the verb: it IS a done deal, RFC 3578 IS a > >> standard. > >> > >> > Only making use of > >> >EMSK optional makes sense to me, regardless of how it is going to be > >> >used. > >> > >> There is no use of EMSK currently defined, neither optional nor > >> mandatory. So no need to make it anything. > >> > >> It is mandatory to generate EMSK and make it available for applications. > >> > >> How many times does is this dead horse going to be beaten? > >> > >> > >> Yoshihiro Ohba > >> > >> On Tue, Nov 21, 2006 at 08:50:46AM -0800, Madjid Nakhjiri wrote: > >> > Hi Yoshi, > >> > > >> > I don't quite agree with this. Defining the full functionality of a > >> new EAP > >> > method (including how it spits out MSK and EMSK) should be the job the > >> EAP > >> > method designer. 3748, EAP keying framework and hokey specs then > >> define how > >> > MSK or EMSK is used. This is modular design. People who use EMSK then > >> do not > >> > have to worry about the crypto behind EMSK generation. > >> > Using your analogy is "go buy the key and lock" but then wait to see > >> which > >> > door you want to install it on:) > >> > >> > I as a home owner do not need to know how to make locks. > >> > > >> > R, > >> > > >> > Madjid > >> > > >> > -----Original Message----- > >> > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > >> > Sent: Friday, November 17, 2006 11:36 AM > >> > To: Blumenthal, Uri > >> > Cc: hokeyp@opendiameter.org; emu@ietf.org > >> > Subject: Re: [Hokeyp] [Emu] Re: MSK but no EMSK > >> > > >> > Hi Uri, > >> > > >> > I have a different view. Mandating generation of EMSK without having > >> > defined its usage *when it was introduced* seems not much different > >> > from not having defining it at all. It looks like selling a key > >> > without a lock, make the lock later and say "You MUST use this key and > >> > lock for your car." Make sense?? > >> > > >> > Yoshihiro Ohba > >> > > >> > > >> > > >> > On Fri, Nov 17, 2006 at 09:22:04AM -0500, Blumenthal, Uri wrote: > >> > > >The discussion focuses on the problem EMSK is optional or > >> mandatory. > >> > > > >> > > I don't think this is a problem - GENERATION of EMSK is compulsoty > >> as > >> > > spelled out in RFC 3578. > >> > > > >> > > The problem is non-compliance. Some, er, people seem to think "the > >> > > standard says do A, but since I don't use A at the moment - I won't > >> > > bother." > >> > > > >> > > >RFC3578 defined EMSK is mandatory, > >> > > > >> > > And that should be the end of discussion. > >> > > > >> > > > but it is not used at all. > >> > > > >> > > First - do you know all the applications that use key-generating EAP > >> > > methods? But really - who cares? > >> > > > >> > > >If EMSK must be used, it is mandatory. if no, I think, > >> > > >it may be better that it is optional. > >> > > > >> > > VERY strongly disagree. Mandatory is what is explicitly specified as > >> > > mandatory, period. Otherwise many would implement just those pieces > >> and > >> > > features of the standard that his particular product needs today. > >> > > > >> > > (I'm proud of my restraint - not even once using a term "B*S*" :-) > >> > > _______________________________________________ > >> > > Hokeyp mailing list > >> > > Hokeyp@opendiameter.org > >> > > http://www.opendiameter.org/mailman/listinfo/hokeyp > >> > > > >> > > >> > _______________________________________________ > >> > Emu mailing list > >> > Emu@ietf.org > >> > https://www1.ietf.org/mailman/listinfo/emu > >> > > >> > > >> > >> > > > >_______________________________________________ > >Emu mailing list > >Emu@ietf.org > >https://www1.ietf.org/mailman/listinfo/emu > > _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Wed Nov 22 21:29:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gn4L5-0004Wb-Sx; Wed, 22 Nov 2006 21:29:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gn4L4-0004WW-Po for emu@ietf.org; Wed, 22 Nov 2006 21:29:22 -0500 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gn4L0-00029h-6y for emu@ietf.org; Wed, 22 Nov 2006 21:29:22 -0500 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id kAN2TGdG025128 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 22 Nov 2006 18:29:17 -0800 Received: from LDONDETI.qualcomm.com (qconnect-10-50-68-188.qualcomm.com [10.50.68.188]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id kAN2TAsa025577 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 22 Nov 2006 18:29:13 -0800 Message-Id: <7.0.1.0.2.20061122181831.04ada8d8@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Wed, 22 Nov 2006 18:29:07 -0800 To: Yoshihiro Ohba From: Lakshminath Dondeti Subject: Re: [Hokeyp] [Emu] Re: MSK but no EMSK In-Reply-To: <20061122140709.GF10177@steelhead> References: <279DDDAFA85EC74C9300A0598E704056FE6D70@hdsmsx412.amr.corp.intel.com> <20061122114656.GC10177@steelhead> <7.0.1.0.2.20061122092631.06f3dd58@qualcomm.com> <20061122140709.GF10177@steelhead> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: b8f3559805f7873076212d6f63ee803e Cc: hokeyp@opendiameter.org, emu@ietf.org, "Blumenthal, Uri" X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org I don't disagree with your latest statements. Those are generally the assumptions I am working with. What I don't understand is the link between those statements and your previous statements. The current EAP authentication model is the default mode of operation if something fails or if the new capabilities are not supported. By that logic there shouldn't really be a blanket statement say one MUST "use" EMSK. Of course, some access technologies may decide to specify MUST try/use EMSK in the first round or something like that, but that is not going to be in an RFC. Anyway, that's my current thinking. We are early in the process here and when the design is complete, we can think further about what makes sense. In the meanwhile, let's stick to what we have in other RFCs. Happy thanksgiving weekend to all Lakshminath At 06:07 AM 11/22/2006, Yoshihiro Ohba wrote: >On Wed, Nov 22, 2006 at 09:35:46AM -0800, Lakshminath Dondeti wrote: > > At 03:46 AM 11/22/2006, Yoshihiro Ohba wrote: > > >Hi Uri, > > > > > >On Wed, Nov 22, 2006 at 09:41:03AM -0500, Blumenthal, Uri wrote: > > >> >The problem we are facing with EMSK is that the key and its usage were > > >> >not defined *at one time". > > >> > > >> True, definition of EMSK has been done in advance, PRIOR to its usage - > > >> so that by the time EMSK usage is defined, all the compliant methods > > >> already have implemented EMSK generation and have it available. This is > > >> not a problem. > > >> > > >> Especially since it is likely that most real-life implementations are > > >> modular enough to allow component upgrades. > > > > > >For any method, how a compliant implementation and a non-compliant > > >implementation can be distinguished? If they are indistinguishable, > > >then there will be an interoperability problem. > > > > This is not rocket science! I have some second-hand experience with > > IPsec interoperability; if implementation X does not interoperate > > with implementation Y, people then figure out which one is > > non-compliant and have that implementation fixed. > >A HOKEY compliant implementation should be able to revert to the >legacy mode of operation (i.e., use of MSK in the current way) so that >it still interoperates with a HOKEY non-compliant implementation >without ending up with a communication failure or changing the HOKEY >non-compliant implementation. Note that a HOKEY non-compliant >implementation is still RFC3748 compliant as long as it generates MSK >and EMSK even if it does not use EMSK. > > > > > > > >For a future method that will be defined after we define an EMSK > > >usage, I agree that we can definetly mandate use of EMSK. > > > > This is moot. EMSK derivation is already defined as mandatory. Are > > you proposing something stronger than a MUST? > >"EMSK derivation is a MUST" does not mean that "use of EMSK is MUST". > >Yoshihiro Ohba > > > > > > Lakshminath > > > > >But > > >ignoring the existing implementations does not make sense, considering > > >the fact that some of them are already part of Wi-Fi certificate. > > > > > >Yoshihiro Ohba > > > > > > > > >> > > >> The problem is shortsightedness of some implementors, whose logic is "if > > >> I don't need this feature NOW, no way I'll spend resources implementing > > >> it". > > >> > > >> >For this reason, I don't agree with > > >> >mandating the use of EMSK for all implementations. > > >> > > >> We cannot mandate what has not been defined yet. This is why we have > > >> mandated only EMSK generation, not EMSK usage. > > >> > > >> Note the grammatic form of the verb: it IS a done deal, RFC 3578 IS a > > >> standard. > > >> > > >> > Only making use of > > >> >EMSK optional makes sense to me, regardless of how it is going to be > > >> >used. > > >> > > >> There is no use of EMSK currently defined, neither optional nor > > >> mandatory. So no need to make it anything. > > >> > > >> It is mandatory to generate EMSK and make it available for applications. > > >> > > >> How many times does is this dead horse going to be beaten? > > >> > > >> > > >> Yoshihiro Ohba > > >> > > >> On Tue, Nov 21, 2006 at 08:50:46AM -0800, Madjid Nakhjiri wrote: > > >> > Hi Yoshi, > > >> > > > >> > I don't quite agree with this. Defining the full functionality of a > > >> new EAP > > >> > method (including how it spits out MSK and EMSK) should be the job the > > >> EAP > > >> > method designer. 3748, EAP keying framework and hokey specs then > > >> define how > > >> > MSK or EMSK is used. This is modular design. People who use EMSK then > > >> do not > > >> > have to worry about the crypto behind EMSK generation. > > >> > Using your analogy is "go buy the key and lock" but then wait to see > > >> which > > >> > door you want to install it on:) > > >> > > >> > I as a home owner do not need to know how to make locks. > > >> > > > >> > R, > > >> > > > >> > Madjid > > >> > > > >> > -----Original Message----- > > >> > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > > >> > Sent: Friday, November 17, 2006 11:36 AM > > >> > To: Blumenthal, Uri > > >> > Cc: hokeyp@opendiameter.org; emu@ietf.org > > >> > Subject: Re: [Hokeyp] [Emu] Re: MSK but no EMSK > > >> > > > >> > Hi Uri, > > >> > > > >> > I have a different view. Mandating generation of EMSK without having > > >> > defined its usage *when it was introduced* seems not much different > > >> > from not having defining it at all. It looks like selling a key > > >> > without a lock, make the lock later and say "You MUST use this key and > > >> > lock for your car." Make sense?? > > >> > > > >> > Yoshihiro Ohba > > >> > > > >> > > > >> > > > >> > On Fri, Nov 17, 2006 at 09:22:04AM -0500, Blumenthal, Uri wrote: > > >> > > >The discussion focuses on the problem EMSK is optional or > > >> mandatory. > > >> > > > > >> > > I don't think this is a problem - GENERATION of EMSK is compulsoty > > >> as > > >> > > spelled out in RFC 3578. > > >> > > > > >> > > The problem is non-compliance. Some, er, people seem to think "the > > >> > > standard says do A, but since I don't use A at the moment - I won't > > >> > > bother." > > >> > > > > >> > > >RFC3578 defined EMSK is mandatory, > > >> > > > > >> > > And that should be the end of discussion. > > >> > > > > >> > > > but it is not used at all. > > >> > > > > >> > > First - do you know all the applications that use key-generating EAP > > >> > > methods? But really - who cares? > > >> > > > > >> > > >If EMSK must be used, it is mandatory. if no, I think, > > >> > > >it may be better that it is optional. > > >> > > > > >> > > VERY strongly disagree. Mandatory is what is explicitly specified as > > >> > > mandatory, period. Otherwise many would implement just those pieces > > >> and > > >> > > features of the standard that his particular product needs today. > > >> > > > > >> > > (I'm proud of my restraint - not even once using a term "B*S*" :-) > > >> > > _______________________________________________ > > >> > > Hokeyp mailing list > > >> > > Hokeyp@opendiameter.org > > >> > > http://www.opendiameter.org/mailman/listinfo/hokeyp > > >> > > > > >> > > > >> > _______________________________________________ > > >> > Emu mailing list > > >> > Emu@ietf.org > > >> > https://www1.ietf.org/mailman/listinfo/emu > > >> > > > >> > > > >> > > >> > > > > > >_______________________________________________ > > >Emu mailing list > > >Emu@ietf.org > > >https://www1.ietf.org/mailman/listinfo/emu > > > > _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Wed Nov 22 22:17:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gn55n-00040c-SU; Wed, 22 Nov 2006 22:17:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gn55k-0003tH-LB for emu@ietf.org; Wed, 22 Nov 2006 22:17:36 -0500 Received: from [2001:418:1403:0:212:17ff:fe52:7811] (helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gn52Z-0003uI-Cp for emu@ietf.org; Wed, 22 Nov 2006 22:14:20 -0500 Received: from localhost (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id kAN3DboE009893; Wed, 22 Nov 2006 22:13:38 -0500 (EST) (envelope-from yohba@tari.toshiba.com) Date: Wed, 22 Nov 2006 22:12:37 -0500 To: Lakshminath Dondeti Subject: Re: [Hokeyp] [Emu] Re: MSK but no EMSK Message-ID: <20061123031237.GI10177@steelhead> References: <279DDDAFA85EC74C9300A0598E704056FE6D70@hdsmsx412.amr.corp.intel.com> <20061122114656.GC10177@steelhead> <7.0.1.0.2.20061122092631.06f3dd58@qualcomm.com> <20061122140709.GF10177@steelhead> <7.0.1.0.2.20061122181831.04ada8d8@qualcomm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <7.0.1.0.2.20061122181831.04ada8d8@qualcomm.com> User-Agent: Mutt/1.5.13 (2006-08-11) From: Yoshihiro Ohba X-Dispatcher: imput version 20050308(IM148) Lines: 228 X-Spam-Score: -2.4 (--) X-Scan-Signature: bcd240e64c427d3d3617cfc704e7fd7f Cc: hokeyp@opendiameter.org, emu@ietf.org, "Blumenthal, Uri" X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org On Wed, Nov 22, 2006 at 06:29:07PM -0800, Lakshminath Dondeti wrote: > I don't disagree with your latest statements. Those are generally > the assumptions I am working with. What I don't understand is the > link between those statements and your previous statements. The > current EAP authentication model is the default mode of operation if > something fails or if the new capabilities are not supported. By > that logic there shouldn't really be a blanket statement say one MUST > "use" EMSK. Of course, some access technologies may decide to > specify MUST try/use EMSK in the first round or something like that, > but that is not going to be in an RFC. These are along with my opinion. Regarding the link between my previous and latest statements, the ability to revert to the default mode of operation if something fails or if the new capabilities are not supported is equivalent to the ability to dintinguish HOKEY compliant and non-compliant implementations. I think we are in convergence. Regards, Yoshihiro Ohba > > Anyway, that's my current thinking. We are early in the process here > and when the design is complete, we can think further about what makes > sense. > > In the meanwhile, let's stick to what we have in other RFCs. > > Happy thanksgiving weekend to all > > Lakshminath > > At 06:07 AM 11/22/2006, Yoshihiro Ohba wrote: > >On Wed, Nov 22, 2006 at 09:35:46AM -0800, Lakshminath Dondeti wrote: > >> At 03:46 AM 11/22/2006, Yoshihiro Ohba wrote: > >> >Hi Uri, > >> > > >> >On Wed, Nov 22, 2006 at 09:41:03AM -0500, Blumenthal, Uri wrote: > >> >> >The problem we are facing with EMSK is that the key and its usage > >were > >> >> >not defined *at one time". > >> >> > >> >> True, definition of EMSK has been done in advance, PRIOR to its usage > >- > >> >> so that by the time EMSK usage is defined, all the compliant methods > >> >> already have implemented EMSK generation and have it available. This > >is > >> >> not a problem. > >> >> > >> >> Especially since it is likely that most real-life implementations are > >> >> modular enough to allow component upgrades. > >> > > >> >For any method, how a compliant implementation and a non-compliant > >> >implementation can be distinguished? If they are indistinguishable, > >> >then there will be an interoperability problem. > >> > >> This is not rocket science! I have some second-hand experience with > >> IPsec interoperability; if implementation X does not interoperate > >> with implementation Y, people then figure out which one is > >> non-compliant and have that implementation fixed. > > > >A HOKEY compliant implementation should be able to revert to the > >legacy mode of operation (i.e., use of MSK in the current way) so that > >it still interoperates with a HOKEY non-compliant implementation > >without ending up with a communication failure or changing the HOKEY > >non-compliant implementation. Note that a HOKEY non-compliant > >implementation is still RFC3748 compliant as long as it generates MSK > >and EMSK even if it does not use EMSK. > > > >> > >> > >> >For a future method that will be defined after we define an EMSK > >> >usage, I agree that we can definetly mandate use of EMSK. > >> > >> This is moot. EMSK derivation is already defined as mandatory. Are > >> you proposing something stronger than a MUST? > > > >"EMSK derivation is a MUST" does not mean that "use of EMSK is MUST". > > > >Yoshihiro Ohba > > > > > >> > >> Lakshminath > >> > >> >But > >> >ignoring the existing implementations does not make sense, considering > >> >the fact that some of them are already part of Wi-Fi certificate. > >> > > >> >Yoshihiro Ohba > >> > > >> > > >> >> > >> >> The problem is shortsightedness of some implementors, whose logic is > >"if > >> >> I don't need this feature NOW, no way I'll spend resources > >implementing > >> >> it". > >> >> > >> >> >For this reason, I don't agree with > >> >> >mandating the use of EMSK for all implementations. > >> >> > >> >> We cannot mandate what has not been defined yet. This is why we have > >> >> mandated only EMSK generation, not EMSK usage. > >> >> > >> >> Note the grammatic form of the verb: it IS a done deal, RFC 3578 IS a > >> >> standard. > >> >> > >> >> > Only making use of > >> >> >EMSK optional makes sense to me, regardless of how it is going to be > >> >> >used. > >> >> > >> >> There is no use of EMSK currently defined, neither optional nor > >> >> mandatory. So no need to make it anything. > >> >> > >> >> It is mandatory to generate EMSK and make it available for > >applications. > >> >> > >> >> How many times does is this dead horse going to be beaten? > >> >> > >> >> > >> >> Yoshihiro Ohba > >> >> > >> >> On Tue, Nov 21, 2006 at 08:50:46AM -0800, Madjid Nakhjiri wrote: > >> >> > Hi Yoshi, > >> >> > > >> >> > I don't quite agree with this. Defining the full functionality of a > >> >> new EAP > >> >> > method (including how it spits out MSK and EMSK) should be the job > >the > >> >> EAP > >> >> > method designer. 3748, EAP keying framework and hokey specs then > >> >> define how > >> >> > MSK or EMSK is used. This is modular design. People who use EMSK > >then > >> >> do not > >> >> > have to worry about the crypto behind EMSK generation. > >> >> > Using your analogy is "go buy the key and lock" but then wait to see > >> >> which > >> >> > door you want to install it on:) > >> >> > >> >> > I as a home owner do not need to know how to make locks. > >> >> > > >> >> > R, > >> >> > > >> >> > Madjid > >> >> > > >> >> > -----Original Message----- > >> >> > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > >> >> > Sent: Friday, November 17, 2006 11:36 AM > >> >> > To: Blumenthal, Uri > >> >> > Cc: hokeyp@opendiameter.org; emu@ietf.org > >> >> > Subject: Re: [Hokeyp] [Emu] Re: MSK but no EMSK > >> >> > > >> >> > Hi Uri, > >> >> > > >> >> > I have a different view. Mandating generation of EMSK without > >having > >> >> > defined its usage *when it was introduced* seems not much different > >> >> > from not having defining it at all. It looks like selling a key > >> >> > without a lock, make the lock later and say "You MUST use this key > >and > >> >> > lock for your car." Make sense?? > >> >> > > >> >> > Yoshihiro Ohba > >> >> > > >> >> > > >> >> > > >> >> > On Fri, Nov 17, 2006 at 09:22:04AM -0500, Blumenthal, Uri wrote: > >> >> > > >The discussion focuses on the problem EMSK is optional or > >> >> mandatory. > >> >> > > > >> >> > > I don't think this is a problem - GENERATION of EMSK is compulsoty > >> >> as > >> >> > > spelled out in RFC 3578. > >> >> > > > >> >> > > The problem is non-compliance. Some, er, people seem to think "the > >> >> > > standard says do A, but since I don't use A at the moment - I > >won't > >> >> > > bother." > >> >> > > > >> >> > > >RFC3578 defined EMSK is mandatory, > >> >> > > > >> >> > > And that should be the end of discussion. > >> >> > > > >> >> > > > but it is not used at all. > >> >> > > > >> >> > > First - do you know all the applications that use key-generating > >EAP > >> >> > > methods? But really - who cares? > >> >> > > > >> >> > > >If EMSK must be used, it is mandatory. if no, I think, > >> >> > > >it may be better that it is optional. > >> >> > > > >> >> > > VERY strongly disagree. Mandatory is what is explicitly specified > >as > >> >> > > mandatory, period. Otherwise many would implement just those > >pieces > >> >> and > >> >> > > features of the standard that his particular product needs today. > >> >> > > > >> >> > > (I'm proud of my restraint - not even once using a term "B*S*" :-) > >> >> > > _______________________________________________ > >> >> > > Hokeyp mailing list > >> >> > > Hokeyp@opendiameter.org > >> >> > > http://www.opendiameter.org/mailman/listinfo/hokeyp > >> >> > > > >> >> > > >> >> > _______________________________________________ > >> >> > Emu mailing list > >> >> > Emu@ietf.org > >> >> > https://www1.ietf.org/mailman/listinfo/emu > >> >> > > >> >> > > >> >> > >> >> > >> > > >> >_______________________________________________ > >> >Emu mailing list > >> >Emu@ietf.org > >> >https://www1.ietf.org/mailman/listinfo/emu > >> > >> > > _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Sat Nov 25 00:35:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnqCD-0007Yb-N6; Sat, 25 Nov 2006 00:35:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnqCC-0007Xm-8o for emu@ietf.org; Sat, 25 Nov 2006 00:35:24 -0500 Received: from smtpout1439.sc1.he.tucows.com ([64.97.157.139] helo=n007.sc1.cp.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnqCA-0008Hu-ME for emu@ietf.org; Sat, 25 Nov 2006 00:35:24 -0500 Received: from CPQ-SEMPRON.mitton.com (71.232.147.244) by n007.sc1.cp.net (7.2.069.1) (authenticated as david@mitton.com) id 455C772200236B80; Sat, 25 Nov 2006 05:35:11 +0000 Message-Id: <6.2.3.4.2.20061124235522.05853290@getmail.mitton.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Sat, 25 Nov 2006 00:28:41 -0500 To: hokeyp@opendiameter.org;,emu@ietf.org From: David Mitton Subject: RE: [Hokeyp] [Emu] Re: MSK but no EMSK In-Reply-To: <000101c70d8d$31698fe0$02fda8c0@china.huawei.com> References: <20061117193530.GC11636@steelhead> <000101c70d8d$31698fe0$02fda8c0@china.huawei.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org I haven't had time to join this discussion prior to this, but I'll just pick this response out of the stream and make a comment or two: On 11/21/2006 11:50 AM, Madjid Nakhjiri wrote: >Hi Yoshi, > >I don't quite agree with this. Defining the full functionality of a new EAP >method (including how it spits out MSK and EMSK) should be the job the EAP >method designer. 3748, EAP keying framework and hokey specs then define how >MSK or EMSK is used. This is modular design. People who use EMSK then do not >have to worry about the crypto behind EMSK generation. >Using your analogy is "go buy the key and lock" but then wait to see which >door you want to install it on:) >I as a home owner do not need to know how to make locks. > >R, > >Madjid > >-----Original Message----- >From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] >Sent: Friday, November 17, 2006 11:36 AM >To: Blumenthal, Uri >Cc: hokeyp@opendiameter.org; emu@ietf.org >Subject: Re: [Hokeyp] [Emu] Re: MSK but no EMSK > >Hi Uri, > >I have a different view. Mandating generation of EMSK without having >defined its usage *when it was introduced* seems not much different >from not having defining it at all. It looks like selling a key >without a lock, make the lock later and say "You MUST use this key and >lock for your car." Make sense?? > >Yoshihiro Ohba The current specification require that a method generate EMSK, but then tell you not to show it to anyone. So to paraphrase the age old question, if an EAP method generates an EMSK in a forest and nobody hears it, does it comply with RFC3748? Until there is a standard API, or a definition of how a method exports an EMSK, or even uses an EMSK to produce a publicly visible result, this issue is a moot question, because there is no consequence of not producing an EMSK and saying that you did. The method is still a black box with this respect. In any case, when something does get defined that makes it matter, only then will method implementers have to make it happen. And it will require the modules to be updated to meet the new requirements, there's no other way. Dave. _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Sun Nov 26 09:15:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GoKmX-0007h4-EP; Sun, 26 Nov 2006 09:14:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GoKmW-0007e3-Mk for emu@ietf.org; Sun, 26 Nov 2006 09:14:56 -0500 Received: from mcfeely.cs.umd.edu ([128.8.128.218]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GoKmT-0001eG-NJ for emu@ietf.org; Sun, 26 Nov 2006 09:14:56 -0500 Received: from mcfeely.cs.umd.edu (localhost [127.0.0.1]) by mcfeely.cs.umd.edu (8.12.11.20060308/8.12.5) with ESMTP id kAQEEpBu021143; Sun, 26 Nov 2006 09:14:51 -0500 Received: (from apache@localhost) by mcfeely.cs.umd.edu (8.12.11.20060308/8.12.11/Submit) id kAQEEgRw021136; Sun, 26 Nov 2006 09:14:42 -0500 X-Authentication-Warning: mcfeely.cs.umd.edu: apache set sender to clancy@cs.umd.edu using -f Received: from 69.136.165.65 (SquirrelMail authenticated user clancy) by webmail.cs.umd.edu with HTTP; Sun, 26 Nov 2006 09:14:42 -0500 (EST) Message-ID: <61224.69.136.165.65.1164550482.squirrel@webmail.cs.umd.edu> In-Reply-To: <20061122140709.GF10177@steelhead> References: <279DDDAFA85EC74C9300A0598E704056FE6D70@hdsmsx412.amr.corp.intel.com> <20061122114656.GC10177@steelhead> <7.0.1.0.2.20061122092631.06f3dd58@qualcomm.com> <20061122140709.GF10177@steelhead> Date: Sun, 26 Nov 2006 09:14:42 -0500 (EST) Subject: Re: [Hokeyp] [Emu] Re: MSK but no EMSK From: "Charles Clancy" To: "Yoshihiro Ohba" User-Agent: SquirrelMail/1.4.5 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: "Blumenthal, Uri" , hokeyp@opendiameter.org, emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org On Wed, November 22, 2006 9:07 am, Yoshihiro Ohba wrote: > A HOKEY compliant implementation should be able to revert to the > legacy mode of operation (i.e., use of MSK in the current way) so that > it still interoperates with a HOKEY non-compliant implementation > without ending up with a communication failure or changing the HOKEY > non-compliant implementation. Note that a HOKEY non-compliant > implementation is still RFC3748 compliant as long as it generates MSK > and EMSK even if it does not use EMSK. Let me point this out again. In order to support HOKEY, EAP implementations MUST change to implement the reauth protocols. Thus, I don't understand why fixing broken methods to export the EMSK at the same time is such a big deal. I'm not convinced by the certification arguments. EAP implementations will all have to be recertified by whomever to check HOKEY compatability anyway. Proper use of the EMSK would be tested then. I'm also not convinced by the versioning arguments, since you'd never need to use the EMSK if you weren't executing some HOKEY reauth protocol. If an implementation didn't derive/export the EMSK, then it has no business executing a reauth. By executing a reauth, an implementation is implicitly signaling that it can derive EMSKs for the originally-executed method. -- t. charles clancy, ph.d. <> tcc@umd.edu <> www.cs.umd.edu/~clancy _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Sun Nov 26 13:15:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GoOXN-0007L7-4f; Sun, 26 Nov 2006 13:15:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GoOXL-0007Gz-Kx for emu@ietf.org; Sun, 26 Nov 2006 13:15:31 -0500 Received: from [2001:418:1403:0:212:17ff:fe52:7811] (helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GoOXE-0001xs-68 for emu@ietf.org; Sun, 26 Nov 2006 13:15:31 -0500 Received: from localhost (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id kAQIEQLS021005; Sun, 26 Nov 2006 13:14:26 -0500 (EST) (envelope-from yohba@tari.toshiba.com) Date: Sun, 26 Nov 2006 13:14:27 -0500 To: Charles Clancy Subject: Re: [Hokeyp] [Emu] Re: MSK but no EMSK Message-ID: <20061126181427.GA1177@steelhead> References: <279DDDAFA85EC74C9300A0598E704056FE6D70@hdsmsx412.amr.corp.intel.com> <20061122114656.GC10177@steelhead> <7.0.1.0.2.20061122092631.06f3dd58@qualcomm.com> <20061122140709.GF10177@steelhead> <61224.69.136.165.65.1164550482.squirrel@webmail.cs.umd.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <61224.69.136.165.65.1164550482.squirrel@webmail.cs.umd.edu> User-Agent: Mutt/1.5.13 (2006-08-11) From: Yoshihiro Ohba X-Dispatcher: imput version 20050308(IM148) Lines: 57 X-Spam-Score: -2.4 (--) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: "Blumenthal, Uri" , hokeyp@opendiameter.org, emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org On Sun, Nov 26, 2006 at 09:14:42AM -0500, Charles Clancy wrote: > On Wed, November 22, 2006 9:07 am, Yoshihiro Ohba wrote: > > > A HOKEY compliant implementation should be able to revert to the > > legacy mode of operation (i.e., use of MSK in the current way) so that > > it still interoperates with a HOKEY non-compliant implementation > > without ending up with a communication failure or changing the HOKEY > > non-compliant implementation. Note that a HOKEY non-compliant > > implementation is still RFC3748 compliant as long as it generates MSK > > and EMSK even if it does not use EMSK. > > Let me point this out again. In order to support HOKEY, EAP > implementations MUST change to implement the reauth protocols. Thus, I > don't understand why fixing broken methods to export the EMSK at the same > time is such a big deal. If the reauth protocols require changes to all peers, authenticators and servers, then isn't it a big deal? I can't realistically assume that such upgrade can be done at one time. > > I'm not convinced by the certification arguments. EAP implementations > will all have to be recertified by whomever to check HOKEY compatability > anyway. Proper use of the EMSK would be tested then. That is certainly possible, but my argument was that HOKEY-compliant implementations must interoperate with HOKEY non-compliant (but still RFC3748-compliant and some of them are WFA-certified) implementations regardless of whether HOKEY will be WFA-certified or not. > > I'm also not convinced by the versioning arguments, since you'd never need > to use the EMSK if you weren't executing some HOKEY reauth protocol. If > an implementation didn't derive/export the EMSK, then it has no business > executing a reauth. By executing a reauth, an implementation is > implicitly signaling that it can derive EMSKs for the originally-executed > method. In my reading of the existing reauth proposal, implicit signaling for reauth capability discovery is made based on whether the peer, authenticator and server understand a new Code which will be siliently discarded by the recipient that do not understand it. This means that reauth implementations based on the existing proposal would need to rely on timeouts to detect implementations that do not support reauth. Relying on timeouts will significantly affect handover performance. Of course, other solution would be possible to detect reauth-unsupported implementations without relying on versioning or timeouts, but versioning were the simplest way for capability discovery. Yoshihiro Ohba > > -- > t. charles clancy, ph.d. <> tcc@umd.edu <> www.cs.umd.edu/~clancy > > _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Mon Nov 27 00:09:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GoYjo-0005xe-CV; Mon, 27 Nov 2006 00:09:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmYNM-0000Op-8Y for emu@ietf.org; Tue, 21 Nov 2006 11:21:36 -0500 Received: from mout.perfora.net ([217.160.230.41]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmYNL-0006Hx-0f for emu@ietf.org; Tue, 21 Nov 2006 11:21:36 -0500 Received: from [85.102.133.158] (helo=IBM52A5038A94F) by mrelay.perfora.net (node=mrelayus1) with ESMTP (Nemesis), id 0MKp2t-1GmYN531ua-0003rd; Tue, 21 Nov 2006 11:21:26 -0500 From: "Alper Yegin" To: "'Bernard Aboba'" , Subject: RE: [Emu] MSK but no EMSK Date: Tue, 21 Nov 2006 18:21:16 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AccMCr/G/i13kSpoTvumXVmKnV+pugBffmKQ In-Reply-To: Message-ID: <0MKp2t-1GmYN531ua-0003rd@mrelay.perfora.net> X-Provags-ID: perfora.net abuse@perfora.net login:abf7a4bb310ea4dfc9b6841113e2970f X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 X-Mailman-Approved-At: Mon, 27 Nov 2006 00:09:02 -0500 Cc: emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Thank you for this survey. One question though. I couldn't find any mention of "MSK" or "EMSK" in RFC 2716. Can you tell us how to get those keys out of that spec? Alper > -----Original Message----- > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] > Sent: Sunday, November 19, 2006 8:44 PM > To: alper.yegin@yegin.org; hokeyp@opendiameter.org > Cc: emu@ietf.org > Subject: RE: [Emu] MSK but no EMSK > > >I remember someone in Hokey WG meeting mentioned that not all methods > >generate EMSK (even though they generate MSK). Is that accurate? > > The simple answer is "we don't know" because prior to RFC 3748, EAP Type > Codes could be allocated without a specification. > > However, for methods published as RFCs or in the RFC Editor Queue, we know > the following: > > a) None of the RFC 3748-specified EAP methods generate keys (EAP MD5, OTP, > GTC). > > b) All of the key generating EAP methods published as RFCs specify how to > derive the MSK and EMSK. This includes EAP TLS (RFC 2716), EAP SIM (RFC > 4186), and EAP AKA (RFC 4817). The generation of the Session-Id, Peer-Id > and Server-Id is also specified for these methods in the Key Management > Framework document. > > c) All of the key generating EAP methods currently in the RFC Editor queue > specify how to derive both the MSK and EMSK. This includes EAP PSK > (draft-bersani-eap-psk-11.txt), EAP SAKE (draft-vanderveen-eap-sake- > 02.txt), > EAP PAX (draft-clancy-eap-pax-11.txt), EAP POTP > (draft-nystrom-eap-potp-07.txt). None of these methods specify how to > derive the Peer-Id, Server-Id and Session-Id (e.g. they are non-compliant > with the EAP Key Management Framework). > > d) Allocation of an EAP Type Code requires specification of the MSK, EMSK, > and Session-Id and Peer-Id/Server-Id if known. > _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Mon Nov 27 00:09:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GoYjo-0005xe-CV; Mon, 27 Nov 2006 00:09:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmYNM-0000Op-8Y for emu@ietf.org; Tue, 21 Nov 2006 11:21:36 -0500 Received: from mout.perfora.net ([217.160.230.41]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmYNL-0006Hx-0f for emu@ietf.org; Tue, 21 Nov 2006 11:21:36 -0500 Received: from [85.102.133.158] (helo=IBM52A5038A94F) by mrelay.perfora.net (node=mrelayus1) with ESMTP (Nemesis), id 0MKp2t-1GmYN531ua-0003rd; Tue, 21 Nov 2006 11:21:26 -0500 From: "Alper Yegin" To: "'Bernard Aboba'" , Subject: RE: [Emu] MSK but no EMSK Date: Tue, 21 Nov 2006 18:21:16 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AccMCr/G/i13kSpoTvumXVmKnV+pugBffmKQ In-Reply-To: Message-ID: <0MKp2t-1GmYN531ua-0003rd@mrelay.perfora.net> X-Provags-ID: perfora.net abuse@perfora.net login:abf7a4bb310ea4dfc9b6841113e2970f X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 X-Mailman-Approved-At: Mon, 27 Nov 2006 00:09:02 -0500 Cc: emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Thank you for this survey. One question though. I couldn't find any mention of "MSK" or "EMSK" in RFC 2716. Can you tell us how to get those keys out of that spec? Alper > -----Original Message----- > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] > Sent: Sunday, November 19, 2006 8:44 PM > To: alper.yegin@yegin.org; hokeyp@opendiameter.org > Cc: emu@ietf.org > Subject: RE: [Emu] MSK but no EMSK > > >I remember someone in Hokey WG meeting mentioned that not all methods > >generate EMSK (even though they generate MSK). Is that accurate? > > The simple answer is "we don't know" because prior to RFC 3748, EAP Type > Codes could be allocated without a specification. > > However, for methods published as RFCs or in the RFC Editor Queue, we know > the following: > > a) None of the RFC 3748-specified EAP methods generate keys (EAP MD5, OTP, > GTC). > > b) All of the key generating EAP methods published as RFCs specify how to > derive the MSK and EMSK. This includes EAP TLS (RFC 2716), EAP SIM (RFC > 4186), and EAP AKA (RFC 4817). The generation of the Session-Id, Peer-Id > and Server-Id is also specified for these methods in the Key Management > Framework document. > > c) All of the key generating EAP methods currently in the RFC Editor queue > specify how to derive both the MSK and EMSK. This includes EAP PSK > (draft-bersani-eap-psk-11.txt), EAP SAKE (draft-vanderveen-eap-sake- > 02.txt), > EAP PAX (draft-clancy-eap-pax-11.txt), EAP POTP > (draft-nystrom-eap-potp-07.txt). None of these methods specify how to > derive the Peer-Id, Server-Id and Session-Id (e.g. they are non-compliant > with the EAP Key Management Framework). > > d) Allocation of an EAP Type Code requires specification of the MSK, EMSK, > and Session-Id and Peer-Id/Server-Id if known. > _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Mon Nov 27 00:09:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GoYjo-0005xy-Lu; Mon, 27 Nov 2006 00:09:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnGZW-0005Al-Km for emu@ietf.org; Thu, 23 Nov 2006 10:33:06 -0500 Received: from ug-out-1314.google.com ([66.249.92.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnGZV-0007HF-BO for emu@ietf.org; Thu, 23 Nov 2006 10:33:06 -0500 Received: by ug-out-1314.google.com with SMTP id 72so420607ugd for ; Thu, 23 Nov 2006 07:33:03 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:from:to:subject:user-agent:cc:references:in-reply-to:mime-version:content-disposition:date:content-type:content-transfer-encoding:message-id:sender; b=BXLFXblQka61/eCXAAGQwzbq2A0/0bMJx1uYtcCK/buIbcZG+PbxPLocOftSr67cKK5a2RPZA+FjHnJXZc57NMskWglfVFvPqO6dyA60LqkaPgT06YpdDzLN/coWDGFWbWnhlVvninxR19+1TYRBupI3Xs8UPNpMDSMUnVh31Jg= Received: by 10.67.121.15 with SMTP id y15mr2614287ugm.1164295982917; Thu, 23 Nov 2006 07:33:02 -0800 (PST) Received: from ?192.168.10.45? ( [149.229.90.158]) by mx.google.com with ESMTP id 29sm12217245uga.2006.11.23.07.33.01; Thu, 23 Nov 2006 07:33:02 -0800 (PST) From: Julien Laganier To: hokeyp@opendiameter.org Subject: Re: [Hokeyp] [Emu] Re: MSK but no EMSK User-Agent: KMail/1.8.2 References: <279DDDAFA85EC74C9300A0598E704056F915FE@hdsmsx412.amr.corp.intel.com> <20061117193530.GC11636@steelhead> In-Reply-To: <20061117193530.GC11636@steelhead> MIME-Version: 1.0 Content-Disposition: inline Date: Thu, 23 Nov 2006 07:32:47 -0800 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200611230732.47997.julien.IETF@laposte.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 X-Mailman-Approved-At: Mon, 27 Nov 2006 00:09:02 -0500 Cc: emu@ietf.org, "Blumenthal, Uri" X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org On Friday 17 November 2006 11:35, Yoshihiro Ohba wrote: > Hi Uri, > > I have a different view. Mandating generation of > EMSK without having defined its usage *when it was > introduced* seems not much different from not having > defining it at all. I think this is exactly the other way around. *Mandating* generation of EMSK without having defined its usage when it was introduced make it possible to later define how it should be used, and use it. That's why it's been *mandated* :) --julien _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu ietf.org with esmtp (Exim 4.43) id 1GoYjo-0005xy-Lu; Mon, 27 Nov 2006 00:09:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnGZW-0005Al-Km for emu@ietf.org; Thu, 23 Nov 2006 10:33:06 -0500 Received: from ug-out-1314.google.com ([66.249.92.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnGZV-0007HF-BO for emu@ietf.org; Thu, 23 Nov 2006 10:33:06 -0500 Received: by ug-out-1314.google.com with SMTP id 72so420607ugd for ; Thu, 23 Nov 2006 07:33:03 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:from:to:subject:user-agent:cc:references:in-reply-to:mime-version:content-disposition:date:content-type:content-transfer-encoding:message-id:sender; b=BXLFXblQka61/eCXAAGQwzbq2A0/0bMJx1uYtcCK/buIbcZG+PbxPLocOftSr67cKK5a2RPZA+FjHnJXZc57NMskWglfVFvPqO6dyA60LqkaPgT06YpdDzLN/coWDGFWbWnhlVvninxR19+1TYRBupI3Xs8UPNpMDSMUnVh31Jg= Received: by 10.67.121.15 with SMTP id y15mr2614287ugm.1164295982917; Thu, 23 Nov 2006 07:33:02 -0800 (PST) Received: from ?192.168.10.45? ( [149.229.90.158]) by mx.google.com with ESMTP id 29sm12217245uga.2006.11.23.07.33.01; Thu, 23 Nov 2006 07:33:02 -0800 (PST) From: Julien Laganier To: hokeyp@opendiameter.org Subject: Re: [Hokeyp] [Emu] Re: MSK but no EMSK User-Agent: KMail/1.8.2 References: <279DDDAFA85EC74C9300A0598E704056F915FE@hdsmsx412.amr.corp.intel.com> <20061117193530.GC11636@steelhead> In-Reply-To: <20061117193530.GC11636@steelhead> MIME-Version: 1.0 Content-Disposition: inline Date: Thu, 23 Nov 2006 07:32:47 -0800 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200611230732.47997.julien.IETF@laposte.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 X-Mailman-Approved-At: Mon, 27 Nov 2006 00:09:02 -0500 Cc: emu@ietf.org, "Blumenthal, Uri" X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org On Friday 17 November 2006 11:35, Yoshihiro Ohba wrote: > Hi Uri, > > I have a different view. Mandating generation of > EMSK without having defined its usage *when it was > introduced* seems not much different from not having > defining it at all. I think this is exactly the other way around. *Mandating* generation of EMSK without having defined its usage when it was introduced make it possible to later define how it should be used, and use it. That's why it's been *mandated* :) --julien _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Mon Nov 27 00:09:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GoYjo-0005xj-IW; Mon, 27 Nov 2006 00:09:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmtHm-0003KS-Co for emu@ietf.org; Wed, 22 Nov 2006 09:41:14 -0500 Received: from mga02.intel.com ([134.134.136.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmtHe-00015v-U3 for emu@ietf.org; Wed, 22 Nov 2006 09:41:14 -0500 Received: from orsmga001.jf.intel.com ([10.7.209.18]) by mga02.intel.com with ESMTP; 22 Nov 2006 06:41:05 -0800 Received: from fmsmsx333.amr.corp.intel.com ([132.233.42.2]) by orsmga001.jf.intel.com with ESMTP; 22 Nov 2006 06:41:04 -0800 X-ExtLoop1: 1 X-IronPort-AV: i="4.09,448,1157353200"; d="scan'208"; a="165424877:sNHT27288541" Received: from hdsmsx412.amr.corp.intel.com ([10.127.2.72]) by fmsmsx333.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Nov 2006 06:41:04 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Hokeyp] [Emu] Re: MSK but no EMSK Date: Wed, 22 Nov 2006 09:41:03 -0500 Message-ID: <279DDDAFA85EC74C9300A0598E704056FE6D70@hdsmsx412.amr.corp.intel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Hokeyp] [Emu] Re: MSK but no EMSK thread-index: AccN5QOSS3PWIkdBQBqQUTHt21UqtQAWRkaw From: "Blumenthal, Uri" To: "Yoshihiro Ohba" , "Madjid Nakhjiri" X-OriginalArrivalTime: 22 Nov 2006 14:41:04.0592 (UTC) FILETIME=[3CEA9500:01C70E44] X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede X-Mailman-Approved-At: Mon, 27 Nov 2006 00:09:02 -0500 Cc: hokeyp@opendiameter.org, emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org >The problem we are facing with EMSK is that the key and its usage were >not defined *at one time". =20 True, definition of EMSK has been done in advance, PRIOR to its usage - so that by the time EMSK usage is defined, all the compliant methods already have implemented EMSK generation and have it available. This is not a problem. =20 Especially since it is likely that most real-life implementations are modular enough to allow component upgrades. The problem is shortsightedness of some implementors, whose logic is "if I don't need this feature NOW, no way I'll spend resources implementing it". >For this reason, I don't agree with >mandating the use of EMSK for all implementations.=20 We cannot mandate what has not been defined yet. This is why we have mandated only EMSK generation, not EMSK usage. Note the grammatic form of the verb: it IS a done deal, RFC 3578 IS a standard. > Only making use of >EMSK optional makes sense to me, regardless of how it is going to be >used. There is no use of EMSK currently defined, neither optional nor mandatory. So no need to make it anything. It is mandatory to generate EMSK and make it available for applications. How many times does is this dead horse going to be beaten? Yoshihiro Ohba On Tue, Nov 21, 2006 at 08:50:46AM -0800, Madjid Nakhjiri wrote: > Hi Yoshi, >=20 > I don't quite agree with this. Defining the full functionality of a new EAP > method (including how it spits out MSK and EMSK) should be the job the EAP > method designer. 3748, EAP keying framework and hokey specs then define how > MSK or EMSK is used. This is modular design. People who use EMSK then do not > have to worry about the crypto behind EMSK generation. > Using your analogy is "go buy the key and lock" but then wait to see which > door you want to install it on:) > I as a home owner do not need to know how to make locks. >=20 > R, >=20 > Madjid >=20 > -----Original Message----- > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com]=20 > Sent: Friday, November 17, 2006 11:36 AM > To: Blumenthal, Uri > Cc: hokeyp@opendiameter.org; emu@ietf.org > Subject: Re: [Hokeyp] [Emu] Re: MSK but no EMSK >=20 > Hi Uri, >=20 > I have a different view. Mandating generation of EMSK without having > defined its usage *when it was introduced* seems not much different > from not having defining it at all. It looks like selling a key > without a lock, make the lock later and say "You MUST use this key and > lock for your car." Make sense?? >=20 > Yoshihiro Ohba >=20 >=20 >=20 > On Fri, Nov 17, 2006 at 09:22:04AM -0500, Blumenthal, Uri wrote: > > >The discussion focuses on the problem EMSK is optional or mandatory. > >=20 > > I don't think this is a problem - GENERATION of EMSK is compulsoty as > > spelled out in RFC 3578. > >=20 > > The problem is non-compliance. Some, er, people seem to think "the > > standard says do A, but since I don't use A at the moment - I won't > > bother." > >=20 > > >RFC3578 defined EMSK is mandatory,=20 > >=20 > > And that should be the end of discussion. > >=20 > > > but it is not used at all.=20 > >=20 > > First - do you know all the applications that use key-generating EAP > > methods? But really - who cares?=20 > >=20 > > >If EMSK must be used, it is mandatory. if no, I think,=20 > > >it may be better that it is optional. > >=20 > > VERY strongly disagree. Mandatory is what is explicitly specified as > > mandatory, period. Otherwise many would implement just those pieces and > > features of the standard that his particular product needs today. > >=20 > > (I'm proud of my restraint - not even once using a term "B*S*" :-) > > _______________________________________________ > > Hokeyp mailing list > > Hokeyp@opendiameter.org > > http://www.opendiameter.org/mailman/listinfo/hokeyp > >=20 >=20 > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www1.ietf.org/mailman/listinfo/emu >=20 >=20 _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Mon Nov 27 02:09:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Goabv-0004rw-15; Mon, 27 Nov 2006 02:09:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Goabs-0004ro-7i for emu@ietf.org; Mon, 27 Nov 2006 02:09:00 -0500 Received: from mail711.megamailservers.com ([69.49.98.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Goabq-0000eH-U6 for emu@ietf.org; Mon, 27 Nov 2006 02:09:00 -0500 X-Authenticated-User: ray.grid-net.com Received: from RBLAPTOP (h-68-167-203-99.snfccasy.covad.net [68.167.203.99]) (authenticated bits=0) by mail711.megamailservers.com (8.13.6.20060614/8.13.1) with ESMTP id kAR78VFD014661; Mon, 27 Nov 2006 02:08:34 -0500 From: "Ray Bell" To: "'Alper Yegin'" , "'Bernard Aboba'" , Subject: RE: [Emu] MSK but no EMSK Date: Sun, 26 Nov 2006 23:08:26 -0800 Message-ID: <001d01c711f2$d6f33790$63cba744@RBLAPTOP> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 thread-index: AccMCr/G/i13kSpoTvumXVmKnV+pugBffmKQARp1mLA= In-Reply-To: <0MKp2t-1GmYN531ua-0003rd@mrelay.perfora.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org RFC 3748 - Extensible Authentication Protocol (EAP), June 2004 Page 6: Master Session Key (MSK) Keying material that is derived between the EAP peer and server and exported by the EAP method. The MSK is at least 64 octets in length. In existing implementations, a AAA server acting as an EAP server transports the MSK to the authenticator. Extended Master Session Key (EMSK) Additional keying material derived between the EAP client and server that is exported by the EAP method. The EMSK is at least 64 octets in length. The EMSK is not shared with the authenticator or any other third party. The EMSK is reserved for future uses that are not defined yet. Ray -----Original Message----- From: Alper Yegin [mailto:alper.yegin@yegin.org] Sent: Tuesday, November 21, 2006 8:21 AM To: 'Bernard Aboba'; hokeyp@opendiameter.org Cc: emu@ietf.org Subject: RE: [Emu] MSK but no EMSK Thank you for this survey. One question though. I couldn't find any mention of "MSK" or "EMSK" in RFC 2716. Can you tell us how to get those keys out of that spec? Alper > -----Original Message----- > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] > Sent: Sunday, November 19, 2006 8:44 PM > To: alper.yegin@yegin.org; hokeyp@opendiameter.org > Cc: emu@ietf.org > Subject: RE: [Emu] MSK but no EMSK > > >I remember someone in Hokey WG meeting mentioned that not all methods > >generate EMSK (even though they generate MSK). Is that accurate? > > The simple answer is "we don't know" because prior to RFC 3748, EAP Type > Codes could be allocated without a specification. > > However, for methods published as RFCs or in the RFC Editor Queue, we know > the following: > > a) None of the RFC 3748-specified EAP methods generate keys (EAP MD5, OTP, > GTC). > > b) All of the key generating EAP methods published as RFCs specify how to > derive the MSK and EMSK. This includes EAP TLS (RFC 2716), EAP SIM (RFC > 4186), and EAP AKA (RFC 4817). The generation of the Session-Id, Peer-Id > and Server-Id is also specified for these methods in the Key Management > Framework document. > > c) All of the key generating EAP methods currently in the RFC Editor queue > specify how to derive both the MSK and EMSK. This includes EAP PSK > (draft-bersani-eap-psk-11.txt), EAP SAKE (draft-vanderveen-eap-sake- > 02.txt), > EAP PAX (draft-clancy-eap-pax-11.txt), EAP POTP > (draft-nystrom-eap-potp-07.txt). None of these methods specify how to > derive the Peer-Id, Server-Id and Session-Id (e.g. they are non-compliant > with the EAP Key Management Framework). > > d) Allocation of an EAP Type Code requires specification of the MSK, EMSK, > and Session-Id and Peer-Id/Server-Id if known. > _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Mon Nov 27 18:12:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GopeV-0006Mm-Ae; Mon, 27 Nov 2006 18:12:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GopeT-0006Mg-US for emu@ietf.org; Mon, 27 Nov 2006 18:12:41 -0500 Received: from usaga01-in.huawei.com ([12.129.211.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GopeO-00053O-4a for emu@ietf.org; Mon, 27 Nov 2006 18:12:41 -0500 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J9E00MBFWGXSX@usaga01-in.huawei.com> for emu@ietf.org; Mon, 27 Nov 2006 15:12:33 -0800 (PST) Received: from N737011 (pool-71-112-12-134.sttlwa.dsl-w.verizon.net [71.112.12.134]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J9E00GA2WGSJ3@usaga01-in.huawei.com> for emu@ietf.org; Mon, 27 Nov 2006 15:12:33 -0800 (PST) Date: Mon, 27 Nov 2006 15:12:28 -0800 From: Madjid Nakhjiri In-reply-to: <20061123014533.GG10177@steelhead> To: 'Yoshihiro Ohba' , hokeyp@opendiameter.org Message-id: <001b01c71279$826f6630$2f01a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AccO1hh9K/ASxRt/SreW5lltMs2mZQDoFT+A X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: emu@ietf.org Subject: [Emu] RE: [Hokeyp] USRK issue X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Hi Yoshi, I cced EMU since I thought we could use some of the expertise there. Yes, this absolutely has to do the "key derivation" portion of application keying. We just thought the term "application" is confusing and used "usage specific" instead. Please note that the full scope of "application keying" is a lot wider than just deriving the USRKs. No child key derivation, key distribution or authorization issues are being discussed. We may however need to create a "handover USRK" if we go based on EMSK for hokey. So at least we got a small part of "application keying" idea approved in the charter and that is not a bad thing IMO. Now, any time you have a key hierarchy where the lifetimes are completely dependent on the top level key lifetimes, you need to re-key the whole tree. I don't know how that is different for Kerberos, say you are doing a Kerberos-EAP combo method, where your key wrapping mechanism uses a key that itself is based on an EMSK that is refreshed, then you are back to square one. You have to rekey your key wrapping key too. I don't agree with the fact that rekeying one USRK would require rekeying other USRK, there supposed to be a crypto-separation between the USRKs and from USRK up to EMSK. So as long as you can access the EMSK you can rekey an individual USRK if you want. Now as far as the need for rekeying USRK based on rekeying EMSK, the more philosophic question is this: say I have a usage (take Mobile IP) that needs a MIP-USRK, from which a bunch of other MIP related keys are derived (say Mobile node-home agent key, MN_HA_key). The AAA needs to authorize MIP before the MIP-USRK is generated, but EMSK is not exported to the AAA layer, which means, the AAA server/layer needs to request the EAP/ method layer/"EMSK-key holder" to generate the MIP-USRK for it. At this point and beyond, it should be up to the AAA server to decide how long the user is authorized to do MIP and then decide the life time for MIP-USRK or the children keys (MN_HA_KEY). Why would the AAA have to tie the MIP-USRK or MN_HA_KEY to the EMSK anymore? Why should MIP authorization and security be tied to the initial EAP access authentication? If you agree with this, then EMSK rekeying would not automatically require USRK rekeying for every USRK? If not, then yes, there is a problem. Madjid -----Original Message----- From: hokeyp-bounces@opendiameter.org [mailto:hokeyp-bounces@opendiameter.org] On Behalf Of Yoshihiro Ohba Sent: Wednesday, November 22, 2006 5:46 PM To: hokeyp@opendiameter.org Subject: [Hokeyp] USRK issue (I tried to reply the following thread but somehow my reply did not appear to the list: http://www.opendiameter.org/pipermail/hokeyp/2006-November/000356.html, so let me post with a new thread.) I have a fundamental issue with deriving multiple root keys used for different purposes as a form of key hierarchy. There are two reasons. When re-keying of EMSK happens, it would require all USRKs derived from EMSK to be re-keyed, regardless of the purposes the USRKs are used for. Second, it is difficult to re-key only a specific USRK without re-keying other USRKs as well. If we consider use of EAP for multiple different types of applications, this issue seems critical to me. I would suggest further investigating this fundamental issue before WG adoption of draft-salowey-eap-emsk-deriv-01. My sense is that a Kerberos-like approach (i.e., use of tickets that carries encrypted key and associated attributes including lifetime and key scope/usage) is much better than key derivation approach such as described in draft-salowey-eap-emsk-deriv-01, from key management perspective even if we consider the complexity aspect of a Kerberos-like approach. I would like to also point out that USRK is related to so called "application keying" in HOAKEY BOF in March 2006, and "application keying" was ruled out from the BOF discussion. Regards, Yoshihiro Ohba _______________________________________________ Hokeyp mailing list Hokeyp@opendiameter.org http://www.opendiameter.org/mailman/listinfo/hokeyp _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Mon Nov 27 20:49:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gos68-0003tr-D6; Mon, 27 Nov 2006 20:49:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gos67-0003tV-NN for emu@ietf.org; Mon, 27 Nov 2006 20:49:23 -0500 Received: from [2001:418:1403:0:212:17ff:fe52:7811] (helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gos64-0007ZS-Ae for emu@ietf.org; Mon, 27 Nov 2006 20:49:23 -0500 Received: from localhost (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id kAS1mFYd027107; Mon, 27 Nov 2006 20:48:15 -0500 (EST) (envelope-from yohba@tari.toshiba.com) Date: Mon, 27 Nov 2006 20:48:17 -0500 To: Madjid Nakhjiri Message-ID: <20061128014817.GF7823@steelhead> References: <20061123014533.GG10177@steelhead> <001b01c71279$826f6630$2f01a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <001b01c71279$826f6630$2f01a8c0@china.huawei.com> User-Agent: Mutt/1.5.13 (2006-08-11) From: Yoshihiro Ohba X-Dispatcher: imput version 20050308(IM148) Lines: 116 X-Spam-Score: -2.4 (--) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: hokeyp@opendiameter.org, emu@ietf.org Subject: [Emu] Re: [Hokeyp] USRK issue X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Hi Madjid, On Mon, Nov 27, 2006 at 03:12:28PM -0800, Madjid Nakhjiri wrote: > Hi Yoshi, > > I cced EMU since I thought we could use some of the expertise there. > > Yes, this absolutely has to do the "key derivation" portion of application > keying. We just thought the term "application" is confusing and used "usage > specific" instead. Please note that the full scope of "application keying" > is a lot wider than just deriving the USRKs. No child key derivation, key > distribution or authorization issues are being discussed. We may however > need to create a "handover USRK" if we go based on EMSK for hokey. So at > least we got a small part of "application keying" idea approved in the > charter and that is not a bad thing IMO. > > Now, any time you have a key hierarchy where the lifetimes are completely > dependent on the top level key lifetimes, you need to re-key the whole tree. > I don't know how that is different for Kerberos, say you are doing a > Kerberos-EAP combo method, where your key wrapping mechanism uses a key that > itself is based on an EMSK that is refreshed, then you are back to square > one. You have to rekey your key wrapping key too. Re-keying key wrapping key may not necessary mean immediate re-keying the keys wrapped by the key wrapping key, because the wrapped key has no cryptographic dependency with the key wrapping key. In the case of Kerberos, whether immediate re-keying is needed when key wrapping key is invalidated seems to be rather an authorization policy issue. In the case of key-hierarchy based approach, there is a cryptographic dependency between the root key and its child keys. Hence, if the root key is re-keyed, then the old root key is not valid, and it is natural to think that the child keys derived from the old root key are no longer valid and re-keying is needed. > > I don't agree with the fact that rekeying one USRK would require rekeying > other USRK, there supposed to be a crypto-separation between the USRKs and > from USRK up to EMSK. So as long as you can access the EMSK you can rekey an > individual USRK if you want. Selective re-keying in key hiearchy approach would be possible only up to the EMSK lifetime and with the use of a usage-specific re-keying protocol. I think this should be cleary spelled out in the I-D. > > Now as far as the need for rekeying USRK based on rekeying EMSK, the more > philosophic question is this: > say I have a usage (take Mobile IP) that needs a MIP-USRK, from which a > bunch of other MIP related keys are derived (say Mobile node-home agent key, > MN_HA_key). The AAA needs to authorize MIP before the MIP-USRK is generated, > but EMSK is not exported to the AAA layer, which means, the AAA server/layer > needs to request the EAP/ method layer/"EMSK-key holder" to generate the > MIP-USRK for it. At this point and beyond, it should be up to the AAA > server to decide how long the user is authorized to do MIP and then decide > the life time for MIP-USRK or the children keys (MN_HA_KEY). Why would the > AAA have to tie the MIP-USRK or MN_HA_KEY to the EMSK anymore? Why should > MIP authorization and security be tied to the initial EAP access > authentication? If you create those keys based on key derivation not key wrapping, then the AAA would have to tie those keys because there is cryptographic dependency between parent and child keys. If you don't want to tie those keys, then key derivation should not be used, IMO. Yoshihiro Ohba > If you agree with this, then EMSK rekeying would not automatically require > USRK rekeying for every USRK? If not, then yes, there is a problem. > > Madjid > > -----Original Message----- > From: hokeyp-bounces@opendiameter.org > [mailto:hokeyp-bounces@opendiameter.org] On Behalf Of Yoshihiro Ohba > Sent: Wednesday, November 22, 2006 5:46 PM > To: hokeyp@opendiameter.org > Subject: [Hokeyp] USRK issue > > (I tried to reply the following thread but somehow my reply did not > appear to the list: > http://www.opendiameter.org/pipermail/hokeyp/2006-November/000356.html, > so let me post with a new thread.) > > I have a fundamental issue with deriving multiple root keys > used for different purposes as a form of key hierarchy. > > There are two reasons. When re-keying of EMSK happens, it would > require all USRKs derived from EMSK to be re-keyed, regardless of the > purposes the USRKs are used for. Second, it is difficult to re-key > only a specific USRK without re-keying other USRKs as well. If we > consider use of EAP for multiple different types of applications, this > issue seems critical to me. > > I would suggest further investigating this fundamental issue before WG > adoption of draft-salowey-eap-emsk-deriv-01. My sense is that a > Kerberos-like approach (i.e., use of tickets that carries encrypted > key and associated attributes including lifetime and key scope/usage) > is much better than key derivation approach such as described in > draft-salowey-eap-emsk-deriv-01, from key management perspective even > if we consider the complexity aspect of a Kerberos-like approach. > > I would like to also point out that USRK is related to so called > "application keying" in HOAKEY BOF in March 2006, and "application > keying" was ruled out from the BOF discussion. > > Regards, > Yoshihiro Ohba > _______________________________________________ > Hokeyp mailing list > Hokeyp@opendiameter.org > http://www.opendiameter.org/mailman/listinfo/hokeyp > > > _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Tue Nov 28 19:19:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpDAs-0000mL-Th; Tue, 28 Nov 2006 19:19:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpDAr-0000k8-M6 for emu@ietf.org; Tue, 28 Nov 2006 19:19:41 -0500 Received: from usaga01-in.huawei.com ([12.129.211.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpDAn-0002Ph-AH for emu@ietf.org; Tue, 28 Nov 2006 19:19:41 -0500 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J9G002C5U8OPW@usaga01-in.huawei.com> for emu@ietf.org; Tue, 28 Nov 2006 16:19:36 -0800 (PST) Received: from N737011 (c-24-17-254-79.hsd1.wa.comcast.net [24.17.254.79]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J9G003XJU8J6A@usaga01-in.huawei.com> for emu@ietf.org; Tue, 28 Nov 2006 16:19:36 -0800 (PST) Date: Tue, 28 Nov 2006 16:19:32 -0800 From: Madjid Nakhjiri Subject: RE: [Hokeyp] [Emu] Re: MSK but no EMSK In-reply-to: <20061119133625.GA6626@steelhead> To: 'Yoshihiro Ohba' Message-id: <000f01c7134c$0b13fcd0$02fda8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Thread-index: AccN5PP19A5VRn5QRb+g5lnB2Ye4hgFZrTwg X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: hokeyp@opendiameter.org, emu@ietf.org, "'Blumenthal, Uri'" X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Hi Yoshi, Sorry for the very late response. I think the issue was whether methods generate EMSK or not, there was not a discussion of usage. Now, some method do generate EMSK and some don't. The same way that some EAP method did one-way authentication and some did mutual authentication. It is the job of the security engineer to pick the right EAP method, more clearly, if he/she needs EMSK and the method does not give it, he/she picks something else, there is no rocket science here. R, Madjid -----Original Message----- From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] Sent: Sunday, November 19, 2006 5:36 AM To: Madjid Nakhjiri Cc: 'Yoshihiro Ohba'; 'Blumenthal, Uri'; hokeyp@opendiameter.org; emu@ietf.org Subject: Re: [Hokeyp] [Emu] Re: MSK but no EMSK Hi Madjid, The problem we are facing with EMSK is that the key and its usage were not defined *at one time". For this reason, I don't agree with mandating the use of EMSK for all implementations. Only making use of EMSK optional makes sense to me, regardless of how it is going to be used. Yoshihiro Ohba On Tue, Nov 21, 2006 at 08:50:46AM -0800, Madjid Nakhjiri wrote: > Hi Yoshi, > > I don't quite agree with this. Defining the full functionality of a new EAP > method (including how it spits out MSK and EMSK) should be the job the EAP > method designer. 3748, EAP keying framework and hokey specs then define how > MSK or EMSK is used. This is modular design. People who use EMSK then do not > have to worry about the crypto behind EMSK generation. > Using your analogy is "go buy the key and lock" but then wait to see which > door you want to install it on:) > I as a home owner do not need to know how to make locks. > > R, > > Madjid > > -----Original Message----- > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > Sent: Friday, November 17, 2006 11:36 AM > To: Blumenthal, Uri > Cc: hokeyp@opendiameter.org; emu@ietf.org > Subject: Re: [Hokeyp] [Emu] Re: MSK but no EMSK > > Hi Uri, > > I have a different view. Mandating generation of EMSK without having > defined its usage *when it was introduced* seems not much different > from not having defining it at all. It looks like selling a key > without a lock, make the lock later and say "You MUST use this key and > lock for your car." Make sense?? > > Yoshihiro Ohba > > > > On Fri, Nov 17, 2006 at 09:22:04AM -0500, Blumenthal, Uri wrote: > > >The discussion focuses on the problem EMSK is optional or mandatory. > > > > I don't think this is a problem - GENERATION of EMSK is compulsoty as > > spelled out in RFC 3578. > > > > The problem is non-compliance. Some, er, people seem to think "the > > standard says do A, but since I don't use A at the moment - I won't > > bother." > > > > >RFC3578 defined EMSK is mandatory, > > > > And that should be the end of discussion. > > > > > but it is not used at all. > > > > First - do you know all the applications that use key-generating EAP > > methods? But really - who cares? > > > > >If EMSK must be used, it is mandatory. if no, I think, > > >it may be better that it is optional. > > > > VERY strongly disagree. Mandatory is what is explicitly specified as > > mandatory, period. Otherwise many would implement just those pieces and > > features of the standard that his particular product needs today. > > > > (I'm proud of my restraint - not even once using a term "B*S*" :-) > > _______________________________________________ > > Hokeyp mailing list > > Hokeyp@opendiameter.org > > http://www.opendiameter.org/mailman/listinfo/hokeyp > > > > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www1.ietf.org/mailman/listinfo/emu > > _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Thu Nov 30 01:56:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpfqR-0004Jo-US; Thu, 30 Nov 2006 01:56:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpfqQ-0004Je-IC for emu@ietf.org; Thu, 30 Nov 2006 01:56:30 -0500 Received: from usaga01-in.huawei.com ([12.129.211.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpfqP-0004V9-7V for emu@ietf.org; Thu, 30 Nov 2006 01:56:30 -0500 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J9J00H9T7A4M0@usaga01-in.huawei.com> for emu@ietf.org; Wed, 29 Nov 2006 22:56:28 -0800 (PST) Received: from N737011 (c-24-17-254-79.hsd1.wa.comcast.net [24.17.254.79]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J9J0082V79VIM@usaga01-in.huawei.com> for emu@ietf.org; Wed, 29 Nov 2006 22:56:28 -0800 (PST) Date: Wed, 29 Nov 2006 22:56:19 -0800 From: Madjid Nakhjiri Subject: RE: [Hokeyp] [Emu] Re: MSK but no EMSK/USRKs In-reply-to: <6.2.3.4.2.20061124235522.05853290@getmail.mitton.com> To: 'David Mitton' , emu@ietf.org Message-id: <001b01c7144c$a6287dd0$02fda8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AccQU9XhgFpr/4a1RLyWQxDj0TqlvgD90z9g X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: hokeyp@opendiameter.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Hi Dave, Thanks for singling out my response. I am choosing to feel good about it:) Your point about the need for an API is really a good one that nobody is discussing in this lengthy thread and the other thread going on in Hokey. I alluded to it several times in EAP WG list, here and on hokey list. Yes, the fact that EMSK is not to be exported, is a scream in the forest, well guess what, For a while people wanted to even throw EMSK cache away, so we managed to get that out of the system:) Now, hokey and others want to use EMSK to generate usage specific root keys (USRK). Once those specs are out, implementers must implement EMSK and some sort of API as follows: If EMSK never gets to the AAA layer, then the AAA layer cannot generate the USRK from EMSK itself. AAA layer must after authorizing a usage, ask EAP layer (who holds the EMSK) to generate a USRK for a specific usage. So this basically means a logical module acting as the EAP server that holds EMSK, must have an API to the AAA module to receive a request for USRK generate it and then send it back. R, Madjid -----Original Message----- From: David Mitton [mailto:david@mitton.com] Sent: Friday, November 24, 2006 9:29 PM To: emu@ietf.org Subject: RE: [Hokeyp] [Emu] Re: MSK but no EMSK I haven't had time to join this discussion prior to this, but I'll just pick this response out of the stream and make a comment or two: On 11/21/2006 11:50 AM, Madjid Nakhjiri wrote: >Hi Yoshi, > >I don't quite agree with this. Defining the full functionality of a new EAP >method (including how it spits out MSK and EMSK) should be the job the EAP >method designer. 3748, EAP keying framework and hokey specs then define how >MSK or EMSK is used. This is modular design. People who use EMSK then do not >have to worry about the crypto behind EMSK generation. >Using your analogy is "go buy the key and lock" but then wait to see which >door you want to install it on:) >I as a home owner do not need to know how to make locks. > >R, > >Madjid > The current specification require that a method generate EMSK, but then tell you not to show it to anyone. So to paraphrase the age old question, if an EAP method generates an EMSK in a forest and nobody hears it, does it comply with RFC3748? Until there is a standard API, or a definition of how a method exports an EMSK, or even uses an EMSK to produce a publicly visible result, this issue is a moot question, because there is no consequence of not producing an EMSK and saying that you did. The method is still a black box with this respect. In any case, when something does get defined that makes it matter, only then will method implementers have to make it happen. And it will require the modules to be updated to meet the new requirements, there's no other way. Dave. _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Thu Nov 30 13:25:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpqbH-0005n5-5m; Thu, 30 Nov 2006 13:25:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpqbF-0005m1-F4 for emu@ietf.org; Thu, 30 Nov 2006 13:25:33 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpqbD-0001Vx-2L for emu@ietf.org; Thu, 30 Nov 2006 13:25:33 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-5.cisco.com with ESMTP; 30 Nov 2006 10:25:30 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id kAUIPTI7027083 for ; Thu, 30 Nov 2006 10:25:29 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kAUIOujR016150 for ; Thu, 30 Nov 2006 10:25:29 -0800 (PST) Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Nov 2006 10:25:02 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 30 Nov 2006 10:25:01 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Password based method design team Thread-Index: AccUrNkSTlTIeDE/TN2YfjLJa80I4w== From: "Joseph Salowey \(jsalowey\)" To: X-OriginalArrivalTime: 30 Nov 2006 18:25:02.0892 (UTC) FILETIME=[DA126EC0:01C714AC] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1129; t=1164911129; x=1165775129; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20\(jsalowey\)=22=20 |Subject:=20Password=20based=20method=20design=20team |Sender:=20; bh=K2a6r4tUtZfyhs4walq3WKdU701Iv1tZzvch5vHoIg8=; b=ThOqjY53eVZot2zRg1PMDzxInuXnw37DGdglCJWndK7wyWV4ruBwVbXSjG1MviudhkFYTzqR i81qOEjdbNJcMyXOw5AkwBSMeGNh3/17gOXRQcUzpMEaLzsscFtpe7jc; Authentication-Results: sj-dkim-3; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Subject: [Emu] Password based method design team X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Hi all, This message is to inform the EMU working group that EMU password based design team has been formed. The members of the design team are: Charles Clancy, Hannes Tschofenig, Hao Zhou, Jouni Malinen, Madjid Nakhjiri, Mohamed Badra, Pascal Urien, Ray Bell, Vijay Devarapalli and the EMU chair.=20 The purpose of this design team is to complete the following WG charter item: "A mechanism meeting RFC 3748 and RFC 4017 requirements that makes use of existing password databases such as AAA databases. The implementation should strive to be usable in resource constrained environments." The output of the design team is one or more documents to the EMU working group. This design team will use a separate mailing list and conference calls. The initial deliverable is a statement of a basic approach to be used in developing the method sent to the working group list for discussion. As with any design team in the IETF, the output of this design team must be approved by the EMU working group nor carries any special consideration in development of EMU working group consensus. Cheers, Joe _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Thu Nov 30 13:28:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpqeW-0007iN-ND; Thu, 30 Nov 2006 13:28:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpqeW-0007hp-1b for emu@ietf.org; Thu, 30 Nov 2006 13:28:56 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpqeU-0001wu-DQ for emu@ietf.org; Thu, 30 Nov 2006 13:28:56 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-4.cisco.com with ESMTP; 30 Nov 2006 10:28:53 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id kAUISrLL005038 for ; Thu, 30 Nov 2006 10:28:53 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id kAUISqW4010606 for ; Thu, 30 Nov 2006 10:28:52 -0800 (PST) Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Nov 2006 10:28:51 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 30 Nov 2006 10:28:51 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG Last Call: draft-simon-emu-rfc2716bis-05 Thread-Index: AccUrWIPnjla35lVQR6XtH3XjQcETw== From: "Joseph Salowey \(jsalowey\)" To: X-OriginalArrivalTime: 30 Nov 2006 18:28:51.0675 (UTC) FILETIME=[626FF2B0:01C714AD] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=257; t=1164911333; x=1165775333; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20\(jsalowey\)=22=20 |Subject:=20WG=20Last=20Call=3A=20draft-simon-emu-rfc2716bis-05 |Sender:=20; bh=Byydsfh0t93bhz1HwWh+NJYDw1Rg6ggnPUsjfeR2GKw=; b=Pa1uugPtu8D9+lA5J+eQeyYUnpOP7eG1pmvkL74ZKVOII6gs7eBSPoMyFbZm1jYpPqRNtWVb 0jufLk881Q2h5YaGeTQgMcv6voi2E81Pc4CtFA2JZ2LoGGUGH/qxABrf; Authentication-Results: sj-dkim-2; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Subject: [Emu] WG Last Call: draft-simon-emu-rfc2716bis-05 X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org This is a working group last call for draft-simon-emu-rfc2716bis-05. =20 Please send you comments to the emu list by December 29, 2006.=20 The document can be accessed here: http://www.ietf.org/internet-drafts/draft-simon-emu-rfc2716bis-05.txt. =20 _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Thu Nov 30 18:01:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpuuD-00054T-KC; Thu, 30 Nov 2006 18:01:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpuuD-00054O-4u for emu@ietf.org; Thu, 30 Nov 2006 18:01:25 -0500 Received: from usaga01-in.huawei.com ([12.129.211.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpuuA-0008Ql-6c for emu@ietf.org; Thu, 30 Nov 2006 18:01:25 -0500 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J9K003G9FY9D1@usaga01-in.huawei.com> for emu@ietf.org; Thu, 30 Nov 2006 15:01:21 -0800 (PST) Received: from N737011 (pool-71-112-12-134.sttlwa.dsl-w.verizon.net [71.112.12.134]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J9K00928FY4XX@usaga01-in.huawei.com> for emu@ietf.org; Thu, 30 Nov 2006 15:01:21 -0800 (PST) Date: Thu, 30 Nov 2006 15:01:15 -0800 From: Madjid Nakhjiri In-reply-to: <20061128014817.GF7823@steelhead> To: 'Yoshihiro Ohba' Message-id: <003901c714d3$704d5640$2f01a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AccSj1NE4+MAoeOSQaWRIw4+tnKWKACQzkNA X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: hokeyp@opendiameter.org, emu@ietf.org Subject: [Emu] RE: [Hokeyp] USRK issue X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Hi Yoshi, -----Original Message----- From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] Sent: Monday, November 27, 2006 5:48 PM To: Madjid Nakhjiri Cc: 'Yoshihiro Ohba'; hokeyp@opendiameter.org; emu@ietf.org Subject: Re: [Hokeyp] USRK issue > > Now, any time you have a key hierarchy where the lifetimes are completely > dependent on the top level key lifetimes, you need to re-key the whole tree. > I don't know how that is different for Kerberos, say you are doing a > Kerberos-EAP combo method, where your key wrapping mechanism uses a key that > itself is based on an EMSK that is refreshed, then you are back to square > one. You have to rekey your key wrapping key too. Re-keying key wrapping key may not necessary mean immediate re-keying the keys wrapped by the key wrapping key, because the wrapped key has no cryptographic dependency with the key wrapping key. In the case of Kerberos, whether immediate re-keying is needed when key wrapping key is invalidated seems to be rather an authorization policy issue. Madjid>> I thought we were discussing rekeying of USRKs, so I assumed your Kerberos example was a use case for USRK spec and that is why I said the key wrapping key could be a USRK. And yes, this being an "authorization policy" is exactly the point I am making In the case of key-hierarchy based approach, there is a cryptographic dependency between the root key and its child keys. Hence, if the root key is re-keyed, then the old root key is not valid, and it is natural to think that the child keys derived from the old root key are no longer valid and re-keying is needed. Madjid>>I don't think cryptographic dependency necessarily translates into life time dependency, especially if the authorization entity (AAA server) is possibly different from the entity generating the key (EAP server). Yes, if you need to rekey using a root key and the root key is now updated, you should use the updated key, but I think that can be worked into the AAA server-EAP server API. I am using this terminology, since we know EMSK is not exported from EAP layer. > _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Thu Nov 30 18:47:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpvcN-0005rD-QD; Thu, 30 Nov 2006 18:47:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpvcM-0005p4-JH for emu@ietf.org; Thu, 30 Nov 2006 18:47:02 -0500 Received: from mail713.megamailservers.com ([69.49.98.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpvcL-0005om-8x for emu@ietf.org; Thu, 30 Nov 2006 18:47:02 -0500 X-Authenticated-User: ray.grid-net.com Received: from RBLAPTOP (h-68-167-203-99.snfccasy.covad.net [68.167.203.99]) (authenticated bits=0) by mail713.megamailservers.com (8.13.6.20060614/8.13.1) with ESMTP id kAUNkhmB014664; Thu, 30 Nov 2006 18:46:46 -0500 From: "Ray Bell" To: "'Madjid Nakhjiri'" , "'Yoshihiro Ohba'" Subject: RE: [Emu] RE: [Hokeyp] USRK issue Date: Thu, 30 Nov 2006 15:46:41 -0800 Message-ID: <005d01c714d9$ca2d65a0$63cba744@RBLAPTOP> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AccSj1NE4+MAoeOSQaWRIw4+tnKWKACQzkNAAAGYp/A= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 In-Reply-To: <003901c714d3$704d5640$2f01a8c0@china.huawei.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: hokeyp@opendiameter.org, emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Some comments below Ray -----Original Message----- From: Madjid Nakhjiri [mailto:mnakhjiri@huawei.com] Sent: Thursday, November 30, 2006 3:01 PM To: 'Yoshihiro Ohba' Cc: hokeyp@opendiameter.org; emu@ietf.org Subject: [Emu] RE: [Hokeyp] USRK issue Hi Yoshi, -----Original Message----- From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] Sent: Monday, November 27, 2006 5:48 PM To: Madjid Nakhjiri Cc: 'Yoshihiro Ohba'; hokeyp@opendiameter.org; emu@ietf.org Subject: Re: [Hokeyp] USRK issue > > Now, any time you have a key hierarchy where the lifetimes are completely > dependent on the top level key lifetimes, you need to re-key the whole tree. > I don't know how that is different for Kerberos, say you are doing a > Kerberos-EAP combo method, where your key wrapping mechanism uses a key that > itself is based on an EMSK that is refreshed, then you are back to square > one. You have to rekey your key wrapping key too. Re-keying key wrapping key may not necessary mean immediate re-keying the keys wrapped by the key wrapping key, because the wrapped key has no cryptographic dependency with the key wrapping key. In the case of Kerberos, whether immediate re-keying is needed when key wrapping key is invalidated seems to be rather an authorization policy issue. Madjid>> I thought we were discussing rekeying of USRKs, so I assumed your Kerberos example was a use case for USRK spec and that is why I said the key wrapping key could be a USRK. And yes, this being an "authorization policy" is exactly the point I am making In the case of key-hierarchy based approach, there is a cryptographic dependency between the root key and its child keys. Hence, if the root key is re-keyed, then the old root key is not valid, and it is natural to think that the child keys derived from the old root key are no longer valid and re-keying is needed. Ray >> So this would pertain to the MSK, it being the root key - yes? Not to the EMSK. Madjid>>I don't think cryptographic dependency necessarily translates into life time dependency, especially if the authorization entity (AAA server) is possibly different from the entity generating the key (EAP server). Yes, if you need to rekey using a root key and the root key is now updated, you should use the updated key, but I think that can be worked into the AAA server-EAP server API. I am using this terminology, since we know EMSK is not exported from EAP layer. Ray >> SDO policy information models support this type of authorization policy modeling, distribution and enforcement. _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Thu Nov 30 20:16:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gpx0d-0002Xy-0l; Thu, 30 Nov 2006 20:16:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gpx0b-0002Xt-Sn for emu@ietf.org; Thu, 30 Nov 2006 20:16:09 -0500 Received: from usaga01-in.huawei.com ([12.129.211.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gpx0a-0002gY-Js for emu@ietf.org; Thu, 30 Nov 2006 20:16:09 -0500 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J9K009T3M6SJ6@usaga01-in.huawei.com> for emu@ietf.org; Thu, 30 Nov 2006 17:16:04 -0800 (PST) Received: from N737011 (pool-71-112-12-134.sttlwa.dsl-w.verizon.net [71.112.12.134]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J9K006GZM6O0H@usaga01-in.huawei.com> for emu@ietf.org; Thu, 30 Nov 2006 17:16:04 -0800 (PST) Date: Thu, 30 Nov 2006 17:15:58 -0800 From: Madjid Nakhjiri Subject: RE: [Emu] RE: [Hokeyp] USRK issue In-reply-to: <005d01c714d9$ca2d65a0$63cba744@RBLAPTOP> To: 'Ray Bell' , 'Yoshihiro Ohba' Message-id: <008701c714e6$4229fcb0$2f01a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AccSj1NE4+MAoeOSQaWRIw4+tnKWKACQzkNAAAGYp/AAA0QU8A== X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: hokeyp@opendiameter.org, emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Yes, SDOs are increasingly using AAA for variety of network security and authorization management tasks and for the AAA server to act as a center of authority, such flexibility is needed. Madjid -----Original Message----- From: Ray Bell [mailto:ray@grid-net.com] Sent: Thursday, November 30, 2006 3:47 PM To: 'Madjid Nakhjiri'; 'Yoshihiro Ohba' Cc: hokeyp@opendiameter.org; emu@ietf.org Subject: RE: [Emu] RE: [Hokeyp] USRK issue Madjid>>I don't think cryptographic dependency necessarily translates into life time dependency, especially if the authorization entity (AAA server) is possibly different from the entity generating the key (EAP server). Yes, if you need to rekey using a root key and the root key is now updated, you should use the updated key, but I think that can be worked into the AAA server-EAP server API. I am using this terminology, since we know EMSK is not exported from EAP layer. Ray >> SDO policy information models support this type of authorization policy modeling, distribution and enforcement. _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu