From hokey-bounces@ietf.org Wed Aug 01 10:04:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGEoB-0000Z7-GS; Wed, 01 Aug 2007 10:04:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGEo9-0000XY-AF for hokey@ietf.org; Wed, 01 Aug 2007 10:04:13 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IGEo7-0007Yo-N3 for hokey@ietf.org; Wed, 01 Aug 2007 10:04:13 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l71E45W4002978; Wed, 1 Aug 2007 17:04:07 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Aug 2007 17:03:58 +0300 Received: from esebe104.NOE.Nokia.com ([172.21.143.44]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Aug 2007 17:03:57 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [HOKEY] revisions to reauth problem statement Date: Wed, 1 Aug 2007 17:03:12 +0300 Message-ID: <83CD3A5F85DE7D43B6A5CC37CCBAEECE04127139@esebe104.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: [HOKEY] revisions to reauth problem statement Thread-Index: AcfURLLeCHsHtvrAQkmJjK8oMUSOmA== From: To: X-OriginalArrivalTime: 01 Aug 2007 14:03:57.0881 (UTC) FILETIME=[CDCA7290:01C7D444] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Cc: hokey@ietf.org X-BeenThere: hokey@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: HOKEY WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0097097961==" Errors-To: hokey-bounces@ietf.org This is a multi-part message in MIME format. --===============0097097961== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7D444.B3303990" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7D444.B3303990 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Hope I'm not responding after deadline for subjected text. If not then here there are few points/suggestions, perhaps you would like to add Referring to section 5 - Design goals -=20 This section very well explains various goals. However in subsection 'lower latency operation' - it can be emphasized in following way -=20 Re-authentication process can be reactive or proactive(e.g. pre-auth) and design goals for these two different approaches should consider low latency performance objective. =20 Referring to section 6 - Security goals -=20 1. key derivation function and keying material format 2. Acceptable policies for handover key recovery? If such points are within the scope of Design goals + security goals then relevant text can be placed. Regds Preeti=20 >I've put together some revisions to the reauth problem statement draft: >http://www.ltsnet.net/ietf/hokey/draft-ietf-hokey-reauth-ps-02a.txt Any comments? Anything else that should be added? Once submissions for IDs reopens, I plan to submit >the updated document, and then go to WGLC. ------_=_NextPart_001_01C7D444.B3303990 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [HOKEY] revisions to reauth problem statement

Hi,

Hope I'm not responding after = deadline for subjected text. If not then here there are few = points/suggestions, perhaps you would like to add

Referring to section 5 - Design = goals -

This section very well explains = various goals. However in subsection 'lower latency operation' - it can = be emphasized in following way -

Re-authentication process can be = reactive or proactive(e.g. pre-auth) and design goals for these two = different approaches should consider low latency performance = objective.  

Referring to section 6 - Security = goals -

1. key derivation function and = keying material format
2. Acceptable policies for = handover key recovery?

If such points are within the = scope of Design goals + security goals then relevant text can be = placed.

Regds
Preeti




>I've put together some revisions to the reauth = problem statement draft:

>http://www.ltsnet.net/ietf/hokey/draft-ietf-hokey-reauth-ps-02a.txt<= /FONT>

<It addresses issues #33 and #34.

>Any = comments? Anything else that should be added? Once submissions for IDs = reopens, I plan to submit >the updated document, and = then go to WGLC.

------_=_NextPart_001_01C7D444.B3303990-- --===============0097097961== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ HOKEY mailing list HOKEY@ietf.org https://www1.ietf.org/mailman/listinfo/hokey --===============0097097961==-- From hokey-bounces@ietf.org Thu Aug 02 16:00:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGgqk-0000oq-VL; Thu, 02 Aug 2007 16:00:47 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGgqj-0000oj-8g for hokey@ietf.org; Thu, 02 Aug 2007 16:00:45 -0400 Received: from consign.cs.umd.edu ([128.8.128.61]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IGgqi-0001lc-Uq for hokey@ietf.org; Thu, 02 Aug 2007 16:00:45 -0400 Received: from webmail.cs.umd.edu (clavin.cs.umd.edu [172.24.0.5]) by consign.cs.umd.edu (8.13.1/8.12.5) with ESMTP id l72K0YOn011544 for ; Thu, 2 Aug 2007 16:00:36 -0400 Received: from 63.239.69.1 (SquirrelMail authenticated user clancy) by webmail.cs.umd.edu with HTTP; Thu, 2 Aug 2007 16:00:35 -0400 (EDT) Message-ID: <38216.63.239.69.1.1186084835.squirrel@webmail.cs.umd.edu> Date: Thu, 2 Aug 2007 16:00:35 -0400 (EDT) From: "Charles Clancy" To: hokey@ietf.org User-Agent: SquirrelMail/1.4.10a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal 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=-4.399, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL 0.00, BAYES_00 -2.60) X-CSD-MailScanner-From: clancy@cs.umd.edu X-Spam-Status: No X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Subject: [HOKEY] WGLC: re-auth problem statement X-BeenThere: hokey@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: HOKEY WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hokey-bounces@ietf.org The updated re-auth problem statement has been posted: http://tools.ietf.org/html/draft-ietf-hokey-reauth-ps-02 We're issing working group last call on this document. Please send your comments to the list by August 17. -- t. charles clancy, ph.d. <> tcc@umd.edu <> eng.umd.edu/~tcc adjunct professor, electrical engineering, university of maryland _______________________________________________ HOKEY mailing list HOKEY@ietf.org https://www1.ietf.org/mailman/listinfo/hokey From hokey-bounces@ietf.org Fri Aug 03 08:04:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGvtB-0007VA-24; Fri, 03 Aug 2007 08:04:17 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGvt5-0007Qf-Ou; Fri, 03 Aug 2007 08:04:12 -0400 Received: from [202.99.23.227] (helo=people.com.cn) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IGvt4-0000FT-P7; Fri, 03 Aug 2007 08:04:11 -0400 Received: from people.com.cn([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jmc46b37e4a; Fri, 03 Aug 2007 20:16:03 +0800 Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm13146ae2fd6; Tue, 31 Jul 2007 02:04:02 +0800 Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC 2.9.5.8) with SMTP id AISP action; Tue, 31 Jul 2007 02:04:02 +0800 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFYqM-0005bO-1i; Mon, 30 Jul 2007 13:15:42 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFYqD-0005T2-Ns; Mon, 30 Jul 2007 13:15:33 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IFYqD-0001zd-8l; Mon, 30 Jul 2007 13:15:33 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 24AD72AC77; Mon, 30 Jul 2007 17:15:03 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IFYpi-0004nf-Ls; Mon, 30 Jul 2007 13:15:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 30 Jul 2007 13:15:02 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list X-AIMC-AUTH: (null) X-AIMC-MAILFROM: i-d-announce-bounces@ietf.org X-AIMC-AUTH: (null) X-AIMC-MAILFROM: Internet-Drafts@ietf.org X-Auto-Forward: jaglee@people.com.cn jag@kw.com.cn X-Spam-Score: 2.8 (++) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: hokey@ietf.org Subject: [HOKEY] I-D ACTION:draft-ietf-hokey-reauth-ps-02.txt X-BeenThere: hokey@ietf.org Reply-To: internet-drafts@ietf.org List-Id: HOKEY WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hokey-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 Handover Keying Working Group of the IETF. Title : Handover Key Management and Re-authentication Problem Statement Author(s) : C. Clancy Filename : draft-ietf-hokey-reauth-ps-02.txt Pages : 13 Date : 2007-7-30 This document describes the Handover Keying (HOKEY) problem statement. The current EAP keying framework is not designed to support re-authentication and handovers. This often cause unacceptable latency in various mobile wireless environments. HOKEY plans to address these HOKEY plans to address these problems by implementing a generic mechanism to reuse derived EAP keying material for handover. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-hokey-reauth-ps-02.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-hokey-reauth-ps-02.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-hokey-reauth-ps-02.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: <2007-7-30125229.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-hokey-reauth-ps-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-hokey-reauth-ps-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-7-30125229.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ HOKEY mailing list HOKEY@ietf.org https://www1.ietf.org/mailman/listinfo/hokey --NextPart-- From hokey-bounces@ietf.org Fri Aug 03 15:29:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IH2qS-00047c-F6; Fri, 03 Aug 2007 15:29:56 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IH2qS-00047X-0c for hokey@ietf.org; Fri, 03 Aug 2007 15:29:56 -0400 Received: from usaga01-in.huawei.com ([206.16.17.211]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IH2qR-0005Gi-Dg for hokey@ietf.org; Fri, 03 Aug 2007 15:29:55 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JM700BGSLH59Z@usaga01-in.huawei.com> for hokey@ietf.org; Fri, 03 Aug 2007 10:48:41 -0700 (PDT) Received: from N737011 ([10.192.25.70]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JM700HM5LH10R@usaga01-in.huawei.com> for hokey@ietf.org; Fri, 03 Aug 2007 10:48:41 -0700 (PDT) Date: Fri, 03 Aug 2007 10:48:36 -0700 From: Madjid Nakhjiri Subject: RE: [HOKEY] WGLC: re-auth problem statement In-reply-to: <38216.63.239.69.1.1186084835.squirrel@webmail.cs.umd.edu> To: 'Charles Clancy' , hokey@ietf.org Message-id: <003d01c7d5f6$853e9250$4619c00a@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: AcfVP5YGOjquvJIOQr+qgvN7iGMZqgAtqu+A X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: X-BeenThere: hokey@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: HOKEY WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hokey-bounces@ietf.org Hi Charles, Thanks for updating the doc. It would probably be good if we include some text on delivery of new keys to authenticators (as part of handover) in the problem statement section. Currently we do talk about re-auth but not handover keying. Madjid -----Original Message----- From: Charles Clancy [mailto:clancy@cs.umd.edu] Sent: Thursday, August 02, 2007 1:01 PM To: hokey@ietf.org Subject: [HOKEY] WGLC: re-auth problem statement The updated re-auth problem statement has been posted: http://tools.ietf.org/html/draft-ietf-hokey-reauth-ps-02 We're issing working group last call on this document. Please send your comments to the list by August 17. -- t. charles clancy, ph.d. <> tcc@umd.edu <> eng.umd.edu/~tcc adjunct professor, electrical engineering, university of maryland _______________________________________________ HOKEY mailing list HOKEY@ietf.org https://www1.ietf.org/mailman/listinfo/hokey _______________________________________________ HOKEY mailing list HOKEY@ietf.org https://www1.ietf.org/mailman/listinfo/hokey From hokey-bounces@ietf.org Fri Aug 03 16:15:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IH3YY-0004Ih-HO; Fri, 03 Aug 2007 16:15:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IH3YW-0004Ic-VD for hokey@ietf.org; Fri, 03 Aug 2007 16:15:28 -0400 Received: from usaga01-in.huawei.com ([206.16.17.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IH3YU-0000w5-5H for hokey@ietf.org; Fri, 03 Aug 2007 16:15:28 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JM700DZBS9N1K@usaga01-in.huawei.com> for hokey@ietf.org; Fri, 03 Aug 2007 13:15:24 -0700 (PDT) Received: from N737011 ([10.192.25.70]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JM7009MRS9JV7@usaga01-in.huawei.com> for hokey@ietf.org; Fri, 03 Aug 2007 13:15:23 -0700 (PDT) Date: Fri, 03 Aug 2007 13:15:46 -0700 From: Madjid Nakhjiri To: hokey@ietf.org Message-id: <005201c7d60b$13edbbc0$4619c00a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Mailer: Microsoft Office Outlook 11 Thread-index: AcfWCxNyhWstL+n0TB2ptSMRN1NWsg== X-Spam-Score: 0.0 (/) X-Scan-Signature: 025f8c5000216988bfe31585db759250 Cc: Subject: [HOKEY] Issue 10: Key type X-BeenThere: hokey@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: HOKEY WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1917183229==" Errors-To: hokey-bounces@ietf.org This is a multi-part message in MIME format. --===============1917183229== Content-type: multipart/alternative; boundary="Boundary_(ID_yWSd/V+FHKqtiWu9R9yZCw)" This is a multi-part message in MIME format. --Boundary_(ID_yWSd/V+FHKqtiWu9R9yZCw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Responding to Yoshi's comment on key-mgm doc on key types: I can see Yoshi's point. I think specifying the key type is cleaner than specifying server type. Now the question is in which messages is key type used and how is key type preference/info communicated 1) The third party could here announce what type of key it wants in the message 0 to the peer, so that the peer could communicate the key type in message 1 towards the server, I am not sure if this is the best option, given that the third party could be a domain server or an authenticator or a HOKEY server, things can get complicated if we want to define a generic protocol. Otherwise, the peer does not what type of key the exchange is about, until end of the exchange. Alternatives: 2) the third party can send a key type in message 2 to the server. 3) Server decides based on the policy and the service ID, what key type to generate. Finally the server needs to include key type in message 3 both in peer token and the token to the third party. Also, the third party announces its device ID to the peer in message 0. I think it should announce the domain ID too (maybe when there is a USRK involved, it won't be needed, not sure at this point). We can include Server ID, domain ID and key type in message going from third party to the server. I prefer option 2, any comments? Madjid [4] I think Key Type needs to be carried in the protocol to identify > the type of key (i.e., USRK, DSUSRK, DSRK, etc.) to be distributed to > the third party. I think that such a key type is part of information > to identity a key. > > Madjid>>Wouldn't you know that based on the type of third party you > Madjid>>are > dealing with? Sounds like the key name discussion. Then the issue would be how to identify the type of third party or server. --Boundary_(ID_yWSd/V+FHKqtiWu9R9yZCw) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Responding to Yoshi’s comment on key-mgm doc on key types:

 

I can see Yoshi’s point.

I think specifying the key type is cleaner than specifying server type.

 

Now the question is in which messages is key type used and how is key type preference/info communicated

 

1) The third party could here announce what type of key it wants in the message 0 to the peer, so that the peer could communicate the key type in message 1 towards the server, I am not sure if this is the best option, given that the third party could be a domain server or an authenticator or a HOKEY server, things can get complicated if we want to define a generic protocol.

 

Otherwise, the peer does not what type of key the exchange is about, until end of the exchange.

Alternatives:

2) the third party can send a key type in message 2 to the server.

3) Server decides based on the policy and the service ID, what key type to generate.

 

Finally the server needs to include key type in message 3 both in peer token and the token to the third party.

 

Also, the third party announces its device ID to the peer in message 0. I think it should announce the domain ID too (maybe when there is a USRK involved, it won’t be needed, not sure at this point).

 

We can include Server ID, domain ID and key type in message going from third party to the server.

 

I prefer option 2, any comments?

 

Madjid

 

 

[4] I think Key Type needs to be carried in the protocol to identify

> the type of key (i.e., USRK, DSUSRK, DSRK, etc.) to be distributed to

> the third party.  I think that such a key type is part of information

> to identity a key.

>

> Madjid>>Wouldn't you know that based on the type of third party you

> Madjid>>are

> dealing with? Sounds like the key name discussion.

 

Then the issue would be how to identify the type of third party or server.

 

 

--Boundary_(ID_yWSd/V+FHKqtiWu9R9yZCw)-- --===============1917183229== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ HOKEY mailing list HOKEY@ietf.org https://www1.ietf.org/mailman/listinfo/hokey --===============1917183229==-- From hokey-bounces@ietf.org Fri Aug 03 23:09:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IHA12-0008IM-Tx; Fri, 03 Aug 2007 23:09:20 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IHA0z-0008CP-Tq for hokey@ietf.org; Fri, 03 Aug 2007 23:09:18 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IHA0z-0005dA-3p for hokey@ietf.org; Fri, 03 Aug 2007 23:09:17 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 03 Aug 2007 20:09:16 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAHWKs0arR7MV/2dsb2JhbACCaQ X-IronPort-AV: i="4.19,219,1183359600"; d="scan'208,217"; a="510258690:sNHT51095126" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l7439GCj032472; Fri, 3 Aug 2007 20:09:16 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l7439GF4016178; Sat, 4 Aug 2007 03:09:16 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Aug 2007 20:09:15 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [HOKEY] Issue 10: Key type Date: Fri, 3 Aug 2007 20:08:33 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB262504BC86E1@xmb-sjc-215.amer.cisco.com> In-Reply-To: <005201c7d60b$13edbbc0$4619c00a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [HOKEY] Issue 10: Key type Thread-Index: AcfWCxNyhWstL+n0TB2ptSMRN1NWsgANhyJg References: <005201c7d60b$13edbbc0$4619c00a@china.huawei.com> From: "Glen Zorn \(gwz\)" To: "Madjid Nakhjiri" X-OriginalArrivalTime: 04 Aug 2007 03:09:15.0844 (UTC) FILETIME=[D71C8840:01C7D644] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=14283; t=1186196956; x=1187060956; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gwz@cisco.com; z=From:=20=22Glen=20Zorn=20\(gwz\)=22=20 |Subject:=20RE=3A=20[HOKEY]=20Issue=2010=3A=20Key=20type |Sender:=20; bh=vGCK01rD70Jss7oImiyBtiGQkjlinDu/ifoG65Z3O98=; b=P5YaK6lYulSuhewnkrj71DXDVSpJaoQmhAe7J5cm8V33W3gxellpqTPABn59lcPWsQr0SbSp 2IUdWeZulT8EOcs0Rw62r28scTw5YNMdrnFQhk+3FKZT1fmQfGuId4r3L6E13vSezRKsAqGf48 LHHa1zFY9/WRSZwXuteiCfBd0=; Authentication-Results: sj-dkim-1; header.From=gwz@cisco.com; dkim=pass (sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 5b943e80df8c8cad631fd60298783617 Cc: hokey@ietf.org X-BeenThere: hokey@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: HOKEY WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0359400718==" Errors-To: hokey-bounces@ietf.org This is a multi-part message in MIME format. --===============0359400718== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7D644.BDD1EA7D" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7D644.BDD1EA7D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Responding to Yoshi's comment on key-mgm doc on key types: =20 I can see Yoshi's point. I think specifying the key type is cleaner than specifying server type. =20 Now the question is in which messages is key type used and how is key type preference/info communicated =20 1) The third party could here announce what type of key it wants in the message 0 to the peer, so that the peer could communicate the key type in message 1 towards the server, I am not sure if this is the best option, given that the third party could be a domain server or an authenticator or a HOKEY server, things can get complicated if we want to define a generic protocol.=20 Exactly! That's why we're not building a protocol that is any more general than it has to be for our purposes.=20 =20 Otherwise, the peer does not what type of key the exchange is about, until end of the exchange.=20 OK, but why does that matter?=20 Alternatives:=20 2) the third party can send a key type in message 2 to the server. 3) Server decides based on the policy and the service ID, what key type to generate. =20 Finally the server needs to include key type in message 3 both in peer token =20 OK and the token to the third party. Why? All this "third party" is going to do is use it, right? Also, the third party announces its device ID =20 Please define "third party"? Device ID? What is that? to the peer in message 0. I think it should announce the domain ID too (maybe when there is a USRK involved, it won't be needed, not sure at this point).=20 Please define "domain ID" (& "domain" for that matter ;-)=20 We can include Server ID, domain ID and key type in message going from third party to the server. =20 I prefer option 2, any comments? =20 Madjid =20 =20 [4] I think Key Type needs to be carried in the protocol to identify=20 > the type of key (i.e., USRK, DSUSRK, DSRK, etc.) to be distributed to=20 > the third party. I think that such a key type is part of information=20 > to identity a key. >=20 > Madjid>>Wouldn't you know that based on the type of third party you=20 > Madjid>>are > dealing with? Sounds like the key name discussion. =20 Then the issue would be how to identify the type of third party or server. =20 =20 ------_=_NextPart_001_01C7D644.BDD1EA7D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Responding to=20 Yoshi’s comment on = key-mgm doc on=20 key types:

 

I can see=20 Yoshi’s=20 point.

I think specifying = the key=20 type is cleaner than specifying server = type.

 

Now the question is = in which=20 messages is key type used and how is key type preference/info=20 communicated

 

1) The third party = could here=20 announce what type of key it wants in the message 0 to the peer, so that = the=20 peer could communicate the key type in message 1 towards the server, I = am not=20 sure if this is the best option, given that the third party could be a = domain=20 server or an authenticator or a HOKEY server, things can get complicated = if we=20 want to define a generic protocol. 

Exactly!  That's why=20 we're not building a protocol that is any more general than it has to be = for our=20 purposes. 

 

Otherwise, the peer = does not=20 what type of key the exchange is about, until end of the exchange. 

OK, but why does that=20 matter? 

Alternatives:=20

2) the third party = can send a=20 key type in message 2 to the server.

3) Server decides = based on=20 the policy and the service ID, what key type to=20 generate.

 

Finally the server = needs to=20 include key type in message 3 both in peer token  

OK

 and the token to the third=20 party.

 Why?  = All this=20 "third party" is going to do is use it,=20 right?

Also, the third = party=20 announces its device ID  

Please define "third party"? Device ID?  = What is=20 that?

to the peer in = message 0. I=20 think it should announce the domain ID too (maybe when there is a USRK = involved,=20 it won’t be=20 needed, not sure at this point).

Please = define "domain=20 ID" (& "domain" for that=20 matter ;-) 

We can include = Server ID,=20 domain ID and key type in message going from third party to the=20 server.

 

I prefer option 2, = any=20 comments?

 

Madjid

 

 

[4] I think Key = Type needs to=20 be carried in the protocol to identify

> the type of = key (i.e.,=20 USRK, DSUSRK, DSRK, etc.) to be distributed to =

> the third = party.  I=20 think that such a key type is part of information =

> to identity a=20 key.

>=20

> = Madjid>>Wouldn't=20 you know that based on the type of third party you =

>=20 Madjid>>are

> dealing with? = Sounds=20 like the key name discussion.

 

Then the issue = would be how=20 to identify the type of third party or = server.

 

 

------_=_NextPart_001_01C7D644.BDD1EA7D-- --===============0359400718== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ HOKEY mailing list HOKEY@ietf.org https://www1.ietf.org/mailman/listinfo/hokey --===============0359400718==-- From hokey-bounces@ietf.org Tue Aug 07 11:18:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIQoz-0007G3-IS; Tue, 07 Aug 2007 11:18:09 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIQoy-0007Eh-RB for hokey@ietf.org; Tue, 07 Aug 2007 11:18:08 -0400 Received: from mgw.toshibaamericaresearch.com ([165.254.55.12] helo=toshi17.tari.toshiba.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IIQoy-0003jT-6V for hokey@ietf.org; Tue, 07 Aug 2007 11:18:08 -0400 Received: from steelhead.localdomain (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id l77FHlO5078465; Tue, 7 Aug 2007 11:17:47 -0400 (EDT) (envelope-from yohba@tari.toshiba.com) Received: from ohba by steelhead.localdomain with local (Exim 4.67) (envelope-from ) id 1IIQoV-0004Yd-3u; Tue, 07 Aug 2007 11:17:39 -0400 Date: Tue, 7 Aug 2007 11:17:37 -0400 To: Charles Clancy Subject: Re: [HOKEY] consensus call: key delivery security protocol Message-ID: <20070807151737.GG16703@steelhead.localdomain> References: <46A4E634.8060708@cs.umd.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <46A4E634.8060708@cs.umd.edu> User-Agent: Mutt/1.5.13 (2006-08-11) From: Yoshihiro Ohba X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: hokey@ietf.org X-BeenThere: hokey@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: HOKEY WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hokey-bounces@ietf.org I was taking vacation and sorry for delayed response. How does option #1 with hop-by-hop security satisfy draft-housley-aaa-key-mgmt-09.txt, especially "Authenticate all parties" and "Keying material confidentiality and integrity" requirements? Regards, Yoshihiro Ohba On Mon, Jul 23, 2007 at 01:32:36PM -0400, Charles Clancy wrote: > Related issue: #28 > > The current key distribution document describes protocols that require a > shared key between the server and third party. According to RFC 4107, > we are required to specify how those keys are provisioned. The result > was 3 options: > > #1: convert the current protocol into one that uses hop-by-hop security > with channel bindings based on AAA > > #2: define a protocol to provision keys, as necessary, between AAA > servers and any remote AAA client that needs a pairwise key for > end-to-end security > > #3: use something like cross-realm Kerberos to provide the necessary > cryptographics to improve upon hop-by-hop security > > An initial hum eliminated option #2. A vote for options #1 and #3 > yielded 23 in favor of #1 and 11 in favor of #3. This email is to > confirm the consensus in the room during the meeting. > > Please comment by August 2. > > -- > t. charles clancy, ph.d. <> tcc@umd.edu <> eng.umd.edu/~tcc > adjunct professor, electrical engineering, university of maryland > > _______________________________________________ > HOKEY mailing list > HOKEY@ietf.org > https://www1.ietf.org/mailman/listinfo/hokey > _______________________________________________ HOKEY mailing list HOKEY@ietf.org https://www1.ietf.org/mailman/listinfo/hokey From hokey-bounces@ietf.org Wed Aug 08 14:51:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIqd7-0000x2-0D; Wed, 08 Aug 2007 14:51:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIqd5-0000wx-BU for hokey@ietf.org; Wed, 08 Aug 2007 14:51:35 -0400 Received: from dispatch.cs.umd.edu ([128.8.128.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IIqd4-0008Ro-0n for hokey@ietf.org; Wed, 08 Aug 2007 14:51:35 -0400 Received: from loompa (loompa.cs.umd.edu [128.8.128.63]) by dispatch.cs.umd.edu (8.13.1/8.12.5) with ESMTP id l78IpHco012365; Wed, 8 Aug 2007 14:51:21 -0400 Date: Wed, 8 Aug 2007 14:51:16 -0400 (EDT) From: "T. Charles Clancy" X-X-Sender: clancy@loompa To: Yoshihiro Ohba Subject: Re: [HOKEY] consensus call: key delivery security protocol In-Reply-To: <20070807151737.GG16703@steelhead.localdomain> Message-ID: References: <46A4E634.8060708@cs.umd.edu> <20070807151737.GG16703@steelhead.localdomain> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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=-3.499, required 5, autolearn=not spam, AWL -0.90, BAYES_00 -2.60) X-CSD-MailScanner-From: clancy@cs.umd.edu X-Spam-Status: No X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: hokey@ietf.org X-BeenThere: hokey@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: HOKEY WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hokey-bounces@ietf.org If AAA-proxy compromise is not part of our threat model, then all parties are securely authenticated and keying material remains undisclosed to non-trusted parties. The draft-housley-aaa-key-mgmt doesn't say to whom the keying material must remain confidential, or that only the two endpoints can know a key. Sure, a proxy can be compromised and misbehave, but so can a AAA server. The cryptographic protocol academic in me cringes to say that, but I don't see any practical way to avoid it. We need to trust the AAA infrastructure. We can certainly document the concerns associated with a hop-by-hop protocol in the security considerations section. -- t. charles clancy, ph.d. <> tcc@umd.edu <> eng.umd.edu/~tcc adjunct professor, electrical engineering, university of maryland On Tue, 7 Aug 2007, Yoshihiro Ohba wrote: > I was taking vacation and sorry for delayed response. > > How does option #1 with hop-by-hop security satisfy > draft-housley-aaa-key-mgmt-09.txt, especially "Authenticate all > parties" and "Keying material confidentiality and integrity" > requirements? > > Regards, > Yoshihiro Ohba > > > > On Mon, Jul 23, 2007 at 01:32:36PM -0400, Charles Clancy wrote: >> Related issue: #28 >> >> The current key distribution document describes protocols that require a >> shared key between the server and third party. According to RFC 4107, >> we are required to specify how those keys are provisioned. The result >> was 3 options: >> >> #1: convert the current protocol into one that uses hop-by-hop security >> with channel bindings based on AAA >> >> #2: define a protocol to provision keys, as necessary, between AAA >> servers and any remote AAA client that needs a pairwise key for >> end-to-end security >> >> #3: use something like cross-realm Kerberos to provide the necessary >> cryptographics to improve upon hop-by-hop security >> >> An initial hum eliminated option #2. A vote for options #1 and #3 >> yielded 23 in favor of #1 and 11 in favor of #3. This email is to >> confirm the consensus in the room during the meeting. >> >> Please comment by August 2. >> >> -- >> t. charles clancy, ph.d. <> tcc@umd.edu <> eng.umd.edu/~tcc >> adjunct professor, electrical engineering, university of maryland >> >> _______________________________________________ >> HOKEY mailing list >> HOKEY@ietf.org >> https://www1.ietf.org/mailman/listinfo/hokey >> > _______________________________________________ HOKEY mailing list HOKEY@ietf.org https://www1.ietf.org/mailman/listinfo/hokey From hokey-bounces@ietf.org Thu Aug 09 05:46:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJ4bS-0006sk-PK; Thu, 09 Aug 2007 05:46:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJ4bR-0006rq-Eo for hokey@ietf.org; Thu, 09 Aug 2007 05:46:49 -0400 Received: from cyclone.jpcert.cc ([192.50.109.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IJ4bP-0005yt-Fr for hokey@ietf.org; Thu, 09 Aug 2007 05:46:49 -0400 Received: from [127.0.0.1] (cyclone.jpcert.cc [192.50.109.55]) by cyclone.jpcert.cc (8.13.6/8.13.6) with ESMTP id l799jLrH022603; Thu, 9 Aug 2007 18:45:27 +0900 (JST) (envelope-from zrelli@jaist.ac.jp) Message-ID: <46BAE1FA.6090808@jaist.ac.jp> Date: Thu, 09 Aug 2007 11:44:26 +0200 From: Saber Zrelli User-Agent: Icedove 1.5.0.12 (X11/20070607) MIME-Version: 1.0 To: hokey@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: mnakhjiri@huawei.com Subject: [HOKEY] Key mgm : locating the server X-BeenThere: hokey@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: HOKEY WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hokey-bounces@ietf.org Hi , I have a question about draft-ietf-hokey-key-mgm-00 As far as I understood, whenever the key distribution protocol is used, the third party (The HOKEY server or the EAP Authenticator) , has to contact the server (The EAP server or the HOKEY server). I imagine a scenario where you have many EAP servers per domain, the HOKEY server needs to know which of these EAP servers shares the EMSK with the EAP peer. How the third-party figure out which server to contact ? Thanks, Saber. _______________________________________________ HOKEY mailing list HOKEY@ietf.org https://www1.ietf.org/mailman/listinfo/hokey From hokey-bounces@ietf.org Thu Aug 09 10:47:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJ9IY-0003zt-To; Thu, 09 Aug 2007 10:47:38 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJ9IW-0003zk-Ty for hokey@ietf.org; Thu, 09 Aug 2007 10:47:36 -0400 Received: from mgw.toshibaamericaresearch.com ([165.254.55.12] helo=toshi17.tari.toshiba.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IJ9IW-0005G1-Ac for hokey@ietf.org; Thu, 09 Aug 2007 10:47:36 -0400 Received: from steelhead.localdomain (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id l79ElTfi089953; Thu, 9 Aug 2007 10:47:30 -0400 (EDT) (envelope-from yohba@tari.toshiba.com) Received: from ohba by steelhead.localdomain with local (Exim 4.67) (envelope-from ) id 1IJ8sr-0006fi-7V; Thu, 09 Aug 2007 10:21:05 -0400 Date: Thu, 9 Aug 2007 10:21:05 -0400 To: "T. Charles Clancy" Subject: Re: [HOKEY] consensus call: key delivery security protocol Message-ID: <20070809142105.GD23421@steelhead.localdomain> References: <46A4E634.8060708@cs.umd.edu> <20070807151737.GG16703@steelhead.localdomain> 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-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Cc: hokey@ietf.org X-BeenThere: hokey@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: HOKEY WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hokey-bounces@ietf.org I think that this issue is fundamental. Please see my comment inline. On Wed, Aug 08, 2007 at 02:51:16PM -0400, T. Charles Clancy wrote: > If AAA-proxy compromise is not part of our threat model, then all parties > are securely authenticated and keying material remains undisclosed to > non-trusted parties. The draft-housley-aaa-key-mgmt doesn't say to whom > the keying material must remain confidential, or that only the two > endpoints can know a key. > > Sure, a proxy can be compromised and misbehave, but so can a AAA server. The issue is not about compromise of an entity that generates or uses the keying material (any key distribution cannot securely work if such compromise happens). The issue is whether it is acceptable for the keying material to be seen by an entity that does not generate or use it in order for the key distribution to work. In the case of HOKEY, such an entity is typically a AAA proxy that may sit on the key distribution path between an authenticator and a HOKEY server or between a HOKEY server and a AAA server. This can happen in real deployment in which there is an intermediate AAA domain between the home AAA domain and visited AAA domain. With regard to draft-housley-aaa-key-mgmt, there is a hint to indicate to whom the keying material must remain confidential: " For example, [RFC4072] enables EAP keying material to be delivered from a AAA server to a AAA client without disclosure to third parties. Thus, key confidentiality is mandatory to implement in Diameter [RFC3588]. However, key confidentiality is not mandatory to use. " I have a doubt if hop-by-hop security is really acceptable for our key distribution mechanism. > > The cryptographic protocol academic in me cringes to say that, but I don't > see any practical way to avoid it. We need to trust the AAA > infrastructure. We can certainly document the concerns associated with a > hop-by-hop protocol in the security considerations section. As Glen mentioned before, Kerberos-like architecture that supports cross-realm operation can work without the keying material exposed to a AAA proxy in the intermediate AAA domain. Do you think that Kerberos is not practical? Also, depending on security policy, we may not fully trust the AAA infrastructure. Otherwise, why does RFC 3588 have the following text? " It is strongly RECOMMENDED that all Diameter implementations support end-to-end security. " Regards, Yoshihiro Ohba > > -- > t. charles clancy, ph.d. <> tcc@umd.edu <> eng.umd.edu/~tcc > adjunct professor, electrical engineering, university of maryland > > > On Tue, 7 Aug 2007, Yoshihiro Ohba wrote: > > >I was taking vacation and sorry for delayed response. > > > >How does option #1 with hop-by-hop security satisfy > >draft-housley-aaa-key-mgmt-09.txt, especially "Authenticate all > >parties" and "Keying material confidentiality and integrity" > >requirements? > > > >Regards, > >Yoshihiro Ohba > > > > > > > >On Mon, Jul 23, 2007 at 01:32:36PM -0400, Charles Clancy wrote: > >>Related issue: #28 > >> > >>The current key distribution document describes protocols that require a > >>shared key between the server and third party. According to RFC 4107, > >>we are required to specify how those keys are provisioned. The result > >>was 3 options: > >> > >>#1: convert the current protocol into one that uses hop-by-hop security > >>with channel bindings based on AAA > >> > >>#2: define a protocol to provision keys, as necessary, between AAA > >>servers and any remote AAA client that needs a pairwise key for > >>end-to-end security > >> > >>#3: use something like cross-realm Kerberos to provide the necessary > >>cryptographics to improve upon hop-by-hop security > >> > >>An initial hum eliminated option #2. A vote for options #1 and #3 > >>yielded 23 in favor of #1 and 11 in favor of #3. This email is to > >>confirm the consensus in the room during the meeting. > >> > >>Please comment by August 2. > >> > >>-- > >>t. charles clancy, ph.d. <> tcc@umd.edu <> eng.umd.edu/~tcc > >>adjunct professor, electrical engineering, university of maryland > >> > >>_______________________________________________ > >>HOKEY mailing list > >>HOKEY@ietf.org > >>https://www1.ietf.org/mailman/listinfo/hokey > >> > > > _______________________________________________ HOKEY mailing list HOKEY@ietf.org https://www1.ietf.org/mailman/listinfo/hokey From hokey-bounces@ietf.org Thu Aug 09 13:25:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJBlF-0004u1-IQ; Thu, 09 Aug 2007 13:25:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJBlB-0004ts-QV for hokey@ietf.org; Thu, 09 Aug 2007 13:25:21 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IJBlA-0007KA-3y for hokey@ietf.org; Thu, 09 Aug 2007 13:25:21 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 09 Aug 2007 10:25:19 -0700 X-IronPort-AV: i="4.19,241,1183359600"; d="scan'208,217"; a="197295054:sNHT88020180" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l79HPJNo014541; Thu, 9 Aug 2007 10:25:19 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l79HPJVp004348; Thu, 9 Aug 2007 17:25:19 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Aug 2007 10:25:19 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [HOKEY] consensus call: key delivery security protocol Date: Thu, 9 Aug 2007 10:25:18 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB262504C8A9B9@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [HOKEY] consensus call: key delivery security protocol Thread-Index: AcfalETeEDLDnNR/QUSSMsiYMMaI8QAFKksr References: <46A4E634.8060708@cs.umd.edu><20070807151737.GG16703@steelhead.localdomain> <20070809142105.GD23421@steelhead.localdomain> From: "Glen Zorn \(gwz\)" To: "Yoshihiro Ohba" , "T. Charles Clancy" X-OriginalArrivalTime: 09 Aug 2007 17:25:19.0318 (UTC) FILETIME=[42316F60:01C7DAAA] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=13091; t=1186680319; x=1187544319; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gwz@cisco.com; z=From:=20=22Glen=20Zorn=20\(gwz\)=22=20 |Subject:=20RE=3A=20[HOKEY]=20consensus=20call=3A=20key=20delivery=20secu rity=20protocol |Sender:=20; bh=y7EOt06Att15SBcJuiFHXj8P91mHDELfn3MQX/dbq+c=; b=UWt1fpUZN3yj6W3RZ0q16OKG3bHDLU0Iaql+KnyExYkXE7lWT7DN7I6j2bObHKbuTiaoQjZ0 HxZ9POBWQmBWfGOwQy8+K/jiZiwMoMOWTju6ujNPGRM+apqyu1iIwCL6; Authentication-Results: sj-dkim-2; header.From=gwz@cisco.com; dkim=pass (sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: -2.2 (--) X-Scan-Signature: 9f79b8e383fd3af2b1b5b1d0910f6094 Cc: hokey@ietf.org X-BeenThere: hokey@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: HOKEY WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1737833942==" Errors-To: hokey-bounces@ietf.org This is a multi-part message in MIME format. --===============1737833942== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7DAAA.41FDBBCB" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7DAAA.41FDBBCB Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable think that this issue is fundamental. Please see my comment inline. On Wed, Aug 08, 2007 at 02:51:16PM -0400, T. Charles Clancy wrote: > If AAA-proxy compromise is not part of our threat model, then all = parties > are securely authenticated and keying material remains undisclosed to > non-trusted parties. The draft-housley-aaa-key-mgmt doesn't say to = whom > the keying material must remain confidential, or that only the two > endpoints can know a key. > > Sure, a proxy can be compromised and misbehave, but so can a AAA = server. The issue is not about compromise of an entity that generates or uses the keying material (any key distribution cannot securely work if such compromise happens). The issue is whether it is acceptable for the keying material to be seen by an entity that does not generate or use it in order for the key distribution to work. In the case of HOKEY, such an entity is typically a AAA proxy that may sit on the key distribution path between an authenticator and a HOKEY server or between a HOKEY server and a AAA server. This can happen in real deployment in which there is an intermediate AAA domain between the home AAA domain and visited AAA domain. With regard to draft-housley-aaa-key-mgmt, there is a hint to indicate to whom the keying material must remain confidential: " For example, [RFC4072] enables EAP keying material to be delivered from a AAA server to a AAA client without disclosure to third parties. Thus, key confidentiality is mandatory to implement in Diameter [RFC3588]. However, key confidentiality is not mandatory to use. " One of the major problems with that draft (now RFC 4962) is that while = claiming to be "guidance for AAA key management", it essentially ignores = the question of proxies. I have a doubt if hop-by-hop security is really acceptable for our key distribution mechanism. There was clear consensus at the Chicago meeting to utilize the = "standard AAA methods" for key transport. > > The cryptographic protocol academic in me cringes to say that, but I = don't > see any practical way to avoid it. We need to trust the AAA > infrastructure. We can certainly document the concerns associated = with a > hop-by-hop protocol in the security considerations section. As Glen mentioned before, Kerberos-like architecture that supports cross-realm operation can work without the keying material exposed to a AAA proxy in the intermediate AAA domain. Do you think that Kerberos is not practical? There was clear consensus at the Chicago meeting not to use Kerberos. = Given that that consensus has not been contradicted on the list, I think = that this conversation is over. Also, depending on security policy, we may not fully trust the AAA infrastructure. Otherwise, why does RFC 3588 have the following text? Because the editor forgot to take it out? " It is strongly RECOMMENDED that all Diameter implementations support end-to-end security. " Regards, Yoshihiro Ohba > > -- > t. charles clancy, ph.d. <> tcc@umd.edu <> eng.umd.edu/~tcc > adjunct professor, electrical engineering, university of maryland > > > On Tue, 7 Aug 2007, Yoshihiro Ohba wrote: > > >I was taking vacation and sorry for delayed response. > > > >How does option #1 with hop-by-hop security satisfy > >draft-housley-aaa-key-mgmt-09.txt, especially "Authenticate all > >parties" and "Keying material confidentiality and integrity" > >requirements? > > > >Regards, > >Yoshihiro Ohba > > > > > > > >On Mon, Jul 23, 2007 at 01:32:36PM -0400, Charles Clancy wrote: > >>Related issue: #28 > >> > >>The current key distribution document describes protocols that = require a > >>shared key between the server and third party. According to RFC = 4107, > >>we are required to specify how those keys are provisioned. The = result > >>was 3 options: > >> > >>#1: convert the current protocol into one that uses hop-by-hop = security > >>with channel bindings based on AAA > >> > >>#2: define a protocol to provision keys, as necessary, between AAA > >>servers and any remote AAA client that needs a pairwise key for > >>end-to-end security > >> > >>#3: use something like cross-realm Kerberos to provide the necessary > >>cryptographics to improve upon hop-by-hop security > >> > >>An initial hum eliminated option #2. A vote for options #1 and #3 > >>yielded 23 in favor of #1 and 11 in favor of #3. This email is to > >>confirm the consensus in the room during the meeting. > >> > >>Please comment by August 2. > >> > >>-- > >>t. charles clancy, ph.d. <> tcc@umd.edu <> eng.umd.edu/~tcc > >>adjunct professor, electrical engineering, university of maryland > >> > >>_______________________________________________ > >>HOKEY mailing list > >>HOKEY@ietf.org > >>https://www1.ietf.org/mailman/listinfo/hokey > >> > > > _______________________________________________ HOKEY mailing list HOKEY@ietf.org https://www1.ietf.org/mailman/listinfo/hokey ------_=_NextPart_001_01C7DAAA.41FDBBCB Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= =0A= =0A= Re: [HOKEY] consensus call: key delivery security protocol=0A= =0A= =0A=
=0A=
 think that this issue is = fundamental.  =0A= Please see my comment inline.

On Wed, Aug 08, 2007 at 02:51:16PM = -0400, =0A= T. Charles Clancy wrote:
> If AAA-proxy compromise is not part of = our =0A= threat model, then all parties
> are securely authenticated and = keying =0A= material remains undisclosed to
> non-trusted parties.  The =0A= draft-housley-aaa-key-mgmt doesn't say to whom
> the keying = material must =0A= remain confidential, or that only the two
> endpoints can know a =0A= key.
>
> Sure, a proxy can be compromised and misbehave, but = so can =0A= a AAA server.

The issue is not about compromise of an entity that =0A= generates or uses
the keying material (any key distribution cannot = securely =0A= work if such
compromise happens).  The issue is whether it is = acceptable =0A= for the
keying material to be seen by an entity that does not = generate or =0A= use
it in order for the key distribution to work.  In the case = of =0A= HOKEY,
such an entity is typically a AAA proxy that may sit on the =0A= key
distribution path between an authenticator and a HOKEY server =0A= or
between a HOKEY server and a AAA server.  This can happen in =0A= real
deployment in which there is an intermediate AAA domain between =0A= the
home AAA domain and visited AAA domain.

With regard to =0A= draft-housley-aaa-key-mgmt, there is a hint to indicate
to whom the = keying =0A= material must remain confidential:

"
   For example, =0A= [RFC4072] enables EAP keying material to be delivered
   = from a AAA =0A= server to a AAA client without disclosure to third
   =0A= parties.  Thus, key confidentiality is mandatory to implement =0A= in
   Diameter [RFC3588].  However, key = confidentiality is not =0A= mandatory to
   use.
"
=0A=
One of = the major =0A= problems with that draft (now RFC 4962) is that while claiming to be = "guidance =0A= for AAA key management", it essentially ignores the question of =0A= proxies.

I have a doubt if hop-by-hop security is really =0A= acceptable for our key
distribution mechanism.
=0A=
There was = clear consensus at =0A= the Chicago meeting to utilize the "standard AAA methods" for key =0A= transport.
=0A=

=0A=
>
> The cryptographic protocol = academic in me =0A= cringes to say that, but I don't
> see any practical way to avoid =0A= it.  We need to trust the AAA
> infrastructure.  We can =0A= certainly document the concerns associated with a
> hop-by-hop = protocol in =0A= the security considerations section.

As Glen mentioned before, =0A= Kerberos-like architecture that supports
cross-realm operation can = work =0A= without the keying material exposed to
a AAA proxy in the = intermediate AAA =0A= domain.  Do you think that
Kerberos is not = practical?
=0A=
=0A=
There was = clear consensus at =0A= the Chicago meeting not to use Kerberos.  Given that = that =0A= consensus has not been contradicted on the list, I think that this = conversation =0A= is over.

Also, depending on security policy, we may not = fully =0A= trust the AAA
infrastructure.  Otherwise, why does RFC 3588 have = the =0A= following text?
=0A=
Because the editor = forgot to take it =0A= out?

"
   It is strongly RECOMMENDED that all =0A= Diameter implementations support
   end-to-end = security.
"
=0A=


Regards,
Yoshihiro = Ohba


>
> =0A= --
> t. charles clancy, ph.d.  <>  = tcc@umd.edu  =0A= <>  eng.umd.edu/~tcc
> adjunct professor, electrical =0A= engineering, university of maryland
>
>
> On Tue, 7 = Aug 2007, =0A= Yoshihiro Ohba wrote:
>
> >I was taking vacation and = sorry for =0A= delayed response.
> >
> >How does option #1 with = hop-by-hop =0A= security satisfy
> >draft-housley-aaa-key-mgmt-09.txt, = especially =0A= "Authenticate all
> >parties" and "Keying material = confidentiality and =0A= integrity"
> >requirements?
> >
> = >Regards,
> =0A= >Yoshihiro Ohba
> >
> >
> >
> >On = Mon, =0A= Jul 23, 2007 at 01:32:36PM -0400, Charles Clancy wrote:
> = >>Related =0A= issue: #28
> >>
> >>The current key distribution =0A= document describes protocols that require a
> >>shared key = between =0A= the server and third party.  According to RFC 4107,
> = >>we are =0A= required to specify how those keys are provisioned.  The = result
> =0A= >>was 3 options:
> >>
> >>#1: convert the = current =0A= protocol into one that uses hop-by-hop security
> >>with = channel =0A= bindings based on AAA
> >>
> >>#2: define a = protocol to =0A= provision keys, as necessary, between AAA
> >>servers and = any remote =0A= AAA client that needs a pairwise key for
> >>end-to-end =0A= security
> >>
> >>#3: use something like = cross-realm =0A= Kerberos to provide the necessary
> >>cryptographics to = improve upon =0A= hop-by-hop security
> >>
> >>An initial hum = eliminated =0A= option #2.  A vote for options #1 and #3
> >>yielded 23 = in =0A= favor of #1 and 11 in favor of #3.  This email is to
> =0A= >>confirm the consensus in the room during the meeting.
> =0A= >>
> >>Please comment by August 2.
> = >>
> =0A= >>--
> >>t. charles clancy, ph.d.  <>  =0A= tcc@umd.edu  <>  eng.umd.edu/~tcc
> = >>adjunct =0A= professor, electrical engineering, university of maryland
> =0A= >>
> = >>_______________________________________________
> =0A= >>HOKEY mailing list
> >>HOKEY@ietf.org
> = >>https://www1.ietf.o= rg/mailman/listinfo/hokey
> =0A= >>
> =0A= >
>

_______________________________________________
HO= KEY =0A= mailing list
HOKEY@ietf.org
https://www1.ietf.o= rg/mailman/listinfo/hokey
=0A= =0A= =0A= ------_=_NextPart_001_01C7DAAA.41FDBBCB-- --===============1737833942== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ HOKEY mailing list HOKEY@ietf.org https://www1.ietf.org/mailman/listinfo/hokey --===============1737833942==-- From hokey-bounces@ietf.org Thu Aug 09 16:39:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJEmn-00029O-QR; Thu, 09 Aug 2007 16:39:13 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJEmk-000273-E1 for hokey@ietf.org; Thu, 09 Aug 2007 16:39:10 -0400 Received: from mgw.toshibaamericaresearch.com ([165.254.55.12] helo=toshi17.tari.toshiba.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IJEmj-0007hv-Mi for hokey@ietf.org; Thu, 09 Aug 2007 16:39:10 -0400 Received: from steelhead.localdomain (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id l79Kca9e091569; Thu, 9 Aug 2007 16:38:36 -0400 (EDT) (envelope-from yohba@tari.toshiba.com) Received: from ohba by steelhead.localdomain with local (Exim 4.67) (envelope-from ) id 1IJEg5-0006wm-5f; Thu, 09 Aug 2007 16:32:17 -0400 Date: Thu, 9 Aug 2007 16:32:17 -0400 To: "Glen Zorn (gwz)" Subject: Re: [HOKEY] consensus call: key delivery security protocol Message-ID: <20070809203217.GE23421@steelhead.localdomain> References: <20070809142105.GD23421@steelhead.localdomain> <4C0FAAC489C8B74F96BEAD85EAEB262504C8A9B9@xmb-sjc-215.amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <4C0FAAC489C8B74F96BEAD85EAEB262504C8A9B9@xmb-sjc-215.amer.cisco.com> User-Agent: Mutt/1.5.13 (2006-08-11) From: Yoshihiro Ohba X-Spam-Score: 0.0 (/) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a Cc: hokey@ietf.org X-BeenThere: hokey@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: HOKEY WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hokey-bounces@ietf.org Glen, A consensus in a face-to-face meeting does not mean it's final consensus simply because not all WG members can participate in face-to-face meetings. It needs to be confirmed over the WG mailing list. Otherwise, what is the purpose of this consensus call? I would like to hear more technical opinion from other WG members on this fundamental issue rather than seeing further discussion being shut up administratively. I believe that RFC 4902 is generic enough to cover proxy environment. Regards, Yoshihiro Ohba On Thu, Aug 09, 2007 at 10:25:18AM -0700, Glen Zorn (gwz) wrote: > think that this issue is fundamental. Please see my comment inline. > > On Wed, Aug 08, 2007 at 02:51:16PM -0400, T. Charles Clancy wrote: > > If AAA-proxy compromise is not part of our threat model, then all parties > > are securely authenticated and keying material remains undisclosed to > > non-trusted parties. The draft-housley-aaa-key-mgmt doesn't say to whom > > the keying material must remain confidential, or that only the two > > endpoints can know a key. > > > > Sure, a proxy can be compromised and misbehave, but so can a AAA server. > > The issue is not about compromise of an entity that generates or uses > the keying material (any key distribution cannot securely work if such > compromise happens). The issue is whether it is acceptable for the > keying material to be seen by an entity that does not generate or use > it in order for the key distribution to work. In the case of HOKEY, > such an entity is typically a AAA proxy that may sit on the key > distribution path between an authenticator and a HOKEY server or > between a HOKEY server and a AAA server. This can happen in real > deployment in which there is an intermediate AAA domain between the > home AAA domain and visited AAA domain. > > With regard to draft-housley-aaa-key-mgmt, there is a hint to indicate > to whom the keying material must remain confidential: > > " > For example, [RFC4072] enables EAP keying material to be delivered > from a AAA server to a AAA client without disclosure to third > parties. Thus, key confidentiality is mandatory to implement in > Diameter [RFC3588]. However, key confidentiality is not mandatory to > use. > " > > One of the major problems with that draft (now RFC 4962) is that while claiming to be "guidance for AAA key management", it essentially ignores the question of proxies. > > I have a doubt if hop-by-hop security is really acceptable for our key > distribution mechanism. > There was clear consensus at the Chicago meeting to utilize the "standard AAA methods" for key transport. > > > > > > The cryptographic protocol academic in me cringes to say that, but I don't > > see any practical way to avoid it. We need to trust the AAA > > infrastructure. We can certainly document the concerns associated with a > > hop-by-hop protocol in the security considerations section. > > As Glen mentioned before, Kerberos-like architecture that supports > cross-realm operation can work without the keying material exposed to > a AAA proxy in the intermediate AAA domain. Do you think that > Kerberos is not practical? > There was clear consensus at the Chicago meeting not to use Kerberos. Given that that consensus has not been contradicted on the list, I think that this conversation is over. > > Also, depending on security policy, we may not fully trust the AAA > infrastructure. Otherwise, why does RFC 3588 have the following text? > Because the editor forgot to take it out? > > " > It is strongly RECOMMENDED that all Diameter implementations support > end-to-end security. > " > > > Regards, > Yoshihiro Ohba > > > > > > -- > > t. charles clancy, ph.d. <> tcc@umd.edu <> eng.umd.edu/~tcc > > adjunct professor, electrical engineering, university of maryland > > > > > > On Tue, 7 Aug 2007, Yoshihiro Ohba wrote: > > > > >I was taking vacation and sorry for delayed response. > > > > > >How does option #1 with hop-by-hop security satisfy > > >draft-housley-aaa-key-mgmt-09.txt, especially "Authenticate all > > >parties" and "Keying material confidentiality and integrity" > > >requirements? > > > > > >Regards, > > >Yoshihiro Ohba > > > > > > > > > > > >On Mon, Jul 23, 2007 at 01:32:36PM -0400, Charles Clancy wrote: > > >>Related issue: #28 > > >> > > >>The current key distribution document describes protocols that require a > > >>shared key between the server and third party. According to RFC 4107, > > >>we are required to specify how those keys are provisioned. The result > > >>was 3 options: > > >> > > >>#1: convert the current protocol into one that uses hop-by-hop security > > >>with channel bindings based on AAA > > >> > > >>#2: define a protocol to provision keys, as necessary, between AAA > > >>servers and any remote AAA client that needs a pairwise key for > > >>end-to-end security > > >> > > >>#3: use something like cross-realm Kerberos to provide the necessary > > >>cryptographics to improve upon hop-by-hop security > > >> > > >>An initial hum eliminated option #2. A vote for options #1 and #3 > > >>yielded 23 in favor of #1 and 11 in favor of #3. This email is to > > >>confirm the consensus in the room during the meeting. > > >> > > >>Please comment by August 2. > > >> > > >>-- > > >>t. charles clancy, ph.d. <> tcc@umd.edu <> eng.umd.edu/~tcc > > >>adjunct professor, electrical engineering, university of maryland > > >> > > >>_______________________________________________ > > >>HOKEY mailing list > > >>HOKEY@ietf.org > > >>https://www1.ietf.org/mailman/listinfo/hokey > > >> > > > > > > > _______________________________________________ > HOKEY mailing list > HOKEY@ietf.org > https://www1.ietf.org/mailman/listinfo/hokey > _______________________________________________ HOKEY mailing list HOKEY@ietf.org https://www1.ietf.org/mailman/listinfo/hokey From hokey-bounces@ietf.org Thu Aug 09 16:51:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJEz2-00073r-Im; Thu, 09 Aug 2007 16:51:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJEz1-00073m-Ja for hokey@ietf.org; Thu, 09 Aug 2007 16:51:51 -0400 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 1IJEz0-00053P-GH for hokey@ietf.org; Thu, 09 Aug 2007 16:51:51 -0400 Received: from steelhead.localdomain (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id l79Kp35V091618; Thu, 9 Aug 2007 16:51:04 -0400 (EDT) (envelope-from yohba@tari.toshiba.com) Received: from ohba by steelhead.localdomain with local (Exim 4.67) (envelope-from ) id 1IJEyE-0006zW-Us; Thu, 09 Aug 2007 16:51:02 -0400 Date: Thu, 9 Aug 2007 16:51:02 -0400 To: Saber Zrelli Message-ID: <20070809205102.GA26552@steelhead.localdomain> References: <46BAE1FA.6090808@jaist.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <46BAE1FA.6090808@jaist.ac.jp> User-Agent: Mutt/1.5.13 (2006-08-11) From: Yoshihiro Ohba X-Spam-Score: -1.4 (-) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: hokey@ietf.org, mnakhjiri@huawei.com Subject: [HOKEY] Re: Key mgm : locating the server X-BeenThere: hokey@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: HOKEY WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hokey-bounces@ietf.org I commented in the past that server identifier should be used instead of domain identifier to allow more flexible operation like multiple servers (http://www1.ietf.org/mail-archive/web/hokey/current/msg00645.html). Such a server identifier can be specified by the peer in the key distribution protocol so that the third-party can determine which server it has to send a message. On the other hand, there is still an issue on how the peer can know the server identifer. I think that a server discovery mechanism should be defined separately from a key distribution protocol (e.g., provided by lower-layer), instead of designing a key distribution protocol to contain a server discovery mechanism. Yoshihiro Ohba On Thu, Aug 09, 2007 at 11:44:26AM +0200, Saber Zrelli wrote: > Hi , > > I have a question about draft-ietf-hokey-key-mgm-00 > > As far as I understood, whenever the key distribution protocol is used, > the third party (The HOKEY server or the EAP Authenticator) , > has to contact the server (The EAP server or the HOKEY server). > > I imagine a scenario where you have many EAP servers per domain, the > HOKEY server > needs to know which of these EAP servers shares the EMSK with the EAP peer. > > How the third-party figure out which server to contact ? > > > Thanks, > Saber. > > > > > _______________________________________________ HOKEY mailing list HOKEY@ietf.org https://www1.ietf.org/mailman/listinfo/hokey From hokey-bounces@ietf.org Thu Aug 09 19:41:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJHck-0008H5-Jl; Thu, 09 Aug 2007 19:41:02 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJHcf-00081r-TR for hokey@ietf.org; Thu, 09 Aug 2007 19:40:58 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IJHcf-0004Kl-By for hokey@ietf.org; Thu, 09 Aug 2007 19:40:57 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 09 Aug 2007 16:40:57 -0700 X-IronPort-AV: i="4.19,243,1183359600"; d="scan'208,217"; a="197529419:sNHT66642489" 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 l79Neujf013829; Thu, 9 Aug 2007 16:40:56 -0700 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 l79NeuiF009262; Thu, 9 Aug 2007 23:40:56 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Aug 2007 16:40:56 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [HOKEY] consensus call: key delivery security protocol Date: Thu, 9 Aug 2007 16:40:55 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB262504C8A9BA@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [HOKEY] consensus call: key delivery security protocol Thread-Index: AcfaxU2Mz5RYOdslTQaaoSyuYt9LOgAFupsJ References: <20070809142105.GD23421@steelhead.localdomain> <4C0FAAC489C8B74F96BEAD85EAEB262504C8A9B9@xmb-sjc-215.amer.cisco.com> <20070809203217.GE23421@steelhead.localdomain> From: "Glen Zorn \(gwz\)" To: "Yoshihiro Ohba" X-OriginalArrivalTime: 09 Aug 2007 23:40:56.0085 (UTC) FILETIME=[BB272C50:01C7DADE] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3596; t=1186702856; x=1187566856; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gwz@cisco.com; z=From:=20=22Glen=20Zorn=20\(gwz\)=22=20 |Subject:=20RE=3A=20[HOKEY]=20consensus=20call=3A=20key=20delivery=20secu rity=20protocol |Sender:=20; bh=i4xlgm4oPfoCHFu/kPxMqrD79VS5bAji798KHnk5a/c=; b=DZzI4nEtxGdNVsWCPYSdqiSK3UdStoU1O+PXoZkldrRickfykBjBo8BlJJUs7mYgt3+FnqC/ ou39nw/NH7Q1e2WSjDVj2nYLzHovOiSnLrGc/nQQe5UoE/gFYRN+EG4x; Authentication-Results: sj-dkim-2; header.From=gwz@cisco.com; dkim=pass (sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 1.8 (+) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: hokey@ietf.org X-BeenThere: hokey@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: HOKEY WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2052516696==" Errors-To: hokey-bounces@ietf.org This is a multi-part message in MIME format. --===============2052516696== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7DADE.BAF0EE5B" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7DADE.BAF0EE5B Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Glen, A consensus in a face-to-face meeting does not mean it's final consensus simply because not all WG members can participate in face-to-face meetings. It needs to be confirmed over the WG mailing list. Otherwise, what is the purpose of this consensus call? Absolutely. However, 20 or 30 people in a face-to-face meeting cannot = be shouted down by a couple of people on a mailing list. I would like to hear more technical opinion from other WG members on this fundamental issue rather than seeing further discussion being shut up administratively. The largest part of a WG chair's job is to gauge WG consensus and move = the work in that direction. The operative terms here are gauge and = move. I have stated my opinion of the WG Consensus. If you choose to = see that as being "administratively shut up" that's up to you. IMHO we = have spent far too much time discussing this already and these endless = arguments amongst a small group of people are seriously impeding the = progress of the WG. If you want to discuss fundamental problems, I = would suggest that an IRTF RG might be a good place to do it. ... ------_=_NextPart_001_01C7DADE.BAF0EE5B Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= =0A= =0A= Re: [HOKEY] consensus call: key delivery security protocol=0A= =0A= =0A=
=0A=
Glen,

A consensus in a face-to-face = meeting =0A= does not mean it's final
consensus simply because not all WG members = can =0A= participate in
face-to-face meetings.  It needs to be confirmed = over the =0A= WG mailing
list.  Otherwise, what is the purpose of this = consensus =0A= call?
=0A=
Absolutely.  =0A= However, 20 or 30 people in a face-to-face meeting cannot be shouted = down by a =0A= couple of people on a mailing list.

I would like to hear = more =0A= technical opinion from other WG members on
this fundamental issue = rather than =0A= seeing further discussion being
shut up administratively.
=0A=
The largest part of a WG chair's job is to gauge = WG =0A= consensus and move the work in that direction.  The operative terms = here =0A= are gauge and  move.  I have stated my = opinion of =0A= the WG Consensus.  If you choose to see that as being = "administratively =0A= shut up" that's up to you.  IMHO we have spent far too much time = discussing =0A= this already and these endless arguments amongst a small group of people = are =0A= seriously impeding the progress of the WG.  If you want to discuss =0A= fundamental problems, I would suggest that an IRTF RG might be = a good =0A= place to do it.

...
=0A= =0A= =0A= ------_=_NextPart_001_01C7DADE.BAF0EE5B-- --===============2052516696== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ HOKEY mailing list HOKEY@ietf.org https://www1.ietf.org/mailman/listinfo/hokey --===============2052516696==-- From hokey-bounces@ietf.org Fri Aug 10 02:49:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJOJ3-0001r7-Dt; Fri, 10 Aug 2007 02:49:09 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJOJ2-0001r0-GZ for hokey@ietf.org; Fri, 10 Aug 2007 02:49:08 -0400 Received: from imx12.toshiba.co.jp ([61.202.160.132]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IJOJ1-0007OV-LO for hokey@ietf.org; Fri, 10 Aug 2007 02:49:08 -0400 Received: from wall11.toshiba.co.jp (wall11 [133.199.90.149]) by imx12.toshiba.co.jp with ESMTP id l7A6mhHQ027506; Fri, 10 Aug 2007 15:48:43 +0900 (JST) Received: (from root@localhost) by wall11.toshiba.co.jp id l7A6mgh9015561; Fri, 10 Aug 2007 15:48:42 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by wall11.toshiba.co.jp with ESMTP id RAA15488; Fri, 10 Aug 2007 15:48:39 +0900 Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id l7A6mdU1011950; Fri, 10 Aug 2007 15:48:39 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id l7A6mXT5029919; Fri, 10 Aug 2007 15:48:36 +0900 (JST) Received: from steelhead.localdomain ([133.196.30.174]) by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTPSA id <0JMJ00BOPPKZCA20@mail.po.toshiba.co.jp>; Fri, 10 Aug 2007 15:48:35 +0900 (JST) Received: from ohba by steelhead.localdomain with local (Exim 4.67) (envelope-from ) id 1IJOFQ-0000z4-RK; Fri, 10 Aug 2007 02:45:24 -0400 Date: Fri, 10 Aug 2007 02:45:24 -0400 From: Yoshihiro Ohba Subject: Re: [HOKEY] consensus call: key delivery security protocol In-reply-to: <4C0FAAC489C8B74F96BEAD85EAEB262504C8A9BA@xmb-sjc-215.amer.cisco.com> To: "Glen Zorn (gwz)" Message-id: <20070810064524.GA341@steelhead.localdomain> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline References: <20070809142105.GD23421@steelhead.localdomain> <4C0FAAC489C8B74F96BEAD85EAEB262504C8A9B9@xmb-sjc-215.amer.cisco.com> <20070809203217.GE23421@steelhead.localdomain> <4C0FAAC489C8B74F96BEAD85EAEB262504C8A9BA@xmb-sjc-215.amer.cisco.com> User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: hokey@ietf.org X-BeenThere: hokey@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: HOKEY WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hokey-bounces@ietf.org Glen, I don't think that we had a fair amount of discussion on this topic before raising hands. Especially no one had raised the issue on how option #1 can meet RFC 4902 until I send an email on this thread, and I still don't see a satisfactory technical answer on the issue. BTW, I have absolutely no intent to impede the progress of the WG. Regards, Yoshihiro Ohba On Thu, Aug 09, 2007 at 04:40:55PM -0700, Glen Zorn (gwz) wrote: > Glen, > > A consensus in a face-to-face meeting does not mean it's final > consensus simply because not all WG members can participate in > face-to-face meetings. It needs to be confirmed over the WG mailing > list. Otherwise, what is the purpose of this consensus call? > Absolutely. However, 20 or 30 people in a face-to-face meeting cannot be shouted down by a couple of people on a mailing list. > > I would like to hear more technical opinion from other WG members on > this fundamental issue rather than seeing further discussion being > shut up administratively. > The largest part of a WG chair's job is to gauge WG consensus and move the work in that direction. The operative terms here are gauge and move. I have stated my opinion of the WG Consensus. If you choose to see that as being "administratively shut up" that's up to you. IMHO we have spent far too much time discussing this already and these endless arguments amongst a small group of people are seriously impeding the progress of the WG. If you want to discuss fundamental problems, I would suggest that an IRTF RG might be a good place to do it. > > ... _______________________________________________ HOKEY mailing list HOKEY@ietf.org https://www1.ietf.org/mailman/listinfo/hokey From hokey-bounces@ietf.org Fri Aug 10 11:55:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJWpP-0007V5-T7; Fri, 10 Aug 2007 11:55:07 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJWpO-0007Ur-5O for hokey@ietf.org; Fri, 10 Aug 2007 11:55:06 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IJWpN-0006tU-Ag for hokey@ietf.org; Fri, 10 Aug 2007 11:55:06 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 10 Aug 2007 08:55:04 -0700 X-IronPort-AV: i="4.19,245,1183359600"; d="scan'208,217"; a="13044618:sNHT35463114" 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 l7AFt4Np031757; Fri, 10 Aug 2007 08:55:04 -0700 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 l7AFt3iF024908; Fri, 10 Aug 2007 15:55:04 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Aug 2007 08:55:02 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [HOKEY] consensus call: key delivery security protocol Date: Fri, 10 Aug 2007 08:55:02 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB262504C8A9BC@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [HOKEY] consensus call: key delivery security protocol Thread-Index: AcfbGoIScNW8z/eETV+qLLiZgK8KfQASqbSp References: <20070809142105.GD23421@steelhead.localdomain> <4C0FAAC489C8B74F96BEAD85EAEB262504C8A9B9@xmb-sjc-215.amer.cisco.com> <20070809203217.GE23421@steelhead.localdomain> <4C0FAAC489C8B74F96BEAD85EAEB262504C8A9BA@xmb-sjc-215.amer.cisco.com> <20070810064524.GA341@steelhead.localdomain> From: "Glen Zorn \(gwz\)" To: "Yoshihiro Ohba" X-OriginalArrivalTime: 10 Aug 2007 15:55:02.0954 (UTC) FILETIME=[D033A0A0:01C7DB66] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5705; t=1186761304; x=1187625304; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gwz@cisco.com; z=From:=20=22Glen=20Zorn=20\(gwz\)=22=20 |Subject:=20RE=3A=20[HOKEY]=20consensus=20call=3A=20key=20delivery=20secu rity=20protocol |Sender:=20; bh=V4bQmJgRAiEU0LgRCOPVXjfbtttKM04v7gkpzgTcmFc=; b=M+XnSYxYkdRE70iqA70JMIwZZsGONYsUB2u4TxYd/24u8QdwWSoDZOl26Vu3m7dGZU3y8Fff sxEru9Citb5FvGunuZLB15rbjsRbfybQwwQOOoOUme+yysj7AWQWvefcXVmx2nqo2qY60rifiS Gzrd3hetZpkIVflQ0L/2HUzQI=; Authentication-Results: sj-dkim-1; header.From=gwz@cisco.com; dkim=pass (sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 1.8 (+) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Cc: hokey@ietf.org X-BeenThere: hokey@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: HOKEY WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1907205660==" Errors-To: hokey-bounces@ietf.org This is a multi-part message in MIME format. --===============1907205660== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7DB66.CFFF47BD" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7DB66.CFFF47BD Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Glen, I don't think that we had a fair amount of discussion on this topic before raising hands. =20 Yoshi, we've been discussing this topic for months now, ever since the = interim meeting in San Jose. Especially no one had raised the issue on how option #1 can meet RFC 4902 until I send an email on this thread, and I still don't see a satisfactory technical answer on the issue. =20 My personal opinion is that RFC 4902 is just wrong, in the interesting = way in which only statements can be: totally. It's not just not Best = Current Practice, it's not _any_ current practice & forcing IETF = standards to conform to it virtually guarantees a steep spiral into = irrelevance. BTW, I have absolutely no intent to impede the progress of the WG. Sometimes our actions have unintended consequences. Regards, Yoshihiro Ohba On Thu, Aug 09, 2007 at 04:40:55PM -0700, Glen Zorn (gwz) wrote: > Glen, > > A consensus in a face-to-face meeting does not mean it's final > consensus simply because not all WG members can participate in > face-to-face meetings. It needs to be confirmed over the WG mailing > list. Otherwise, what is the purpose of this consensus call? > Absolutely. However, 20 or 30 people in a face-to-face meeting cannot = be shouted down by a couple of people on a mailing list. > > I would like to hear more technical opinion from other WG members on > this fundamental issue rather than seeing further discussion being > shut up administratively. > The largest part of a WG chair's job is to gauge WG consensus and move = the work in that direction. The operative terms here are gauge and = move. I have stated my opinion of the WG Consensus. If you choose to = see that as being "administratively shut up" that's up to you. IMHO we = have spent far too much time discussing this already and these endless = arguments amongst a small group of people are seriously impeding the = progress of the WG. If you want to discuss fundamental problems, I = would suggest that an IRTF RG might be a good place to do it. > > ... ------_=_NextPart_001_01C7DB66.CFFF47BD Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= =0A= =0A= Re: [HOKEY] consensus call: key delivery security protocol=0A= =0A= =0A=
=0A=
Glen,

I don't think that we had a = fair amount =0A= of discussion on this topic
before raising hands. 
=0A=
Yoshi, we've = been discussing =0A= this topic for months now, ever since the interim meeting in San =0A= Jose.
=0A=
Especially no one had raised the issue on =0A= how
option #1 can meet RFC 4902 until I send an email on this thread, =0A= and
I still don't see a satisfactory technical answer on the = issue.  =0A=
=0A=
My personal = opinion is that =0A= RFC 4902 is just wrong, in the interesting way in which only statements = can be: =0A= totally.  It's not just not Best Current Practice, it's not _any_ = current =0A= practice & forcing IETF standards to conform to it virtually = guarantees a =0A= steep spiral into irrelevance.
=0A=
BTW,
I have absolutely no intent to = impede the =0A= progress of the WG.
=0A=
Sometimes our actions =0A= have unintended consequences.

Regards,
Yoshihiro =0A= Ohba


On Thu, Aug 09, 2007 at 04:40:55PM -0700, Glen Zorn = (gwz) =0A= wrote:
> Glen,
>
> A consensus in a face-to-face = meeting does =0A= not mean it's final
> consensus simply because not all WG members = can =0A= participate in
> face-to-face meetings.  It needs to be = confirmed =0A= over the WG mailing
> list.  Otherwise, what is the purpose = of this =0A= consensus call?
> Absolutely.  However, 20 or 30 people in a =0A= face-to-face meeting cannot be shouted down by a couple of people on a = mailing =0A= list.

>
> I would like to hear more technical opinion = from other =0A= WG members on
> this fundamental issue rather than seeing further =0A= discussion being
> shut up administratively.
> The largest = part of a =0A= WG chair's job is to gauge WG consensus and move the work in that =0A= direction.  The operative terms here are gauge and  = move.  I have =0A= stated my opinion of the WG Consensus.  If you choose to see that = as being =0A= "administratively shut up" that's up to you.  IMHO we have spent = far too =0A= much time discussing this already and these endless arguments amongst a = small =0A= group of people are seriously impeding the progress of the WG.  If = you want =0A= to discuss fundamental problems, I would suggest that an IRTF RG might = be a good =0A= place to do it.

>
> ...
=0A= =0A= =0A= ------_=_NextPart_001_01C7DB66.CFFF47BD-- --===============1907205660== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ HOKEY mailing list HOKEY@ietf.org https://www1.ietf.org/mailman/listinfo/hokey --===============1907205660==-- From hokey-bounces@ietf.org Mon Aug 13 05:58:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKWgi-00070f-88; Mon, 13 Aug 2007 05:58:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKWgg-00070U-W6 for hokey@ietf.org; Mon, 13 Aug 2007 05:58:14 -0400 Received: from cyclone.jpcert.cc ([192.50.109.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IKWgf-0007zC-2s for hokey@ietf.org; Mon, 13 Aug 2007 05:58:14 -0400 Received: from www.cyclone.jpcert.cc (localhost [127.0.0.1]) by cyclone.jpcert.cc (8.13.6/8.13.6) with ESMTP id l7D9uakA049466; Mon, 13 Aug 2007 18:56:45 +0900 (JST) (envelope-from zrelli@jaist.ac.jp) Received: from 2001:660:f183:3:210:c6ff:fedd:3281 (SquirrelMail authenticated user zrelli) by www.cyclone.jpcert.cc with HTTP; Mon, 13 Aug 2007 18:56:54 +0900 (JST) Message-ID: <49350.2001:660:f183:3:210:c6ff:fedd:3281.1186999014.squirrel@www.cyclone.jpcert.cc> Date: Mon, 13 Aug 2007 18:56:54 +0900 (JST) From: "Saber Zrelli" To: "Yoshihiro Ohba" User-Agent: SquirrelMail/1.5.1 MIME-Version: 1.0 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: 8bit References: <46BAE1FA.6090808@jaist.ac.jp> <20070809205102.GA26552@steelhead.localdomain> In-Reply-To: <20070809205102.GA26552@steelhead.localdomain> X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: hokey@ietf.org, mnakhjiri@huawei.com Subject: [HOKEY] Re: Key mgm : locating the server X-BeenThere: hokey@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: zrelli@jaist.ac.jp List-Id: HOKEY WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hokey-bounces@ietf.org Hi Yoshihiro, On Fri, August 10, 2007 5:51 am, Yoshihiro Ohba wrote: > I commented in the past that server identifier should be used instead > of domain identifier to allow more flexible operation like multiple servers > (http://www1.ietf.org/mail-archive/web/hokey/current/msg00645.html). > > > Such a server identifier can be specified by the peer in the key > distribution protocol so that the third-party can determine which server it has to send a > message. On the other hand, there is still an issue on how the peer can know the server > identifer. With regard to this issue, I think a possible approach would be to push the HRK from the EAP peer to the HOKEY server at the time of the initial full EAP authentication. IMHO, there is no need to use three-party protocol for transferring HRK from the EAP server to HOKEY server. Regarding context binding of the HRK, the EAP server has already all information about the peer and the HOKEY server of the access domain. This would eliminate the the issue of finding which EAP server to contact. The other use-case is where the third-party is the new EAP authenticator, the EAP Authenticator needs to determine which HOKEY server to contact in order to share a key with the peer. In this case, the EAP peer can refer to the Hokey server using the Hokey domain name and/or HOKEY server ID, that it would have obtained during the initial full EAP authentication from an enhanced EAP-Identity Request or lower-layer means, the EAP authenticator would look up the Hokey server using this information and initiate the three-party protocol. > > I think that a server discovery mechanism should be defined separately > from a key distribution protocol (e.g., provided by lower-layer), instead of designing a > key distribution protocol to contain a server discovery mechanism. Such protocols already exist in my opinion, DNS is a good example, no ? Kerberos entities uses it to locate Key Distribution Centers given a Kerberos realm name. We could think of using the same approach for locating HOKEY servers. Best Regards, Saber Zrelli. > > Yoshihiro Ohba > > > > On Thu, Aug 09, 2007 at 11:44:26AM +0200, Saber Zrelli wrote: > >> Hi , >> >> >> I have a question about draft-ietf-hokey-key-mgm-00 >> >> >> As far as I understood, whenever the key distribution protocol is used, >> the third party (The HOKEY server or the EAP Authenticator) , has to contact the server >> (The EAP server or the HOKEY server). >> >> >> I imagine a scenario where you have many EAP servers per domain, the >> HOKEY server >> needs to know which of these EAP servers shares the EMSK with the EAP peer. >> >> How the third-party figure out which server to contact ? >> >> >> >> Thanks, >> Saber. >> >> >> >> >> >> > --saber _______________________________________________ HOKEY mailing list HOKEY@ietf.org https://www1.ietf.org/mailman/listinfo/hokey From hokey-bounces@ietf.org Wed Aug 15 03:04:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILCvO-0003x0-MC; Wed, 15 Aug 2007 03:04:14 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILCvN-0003wr-E3 for hokey@ietf.org; Wed, 15 Aug 2007 03:04:13 -0400 Received: from mgw.toshibaamericaresearch.com ([165.254.55.12] helo=toshi17.tari.toshiba.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ILCvM-0000g5-Rs for hokey@ietf.org; Wed, 15 Aug 2007 03:04:13 -0400 Received: from steelhead.localdomain (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id l7F73jxj010335; Wed, 15 Aug 2007 03:03:55 -0400 (EDT) (envelope-from yohba@tari.toshiba.com) Received: from ohba by steelhead.localdomain with local (Exim 4.67) (envelope-from ) id 1IKPCa-0002Jx-M1; Sun, 12 Aug 2007 21:58:40 -0400 Date: Sun, 12 Aug 2007 21:58:40 -0400 To: "Glen Zorn (gwz)" Subject: Re: [HOKEY] consensus call: key delivery security protocol Message-ID: <20070813015840.GC8439@steelhead.localdomain> References: <20070809142105.GD23421@steelhead.localdomain> <4C0FAAC489C8B74F96BEAD85EAEB262504C8A9B9@xmb-sjc-215.amer.cisco.com> <20070809203217.GE23421@steelhead.localdomain> <4C0FAAC489C8B74F96BEAD85EAEB262504C8A9BA@xmb-sjc-215.amer.cisco.com> <20070810064524.GA341@steelhead.localdomain> <4C0FAAC489C8B74F96BEAD85EAEB262504C8A9BC@xmb-sjc-215.amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <4C0FAAC489C8B74F96BEAD85EAEB262504C8A9BC@xmb-sjc-215.amer.cisco.com> User-Agent: Mutt/1.5.13 (2006-08-11) From: Yoshihiro Ohba X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: hokey@ietf.org X-BeenThere: hokey@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: HOKEY WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hokey-bounces@ietf.org Glen, RFC 4962 (4902 was a typo) is Best Current Practice (BCP 132). Shouldn't HOKEY WG drafts ratify RFC 4962 according to RFC 2026? " 5. BEST CURRENT PRACTICE (BCP) RFCs The BCP subseries of the RFC series is designed to be a way to standardize practices and the results of community deliberations. A BCP document is subject to the same basic set of procedures as standards track documents and thus is a vehicle by which the IETF community can define and ratify the community's best current thinking on a statement of principle or on what is believed to be the best way to perform some operations or IETF process function. " Regards, Yoshihiro Ohba On Fri, Aug 10, 2007 at 08:55:02AM -0700, Glen Zorn (gwz) wrote: > Glen, > > I don't think that we had a fair amount of discussion on this topic > before raising hands. > Yoshi, we've been discussing this topic for months now, ever since the interim meeting in San Jose. > Especially no one had raised the issue on how > option #1 can meet RFC 4902 until I send an email on this thread, and > I still don't see a satisfactory technical answer on the issue. > My personal opinion is that RFC 4902 is just wrong, in the interesting way in which only statements can be: totally. It's not just not Best Current Practice, it's not _any_ current practice & forcing IETF standards to conform to it virtually guarantees a steep spiral into irrelevance. > BTW, > I have absolutely no intent to impede the progress of the WG. > Sometimes our actions have unintended consequences. > > Regards, > Yoshihiro Ohba > > > On Thu, Aug 09, 2007 at 04:40:55PM -0700, Glen Zorn (gwz) wrote: > > Glen, > > > > A consensus in a face-to-face meeting does not mean it's final > > consensus simply because not all WG members can participate in > > face-to-face meetings. It needs to be confirmed over the WG mailing > > list. Otherwise, what is the purpose of this consensus call? > > Absolutely. However, 20 or 30 people in a face-to-face meeting cannot be shouted down by a couple of people on a mailing list. > > > > > I would like to hear more technical opinion from other WG members on > > this fundamental issue rather than seeing further discussion being > > shut up administratively. > > The largest part of a WG chair's job is to gauge WG consensus and move the work in that direction. The operative terms here are gauge and move. I have stated my opinion of the WG Consensus. If you choose to see that as being "administratively shut up" that's up to you. IMHO we have spent far too much time discussing this already and these endless arguments amongst a small group of people are seriously impeding the progress of the WG. If you want to discuss fundamental problems, I would suggest that an IRTF RG might be a good place to do it. > > > > > ... > _______________________________________________ HOKEY mailing list HOKEY@ietf.org https://www1.ietf.org/mailman/listinfo/hokey From hokey-bounces@ietf.org Wed Aug 15 11:57:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILLFc-0001sW-7r; Wed, 15 Aug 2007 11:57:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILLFa-0001sQ-FR for hokey@ietf.org; Wed, 15 Aug 2007 11:57:38 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ILLFY-00013T-Ow for hokey@ietf.org; Wed, 15 Aug 2007 11:57:38 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 15 Aug 2007 08:57:36 -0700 X-IronPort-AV: i="4.19,267,1183359600"; d="scan'208,217"; a="513745681:sNHT89798460" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l7FFva5k029372; Wed, 15 Aug 2007 08:57:36 -0700 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 l7FFvUid024871; Wed, 15 Aug 2007 15:57:36 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Aug 2007 08:57:26 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [HOKEY] consensus call: key delivery security protocol Date: Wed, 15 Aug 2007 08:57:25 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB262504C8A9E5@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [HOKEY] consensus call: key delivery security protocol Thread-Index: AcffCnqXod/KNi5PQQCrSRkxUuJtQQAReTSN References: <20070809142105.GD23421@steelhead.localdomain> <4C0FAAC489C8B74F96BEAD85EAEB262504C8A9B9@xmb-sjc-215.amer.cisco.com> <20070809203217.GE23421@steelhead.localdomain> <4C0FAAC489C8B74F96BEAD85EAEB262504C8A9BA@xmb-sjc-215.amer.cisco.com> <20070810064524.GA341@steelhead.localdomain> <4C0FAAC489C8B74F96BEAD85EAEB262504C8A9BC@xmb-sjc-215.amer.cisco.com> <20070813015840.GC8439@steelhead.localdomain> From: "Glen Zorn \(gwz\)" To: "Yoshihiro Ohba" X-OriginalArrivalTime: 15 Aug 2007 15:57:26.0313 (UTC) FILETIME=[F9B73990:01C7DF54] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=10467; t=1187193456; x=1188057456; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gwz@cisco.com; z=From:=20=22Glen=20Zorn=20\(gwz\)=22=20 |Subject:=20RE=3A=20[HOKEY]=20consensus=20call=3A=20key=20delivery=20secu rity=20protocol |Sender:=20; bh=UzBCzNzaEn6fa88RlyjcE+HP26igBWgKEMREt0c5XQc=; b=e3b+OGMlFudLuXnDEkNjT5YjcEbr9xcqOopcv/VwCKtjPhp9ldL0OGUDMxTMd1srQAfWTbrZ tKM5gHLydG4x0xQEzvEjh1EL2AOu6uwgaqKmpi9xgHgxbpYSwiWcqk7g; Authentication-Results: sj-dkim-3; header.From=gwz@cisco.com; dkim=pass (sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: -2.2 (--) X-Scan-Signature: 7698d1420ecbbce1995432e99bb6d1a1 Cc: hokey@ietf.org X-BeenThere: hokey@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: HOKEY WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1083470079==" Errors-To: hokey-bounces@ietf.org This is a multi-part message in MIME format. --===============1083470079== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7DF54.F960F13F" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7DF54.F960F13F Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Glen, RFC 4962 (4902 was a typo) is Best Current Practice (BCP 132).=20 gwz> Another typo was "My personal opinion is that RFC 4992 is just = wrong, in the interesting way in which only statements can be: totally." = It _should_ have said "My personal opinion is that RFC 4962 is just = wrong, in the interesting way in which only _religious_ statements can = be: totally."=20 Shouldn't HOKEY WG drafts ratify RFC 4962 according to RFC 2026? I hope I've made my opinion of RFC 4062 clear ;-). Be that as it may, = however, as WG chair I suppose I have to agree with your statement. So = what, exactly, do you think violates it? AFAICT, RFC 4962 (among its = other flaws) completely ignores the existence of RADIUS proxies. What = _might_ have relevance to the question is in section 3, under the = heading "Limit key scope". It says "Following the principle of least = privilege, parties MUST NOT have access to keying material that is not = needed to perform their role." This statement is ambiguous: is it the = _access_ that is not needed to perform the role or the _keying = material_? I prefer to resolve the ambiguity in favor of utility & say = that it is the _access_; since RADIUS proxies MUST have access to the = plaintext contents of any encrypted attribute (including passwords) in = order to perform their role, they don't violate RFC 4962 in this case. = Can you find a case where they do? " 5. BEST CURRENT PRACTICE (BCP) RFCs The BCP subseries of the RFC series is designed to be a way to standardize practices and the results of community deliberations. A BCP document is subject to the same basic set of procedures as standards track documents and thus is a vehicle by which the IETF community can define and ratify the community's best current thinking on a statement of principle or on what is believed to be the best way to perform some operations or IETF process function. " Regards, Yoshihiro Ohba On Fri, Aug 10, 2007 at 08:55:02AM -0700, Glen Zorn (gwz) wrote: > Glen, > > I don't think that we had a fair amount of discussion on this topic > before raising hands.=20 > Yoshi, we've been discussing this topic for months now, ever since the = interim meeting in San Jose. > Especially no one had raised the issue on how > option #1 can meet RFC 4902 until I send an email on this thread, and > I still don't see a satisfactory technical answer on the issue.=20 > My personal opinion is that RFC 4902 is just wrong, in the interesting = way in which only statements can be: totally. It's not just not Best = Current Practice, it's not _any_ current practice & forcing IETF = standards to conform to it virtually guarantees a steep spiral into = irrelevance. > BTW, > I have absolutely no intent to impede the progress of the WG. > Sometimes our actions have unintended consequences. > > Regards, > Yoshihiro Ohba > > > On Thu, Aug 09, 2007 at 04:40:55PM -0700, Glen Zorn (gwz) wrote: > > Glen, > > > > A consensus in a face-to-face meeting does not mean it's final > > consensus simply because not all WG members can participate in > > face-to-face meetings. It needs to be confirmed over the WG mailing > > list. Otherwise, what is the purpose of this consensus call? > > Absolutely. However, 20 or 30 people in a face-to-face meeting = cannot be shouted down by a couple of people on a mailing list. > > > > > I would like to hear more technical opinion from other WG members on > > this fundamental issue rather than seeing further discussion being > > shut up administratively. > > The largest part of a WG chair's job is to gauge WG consensus and = move the work in that direction. The operative terms here are gauge and = move. I have stated my opinion of the WG Consensus. If you choose to = see that as being "administratively shut up" that's up to you. IMHO we = have spent far too much time discussing this already and these endless = arguments amongst a small group of people are seriously impeding the = progress of the WG. If you want to discuss fundamental problems, I = would suggest that an IRTF RG might be a good place to do it. > > > > > ... > ------_=_NextPart_001_01C7DF54.F960F13F Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= =0A= =0A= Re: [HOKEY] consensus call: key delivery security protocol=0A= =0A= =0A=
=0A=
Glen,

RFC 4962 (4902 was a typo) is = Best =0A= Current Practice (BCP 132). 
=0A=
gwz> = Another typo =0A= was "My personal opinion is that RFC 4992 is just wrong, in the = interesting way =0A= in which only statements can be: totally."  It _should_ = have said =0A= "My personal opinion is that RFC 4962 is just wrong, in the interesting = way in =0A= which only _religious_ statements can be: totally."=0A=

Shouldn't HOKEY WG drafts ratify RFC 4962 according = to RFC =0A= 2026?
I hope =0A= I've made my opinion of RFC 4062 clear ;-).  Be that as it may, = however, as =0A= WG chair I suppose I have to agree with your statement.  So what, = exactly, =0A= do you think violates it?  AFAICT, RFC 4962 (among its other flaws) =0A= completely ignores the existence of RADIUS proxies.  What =0A= _might_ have relevance to the question is in section 3, under = the =0A= heading "Limit key scope".  It says "Following the = principle =0A= of least privilege, parties MUST NOT have access to keying material that = is not =0A= needed to perform their role."  This statement is ambiguous: is it = the =0A= _access_ that is not needed to perform the role or the = _keying =0A= material_?  I prefer to resolve the ambiguity in favor of = utility =0A= & say that it is the _access_; since RADIUS proxies MUST = have =0A= access to the plaintext contents of any encrypted attribute (including =0A= passwords) in order to perform their role, they don't violate RFC 4962 = in this =0A= case.  Can you find a case where they do?
=0A=

"
5.  BEST CURRENT PRACTICE (BCP) =0A= RFCs

   The BCP subseries of the RFC series is designed = to be a =0A= way to
   standardize practices and the results of = community =0A= deliberations.  A
   BCP document is subject to the = same basic =0A= set of procedures as
   standards track documents and thus = is a =0A= vehicle by which the IETF
   community can define and = ratify the =0A= community's best current thinking
   on a statement of = principle or =0A= on what is believed to be the best way
   to perform some =0A= operations or IETF process function.
"

Regards,
Yoshihiro =0A= Ohba

On Fri, Aug 10, 2007 at 08:55:02AM -0700, Glen Zorn (gwz) =0A= wrote:
> Glen,
>
> I don't think that we had a fair = amount of =0A= discussion on this topic
> before raising hands. 
> = Yoshi, =0A= we've been discussing this topic for months now, ever since the interim = meeting =0A= in San Jose.
> Especially no one had raised the issue on = how
> =0A= option #1 can meet RFC 4902 until I send an email on this thread, = and
> I =0A= still don't see a satisfactory technical answer on the = issue. 
> My =0A= personal opinion is that RFC 4902 is just wrong, in the interesting way = in which =0A= only statements can be: totally.  It's not just not Best Current = Practice, =0A= it's not _any_ current practice & forcing IETF standards to conform = to it =0A= virtually guarantees a steep spiral into irrelevance.
> = BTW,
> I =0A= have absolutely no intent to impede the progress of the WG.
> = Sometimes =0A= our actions have unintended consequences.
>
> = Regards,
> =0A= Yoshihiro Ohba
>
>
> On Thu, Aug 09, 2007 at = 04:40:55PM -0700, =0A= Glen Zorn (gwz) wrote:
> > Glen,
> >
> > A = consensus =0A= in a face-to-face meeting does not mean it's final
> > = consensus simply =0A= because not all WG members can participate in
> > face-to-face =0A= meetings.  It needs to be confirmed over the WG mailing
> = > =0A= list.  Otherwise, what is the purpose of this consensus = call?
> > =0A= Absolutely.  However, 20 or 30 people in a face-to-face meeting = cannot be =0A= shouted down by a couple of people on a mailing list.
>
> =0A= >
> > I would like to hear more technical opinion from other = WG =0A= members on
> > this fundamental issue rather than seeing = further =0A= discussion being
> > shut up administratively.
> > The = largest =0A= part of a WG chair's job is to gauge WG consensus and move the work in = that =0A= direction.  The operative terms here are gauge and  = move.  I have =0A= stated my opinion of the WG Consensus.  If you choose to see that = as being =0A= "administratively shut up" that's up to you.  IMHO we have spent = far too =0A= much time discussing this already and these endless arguments amongst a = small =0A= group of people are seriously impeding the progress of the WG.  If = you want =0A= to discuss fundamental problems, I would suggest that an IRTF RG might = be a good =0A= place to do it.
>
> >
> > =0A= ...
>
=0A= =0A= =0A= ------_=_NextPart_001_01C7DF54.F960F13F-- --===============1083470079== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ HOKEY mailing list HOKEY@ietf.org https://www1.ietf.org/mailman/listinfo/hokey --===============1083470079==-- From hokey-bounces@ietf.org Wed Aug 15 13:44:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILMuX-000242-6j; Wed, 15 Aug 2007 13:44:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILMuW-00023x-3d for hokey@ietf.org; Wed, 15 Aug 2007 13:44:00 -0400 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 1ILMuU-0003yo-T9 for hokey@ietf.org; Wed, 15 Aug 2007 13:44:00 -0400 Received: from steelhead.localdomain (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id l7FHhN5H012214; Wed, 15 Aug 2007 13:43:23 -0400 (EDT) (envelope-from yohba@tari.toshiba.com) Received: from ohba by steelhead.localdomain with local (Exim 4.67) (envelope-from ) id 1ILMtm-0003AF-QA; Wed, 15 Aug 2007 13:43:14 -0400 Date: Wed, 15 Aug 2007 13:43:12 -0400 To: "Glen Zorn (gwz)" Subject: Re: [HOKEY] consensus call: key delivery security protocol Message-ID: <20070815174312.GD9388@steelhead.localdomain> References: <20070809142105.GD23421@steelhead.localdomain> <4C0FAAC489C8B74F96BEAD85EAEB262504C8A9B9@xmb-sjc-215.amer.cisco.com> <20070809203217.GE23421@steelhead.localdomain> <4C0FAAC489C8B74F96BEAD85EAEB262504C8A9BA@xmb-sjc-215.amer.cisco.com> <20070810064524.GA341@steelhead.localdomain> <4C0FAAC489C8B74F96BEAD85EAEB262504C8A9BC@xmb-sjc-215.amer.cisco.com> <20070813015840.GC8439@steelhead.localdomain> <4C0FAAC489C8B74F96BEAD85EAEB262504C8A9E5@xmb-sjc-215.amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <4C0FAAC489C8B74F96BEAD85EAEB262504C8A9E5@xmb-sjc-215.amer.cisco.com> User-Agent: Mutt/1.5.13 (2006-08-11) From: Yoshihiro Ohba X-Spam-Score: -1.4 (-) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: hokey@ietf.org X-BeenThere: hokey@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: HOKEY WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hokey-bounces@ietf.org Glen, On Wed, Aug 15, 2007 at 08:57:25AM -0700, Glen Zorn (gwz) wrote: > Glen, > > RFC 4962 (4902 was a typo) is Best Current Practice (BCP 132). > gwz> Another typo was "My personal opinion is that RFC 4992 is just wrong, in the interesting way in which only statements can be: totally." It _should_ have said "My personal opinion is that RFC 4962 is just wrong, in the interesting way in which only _religious_ statements can be: totally." > > Shouldn't HOKEY WG drafts ratify RFC 4962 according to RFC 2026? > I hope I've made my opinion of RFC 4062 clear ;-). There is another typo, s/4062/4962/ :) >Be that as it may, however, as WG chair I suppose I have to agree with your statement. So what, exactly, do you think violates it? AFAICT, RFC 4962 (among its other flaws) completely ignores the existence of RADIUS proxies. What _might_ have relevance to the question is in section 3, under the heading "Limit key scope". It says "Following the principle of least privilege, parties MUST NOT have access to keying material that is not needed to perform their role." This statement is ambiguous: is it the _access_ that is not needed to perform the role or the _keying material_? I prefer to resolve the ambiguity in favor of utility & say that it is the _access_; since RADIUS proxies MUST have access to the plaintext contents of any encrypted attribute (including passwords) in order to perform their role, they don't violate RFC 4962 in this case. Can you find a case where they do? Although I don't think that the statement you quoted above is ambiguous, I don't think we can classify the RADIUS proxies as an entity that is allowed to have access to the keying material, because the RADIUS proxies do not need to have access to the keying material in order to perform their role unless hop-by-hop security is used for transporting the keying material. It would be important to note that use of RADIUS proxies is not the same as use of hop-by-hop security. It appears to me that a solution that relies on hop-by-hop security violates RFC 4962. Regards, Yoshihiro Ohba > > " > 5. BEST CURRENT PRACTICE (BCP) RFCs > > The BCP subseries of the RFC series is designed to be a way to > standardize practices and the results of community deliberations. A > BCP document is subject to the same basic set of procedures as > standards track documents and thus is a vehicle by which the IETF > community can define and ratify the community's best current thinking > on a statement of principle or on what is believed to be the best way > to perform some operations or IETF process function. > " > > Regards, > Yoshihiro Ohba > > On Fri, Aug 10, 2007 at 08:55:02AM -0700, Glen Zorn (gwz) wrote: > > Glen, > > > > I don't think that we had a fair amount of discussion on this topic > > before raising hands. > > Yoshi, we've been discussing this topic for months now, ever since the interim meeting in San Jose. > > Especially no one had raised the issue on how > > option #1 can meet RFC 4902 until I send an email on this thread, and > > I still don't see a satisfactory technical answer on the issue. > > My personal opinion is that RFC 4902 is just wrong, in the interesting way in which only statements can be: totally. It's not just not Best Current Practice, it's not _any_ current practice & forcing IETF standards to conform to it virtually guarantees a steep spiral into irrelevance. > > BTW, > > I have absolutely no intent to impede the progress of the WG. > > Sometimes our actions have unintended consequences. > > > > Regards, > > Yoshihiro Ohba > > > > > > On Thu, Aug 09, 2007 at 04:40:55PM -0700, Glen Zorn (gwz) wrote: > > > Glen, > > > > > > A consensus in a face-to-face meeting does not mean it's final > > > consensus simply because not all WG members can participate in > > > face-to-face meetings. It needs to be confirmed over the WG mailing > > > list. Otherwise, what is the purpose of this consensus call? > > > Absolutely. However, 20 or 30 people in a face-to-face meeting cannot be shouted down by a couple of people on a mailing list. > > > > > > > > I would like to hear more technical opinion from other WG members on > > > this fundamental issue rather than seeing further discussion being > > > shut up administratively. > > > The largest part of a WG chair's job is to gauge WG consensus and move the work in that direction. The operative terms here are gauge and move. I have stated my opinion of the WG Consensus. If you choose to see that as being "administratively shut up" that's up to you. IMHO we have spent far too much time discussing this already and these endless arguments amongst a small group of people are seriously impeding the progress of the WG. If you want to discuss fundamental problems, I would suggest that an IRTF RG might be a good place to do it. > > > > > > > > ... > > > _______________________________________________ HOKEY mailing list HOKEY@ietf.org https://www1.ietf.org/mailman/listinfo/hokey From hokey-bounces@ietf.org Wed Aug 15 15:20:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILOQ4-0000fS-6K; Wed, 15 Aug 2007 15:20:40 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILOQ3-0000cD-Ko for hokey@ietf.org; Wed, 15 Aug 2007 15:20:39 -0400 Received: from mout.perfora.net ([74.208.4.195]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ILOQ3-0005Bi-9X for hokey@ietf.org; Wed, 15 Aug 2007 15:20:39 -0400 Received: from [88.233.137.79] (helo=IBM52A5038A94F) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis), id 0MKpCa-1ILOPq0GCn-00056v; Wed, 15 Aug 2007 15:20:34 -0400 From: "Alper Yegin" To: "'Yoshihiro Ohba'" , "'Glen Zorn \(gwz\)'" Subject: RE: [HOKEY] consensus call: key delivery security protocol Date: Wed, 15 Aug 2007 22:20:22 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <20070815174312.GD9388@steelhead.localdomain> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcffY93XN8BVlIP4SfiSrcJgz6MjAQADV6nQ Message-ID: <0MKpCa-1ILOPq0GCn-00056v@mrelay.perfora.net> X-Provags-ID: V01U2FsdGVkX1/SopUGPEhcaUSncTnAwEIX+0W0Yjf5i4iLkui HloCNz5TuJ8iPSOdcWq7BneXyxQ2ZieDcgNOeaik6TN2u5B75A lg0WclVcKISpX8XsKJqtA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db Cc: hokey@ietf.org X-BeenThere: hokey@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: HOKEY WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hokey-bounces@ietf.org > It appears to me that a solution that relies on hop-by-hop security > violates RFC 4962. Isn't that plain obvious? _______________________________________________ HOKEY mailing list HOKEY@ietf.org https://www1.ietf.org/mailman/listinfo/hokey From hokey-bounces@ietf.org Thu Aug 16 10:41:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILgXk-0006U4-Ds; Thu, 16 Aug 2007 10:41:48 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILgXj-0006SV-3t for hokey@ietf.org; Thu, 16 Aug 2007 10:41:47 -0400 Received: from mgw.toshibaamericaresearch.com ([165.254.55.12] helo=toshi17.tari.toshiba.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ILgXi-0000ip-PW for hokey@ietf.org; Thu, 16 Aug 2007 10:41:47 -0400 Received: from steelhead.localdomain (tarij-95.tari.toshiba.com [172.30.24.143]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id l7GEfU2W015884; Thu, 16 Aug 2007 10:41:30 -0400 (EDT) (envelope-from yohba@tari.toshiba.com) Received: from ohba by steelhead.localdomain with local (Exim 4.67) (envelope-from ) id 1ILgXL-0004X2-Bz; Thu, 16 Aug 2007 10:41:23 -0400 Date: Thu, 16 Aug 2007 10:41:23 -0400 To: Alper Yegin Subject: Re: [HOKEY] consensus call: key delivery security protocol Message-ID: <20070816144123.GD16496@steelhead.localdomain> References: <20070815174312.GD9388@steelhead.localdomain> <0MKpCa-1ILOPq0GCn-00056v@mrelay.perfora.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <0MKpCa-1ILOPq0GCn-00056v@mrelay.perfora.net> User-Agent: Mutt/1.5.13 (2006-08-11) From: Yoshihiro Ohba X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: hokey@ietf.org X-BeenThere: hokey@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: HOKEY WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hokey-bounces@ietf.org So, here is my conclusion: it might be difficult to adopt a solution that violates RFC 4962, regardless of how 23 people in the meeting room were in favor of the solution. (Again, I have no intent to impede the progress of the work. What I really care is to waste our time to work on something that has a risk of being pushed back from IETF community and IESG in the later stages. BTW, I have a different type of concern on another concensus call on ERX transport which requires modification to EAP state machine.) Best Regards, Yoshihiro Ohba On Wed, Aug 15, 2007 at 10:20:22PM +0300, Alper Yegin wrote: > > It appears to me that a solution that relies on hop-by-hop security > > violates RFC 4962. > > Isn't that plain obvious? > > _______________________________________________ HOKEY mailing list HOKEY@ietf.org https://www1.ietf.org/mailman/listinfo/hokey From hokey-bounces@ietf.org Fri Aug 17 19:28:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IMBFG-0002OY-1h; Fri, 17 Aug 2007 19:28:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IMBFD-0002Nm-8h for hokey@ietf.org; Fri, 17 Aug 2007 19:28:43 -0400 Received: from usaga01-in.huawei.com ([206.16.17.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IMBF6-0007mQ-LJ for hokey@ietf.org; Fri, 17 Aug 2007 19:28:43 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JMX00E25YJNYZ@usaga01-in.huawei.com> for hokey@ietf.org; Fri, 17 Aug 2007 16:28:36 -0700 (PDT) Received: from N737011 ([10.192.25.70]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JMX000MAYJG5O@usaga01-in.huawei.com> for hokey@ietf.org; Fri, 17 Aug 2007 16:28:35 -0700 (PDT) Date: Fri, 17 Aug 2007 16:28:28 -0700 From: Madjid Nakhjiri Subject: RE: [HOKEY] consensus call: key delivery security protocol In-reply-to: <4C0FAAC489C8B74F96BEAD85EAEB262504C8A9E5@xmb-sjc-215.amer.cisco.com> To: "'Glen Zorn (gwz)'" , 'Yoshihiro Ohba' Message-id: <002201c7e126$51772c80$4619c00a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Thread-index: AcffCnqXod/KNi5PQQCrSRkxUuJtQQAReTSNAHRg4LA= X-Spam-Score: 0.0 (/) X-Scan-Signature: 4de5d7f989d6c039c8b887f1940f36ab Cc: 'Tim Polk' , 'Sam Hartman' , hokey@ietf.org X-BeenThere: hokey@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: HOKEY WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0731953756==" Errors-To: hokey-bounces@ietf.org This is a multi-part message in MIME format. --===============0731953756== Content-type: multipart/alternative; boundary="Boundary_(ID_4j5ZrNcQV6TKypxLK9i4IA)" This is a multi-part message in MIME format. --Boundary_(ID_4j5ZrNcQV6TKypxLK9i4IA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi Glen, The issue with sending keys through AAA proxy and its conflict with aaa-key-mgm draft was put in front of us during a recent security area review of RADIUS support for Mobile IP. Ambigious or not, the "limited scope" requirement comes from Russ Housley, former security AD and now chair of IETF and 4962 (when it was a draft) was used as a basis and motivator for creation of HOKEY WG, so if you think it is wrong, or it should fit itself to legacy RADIUS infrastructure, then with all due respect you have put the wrong hat on. During the BoFs and many other discussions in other SDOs people were telling us, you can pass the key from one authenticator/Base station to another as you handover, since it is all trusted infrastructure, so you don't need a new hierarchy or re-authentication (please see Dallas meeting minutes as an example), so where does that leave this group? Without stating my opinion about 4962 and as much as I personally like to use the AAA infrastructure for our solution, before you declare this a done deal, I think the chairs should really make sure that the IESG, especially security area is ok with this (this with no disrespect to your personal opinion, we all have put a lot of time, energy and money, not mention nerves here). Given the track record of this group reneging its own past declarations of consensus (both DSRK and ERX as examples), we might want to check this with the ADs. As an editor of this (or a "potential" editor based on what I am experiencing), I would have hard time committing to going two years down the road with this document only to get a push back from IESG later. I rather see the progress being "impeded" now for a month, than for 2 years between 2008-2010. We are simply doing an impedance matching between HOKEY and IESG (sorry for the RF joke). Sure we had a good hum in Chicago, and the consensus of course needs to be confirmed on the list (you may say it has been done), but I like to see this being confirmed with security area directorate. My experience in IETF, is when it comes to security, we should be proactive. Madjid _____ From: Glen Zorn (gwz) [mailto:gwz@cisco.com] Sent: Wednesday, August 15, 2007 8:57 AM To: Yoshihiro Ohba Cc: hokey@ietf.org Subject: RE: [HOKEY] consensus call: key delivery security protocol Glen, RFC 4962 (4902 was a typo) is Best Current Practice (BCP 132). gwz> Another typo was "My personal opinion is that RFC 4992 is just wrong, in the interesting way in which only statements can be: totally." It _should_ have said "My personal opinion is that RFC 4962 is just wrong, in the interesting way in which only _religious_ statements can be: totally." Shouldn't HOKEY WG drafts ratify RFC 4962 according to RFC 2026? I hope I've made my opinion of RFC 4062 clear ;-). Be that as it may, however, as WG chair I suppose I have to agree with your statement. So what, exactly, do you think violates it? AFAICT, RFC 4962 (among its other flaws) completely ignores the existence of RADIUS proxies. What _might_ have relevance to the question is in section 3, under the heading "Limit key scope". It says "Following the principle of least privilege, parties MUST NOT have access to keying material that is not needed to perform their role." This statement is ambiguous: is it the _access_ that is not needed to perform the role or the _keying material_? I prefer to resolve the ambiguity in favor of utility & say that it is the _access_; since RADIUS proxies MUST have access to the plaintext contents of any encrypted attribute (including passwords) in order to perform their role, they don't violate RFC 4962 in this case. Can you find a case where they do? " 5. BEST CURRENT PRACTICE (BCP) RFCs The BCP subseries of the RFC series is designed to be a way to standardize practices and the results of community deliberations. A BCP document is subject to the same basic set of procedures as standards track documents and thus is a vehicle by which the IETF community can define and ratify the community's best current thinking on a statement of principle or on what is believed to be the best way to perform some operations or IETF process function. " Regards, Yoshihiro Ohba On Fri, Aug 10, 2007 at 08:55:02AM -0700, Glen Zorn (gwz) wrote: > Glen, > > I don't think that we had a fair amount of discussion on this topic > before raising hands. > Yoshi, we've been discussing this topic for months now, ever since the interim meeting in San Jose. > Especially no one had raised the issue on how > option #1 can meet RFC 4902 until I send an email on this thread, and > I still don't see a satisfactory technical answer on the issue. > My personal opinion is that RFC 4902 is just wrong, in the interesting way in which only statements can be: totally. It's not just not Best Current Practice, it's not _any_ current practice & forcing IETF standards to conform to it virtually guarantees a steep spiral into irrelevance. > BTW, > I have absolutely no intent to impede the progress of the WG. > Sometimes our actions have unintended consequences. > > Regards, > Yoshihiro Ohba > > > On Thu, Aug 09, 2007 at 04:40:55PM -0700, Glen Zorn (gwz) wrote: > > Glen, > > > > A consensus in a face-to-face meeting does not mean it's final > > consensus simply because not all WG members can participate in > > face-to-face meetings. It needs to be confirmed over the WG mailing > > list. Otherwise, what is the purpose of this consensus call? > > Absolutely. However, 20 or 30 people in a face-to-face meeting cannot be shouted down by a couple of people on a mailing list. > > > > > I would like to hear more technical opinion from other WG members on > > this fundamental issue rather than seeing further discussion being > > shut up administratively. > > The largest part of a WG chair's job is to gauge WG consensus and move the work in that direction. The operative terms here are gauge and move. I have stated my opinion of the WG Consensus. If you choose to see that as being "administratively shut up" that's up to you. IMHO we have spent far too much time discussing this already and these endless arguments amongst a small group of people are seriously impeding the progress of the WG. If you want to discuss fundamental problems, I would suggest that an IRTF RG might be a good place to do it. > > > > > ... > --Boundary_(ID_4j5ZrNcQV6TKypxLK9i4IA) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT Re: [HOKEY] consensus call: key delivery security protocol

Hi Glen,

 

The issue with sending keys through AAA proxy and its conflict with aaa-key-mgm draft was put in front of us during a recent security area review of RADIUS support for Mobile IP.

 

Ambigious or not, the “limited scope” requirement comes from Russ Housley, former security AD and now chair of IETF and

4962 (when it was a draft) was used as a basis and motivator for creation of HOKEY WG, so if you think it is wrong, or it should fit itself to legacy RADIUS infrastructure, then with all due respect you have put the wrong hat on.

During the BoFs and many other discussions in other SDOs people were telling us, you can pass the key from one authenticator/Base station to another as you handover, since it is all trusted infrastructure, so you don’t need a new hierarchy or re-authentication (please see Dallas meeting minutes as an example), so where does that leave this group?

 

Without stating my opinion about 4962 and as much as I personally like to use the AAA infrastructure for our solution, before you declare this a done deal, I think the chairs should really make sure that the IESG, especially security area is ok with this (this with no disrespect to your personal opinion, we all have put a lot of time, energy and money, not mention nerves here).

 

Given the track record of this group reneging its own past declarations of consensus (both DSRK and ERX as examples), we might want to check this with the ADs.

As an editor of this (or a “potential” editor based on what I am experiencing), I would have hard time committing to going two years down the road with this document only to get a push back from IESG later.

I rather see the progress being “impeded” now for a month, than for 2 years between 2008-2010.

We are simply doing an impedance matching between HOKEY and IESG (sorry for the RF joke).

 

 

Sure we had a good hum in Chicago, and the consensus of course needs to be confirmed on the list (you may say it has been done), but I like to see this being confirmed with security area directorate. My experience in IETF, is when it comes to security, we should be proactive.

 

Madjid

 

 

 

From: Glen Zorn (gwz) [mailto:gwz@cisco.com]
Sent: Wednesday, August 15, 2007 8:57 AM
To: Yoshihiro Ohba
Cc: hokey@ietf.org
Subject: RE: [HOKEY] consensus call: key delivery security protocol

 

Glen,

RFC 4962 (4902 was a typo) is Best Current Practice (BCP 132). 

gwz> Another typo was "My personal opinion is that RFC 4992 is just wrong, in the interesting way in which only statements can be: totally."  It _should_ have said "My personal opinion is that RFC 4962 is just wrong, in the interesting way in which only _religious_ statements can be: totally."


Shouldn't HOKEY WG drafts ratify RFC 4962 according to RFC 2026?
I hope I've made my opinion of RFC 4062 clear ;-).  Be that as it may, however, as WG chair I suppose I have to agree with your statement.  So what, exactly, do you think violates it?  AFAICT, RFC 4962 (among its other flaws) completely ignores the existence of RADIUS proxies.  What _might_ have relevance to the question is in section 3, under the heading "Limit key scope".  It says "Following the principle of least privilege, parties MUST NOT have access to keying material that is not needed to perform their role."  This statement is ambiguous: is it the _access_ that is not needed to perform the role or the _keying material_?  I prefer to resolve the ambiguity in favor of utility & say that it is the _access_; since RADIUS proxies MUST have access to the plaintext contents of any encrypted attribute (including passwords) in order to perform their role, they don't violate RFC 4962 in this case.  Can you find a case where they do?


"
5.  BEST CURRENT PRACTICE (BCP) RFCs

   The BCP subseries of the RFC series is designed to be a way to
   standardize practices and the results of community deliberations.  A
   BCP document is subject to the same basic set of procedures as
   standards track documents and thus is a vehicle by which the IETF
   community can define and ratify the community's best current thinking
   on a statement of principle or on what is believed to be the best way
   to perform some operations or IETF process function.
"

Regards,
Yoshihiro Ohba

On Fri, Aug 10, 2007 at 08:55:02AM -0700, Glen Zorn (gwz) wrote:
> Glen,
>
> I don't think that we had a fair amount of discussion on this topic
> before raising hands. 
> Yoshi, we've been discussing this topic for months now, ever since the interim meeting in San Jose.
> Especially no one had raised the issue on how
> option #1 can meet RFC 4902 until I send an email on this thread, and
> I still don't see a satisfactory technical answer on the issue. 
> My personal opinion is that RFC 4902 is just wrong, in the interesting way in which only statements can be: totally.  It's not just not Best Current Practice, it's not _any_ current practice & forcing IETF standards to conform to it virtually guarantees a steep spiral into irrelevance.
> BTW,
> I have absolutely no intent to impede the progress of the WG.
> Sometimes our actions have unintended consequences.
>
> Regards,
> Yoshihiro Ohba
>
>
> On Thu, Aug 09, 2007 at 04:40:55PM -0700, Glen Zorn (gwz) wrote:
> > Glen,
> >
> > A consensus in a face-to-face meeting does not mean it's final
> > consensus simply because not all WG members can participate in
> > face-to-face meetings.  It needs to be confirmed over the WG mailing
> > list.  Otherwise, what is the purpose of this consensus call?
> > Absolutely.  However, 20 or 30 people in a face-to-face meeting cannot be shouted down by a couple of people on a mailing list.
>
> >
> > I would like to hear more technical opinion from other WG members on
> > this fundamental issue rather than seeing further discussion being
> > shut up administratively.
> > The largest part of a WG chair's job is to gauge WG consensus and move the work in that direction.  The operative terms here are gauge and  move.  I have stated my opinion of the WG Consensus.  If you choose to see that as being "administratively shut up" that's up to you.  IMHO we have spent far too much time discussing this already and these endless arguments amongst a small group of people are seriously impeding the progress of the WG.  If you want to discuss fundamental problems, I would suggest that an IRTF RG might be a good place to do it.
>
> >
> > ...
>

--Boundary_(ID_4j5ZrNcQV6TKypxLK9i4IA)-- --===============0731953756== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ HOKEY mailing list HOKEY@ietf.org https://www1.ietf.org/mailman/listinfo/hokey --===============0731953756==-- From hokey-bounces@ietf.org Mon Aug 20 13:17:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INAss-0005hl-Ti; Mon, 20 Aug 2007 13:17:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INAss-0005cf-19 for hokey@ietf.org; Mon, 20 Aug 2007 13:17:46 -0400 Received: from dhcp-18-188-10-61.dyn.mit.edu ([18.188.10.61] helo=carter-zimmerman.suchdamage.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1INAsq-0003KF-TS for hokey@ietf.org; Mon, 20 Aug 2007 13:17:46 -0400 Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 9005A48C3; Mon, 20 Aug 2007 13:17:44 -0400 (EDT) From: Sam Hartman To: Madjid Nakhjiri Subject: Re: [HOKEY] consensus call: key delivery security protocol References: <002201c7e126$51772c80$4619c00a@china.huawei.com> Date: Mon, 20 Aug 2007 13:17:44 -0400 In-Reply-To: <002201c7e126$51772c80$4619c00a@china.huawei.com> (Madjid Nakhjiri's message of "Fri, 17 Aug 2007 16:28:28 -0700") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.1 (/) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 Cc: 'Tim Polk' , hokey@ietf.org X-BeenThere: hokey@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: HOKEY WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hokey-bounces@ietf.org I will admit that I find it hard to tell wether Russ's draft permits sharing keys through AAA infrastructure or not. It's ambiguous because it seems clearly permitted for the MSK. _______________________________________________ HOKEY mailing list HOKEY@ietf.org https://www1.ietf.org/mailman/listinfo/hokey From hokey-bounces@ietf.org Tue Aug 21 17:40:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INbSk-0003sp-Up; Tue, 21 Aug 2007 17:40:34 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INbSj-0003rv-Mj for hokey@ietf.org; Tue, 21 Aug 2007 17:40:33 -0400 Received: from usaga01-in.huawei.com ([206.16.17.211]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1INbSj-0005FV-Co for hokey@ietf.org; Tue, 21 Aug 2007 17:40:33 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JN500DZM87KAR@usaga01-in.huawei.com> for hokey@ietf.org; Tue, 21 Aug 2007 14:40:32 -0700 (PDT) Received: from N737011 ([10.192.25.70]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JN500CV987F7D@usaga01-in.huawei.com> for hokey@ietf.org; Tue, 21 Aug 2007 14:40:32 -0700 (PDT) Date: Tue, 21 Aug 2007 14:40:27 -0700 From: Madjid Nakhjiri Subject: RE: [HOKEY] consensus call: key delivery security protocol In-reply-to: To: 'Sam Hartman' Message-id: <000401c7e43b$e42609d0$4619c00a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcfjThOmDm3twz4fRG2LNSgRjNdlzQA7X11Q X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: 'Tim Polk' , hokey@ietf.org X-BeenThere: hokey@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: HOKEY WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hokey-bounces@ietf.org Well, this much uncertainty is worrisome, it almost seem that we need to somehow force this through IESG and sec area review before going further. Given that the ps draft is the only one with any requirements in it, the quickest way I see this happening is possibly capture it in the PS draft somehow... Madjid -----Original Message----- From: Sam Hartman [mailto:hartmans-ietf@mit.edu] Sent: Monday, August 20, 2007 10:18 AM To: Madjid Nakhjiri Cc: 'Tim Polk'; hokey@ietf.org Subject: Re: [HOKEY] consensus call: key delivery security protocol I will admit that I find it hard to tell wether Russ's draft permits sharing keys through AAA infrastructure or not. It's ambiguous because it seems clearly permitted for the MSK. _______________________________________________ HOKEY mailing list HOKEY@ietf.org https://www1.ietf.org/mailman/listinfo/hokey _______________________________________________ HOKEY mailing list HOKEY@ietf.org https://www1.ietf.org/mailman/listinfo/hokey From hokey-bounces@ietf.org Tue Aug 21 18:07:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INbrp-00032B-Ja; Tue, 21 Aug 2007 18:06:29 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INbro-000326-IV for hokey@ietf.org; Tue, 21 Aug 2007 18:06:28 -0400 Received: from colo.trepanning.net ([69.55.226.174] helo=mail1.trepanning.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1INbro-0005x9-53 for hokey@ietf.org; Tue, 21 Aug 2007 18:06:28 -0400 Received: from www.trepanning.net (localhost [127.0.0.1]) by mail1.trepanning.net (Postfix) with ESMTP id 10C6D1FA61B6; Tue, 21 Aug 2007 15:06:27 -0700 (PDT) Received: from 65.105.205.133 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Tue, 21 Aug 2007 15:06:27 -0700 (PDT) Message-ID: <38065.65.105.205.133.1187733987.squirrel@www.trepanning.net> In-Reply-To: References: <002201c7e126$51772c80$4619c00a@china.huawei.com> Date: Tue, 21 Aug 2007 15:06:27 -0700 (PDT) Subject: Re: [HOKEY] consensus call: key delivery security protocol From: "Dan Harkins" To: "Sam Hartman" User-Agent: SquirrelMail/1.4.8 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 (Normal) Importance: Normal Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: 'Tim Polk' , hokey@ietf.org, Madjid Nakhjiri X-BeenThere: hokey@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: HOKEY WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hokey-bounces@ietf.org Sam, Where do you read that it is permitted for the MSK? It seems to me that RFC4962 deals with the security around distribution and generation of session keys and not with distribution of network access credentials (like the MSK). Look at "Limit Key Scope": you have access to a key if you have all the secret information needed derive it. That's clearly talking about session keys since it is obviously false when talking about an MSK-- I have access to an MSK if I know it even if I don't know the inputs to the TLS PRF that derived it. This section also specifically mentions "session keys". Look at "Authenticate All Parties": RADIUS and DIAMETER provide a mechanism for identification of AAA clients. Which follows from the preceding paragraph talking about parties involved in a session key establishment protocol needing to identify themselves. The section on "Peer and authenticator authorization" uses the example of 802.11's 4-way handshake which is a protocol used to derive session keys. In the "Prevent the Domino Effect" section it says, "the scope of the keying material must be defined and understood by all parties that communicate with a party that holds that keying material." If the "keying material" is an MSK and there are proxies among "all parties" how do you address that requirement? Dan. On Mon, August 20, 2007 10:17 am, Sam Hartman wrote: > I will admit that I find it hard to tell wether Russ's draft permits > sharing keys through AAA infrastructure or not. > > It's ambiguous because it seems clearly permitted for the MSK. > > _______________________________________________ > HOKEY mailing list > HOKEY@ietf.org > https://www1.ietf.org/mailman/listinfo/hokey > _______________________________________________ HOKEY mailing list HOKEY@ietf.org https://www1.ietf.org/mailman/listinfo/hokey From hokey-bounces@ietf.org Tue Aug 21 18:26:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INcAH-0004U9-Ee; Tue, 21 Aug 2007 18:25:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INcAG-0004U4-83 for hokey@ietf.org; Tue, 21 Aug 2007 18:25:32 -0400 Received: from bay0-omc2-s22.bay0.hotmail.com ([65.54.246.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1INcAF-0001FT-EF for hokey@ietf.org; Tue, 21 Aug 2007 18:25:32 -0400 Received: from BAY113-W4 ([65.54.168.104]) by bay0-omc2-s22.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Tue, 21 Aug 2007 15:25:30 -0700 Message-ID: X-Originating-IP: [67.170.84.64] From: Glen Zorn To: Dan Harkins , Sam Hartman Subject: RE: [HOKEY] consensus call: key delivery security protocol Date: Tue, 21 Aug 2007 15:25:29 -0700 Importance: Normal In-Reply-To: <38065.65.105.205.133.1187733987.squirrel@www.trepanning.net> References: <002201c7e126$51772c80$4619c00a@china.huawei.com> <38065.65.105.205.133.1187733987.squirrel@www.trepanning.net> MIME-Version: 1.0 X-OriginalArrivalTime: 21 Aug 2007 22:25:30.0144 (UTC) FILETIME=[2E706200:01C7E442] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: 'Tim Polk' , hokey@ietf.org, Madjid Nakhjiri X-BeenThere: hokey@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: HOKEY WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2127726910==" Errors-To: hokey-bounces@ietf.org --===============2127726910== Content-Type: multipart/alternative; boundary="_6a28f4e8-2016-4dda-85ec-c84b7dab5908_" --_6a28f4e8-2016-4dda-85ec-c84b7dab5908_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > Sam,> > Where do you read that it is permitted for the MSK? It seems to m= e> that RFC4962 deals with the security around distribution and generation>= of session keys and not with distribution of network access credentials> (= like the MSK). =20 Let's just say that (despite the name) the MSK is not a "Master Session Key= " & is in fact a network access credential (where do you get that from, BTW= ?). Since AFAIK the MSK is the only key commonly transferred via AAA, does= n't that make RFC 4962 kind of, well, irrelevant? > > Look at "Limit Key Scope": you have access to a key if you have> all th= e secret information needed derive it. That's clearly talking> about sessio= n keys since it is obviously false when talking about an> MSK-- I have acce= ss to an MSK if I know it even if I don't know the> inputs to the TLS PRF t= hat derived it. This section also specifically> mentions "session keys". =20 So why isn't that statement false WRT any symmetric key, session or otherwi= se? How can I know a key without having (possibly unauthorized) access to = it? =20 ... =20 > > In the "Prevent the Domino Effect" section it says, "the scope of the> = keying material must be defined and understood by all parties that> communi= cate with a party that holds that keying material." If the "keying> materia= l" is an MSK and there are proxies among "all parties" how do you> address = that requirement? =20 Good question. As I've said before, I consider the biggest flaw in the doc= ument is its insistence on ignoring the way that AAA systems in the real wo= rld actually function.> > Dan.> > On Mon, August 20, 2007 10:17 am, Sam Har= tman wrote:> > I will admit that I find it hard to tell wether Russ's draft= permits> > sharing keys through AAA infrastructure or not.> >> > It's ambi= guous because it seems clearly permitted for the MSK.> >> > _______________= ________________________________> > HOKEY mailing list> > HOKEY@ietf.org> >= https://www1.ietf.org/mailman/listinfo/hokey> >> > > > ___________________= ____________________________> HOKEY mailing list> HOKEY@ietf.org> https://w= ww1.ietf.org/mailman/listinfo/hokey _________________________________________________________________ Connect to the next generation of MSN Messenger=A0 http://imagine-msn.com/messenger/launch80/default.aspx?locale=3Den-us&sourc= e=3Dwlmailtagline= --_6a28f4e8-2016-4dda-85ec-c84b7dab5908_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > Sam,
>
> Where do you read that= it is permitted for the MSK? It seems to me
> that RFC4962 deals wit= h the security around distribution and generation
> of session keys a= nd not with distribution of network access credentials
> (like the MS= K).
 
Let's just say that (despite the name) the MSK is not a "Master Se= ssion Key" & is in fact a network access credential (where do you get t= hat from, BTW?).  Since AFAIK the MSK is the only key commonl= y transferred via AAA, doesn't that make RFC 4962 kind of, well, irrelevant= ?

>
> Look at "Limit Key Scope": you have access to a key if yo= u have
> all the secret information needed derive it. That's clearly = talking
> about session keys since it is obviously false when talking= about an
> MSK-- I have access to an MSK if I know it even if I don'= t know the
> inputs to the TLS PRF that derived it. This section also= specifically
> mentions "session keys".
 
So why isn't that statement false WRT any symmetric key, session o= r otherwise?  How can I know a key without having (possibly unauthoriz= ed) access to it?
 
...
 
>
> In the "Prevent the Domino Effect" section it says, "the scop= e of the
> keying material must be defined and understood by all part= ies that
> communicate with a party that holds that keying material."= If the "keying
> material" is an MSK and there are proxies among "al= l parties" how do you
> address that requirement?
 
Good question.  As I've said before, I consider the biggest flaw in th= e document is its insistence on ignoring the way that AAA systems in the re= al world actually function.
>
> Dan.
>
> On Mon, = August 20, 2007 10:17 am, Sam Hartman wrote:
> > I will admit that= I find it hard to tell wether Russ's draft permits
> > sharing ke= ys through AAA infrastructure or not.
> >
> > It's ambigu= ous because it seems clearly permitted for the MSK.
> >
> &g= t; _______________________________________________
> > HOKEY maili= ng list
> > HOKEY@ietf.org
> > https://www1.ietf.org/mail= man/listinfo/hokey
> >
>
>
>
> ________= _______________________________________
> HOKEY mailing list
> = HOKEY@ietf.org
> https://www1.ietf.org/mailman/listinfo/hokey

=
Connect to the next generation of MSN Messenger=A0 Get it now! = --_6a28f4e8-2016-4dda-85ec-c84b7dab5908_-- --===============2127726910== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ HOKEY mailing list HOKEY@ietf.org https://www1.ietf.org/mailman/listinfo/hokey --===============2127726910==-- From hokey-bounces@ietf.org Tue Aug 21 19:12:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INcu7-0000Rs-IX; Tue, 21 Aug 2007 19:12:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INcu5-0000Rm-Rl for hokey@ietf.org; Tue, 21 Aug 2007 19:12:53 -0400 Received: from stratton-six-thirty.mit.edu ([18.187.7.119] helo=carter-zimmerman.suchdamage.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1INcu4-0002Xc-M9 for hokey@ietf.org; Tue, 21 Aug 2007 19:12:53 -0400 Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 5183648C3; Tue, 21 Aug 2007 19:12:52 -0400 (EDT) From: Sam Hartman To: "Dan Harkins" Subject: Re: [HOKEY] consensus call: key delivery security protocol References: <002201c7e126$51772c80$4619c00a@china.huawei.com> <38065.65.105.205.133.1187733987.squirrel@www.trepanning.net> Date: Tue, 21 Aug 2007 19:12:52 -0400 In-Reply-To: <38065.65.105.205.133.1187733987.squirrel@www.trepanning.net> (Dan Harkins's message of "Tue, 21 Aug 2007 15:06:27 -0700 (PDT)") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: 'Tim Polk' , hokey@ietf.org, Madjid Nakhjiri X-BeenThere: hokey@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: HOKEY WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hokey-bounces@ietf.org >>>>> "Dan" == Dan Harkins writes: Dan> Sam, Dan> Where do you read that it is permitted for the MSK? It Dan> seems to me that RFC4962 deals with the security around Dan> distribution and generation of session keys and not with Dan> distribution of network access credentials (like the MSK). It is definitely true that some parts of RFC 4962 only deal with session keys. It is also true that the MSK is not a session key. Dan> Look at "Limit Key Scope": you have access to a key if you Dan> have all the secret information needed derive it. That's Dan> clearly talking about session keys since it is obviously Dan> false when talking about an MSK-- I have access to an MSK if Dan> I know it even if I don't know the inputs to the TLS PRF that Dan> derived it. This section also specifically mentions "session Dan> keys". I think you also have a key if you have been given that key. That's an if statement not an only if statement. I agree that the limit key scope section does not apply to the MSK. Dan> Look at "Authenticate All Parties": RADIUS and DIAMETER Dan> provide a mechanism for identification of AAA clients. Which Dan> follows from the preceding paragraph talking about parties Dan> involved in a session key establishment protocol needing to Dan> identify themselves. Dan> The section on "Peer and authenticator authorization" uses Dan> the example of 802.11's 4-way handshake which is a protocol Dan> used to derive session keys. Dan> In the "Prevent the Domino Effect" section it says, "the Dan> scope of the keying material must be defined and understood Dan> by all parties that communicate with a party that holds that Dan> keying material." If the "keying material" is an MSK and Dan> there are proxies among "all parties" how do you address that Dan> requirement? This is a good question. _______________________________________________ HOKEY mailing list HOKEY@ietf.org https://www1.ietf.org/mailman/listinfo/hokey From hokey-bounces@ietf.org Tue Aug 21 21:30:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INf2q-0000zv-Qv; Tue, 21 Aug 2007 21:30:04 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INf2q-0000wj-CH for hokey@ietf.org; Tue, 21 Aug 2007 21:30:04 -0400 Received: from mgw.toshibaamericaresearch.com ([165.254.55.12] helo=toshi17.tari.toshiba.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1INf2m-0002LL-SD for hokey@ietf.org; Tue, 21 Aug 2007 21:30:01 -0400 Received: from steelhead.localdomain (tarij-83.tari.toshiba.com [172.30.24.131]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id l7M1TRE5036948; Tue, 21 Aug 2007 21:29:28 -0400 (EDT) (envelope-from yohba@tari.toshiba.com) Received: from ohba by steelhead.localdomain with local (Exim 4.67) (envelope-from ) id 1INf1x-0003GV-2W; Tue, 21 Aug 2007 21:29:09 -0400 Date: Tue, 21 Aug 2007 21:29:09 -0400 To: Dan Harkins Subject: Re: [HOKEY] consensus call: key delivery security protocol Message-ID: <20070822012909.GL856@steelhead.localdomain> References: <002201c7e126$51772c80$4619c00a@china.huawei.com> <38065.65.105.205.133.1187733987.squirrel@www.trepanning.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <38065.65.105.205.133.1187733987.squirrel@www.trepanning.net> User-Agent: Mutt/1.5.13 (2006-08-11) From: Yoshihiro Ohba X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: 'Tim Polk' , Sam Hartman , hokey@ietf.org, Madjid Nakhjiri X-BeenThere: hokey@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: HOKEY WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hokey-bounces@ietf.org Dan, On Tue, Aug 21, 2007 at 03:06:27PM -0700, Dan Harkins wrote: > > Sam, > > Where do you read that it is permitted for the MSK? It seems to me > that RFC4962 deals with the security around distribution and generation > of session keys and not with distribution of network access credentials > (like the MSK). While some part of RFC 4962 specifically talks about session keys, I don't think that it does not deal with distribution of other keying material including MSK. For example: " Keying material confidentiality and integrity While preserving algorithm independence, confidentiality and integrity of all keying material MUST be maintained. " The above requirement mentions "all keying material". I can interpret this to cover both session keys and network access credentials. > > Look at "Limit Key Scope": you have access to a key if you have > all the secret information needed derive it. That's clearly talking > about session keys since it is obviously false when talking about an > MSK-- I have access to an MSK if I know it even if I don't know the > inputs to the TLS PRF that derived it. This section also specifically > mentions "session keys". This section mentions "session keys" in the second paragraph, but I can interpret that the first paragraph covers both session keys and network access credentials: " Limit key scope Following the principle of least privilege, parties MUST NOT have access to keying material that is not needed to perform their role. A party has access to a particular key if it has access to all of the secret information needed to derive it. Any protocol that is used to establish session keys MUST specify the scope for session keys, clearly identifying the parties to whom the session key is available. " Yoshihiro Ohba > > Look at "Authenticate All Parties": RADIUS and DIAMETER provide a > mechanism for identification of AAA clients. Which follows from the > preceding paragraph talking about parties involved in a session key > establishment protocol needing to identify themselves. > > The section on "Peer and authenticator authorization" uses the example > of 802.11's 4-way handshake which is a protocol used to derive session > keys. > > In the "Prevent the Domino Effect" section it says, "the scope of the > keying material must be defined and understood by all parties that > communicate with a party that holds that keying material." If the "keying > material" is an MSK and there are proxies among "all parties" how do you > address that requirement? > > Dan. > > On Mon, August 20, 2007 10:17 am, Sam Hartman wrote: > > I will admit that I find it hard to tell wether Russ's draft permits > > sharing keys through AAA infrastructure or not. > > > > It's ambiguous because it seems clearly permitted for the MSK. > > > > _______________________________________________ > > HOKEY mailing list > > HOKEY@ietf.org > > https://www1.ietf.org/mailman/listinfo/hokey > > > > > > _______________________________________________ > HOKEY mailing list > HOKEY@ietf.org > https://www1.ietf.org/mailman/listinfo/hokey > > _______________________________________________ HOKEY mailing list HOKEY@ietf.org https://www1.ietf.org/mailman/listinfo/hokey From hokey-bounces@ietf.org Fri Aug 24 00:49:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOR6b-0002wh-F7; Fri, 24 Aug 2007 00:49:09 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOR6Z-0002qz-It for hokey@ietf.org; Fri, 24 Aug 2007 00:49:07 -0400 Received: from dispatch.cs.umd.edu ([128.8.128.60]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IOR6Z-0007JY-6C for hokey@ietf.org; Fri, 24 Aug 2007 00:49:07 -0400 Received: from [192.168.7.102] (c-69-136-165-65.hsd1.in.comcast.net [69.136.165.65]) (authenticated bits=0) by dispatch.cs.umd.edu (8.13.1/8.12.5) with ESMTP id l7O4mUOZ021824 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 24 Aug 2007 00:48:32 -0400 Message-ID: <46CE1CDB.9080207@cs.umd.edu> Date: Fri, 24 Aug 2007 00:48:43 +0100 From: Charles Clancy User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Madjid Nakhjiri Subject: Re: [HOKEY] WGLC: re-auth problem statement References: <003d01c7d5f6$853e9250$4619c00a@china.huawei.com> In-Reply-To: <003d01c7d5f6$853e9250$4619c00a@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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=-4.37, required 5, ALL_TRUSTED -1.80, AWL -0.01, BAYES_00 -2.60, DATE_IN_PAST_03_06 0.04) X-CSD-MailScanner-From: clancy@cs.umd.edu X-Spam-Status: No X-Spam-Score: 1.4 (+) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: hokey@ietf.org X-BeenThere: hokey@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: HOKEY WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hokey-bounces@ietf.org Captured as issue 35. When we wrote the document, it was specifically the "re-auth" problem statement (hence the title), and did not discuss key distribution (or at the time, "roaming"). In fact, all references to it in the early drafts were specifically removed. And indeed, our charter deliverables do not include a problem statement for anything other than re-auth. I don't have any objection to adding a paragraph to section 4 that talks about it. Does anyone else feel strongly about this? Madjid, could you propose some text? -- t. charles clancy, ph.d. <> tcc@umd.edu <> eng.umd.edu/~tcc Madjid Nakhjiri wrote: > Hi Charles, > > Thanks for updating the doc. It would probably be good if we include some > text on delivery of new keys to authenticators (as part of handover) in the > problem statement section. Currently we do talk about re-auth but not > handover keying. > > Madjid > -----Original Message----- > From: Charles Clancy [mailto:clancy@cs.umd.edu] > Sent: Thursday, August 02, 2007 1:01 PM > To: hokey@ietf.org > Subject: [HOKEY] WGLC: re-auth problem statement > > The updated re-auth problem statement has been posted: > > http://tools.ietf.org/html/draft-ietf-hokey-reauth-ps-02 > > We're issing working group last call on this document. Please send your > comments to the list by August 17. > > -- > t. charles clancy, ph.d. <> tcc@umd.edu <> eng.umd.edu/~tcc > adjunct professor, electrical engineering, university of maryland > > > > > > _______________________________________________ > HOKEY mailing list > HOKEY@ietf.org > https://www1.ietf.org/mailman/listinfo/hokey > _______________________________________________ HOKEY mailing list HOKEY@ietf.org https://www1.ietf.org/mailman/listinfo/hokey From hokey-bounces@ietf.org Fri Aug 24 00:58:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IORFf-0001fM-Ft; Fri, 24 Aug 2007 00:58:31 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IORFe-0001fD-Pr for hokey@ietf.org; Fri, 24 Aug 2007 00:58:30 -0400 Received: from consign.cs.umd.edu ([128.8.128.61]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IORFe-0007UM-Dw for hokey@ietf.org; Fri, 24 Aug 2007 00:58:30 -0400 Received: from [192.168.7.102] (c-69-136-165-65.hsd1.in.comcast.net [69.136.165.65]) (authenticated bits=0) by consign.cs.umd.edu (8.13.1/8.12.5) with ESMTP id l7O4wO8L028034 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 24 Aug 2007 00:58:24 -0400 Message-ID: <46CE1F2C.60003@cs.umd.edu> Date: Fri, 24 Aug 2007 00:58:36 +0100 From: Charles Clancy User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: hokey@ietf.org Subject: Re: [HOKEY] preauth discussion References: <46A7B772.9030300@cs.umd.edu> In-Reply-To: <46A7B772.9030300@cs.umd.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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=-4.366, required 5, ALL_TRUSTED -1.80, AWL -0.01, BAYES_00 -2.60, DATE_IN_PAST_03_06 0.04) X-CSD-MailScanner-From: clancy@cs.umd.edu X-Spam-Status: No X-Spam-Score: 1.4 (+) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 X-BeenThere: hokey@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: HOKEY WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hokey-bounces@ietf.org There seems to be strong consensus for starting with Yoshi's preauth document ... http://tools.ietf.org/html/draft-ohba-hokeyp-preauth-ps-00 ... to satisfy our preauth charter item, and that a design team is not necessary. I propose that the authors of this document rev it to bring it in line with the current HOKEY terminology, and then submit it as a WG document. Are there any objections to this proposal? -- t. charles clancy, ph.d. <> tcc@umd.edu <> eng.umd.edu/~tcc Charles Clancy wrote: > During the WG meeting, there seemed to be support for simply developing > recommendations for pre-authentication in the HOKEY working group, and > not an actual protocol. Tim agrees that this could be done without > modifying our deliverables or milestones, given the current charter > wording. > > Is there any objection to taking this route? > > Assuming we pursue this route, are there volunteers to work on a design > team for developing a -00 document on pre-authentication? > > Please respond by August 8th. > _______________________________________________ HOKEY mailing list HOKEY@ietf.org https://www1.ietf.org/mailman/listinfo/hokey From hokey-bounces@ietf.org Fri Aug 24 01:34:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IORol-0003gg-H6; Fri, 24 Aug 2007 01:34:47 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IORoj-0003gP-7T for hokey@ietf.org; Fri, 24 Aug 2007 01:34:45 -0400 Received: from dispatch.cs.umd.edu ([128.8.128.60]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IORoi-0008K6-PW for hokey@ietf.org; Fri, 24 Aug 2007 01:34:45 -0400 Received: from [192.168.7.102] (c-69-136-165-65.hsd1.in.comcast.net [69.136.165.65]) (authenticated bits=0) by dispatch.cs.umd.edu (8.13.1/8.12.5) with ESMTP id l7O5YQek026580 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 24 Aug 2007 01:34:27 -0400 Message-ID: <46CE279E.1050707@cs.umd.edu> Date: Fri, 24 Aug 2007 01:34:38 +0100 From: Charles Clancy User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Preetida.Vinayakray-Jani@nokia.com Subject: Re: [HOKEY] revisions to reauth problem statement References: <83CD3A5F85DE7D43B6A5CC37CCBAEECE04127139@esebe104.NOE.Nokia.com> In-Reply-To: <83CD3A5F85DE7D43B6A5CC37CCBAEECE04127139@esebe104.NOE.Nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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=-4.364, required 5, ALL_TRUSTED -1.80, AWL -0.01, BAYES_00 -2.60, DATE_IN_PAST_03_06 0.04) X-CSD-MailScanner-From: clancy@cs.umd.edu X-Spam-Status: No X-Spam-Score: 1.4 (+) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: hokey@ietf.org X-BeenThere: hokey@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: HOKEY WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hokey-bounces@ietf.org Preeti, Thanks for your comments. I don't think we want to get into reactive vs proactive and preauth here, because this is specifically the reauth problem statement. With regard to the security goals section, I think your suggestions may be a little too specific. The KDF and key material formatting are specified in the "solutions" drafts, not here, and existing security goals would require them to be done properly. I'm not sure what you mean by handover key recovery. We don't talk about key distribution at all in this document. Can you be more specific? -- t. charles clancy, ph.d. <> tcc@umd.edu <> eng.umd.edu/~tcc adjunct professor, electrical engineering, university of maryland Preetida.Vinayakray-Jani@nokia.com wrote: > Hi, > > Hope I'm not responding after deadline for subjected text. If not then > here there are few points/suggestions, perhaps you would like to add > > Referring to section 5 - Design goals - > > This section very well explains various goals. However in subsection > 'lower latency operation' - it can be emphasized in following way - > > Re-authentication process can be reactive or proactive(e.g. pre-auth) > and design goals for these two different approaches should consider low > latency performance objective. > > Referring to section 6 - Security goals - > > 1. key derivation function and keying material format > 2. Acceptable policies for handover key recovery? > > If such points are within the scope of Design goals + security goals > then relevant text can be placed. > > Regds > Preeti > > > > > >I've put together some revisions to the reauth problem statement draft: > > >_http://www.ltsnet.net/ietf/hokey/draft-ietf-hokey-reauth-ps-02a.txt_ > > > >Any comments? Anything else that should be added? Once submissions for > IDs reopens, I plan to submit >the updated document, and then go to WGLC. > _______________________________________________ HOKEY mailing list HOKEY@ietf.org https://www1.ietf.org/mailman/listinfo/hokey From hokey-bounces@ietf.org Fri Aug 24 14:57:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOeL7-0002RO-2r; Fri, 24 Aug 2007 14:57:01 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOeL5-0002PP-BF for hokey@ietf.org; Fri, 24 Aug 2007 14:56:59 -0400 Received: from colo.trepanning.net ([69.55.226.174] helo=mail1.trepanning.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IOeL4-00064g-Mg for hokey@ietf.org; Fri, 24 Aug 2007 14:56:59 -0400 Received: from www.trepanning.net (localhost [127.0.0.1]) by mail1.trepanning.net (Postfix) with ESMTP id 72B751FA6046; Fri, 24 Aug 2007 11:56:57 -0700 (PDT) Received: from 65.105.205.133 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Fri, 24 Aug 2007 11:56:57 -0700 (PDT) Message-ID: <46953.65.105.205.133.1187981817.squirrel@www.trepanning.net> In-Reply-To: References: <002201c7e126$51772c80$4619c00a@china.huawei.com> <38065.65.105.205.133.1187733987.squirrel@www.trepanning.net> Date: Fri, 24 Aug 2007 11:56:57 -0700 (PDT) Subject: RE: [HOKEY] consensus call: key delivery security protocol From: "Dan Harkins" To: "Glen Zorn" User-Agent: SquirrelMail/1.4.8 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 (Normal) Importance: Normal Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: 'Tim Polk' , Sam Hartman , hokey@ietf.org, Madjid Nakhjiri X-BeenThere: hokey@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: HOKEY WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hokey-bounces@ietf.org Glen, On Tue, August 21, 2007 3:25 pm, Glen Zorn wrote: >> Sam,> > Where do you read that it is permitted for the MSK? It seems t= o >> me> that RFC4962 deals with the security around distribution and >> generation> of session keys and not with distribution of network acces= s >> credentials> (like the MSK). > > Let's just say that (despite the name) the MSK is not a "Master Session > Key" & is in fact a network access credential (where do you get that fr= om, > BTW?). Since AFAIK the MSK is the only key commonly transferred via AA= A, > doesn't that make RFC 4962 kind of, well, irrelevant? I get "network access credential" from its use. If a client can prove possession of that blob-of-bits then it gets network access. I don't think we should get hung up on the semantics of it. Perhaps we can call it the Mega Super Key. I don't think RFC4962 is necessarily irrelevent. It talks about AAA key management and, according to it AAA key management often includes a collection of protocols, one of which is the AAA protocol. Other protocols are used in conjunction with the AAA protocol to provide an overall solution. These other protocols often provide authentication and security association establishment. So my read is that it is giving guidance to the "other protocols" that provide authentication and security association establishment. For instance 802.11's 4 way handshake. It provides "authentication" by provin= g possession of the Mega Super Key. It derives security associations bound to some lower-layer identity (BSSID/MAC addr) that contain some transient session keys used to protect a particular traffic flow. Unfortunately I don't think it talks directly about _key distribution_ protocols that send peers' network access credentials hither and yon. >> > Look at "Limit Key Scope": you have access to a key if you have> all >> the secret information needed derive it. That's clearly talking> about >> session keys since it is obviously false when talking about an> MSK-- >> I have access to an MSK if I know it even if I don't know the> inputs >> to the TLS PRF that derived it. This section also specifically> >> mentions "session keys". > > So why isn't that statement false WRT any symmetric key, session or > otherwise? How can I know a key without having (possibly unauthorized) > access to it? Perhaps I phrased it poorly. I'm saying that if you know the MSK then you ipso facto have access to it. But "Limit Key Scope" says you have access to a key if you know the secret information needed to derive it. Because of that wording I think it's addressing keys derived from the MSK by some secure association protocol. If "Limit Key Scope" was talking about the MSK then, in my opinion, it wouldn't say what it says the way it says it. Maybe I'm getting hung up on the semantics though.... > ... > >> > In the "Prevent the Domino Effect" section it says, "the scope of th= e> >> keying material must be defined and understood by all parties that> >> communicate with a party that holds that keying material." If the >> "keying> material" is an MSK and there are proxies among "all parties" >> how do you> address that requirement? > > Good question. As I've said before, I consider the biggest flaw in the > document is its insistence on ignoring the way that AAA systems in the > real world actually function. Actually what I think the problem you have with it is that it does not make accomodations for the way AAA systems in the "real world" actually function. But insecure practices should be stopped. I'm sure when traffic signs were first introduced people said, "they ignore the way carts and buggies actually work in the real world" because previously carts and buggy traffic was unregulated (and dangerous). Dan. _______________________________________________ HOKEY mailing list HOKEY@ietf.org https://www1.ietf.org/mailman/listinfo/hokey From hokey-bounces@ietf.org Fri Aug 24 21:20:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOkJo-0008RA-Mc; Fri, 24 Aug 2007 21:20:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOkJn-0008R2-DX; Fri, 24 Aug 2007 21:20:03 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IOkJm-0005Qp-9J; Fri, 24 Aug 2007 21:20:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 3DF3932854; Sat, 25 Aug 2007 01:20:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IOkJm-0006QS-5I; Fri, 24 Aug 2007 21:20:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 24 Aug 2007 21:20:02 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: hokey@ietf.org Subject: [HOKEY] I-D Action:draft-ietf-hokey-erx-04.txt X-BeenThere: hokey@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: HOKEY WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hokey-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 Handover Keying Working Group of the IETF. Title : EAP Extensions for EAP Reauthentication Protocol (ERP) Author(s) : V. Narayanan, L. Dondeti Filename : draft-ietf-hokey-erx-04.txt Pages : 35 Date : 2007-08-24 The extensible authentication protocol (EAP) is a generic framework supporting multiple types of authentication methods. In systems where EAP is used for authentication, it is desirable to not repeat the entire EAP exchange with another authenticator. This document specifies, EAP Reauthentication Extensions (ERX), extensions to EAP and EAP keying hierarchy to support a EAP method-independent protocol for efficient Re-authentication between the peer and the server through an authenticator. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-hokey-erx-04.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-hokey-erx-04.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-hokey-erx-04.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: <2007-08-24211342.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-hokey-erx-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-hokey-erx-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-08-24211342.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ HOKEY mailing list HOKEY@ietf.org https://www1.ietf.org/mailman/listinfo/hokey --NextPart-- From hokey-bounces@ietf.org Fri Aug 24 21:26:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOkPh-0005td-1l; Fri, 24 Aug 2007 21:26:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOkPg-0005tY-Nr for hokey@ietf.org; Fri, 24 Aug 2007 21:26:08 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IOkPf-0005dq-9m for hokey@ietf.org; Fri, 24 Aug 2007 21:26:08 -0400 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 l7P1Q5lN024155 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 24 Aug 2007 18:26:06 -0700 Received: from SANEXCAS03.na.qualcomm.com (sanexcas03.qualcomm.com [172.30.32.65]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l7P1Q5Ep008265 for ; Fri, 24 Aug 2007 18:26:05 -0700 Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by SANEXCAS03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 24 Aug 2007 18:26:05 -0700 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: Fri, 24 Aug 2007 18:26:04 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-hokey-erx-04 - Revision and Fixes to Issues from Tracker Thread-Index: AcfmtudpZXEs56qbQsiGnnXC9V2eBA== From: "Narayanan, Vidya" To: X-OriginalArrivalTime: 25 Aug 2007 01:26:05.0263 (UTC) FILETIME=[E7E995F0:01C7E6B6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Subject: [HOKEY] draft-ietf-hokey-erx-04 - Revision and Fixes to Issues from Tracker X-BeenThere: hokey@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: HOKEY WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hokey-bounces@ietf.org All, The updated draft can be found at http://www.ietf.org/internet-drafts/draft-ietf-hokey-erx-04.txt. The authors believe that this revision captures all the issues that need to be addressed based on the issues tracker (status detailed below) and that the document is ready for WGLC. Assuming the chairs believe that the issues have been resolved satisfactorily, we request them to issue a last call on the document.=20 Thanks, Vidya Here is a status on the issues from the issues tracker:=20 ------------------------ Issue 4: ERX: channel binding support needed =20 Resolved in the earlier version ------------------------ Issue 5: ERX: initial HOKEY message =20 Resolved - added EAP Initiate Re-auth-Start message for authenticator initiation ------------------------ Issue 17: ERX: ERX in the title =20 Resolved - changed title to "EAP Extensions for EAP Re-authentication Protocol (ERP)" to include ERP in the title ------------------------ Issue 16: ERX: terminology issues =20 There was no consensus on changing the terms. Hence, no changes have been done in this revision.=20 ------------------------ Issue 15: ERX: bootstrapping possibly broken =20 No technical issues with ERP bootstrapping were noted. We are not suggesting any changes to the EAP behavior or use of the MSK produced by EAP - hence, any restrictions/changes to the use of the MSK is inappropriate for this document. Hence, no changes are needed here.=20 ------------------------ Issue 19: ERX: location of integrity key =20 The use of rIK for the ERP exchange itself is appropriate, since it uses an integrity key that is produced for the context of re-authentication. If the re-authentication functions were performed by an entity other than the EAP server (EMSK holder), this produces no dependencies on any key outside the re-authentication key hierarchy. Hence, no changes are needed here.=20 ------------------------ Issue 20: ERX: preauth text =20 Resolved ------------------------ Issue 18: ERX: editorial changes =20 Resolved ------------------------ Issue 21: ERX: rMSK derivation id/seq =20 Cryptographically, the necessary separation across rMSKs is provided by the sequence number. The EAP methods do not use any authenticator IDs in the MSK generation as well. So, there is no need to include identities in the rMSK generation either. Channel binding support is provided in ERP and that can be used to assert identities when needed. The lower layer may choose to include the appropriate identities in the TSK generation (as some lower layers already do).=20 ------------------------ Issue 22: ERX: key transport and refs to key mgt doc=20 Open issue; not sure what the reference would be needed for.=20 ------------------------ Issue 23: ERX: root key -- USRK or DSUSRK? =20 Subsequent consensus is not to derive DSUSRKs from USRKs. Hence, this issue is no longer valid.=20 ------------------------ Issue 32: ERX: transport protocol =20 Subsequent to the discussion at IETF69, this no longer seems to be an issue.=20 ------------------------ _______________________________________________ HOKEY mailing list HOKEY@ietf.org https://www1.ietf.org/mailman/listinfo/hokey From hokey-bounces@ietf.org Sat Aug 25 08:51:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOv6Y-0005dc-Tj; Sat, 25 Aug 2007 08:51:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOv6X-0005dV-MP for hokey@ietf.org; Sat, 25 Aug 2007 08:51:05 -0400 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 1IOv6W-0004BJ-Ie for hokey@ietf.org; Sat, 25 Aug 2007 08:51:05 -0400 Received: from steelhead.localdomain (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id l7PCoKju095546; Sat, 25 Aug 2007 08:50:21 -0400 (EDT) (envelope-from yohba@tari.toshiba.com) Received: from ohba by steelhead.localdomain with local (Exim 4.67) (envelope-from ) id 1IOuze-0001rh-9M; Sat, 25 Aug 2007 08:43:58 -0400 Date: Sat, 25 Aug 2007 08:43:56 -0400 To: Charles Clancy Subject: Re: [HOKEY] preauth discussion Message-ID: <20070825124356.GA7003@steelhead.localdomain> References: <46A7B772.9030300@cs.umd.edu> <46CE1F2C.60003@cs.umd.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <46CE1F2C.60003@cs.umd.edu> User-Agent: Mutt/1.5.13 (2006-08-11) From: Yoshihiro Ohba X-Spam-Score: -1.4 (-) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: hokey@ietf.org X-BeenThere: hokey@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: HOKEY WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hokey-bounces@ietf.org Thanks. I have no objection. BTW, the URL of the base draft is old. The latest URL is: http://www.ietf.org/internet-drafts/draft-ohba-preauth-ps-01.txt Also, several people indicated that the following draft on AAA requirements should be merged into preauth-ps draft: http://tools.ietf.org/id/draft-nakhjiri-preauth-aaa-req-00.txt I believe that pre-authentication AAA requirements are as important as problem statement and the merging should happen. Yoshihiro Ohba On Fri, Aug 24, 2007 at 12:58:36AM +0100, Charles Clancy wrote: > There seems to be strong consensus for starting with Yoshi's preauth > document ... > > http://tools.ietf.org/html/draft-ohba-hokeyp-preauth-ps-00 > > ... to satisfy our preauth charter item, and that a design team is not > necessary. > > I propose that the authors of this document rev it to bring it in line > with the current HOKEY terminology, and then submit it as a WG document. > Are there any objections to this proposal? > > -- > t. charles clancy, ph.d. <> tcc@umd.edu <> eng.umd.edu/~tcc > > > Charles Clancy wrote: > >During the WG meeting, there seemed to be support for simply developing > >recommendations for pre-authentication in the HOKEY working group, and > >not an actual protocol. Tim agrees that this could be done without > >modifying our deliverables or milestones, given the current charter > >wording. > > > >Is there any objection to taking this route? > > > >Assuming we pursue this route, are there volunteers to work on a design > >team for developing a -00 document on pre-authentication? > > > >Please respond by August 8th. > > > > > > _______________________________________________ > HOKEY mailing list > HOKEY@ietf.org > https://www1.ietf.org/mailman/listinfo/hokey > _______________________________________________ HOKEY mailing list HOKEY@ietf.org https://www1.ietf.org/mailman/listinfo/hokey From hokey-bounces@ietf.org Sat Aug 25 14:19:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IP0EI-0003Sm-O3; Sat, 25 Aug 2007 14:19:26 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IP0EH-0003Sf-IL for hokey@ietf.org; Sat, 25 Aug 2007 14:19:25 -0400 Received: from dispatch.cs.umd.edu ([128.8.128.60]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IP0EH-0002Z1-5f for hokey@ietf.org; Sat, 25 Aug 2007 14:19:25 -0400 Received: from [127.0.0.1] (c-69-136-165-65.hsd1.in.comcast.net [69.136.165.65]) (authenticated bits=0) by dispatch.cs.umd.edu (8.13.1/8.12.5) with ESMTP id l7PIJ79G006908 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 25 Aug 2007 14:19:09 -0400 Message-ID: <46D0729A.4090103@cs.umd.edu> Date: Sat, 25 Aug 2007 14:19:06 -0400 From: Charles Clancy User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Yoshihiro Ohba Subject: Re: [HOKEY] preauth discussion References: <46A7B772.9030300@cs.umd.edu> <46CE1F2C.60003@cs.umd.edu> <20070825124356.GA7003@steelhead.localdomain> In-Reply-To: <20070825124356.GA7003@steelhead.localdomain> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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=-4.384, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL 0.01, BAYES_00 -2.60) X-CSD-MailScanner-From: clancy@cs.umd.edu X-Spam-Status: No X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: hokey@ietf.org X-BeenThere: hokey@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: HOKEY WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hokey-bounces@ietf.org I suggest adding section 3 of draft-nakhjiri-preauth-aaa-req into draft-ohba-preauth-ps, and adding Madjid as an author. The list of authors on draft-ohba-preauth-ps is getting long, so I suggest moving them to a section in the document, and listing editors at the top. Then we can submit it as a WG document. Sound reasonable? -- t. charles clancy, ph.d. <> tcc@umd.edu <> eng.umd.edu/~tcc adjunct professor, electrical engineering, university of maryland Yoshihiro Ohba wrote: > Thanks. I have no objection. > > BTW, the URL of the base draft is old. The latest URL is: > > http://www.ietf.org/internet-drafts/draft-ohba-preauth-ps-01.txt > > Also, several people indicated that the following draft on AAA > requirements should be merged into preauth-ps draft: > > http://tools.ietf.org/id/draft-nakhjiri-preauth-aaa-req-00.txt > > I believe that pre-authentication AAA requirements are as important as > problem statement and the merging should happen. > > Yoshihiro Ohba > > On Fri, Aug 24, 2007 at 12:58:36AM +0100, Charles Clancy wrote: >> There seems to be strong consensus for starting with Yoshi's preauth >> document ... >> >> http://tools.ietf.org/html/draft-ohba-hokeyp-preauth-ps-00 > >> ... to satisfy our preauth charter item, and that a design team is not >> necessary. >> >> I propose that the authors of this document rev it to bring it in line >> with the current HOKEY terminology, and then submit it as a WG document. >> Are there any objections to this proposal? >> >> -- >> t. charles clancy, ph.d. <> tcc@umd.edu <> eng.umd.edu/~tcc >> >> >> Charles Clancy wrote: >>> During the WG meeting, there seemed to be support for simply developing >>> recommendations for pre-authentication in the HOKEY working group, and >>> not an actual protocol. Tim agrees that this could be done without >>> modifying our deliverables or milestones, given the current charter >>> wording. >>> >>> Is there any objection to taking this route? >>> >>> Assuming we pursue this route, are there volunteers to work on a design >>> team for developing a -00 document on pre-authentication? >>> >>> Please respond by August 8th. >>> >> >> >> _______________________________________________ >> HOKEY mailing list >> HOKEY@ietf.org >> https://www1.ietf.org/mailman/listinfo/hokey >> _______________________________________________ HOKEY mailing list HOKEY@ietf.org https://www1.ietf.org/mailman/listinfo/hokey From hokey-bounces@ietf.org Sun Aug 26 17:55:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPQ53-0000IS-Ce; Sun, 26 Aug 2007 17:55:37 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPQ51-0000I1-UQ for hokey@ietf.org; Sun, 26 Aug 2007 17:55:35 -0400 Received: from mgw.toshibaamericaresearch.com ([165.254.55.12] helo=toshi17.tari.toshiba.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IPQ51-0006uN-Bm for hokey@ietf.org; Sun, 26 Aug 2007 17:55:35 -0400 Received: from steelhead.localdomain (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id l7QLt0kK099091; Sun, 26 Aug 2007 17:55:02 -0400 (EDT) (envelope-from yohba@tari.toshiba.com) Received: from ohba by steelhead.localdomain with local (Exim 4.67) (envelope-from ) id 1IPQ4R-0001zs-Im; Sun, 26 Aug 2007 17:54:59 -0400 Date: Sun, 26 Aug 2007 17:54:59 -0400 To: Charles Clancy Subject: Re: [HOKEY] preauth discussion Message-ID: <20070826215459.GB7389@steelhead.localdomain> References: <46A7B772.9030300@cs.umd.edu> <46CE1F2C.60003@cs.umd.edu> <20070825124356.GA7003@steelhead.localdomain> <46D0729A.4090103@cs.umd.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <46D0729A.4090103@cs.umd.edu> User-Agent: Mutt/1.5.13 (2006-08-11) From: Yoshihiro Ohba X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: hokey@ietf.org X-BeenThere: hokey@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: HOKEY WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hokey-bounces@ietf.org Yes, this sounds reasonable. The authors will work on the required editings and submit a WG document soon. Thanks, Yoshihiro Ohba On Sat, Aug 25, 2007 at 02:19:06PM -0400, Charles Clancy wrote: > I suggest adding section 3 of draft-nakhjiri-preauth-aaa-req into > draft-ohba-preauth-ps, and adding Madjid as an author. The list of > authors on draft-ohba-preauth-ps is getting long, so I suggest moving > them to a section in the document, and listing editors at the top. Then > we can submit it as a WG document. > > Sound reasonable? > > -- > t. charles clancy, ph.d. <> tcc@umd.edu <> eng.umd.edu/~tcc > adjunct professor, electrical engineering, university of maryland > > > Yoshihiro Ohba wrote: > >Thanks. I have no objection. > > > >BTW, the URL of the base draft is old. The latest URL is: > > > >http://www.ietf.org/internet-drafts/draft-ohba-preauth-ps-01.txt > > > >Also, several people indicated that the following draft on AAA > >requirements should be merged into preauth-ps draft: > > > >http://tools.ietf.org/id/draft-nakhjiri-preauth-aaa-req-00.txt > > > >I believe that pre-authentication AAA requirements are as important as > >problem statement and the merging should happen. > > > >Yoshihiro Ohba > > > >On Fri, Aug 24, 2007 at 12:58:36AM +0100, Charles Clancy wrote: > >>There seems to be strong consensus for starting with Yoshi's preauth > >>document ... > >> > >> http://tools.ietf.org/html/draft-ohba-hokeyp-preauth-ps-00 > > > >>... to satisfy our preauth charter item, and that a design team is not > >>necessary. > >> > >>I propose that the authors of this document rev it to bring it in line > >>with the current HOKEY terminology, and then submit it as a WG document. > >> Are there any objections to this proposal? > >> > >>-- > >>t. charles clancy, ph.d. <> tcc@umd.edu <> eng.umd.edu/~tcc > >> > >> > >>Charles Clancy wrote: > >>>During the WG meeting, there seemed to be support for simply developing > >>>recommendations for pre-authentication in the HOKEY working group, and > >>>not an actual protocol. Tim agrees that this could be done without > >>>modifying our deliverables or milestones, given the current charter > >>>wording. > >>> > >>>Is there any objection to taking this route? > >>> > >>>Assuming we pursue this route, are there volunteers to work on a design > >>>team for developing a -00 document on pre-authentication? > >>> > >>>Please respond by August 8th. > >>> > >> > >> > >>_______________________________________________ > >>HOKEY mailing list > >>HOKEY@ietf.org > >>https://www1.ietf.org/mailman/listinfo/hokey > >> > > _______________________________________________ HOKEY mailing list HOKEY@ietf.org https://www1.ietf.org/mailman/listinfo/hokey From hokey-bounces@ietf.org Mon Aug 27 04:29:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPZxz-0006qm-Vv; Mon, 27 Aug 2007 04:28:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPZxy-0006qg-Hf for hokey@ietf.org; Mon, 27 Aug 2007 04:28:58 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IPZxx-00038c-3x for hokey@ietf.org; Mon, 27 Aug 2007 04:28:58 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l7R8SIBg005412; Mon, 27 Aug 2007 11:28:52 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Aug 2007 11:28:30 +0300 Received: from esebe104.NOE.Nokia.com ([172.21.143.44]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Aug 2007 11:28:30 +0300 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: [HOKEY] revisions to reauth problem statement Date: Mon, 27 Aug 2007 11:28:29 +0300 Message-ID: <83CD3A5F85DE7D43B6A5CC37CCBAEECE042A5FD5@esebe104.NOE.Nokia.com> In-Reply-To: <46CE279E.1050707@cs.umd.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [HOKEY] revisions to reauth problem statement Thread-Index: AcfmEH2g79LuYWfDQHqp4PquUcG0PgCcEa4g References: <83CD3A5F85DE7D43B6A5CC37CCBAEECE04127139@esebe104.NOE.Nokia.com> <46CE279E.1050707@cs.umd.edu> From: To: X-OriginalArrivalTime: 27 Aug 2007 08:28:30.0635 (UTC) FILETIME=[3FC1EFB0:01C7E884] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: hokey@ietf.org X-BeenThere: hokey@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: HOKEY WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hokey-bounces@ietf.org Hi: Sorry, unable to respond earlier, as I was away. Thanks for following response- Pl. find my response inline. Preeti=20 >-----Original Message----- >From: ext Charles Clancy [mailto:clancy@cs.umd.edu]=20 >Sent: 24 August, 2007 03:35 >To: Vinayakray-Jani Preetida (Nokia-NRC/Helsinki) >Cc: hokey@ietf.org >Subject: Re: [HOKEY] revisions to reauth problem statement > >Preeti, > >Thanks for your comments. I don't think we want to get into=20 >reactive vs proactive and preauth here, because this is=20 >specifically the reauth problem statement. >With regard to the security goals section, I think your=20 >suggestions may be a little too specific. The KDF and key=20 >material formatting are specified in the "solutions" drafts,=20 >not here, and existing security goals would require them to be=20 >done properly. > >I'm not sure what you mean by handover key recovery. We don't=20 >talk about key distribution at all in this document. Can you=20 >be more specific? (preeti) I have to admit that I've not finished reading draft-ietf-hokey-key-mgm-00 draft. In my view if such draft targets one of the objectives of HOKEY, then problem statement draft can provide some text relevant to key management as problem statement title - Handover Key management and Re-authetication Problem statement - very much suggests that. I am not asking here to be very specific. And when there is a key management relevant to handover then I presume there will be relevant policies also. And policies for key management deal with defining key usage, key lifetime, and key recovery procedures and most of the time depend on the security requirements for the scenario they are being deployed. I am asking here to place any specific details about key distribution or etc. However if you consider that such overview will bring some relevance to problem statement then some overview in problem statement will be enough.=20 =20 > >-- >t. charles clancy, ph.d. <> tcc@umd.edu <> =20 >eng.umd.edu/~tcc adjunct professor, electrical engineering,=20 >university of maryland > > > >Preetida.Vinayakray-Jani@nokia.com wrote: >> Hi, >>=20 >> Hope I'm not responding after deadline for subjected text.=20 >If not then=20 >> here there are few points/suggestions, perhaps you would like to add >>=20 >> Referring to section 5 - Design goals - >>=20 >> This section very well explains various goals. However in subsection=20 >> 'lower latency operation' - it can be emphasized in following way - >>=20 >> Re-authentication process can be reactive or proactive(e.g.=20 >pre-auth)=20 >> and design goals for these two different approaches should=20 >consider low=20 >> latency performance objective. =20 >>=20 >> Referring to section 6 - Security goals - >>=20 >> 1. key derivation function and keying material format >> 2. Acceptable policies for handover key recovery? >>=20 >> If such points are within the scope of Design goals + security goals=20 >> then relevant text can be placed. >>=20 >> Regds >> Preeti >>=20 >>=20 >>=20 >>=20 >> >I've put together some revisions to the reauth problem=20 >statement draft: >>=20 >> =20 >>_http://www.ltsnet.net/ietf/hokey/draft-ietf-hokey-reauth-ps-02a.txt_ >>=20 >> >=20 >> >Any comments? Anything else that should be added? Once=20 >submissions for=20 >> IDs reopens, I plan to submit >the updated document, and=20 >then go to WGLC. >>=20 > > _______________________________________________ HOKEY mailing list HOKEY@ietf.org https://www1.ietf.org/mailman/listinfo/hokey From hokey-bounces@ietf.org Mon Aug 27 12:19:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPhJU-0004gY-7H; Mon, 27 Aug 2007 12:19:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPhJS-0004bn-LT for hokey@ietf.org; Mon, 27 Aug 2007 12:19:38 -0400 Received: from usaga01-in.huawei.com ([206.16.17.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IPhJQ-0005Sx-Vm for hokey@ietf.org; Mon, 27 Aug 2007 12:19:38 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JNF0060YXCL4Z@usaga01-in.huawei.com> for hokey@ietf.org; Mon, 27 Aug 2007 09:19:34 -0700 (PDT) Received: from N737011 ([10.192.25.70]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JNF00IB8XCDMY@usaga01-in.huawei.com> for hokey@ietf.org; Mon, 27 Aug 2007 09:19:33 -0700 (PDT) Date: Mon, 27 Aug 2007 09:19:24 -0700 From: Madjid Nakhjiri Subject: RE: [HOKEY] WGLC: re-auth problem statement In-reply-to: <46CE1CDB.9080207@cs.umd.edu> To: 'Charles Clancy' Message-id: <000c01c7e8c6$09a20450$4619c00a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcfmCiBXNuL4MOttQ3+A71DkgKchmACuz5vA X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: hokey@ietf.org X-BeenThere: hokey@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: HOKEY WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hokey-bounces@ietf.org Well, this is yet another surprise. The charter deliverable 1, specifically says: "A Problem Statement that defines the problem of re-authentication and key management." And specifically has text related to handover. As far as I remember, this draft was produced as a merger of two documents, > draft-vidya-eap-reauth-ps-00 > draft-nakhjiri-aaa-hokey-ps-03 one of which clearly was a problem statement for handover keying, and in fact this doc was called HOKEY-ps first, so I really don't know what to say. As for the text you are looking for, I am sure aaa-hokey-ps offers plenty.. If you still cannot find it, please let me know. R, Madjid -----Original Message----- From: Charles Clancy [mailto:clancy@cs.umd.edu] Sent: Thursday, August 23, 2007 4:49 PM To: Madjid Nakhjiri Cc: hokey@ietf.org Subject: Re: [HOKEY] WGLC: re-auth problem statement Captured as issue 35. When we wrote the document, it was specifically the "re-auth" problem statement (hence the title), and did not discuss key distribution (or at the time, "roaming"). In fact, all references to it in the early drafts were specifically removed. And indeed, our charter deliverables do not include a problem statement for anything other than re-auth. I don't have any objection to adding a paragraph to section 4 that talks about it. Does anyone else feel strongly about this? Madjid, could you propose some text? -- t. charles clancy, ph.d. <> tcc@umd.edu <> eng.umd.edu/~tcc Madjid Nakhjiri wrote: > Hi Charles, > > Thanks for updating the doc. It would probably be good if we include some > text on delivery of new keys to authenticators (as part of handover) in the > problem statement section. Currently we do talk about re-auth but not > handover keying. > > Madjid > -----Original Message----- > From: Charles Clancy [mailto:clancy@cs.umd.edu] > Sent: Thursday, August 02, 2007 1:01 PM > To: hokey@ietf.org > Subject: [HOKEY] WGLC: re-auth problem statement > > The updated re-auth problem statement has been posted: > > http://tools.ietf.org/html/draft-ietf-hokey-reauth-ps-02 > > We're issing working group last call on this document. Please send your > comments to the list by August 17. > > -- > t. charles clancy, ph.d. <> tcc@umd.edu <> eng.umd.edu/~tcc > adjunct professor, electrical engineering, university of maryland > > > > > > _______________________________________________ > HOKEY mailing list > HOKEY@ietf.org > https://www1.ietf.org/mailman/listinfo/hokey > _______________________________________________ HOKEY mailing list HOKEY@ietf.org https://www1.ietf.org/mailman/listinfo/hokey From hokey-bounces@ietf.org Mon Aug 27 14:49:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPjeQ-0006F0-N6; Mon, 27 Aug 2007 14:49:26 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPjeO-0006Dm-ND for hokey@ietf.org; Mon, 27 Aug 2007 14:49:24 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IPjeO-0005nY-8D for hokey@ietf.org; Mon, 27 Aug 2007 14:49:24 -0400 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l7RInMMP008855 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 27 Aug 2007 11:49:23 -0700 Received: from SANEXCAS03.na.qualcomm.com (sanexcas03.qualcomm.com [172.30.32.65]) by hamtaro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l7RInHNK005444 for ; Mon, 27 Aug 2007 11:49:22 -0700 (PDT) Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by SANEXCAS03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 27 Aug 2007 11:49:19 -0700 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, 27 Aug 2007 11:49:17 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: rIK length in draft-ietf-hokey-erx-04 Thread-Index: Acfo2vi5k4D2g24vQCWTPkVSvFH8PQ== From: "Narayanan, Vidya" To: X-OriginalArrivalTime: 27 Aug 2007 18:49:19.0591 (UTC) FILETIME=[F9DD8F70:01C7E8DA] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Subject: [HOKEY] rIK length in draft-ietf-hokey-erx-04 X-BeenThere: hokey@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: HOKEY WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hokey-bounces@ietf.org All, Subsequent to the last revision of the draft, with input from CFRG, we had decided to stick with hashing to reduce the rIK length if needed. The current section 4.1.5 in the draft still has the old text - we focused on the issues on the issues tracker and this one got left out. =20 If the WG prefers, we can submit a revision to address that right away, but, if it is acceptable, we can capture this on the tracker and address it either as part of WGLC comments or the next revision, whichever happens first. =20 Thanks, Vidya _______________________________________________ HOKEY mailing list HOKEY@ietf.org https://www1.ietf.org/mailman/listinfo/hokey From hokey-bounces@ietf.org Mon Aug 27 17:08:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPlok-0000Hu-4k; Mon, 27 Aug 2007 17:08:14 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPloj-0000Hp-Hz for hokey@ietf.org; Mon, 27 Aug 2007 17:08:13 -0400 Received: from alnrmhc15.comcast.net ([204.127.225.95]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IPloj-0001oI-5h for hokey@ietf.org; Mon, 27 Aug 2007 17:08:13 -0400 Received: from gwzpc (unknown[67.170.84.64]) by comcast.net (alnrmhc15) with SMTP id <20070827210811b1500a1niqe>; Mon, 27 Aug 2007 21:08:11 +0000 From: "Glen Zorn" To: References: <002201c7e126$51772c80$4619c00a@china.huawei.com> <38065.65.105.205.133.1187733987.squirrel@www.trepanning.net> <46953.65.105.205.133.1187981817.squirrel@www.trepanning.net> In-Reply-To: Subject: RE: [HOKEY] consensus call: key delivery security protocol Date: Mon, 27 Aug 2007 14:07:58 -0700 Message-ID: <003201c7e8ee$58e43600$0aaca200$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acfo6OeoovEedNUERrOY2b9wm+BseAAAagiw Content-Language: en-us X-Spam-Score: 0.0 (/) X-Scan-Signature: f1405b5eaa25d745f8c52e3273d3af78 Cc: tim.polk@nist.gov, hartmans-ietf@mit.edu, hokey@ietf.org, mnakhjiri@huawei.com X-BeenThere: hokey@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: HOKEY WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1046485000==" Errors-To: hokey-bounces@ietf.org This is a multipart message in MIME format. --===============1046485000== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0033_01C7E8B3.AC855E00" Content-Language: en-us This is a multipart message in MIME format. ------=_NextPart_000_0033_01C7E8B3.AC855E00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit > Glen, > > On Tue, August 21, 2007 3:25 pm, Glen Zorn wrote: > >> Sam,> > Where do you read that it is permitted for the MSK? It seems to > >> me> that RFC4962 deals with the security around distribution and > >> generation> of session keys and not with distribution of network access > >> credentials> (like the MSK). > > > > Let's just say that (despite the name) the MSK is not a "Master Session > > Key" & is in fact a network access credential (where do you get that from, > > BTW?). Since AFAIK the MSK is the only key commonly transferred via AAA, > > doesn't that make RFC 4962 kind of, well, irrelevant? > > I get "network access credential" from its use. If a client can > prove possession of that blob-of-bits then it gets network access. I > don't think we should get hung up on the semantics of it. Perhaps we can > call it the Mega Super Key. [gwz] Hmm, silly me: I thought that what gained network access in 802.11i was successful 802.1X authentication. Now it turns out that no such thing is actually required. Wow. > > I don't think RFC4962 is necessarily irrelevent. It talks about AAA > key management and, according to it > > AAA key management often includes a collection of protocols, one of > which is the AAA protocol. Other protocols are used in conjunction > with the AAA protocol to provide an overall solution. These other > protocols often provide authentication and security association > establishment. > > So my read is that it is giving guidance to the "other protocols" that > provide authentication and security association establishment. For > instance 802.11's 4 way handshake. It provides "authentication" by proving > possession of the Mega Super Key. [gwz] No. The user authentication is done with EAP. The 4-way handshake just proves to .11i that the .1X authentication was successful. IIRC, the only reason the 4-way handshake is necessary is that .1X & .11i don't talk: .1X doesn't provide any indication that authentication has succeeded to other layers, it just opens the controlled port to traffic. Since the purpose of .11i is to protect data in the air w/encryption & integrity protection, it wouldn't do for traffic to start flowing unencrypted so .11i implements its own version of the "controlled port"; a successful 4-way handshake & the subsequend derivation of TSKs opens that gate. You make it sound as if one can simply take the MSK off & use it to obtain network access by itself but that is not possible. . > > Good question. As I've said before, I consider the biggest flaw in the > > document is its insistence on ignoring the way that AAA systems in the > > real world actually function. > > Actually what I think the problem you have with it is that it does not > make accomodations for the way AAA systems in the "real world" actually > function. But insecure practices should be stopped. [gwz] Non-secure practices are only stopped because there is value perceived in doing so, not because of IETF fiat. I'm sure when traffic > signs were first introduced people said, "they ignore the way carts and > buggies actually work in the real world" because previously carts and > buggy traffic was unregulated (and dangerous). [gwz] Not like those ultra-safe automobiles! ------=_NextPart_000_0033_01C7E8B3.AC855E00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

> Glen,
>
> On Tue, August 21, 2007 3:25 pm, Glen Zorn wrote:
> >> Sam,> > Where do you read that it is permitted for = the MSK? It seems to
> >> me> that RFC4962 deals with the security around = distribution and
> >> generation> of session keys and not with distribution = of network access
> >> credentials> (like the MSK).
> >
> > Let's just say that (despite the name) the MSK is not a = "Master Session
> > Key" & is in fact a network access credential (where = do you get that from,
> > BTW?). Since AFAIK the MSK is the only key commonly = transferred via AAA,
> > doesn't that make RFC 4962 kind of, well, irrelevant?
>
> I get "network access credential" from its use. If a = client can
> prove possession of that blob-of-bits then it gets network access. = I
> don't think we should get hung up on the semantics of it. Perhaps = we can
> call it the Mega Super Key.

[gwz] Hmm, = silly me: I thought that what gained network access in 802.11i was successful 802.1X authentication.  Now it turns out that no such thing is actually required.  Wow.


>
> I don't think RFC4962 is necessarily irrelevent. It talks about = AAA
> key management and, according to it
>
> AAA key management often includes a collection of protocols, one = of
> which is the AAA protocol. Other protocols are used in = conjunction
> with the AAA protocol to provide an overall solution. These = other
> protocols often provide authentication and security association
> establishment.
>
> So my read is that it is giving guidance to the "other protocols" that
> provide authentication and security association establishment. = For
> instance 802.11's 4 way handshake. It provides = "authentication" by proving
> possession of the Mega Super Key.

[gwz] No.  = The user authentication is done with EAP.  The 4-way handshake just = proves to .11i that the .1X authentication was successful.  IIRC, the only reason = the 4-way handshake is necessary is that .1X & .11i don't talk: .1X = doesn't provide any indication that authentication has succeeded to other = layers, it just opens the controlled port to traffic.  Since the purpose of = .11i is to protect data in the air w/encryption & integrity protection, it = wouldn't do for traffic to start flowing unencrypted so .11i implements its own = version of the "controlled port"; a successful 4-way handshake & = the subsequend derivation of TSKs opens that gate.  You make it sound as if one = can simply take the MSK off & use it to obtain network access by itself = but that is not possible.

…

> > Good question. As I've said before, I consider the biggest flaw in the
> > document is its insistence on ignoring the way that AAA = systems in the
> > real world actually function.
>
> Actually what I think the problem you have with it is that it does = not
> make accomodations for the way AAA systems in the "real = world" actually
> function. But insecure practices should be stopped.

[gwz] = Non-secure practices are only stopped because there is value perceived in doing so, = not because of IETF fiat. 

I'm sure when traffic
> signs were first introduced people said, "they ignore the way = carts and
> buggies actually work in the real world" because previously = carts and
> buggy traffic was unregulated (and dangerous).

[gwz] Not like = those ultra-safe automobiles!

------=_NextPart_000_0033_01C7E8B3.AC855E00-- --===============1046485000== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ HOKEY mailing list HOKEY@ietf.org https://www1.ietf.org/mailman/listinfo/hokey --===============1046485000==-- From hokey-bounces@ietf.org Tue Aug 28 14:00:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQ5Mv-00070H-JQ; Tue, 28 Aug 2007 14:00:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQ5Mt-00070C-K2 for hokey@ietf.org; Tue, 28 Aug 2007 14:00:47 -0400 Received: from colo.trepanning.net ([69.55.226.174] helo=mail1.trepanning.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQ5Ms-000294-4a for hokey@ietf.org; Tue, 28 Aug 2007 14:00:47 -0400 Received: from www.trepanning.net (localhost [127.0.0.1]) by mail1.trepanning.net (Postfix) with ESMTP id 46C151FA602D; Tue, 28 Aug 2007 11:00:45 -0700 (PDT) Received: from 65.105.205.133 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Tue, 28 Aug 2007 11:00:45 -0700 (PDT) Message-ID: <60043.65.105.205.133.1188324045.squirrel@www.trepanning.net> In-Reply-To: <003201c7e8ee$58e43600$0aaca200$@net> References: <002201c7e126$51772c80$4619c00a@china.huawei.com> <38065.65.105.205.133.1187733987.squirrel@www.trepanning.net> <46953.65.105.205.133.1187981817.squirrel@www.trepanning.net> <003201c7e8ee$58e43600$0aaca200$@net> Date: Tue, 28 Aug 2007 11:00:45 -0700 (PDT) Subject: RE: [HOKEY] consensus call: key delivery security protocol From: "Dan Harkins" To: "Glen Zorn" User-Agent: SquirrelMail/1.4.8 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 (Normal) Importance: Normal Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: tim.polk@nist.gov, hartmans-ietf@mit.edu, hokey@ietf.org, mnakhjiri@huawei.com X-BeenThere: hokey@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: HOKEY WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hokey-bounces@ietf.org Glen, On Mon, August 27, 2007 2:07 pm, Glen Zorn wrote: >> Glen, >> >> On Tue, August 21, 2007 3:25 pm, Glen Zorn wrote: >> >> Sam,> > Where do you read that it is permitted for the MSK? It seem= s >> to >> >> me> that RFC4962 deals with the security around distribution and >> >> generation> of session keys and not with distribution of network >> access >> >> credentials> (like the MSK). >> > >> > Let's just say that (despite the name) the MSK is not a "Master >> Session >> > Key" & is in fact a network access credential (where do you get that > from, >> > BTW?). Since AFAIK the MSK is the only key commonly transferred via >> AAA, >> > doesn't that make RFC 4962 kind of, well, irrelevant? >> >> I get "network access credential" from its use. If a client can >> prove possession of that blob-of-bits then it gets network access. I >> don't think we should get hung up on the semantics of it. Perhaps we c= an >> call it the Mega Super Key. > > [gwz] Hmm, silly me: I thought that what gained network access in 802.1= 1i > was successful 802.1X authentication. Now it turns out that no such th= ing > is actually required. Wow. Check out how PMK caching works in 802.11. As the client does a handoff all he has to do is prove possession of a PMK/MSK and he gets network access. If he fails to prove possession of a PMK/MSK he gets the boot. >> >> I don't think RFC4962 is necessarily irrelevent. It talks about AAA >> key management and, according to it >> >> AAA key management often includes a collection of protocols, one of >> which is the AAA protocol. Other protocols are used in conjunction >> with the AAA protocol to provide an overall solution. These other >> protocols often provide authentication and security association >> establishment. >> >> So my read is that it is giving guidance to the "other protocols" that >> provide authentication and security association establishment. For >> instance 802.11's 4 way handshake. It provides "authentication" by >> proving >> possession of the Mega Super Key. > > [gwz] No. The user authentication is done with EAP. The 4-way handsha= ke > just proves to .11i that the .1X authentication was successful. IIRC, = the > only reason the 4-way handshake is necessary is that .1X & .11i don't > talk: > .1X doesn't provide any indication that authentication has succeeded to > other layers, it just opens the controlled port to traffic. Since the > purpose of .11i is to protect data in the air w/encryption & integrity > protection, it wouldn't do for traffic to start flowing unencrypted so > .11i > implements its own version of the "controlled port"; a successful 4-way > handshake & the subsequend derivation of TSKs opens that gate. You mak= e > it > sound as if one can simply take the MSK off & use it to obtain network > access by itself but that is not possible. Then why is there a proof-of-possession of the PMK/MSK in the 4way handshake? If all it had to do was create TSKs it could be the 2way handshake-- authenticator sends nonce, supplicant sends nonce, they both hash up some TSKs and away they go. It's there for a reason and that reason is for a form of "authentication". Look how PMK caching works. The client claims it has a PMK/MSK. If it can prove possession of that _network access credential_ via another 4way handshake it gets network access without having to do another full-blown 802.1x/EAP exchange. Dan. _______________________________________________ HOKEY mailing list HOKEY@ietf.org https://www1.ietf.org/mailman/listinfo/hokey From hokey-bounces@ietf.org Wed Aug 29 00:49:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQFUP-0003Pw-6E; Wed, 29 Aug 2007 00:49:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQFUN-0003Ow-As for hokey@ietf.org; Wed, 29 Aug 2007 00:49:11 -0400 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 1IQFUM-00040J-6m for hokey@ietf.org; Wed, 29 Aug 2007 00:49:11 -0400 Received: from steelhead.localdomain (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id l7T4moKG011227; Wed, 29 Aug 2007 00:48:50 -0400 (EDT) (envelope-from yohba@tari.toshiba.com) Received: from ohba by steelhead.localdomain with local (Exim 4.67) (envelope-from ) id 1IQFU1-0003fN-M3; Wed, 29 Aug 2007 00:48:49 -0400 Date: Wed, 29 Aug 2007 00:48:49 -0400 To: hokey@ietf.org Message-ID: <20070829044849.GE12764@steelhead.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline User-Agent: Mutt/1.5.13 (2006-08-11) From: Yoshihiro Ohba X-Spam-Score: -1.4 (-) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db Subject: [HOKEY] Kerberized handover keying paper X-BeenThere: hokey@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: HOKEY WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hokey-bounces@ietf.org FYI. The paper I mentioned before is now publicly available: http://user.informatik.uni-goettingen.de/~mobiarch/2007/Ohba_MIHKey.pdf Yoshihiro Ohba _______________________________________________ HOKEY mailing list HOKEY@ietf.org https://www1.ietf.org/mailman/listinfo/hokey