From hokey-bounces@ietf.org Mon Apr 02 15:26:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYSAn-00025j-Ec; Mon, 02 Apr 2007 15:26:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYSAm-00025e-80 for hokey@ietf.org; Mon, 02 Apr 2007 15:26:36 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYSAk-0004uj-Pf for hokey@ietf.org; Mon, 02 Apr 2007 15:26:36 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l32JQPBj026394 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 2 Apr 2007 12:26:25 -0700 Received: from [129.46.78.141] (ldondeti.na.qualcomm.com [129.46.78.141]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l32JQP7i016617 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 2 Apr 2007 12:26:25 -0700 Message-ID: <461158E1.3000002@qualcomm.com> Date: Mon, 02 Apr 2007 12:26:25 -0700 From: Lakshminath Dondeti User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: Charles Clancy Subject: Re: [HOKEY] consensus call: key distribution security requirement References: <460EB36E.5010604@cs.umd.edu> In-Reply-To: <460EB36E.5010604@cs.umd.edu> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 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 Sam sent an email to the IETF discussion list on identities and identity assertion in a similar (same?) context as we are discussing. I am not sure whether I fully understand what he is saying and so I cannot say that I agree with him fully, but in a conversation with him in Prague, I agreed with him at a conceptual level (I may yet ask him for clarification on his email to the IETF Discussion list). Anyway, the point of this email is that there is a notion of identities at different layers and furthermore there is also a notion of whether identity assertion is required or possible in all deployments. So, I suggest that we should use the word "recommended" instead of "required" in this latest addition to the PS. thanks, Lakshminath Charles Clancy wrote: > HOKEY WG, > > The 3-party protocol proposal at IETF 68 listed a variety of protocol > requirements, some of which went beyond those currently specified in the > problem statements draft. The main extension was a requirement for > stronger key distribution security. > > Discussion: The problem statements document currently requires channel > bindings to allow clients to authenticate the network to which they are > connecting, and prevent the lying NAS problem. However one possible > implementation of channel bindings would allow keys to be distributed > prior to the network being authenticated by the peer. While the peer > may decide to not use a network after it's validated its identity, > network entities could retain the keying material. There has been much > debate on the list as to whether or not network entities could > maliciously use this keying material, and the intent here is to not > rehash all that discussion. > > Question: Should additional text be added to the problem statement draft > to require peer authorization for distributing keying material? > > Protocol Implications: If "yes" then a 3-party protocol would be need, > and would require L2 advertisement of the NAS-ID and local AAA domain > name. If "no" then channel bindings where identities are hashed into > the key derivation would be sufficient. > _______________________________________________ HOKEY mailing list HOKEY@ietf.org https://www1.ietf.org/mailman/listinfo/hokey From hokey-bounces@ietf.org Mon Apr 02 19:16:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYVl8-00059o-Cc; Mon, 02 Apr 2007 19:16:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYVl7-00058V-7r for hokey@ietf.org; Mon, 02 Apr 2007 19:16:21 -0400 Received: from usaga01-in.huawei.com ([206.16.17.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYVl2-0003n8-8j for hokey@ietf.org; Mon, 02 Apr 2007 19:16:21 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JFW000J88N33Z@usaga01-in.huawei.com> for hokey@ietf.org; Mon, 02 Apr 2007 16:16:15 -0700 (PDT) Received: from N737011 (pool-71-112-126-182.sttlwa.dsl-w.verizon.net [71.112.126.182]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JFW00HW38MYWP@usaga01-in.huawei.com> for hokey@ietf.org; Mon, 02 Apr 2007 16:16:15 -0700 (PDT) Date: Mon, 02 Apr 2007 16:16:12 -0700 From: Madjid Nakhjiri Subject: RE: [HOKEY] consensus call: EAP-ER as HOKEY protocol In-reply-to: <460EAF24.7070506@cs.umd.edu> To: 'Charles Clancy' , hokey@ietf.org Message-id: <002701c7757c$ea5d0e30$2f01a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcdzxrdXH0MDR7HiRu+gWh81a7SnMwBs78og X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 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, I like to seek a clarification here first. Have we put the discussion of use of EAP code versus EAP types to bed, completely satisfied that EAP types will absolutely not solve the problems? Given that the Russ only first gave the few of us present in San Jose the green light to change EAP, I feel that we did not quite discuss the impact of adding new EAP codes versus other changes to an end. A simple analysis shows (I have confirmed this with several EAP experts) that using a new EAP type and adding some payload to EAP success you can easily achieve near 1 roundtrip exchanges. I can forward that analysis in a separate email. It is not clear whether adding data to EAP success is more severe than the changes that EAP-ER is suggesting, to name a few: 1) adding new codes even though 3748 mandates a discard code>4 2) change of authenticator state machine to treat EAP ER Request as a response to EAP Identity request. This seems a lot more intrusive on the massive scale of existing authenticators, than adding data to EAP success intended for the peer. It seems that before fully deciding the EAP code versus EAP type options, it is hard to make a judgement on a solution that is based on EAP code. After that, there are issues such as identity exchanges that are needed for key derivation according to the EMSK draft and it seems that EAP-ER is considering those out of band or requires explicit additional signaling. Finally the other clarification I am seeking is regarding the second document, don't we want to specify how the per-authenticator keys are derived? It seems that it should be included in the second spec as well. R, Madjid -----Original Message----- From: Charles Clancy [mailto:clancy@cs.umd.edu] Sent: Saturday, March 31, 2007 11:58 AM To: hokey@ietf.org Subject: [HOKEY] consensus call: EAP-ER as HOKEY protocol HOKEY WG, The chairs are making a second consensus call request to adopt EAP-ER as a WG document to satisfy our re-auth and hand-off deliverables. It would serve as a starting point for development of the HOKEY protocol. Note that if accepted, it may be split into two WG documents, separating the EAP-ER-Bootstrap into a second set of messages that could be transported by any service to obtain a USRK or DSUSRK. Please respond by Friday, April 13. -- t. charles clancy, ph.d. <> tcc@umd.edu <> www.cs.umd.edu/~clancy _______________________________________________ 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 Apr 02 22:14:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYYX7-0002Ng-U2; Mon, 02 Apr 2007 22:14:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYYX6-0002NJ-GV for hokey@ietf.org; Mon, 02 Apr 2007 22:14:04 -0400 Received: from sccrmhc15.comcast.net ([204.127.200.85]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYYX5-0003us-83 for hokey@ietf.org; Mon, 02 Apr 2007 22:14:04 -0400 Received: from [127.0.0.1] (c-68-49-199-146.hsd1.md.comcast.net[68.49.199.146]) by comcast.net (sccrmhc15) with ESMTP id <20070403021402015008njece>; Tue, 3 Apr 2007 02:14:02 +0000 Message-ID: <4611B86F.6080500@cs.umd.edu> Date: Mon, 02 Apr 2007 22:14:07 -0400 From: Charles Clancy User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Madjid Nakhjiri Subject: Re: [HOKEY] consensus call: EAP-ER as HOKEY protocol References: <002701c7757c$ea5d0e30$2f01a8c0@china.huawei.com> In-Reply-To: <002701c7757c$ea5d0e30$2f01a8c0@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 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 Madjid, At the interim, we only discussed method vs code-based transport. We did not discuss altering existing EAP messages. If you have a comparative analysis of the options you think would be beneficial to the group, then please share it. Regardless, I don't see this as a reason to not adopt EAP-ER. We can change what packet codes it uses if there is WG consensus to do so. -- t. charles clancy, ph.d. <> tcc@umd.edu <> www.cs.umd.edu/~clancy Madjid Nakhjiri wrote: > Hi, > > I like to seek a clarification here first. > Have we put the discussion of use of EAP code versus EAP types to bed, > completely satisfied that EAP types will absolutely not solve the problems? > > Given that the Russ only first gave the few of us present in San Jose the > green light to change EAP, I feel that we did not quite discuss the impact > of adding new EAP codes versus other changes to an end. A simple analysis > shows (I have confirmed this with several EAP experts) that using a new EAP > type and adding some payload to EAP success you can easily achieve near 1 > roundtrip exchanges. I can forward that analysis in a separate email. > > It is not clear whether adding data to EAP success is more severe than the > changes that EAP-ER is suggesting, to name a few: > > 1) adding new codes even though 3748 mandates a discard code>4 > 2) change of authenticator state machine to treat EAP ER Request as a > response to EAP Identity request. This seems a lot more intrusive on the > massive scale of existing authenticators, than adding data to EAP success > intended for the peer. > > It seems that before fully deciding the EAP code versus EAP type options, it > is hard to make a judgement on a solution that is based on EAP code. After > that, there are issues such as identity exchanges that are needed for key > derivation according to the EMSK draft and it seems that EAP-ER is > considering those out of band or requires explicit additional signaling. > > Finally the other clarification I am seeking is regarding the second > document, don't we want to specify how the per-authenticator keys are > derived? It seems that it should be included in the second spec as well. > > R, > > Madjid > > -----Original Message----- > From: Charles Clancy [mailto:clancy@cs.umd.edu] > Sent: Saturday, March 31, 2007 11:58 AM > To: hokey@ietf.org > Subject: [HOKEY] consensus call: EAP-ER as HOKEY protocol > > HOKEY WG, > > The chairs are making a second consensus call request to adopt EAP-ER as > a WG document to satisfy our re-auth and hand-off deliverables. It > would serve as a starting point for development of the HOKEY protocol. > > Note that if accepted, it may be split into two WG documents, separating > the EAP-ER-Bootstrap into a second set of messages that could be > transported by any service to obtain a USRK or DSUSRK. > > Please respond by Friday, April 13. > _______________________________________________ HOKEY mailing list HOKEY@ietf.org https://www1.ietf.org/mailman/listinfo/hokey From hokey-bounces@ietf.org Mon Apr 02 22:17: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 1HYYaL-0004K5-J7; Mon, 02 Apr 2007 22:17:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYYaK-0004Jv-NS for hokey@ietf.org; Mon, 02 Apr 2007 22:17:24 -0400 Received: from sccrmhc14.comcast.net ([63.240.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYYaJ-0004HK-Ex for hokey@ietf.org; Mon, 02 Apr 2007 22:17:24 -0400 Received: from [127.0.0.1] (c-68-49-199-146.hsd1.md.comcast.net[68.49.199.146]) by comcast.net (sccrmhc14) with ESMTP id <200704030217220140023481e>; Tue, 3 Apr 2007 02:17:22 +0000 Message-ID: <4611B937.4080204@cs.umd.edu> Date: Mon, 02 Apr 2007 22:17:27 -0400 From: Charles Clancy User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Madjid Nakhjiri Subject: Re: [HOKEY] consensus call: EAP-ER as HOKEY protocol References: <002701c7757c$ea5d0e30$2f01a8c0@china.huawei.com> In-Reply-To: <002701c7757c$ea5d0e30$2f01a8c0@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 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 Madjid, In response to your second question about the additional document -- the whole point is to separate out the part of HOKEY that would could be reused by another application to obtain a USRK. The per-authenticator keying has nothing to do with other services or their ability to obtain a USRK, so I don't think it should be included in the second document. -- t. charles clancy, ph.d. <> tcc@umd.edu <> www.cs.umd.edu/~clancy Madjid Nakhjiri wrote: > Hi, > > I like to seek a clarification here first. > Have we put the discussion of use of EAP code versus EAP types to bed, > completely satisfied that EAP types will absolutely not solve the problems? > > Given that the Russ only first gave the few of us present in San Jose the > green light to change EAP, I feel that we did not quite discuss the impact > of adding new EAP codes versus other changes to an end. A simple analysis > shows (I have confirmed this with several EAP experts) that using a new EAP > type and adding some payload to EAP success you can easily achieve near 1 > roundtrip exchanges. I can forward that analysis in a separate email. > > It is not clear whether adding data to EAP success is more severe than the > changes that EAP-ER is suggesting, to name a few: > > 1) adding new codes even though 3748 mandates a discard code>4 > 2) change of authenticator state machine to treat EAP ER Request as a > response to EAP Identity request. This seems a lot more intrusive on the > massive scale of existing authenticators, than adding data to EAP success > intended for the peer. > > It seems that before fully deciding the EAP code versus EAP type options, it > is hard to make a judgement on a solution that is based on EAP code. After > that, there are issues such as identity exchanges that are needed for key > derivation according to the EMSK draft and it seems that EAP-ER is > considering those out of band or requires explicit additional signaling. > > Finally the other clarification I am seeking is regarding the second > document, don't we want to specify how the per-authenticator keys are > derived? It seems that it should be included in the second spec as well. > > R, > > Madjid > > -----Original Message----- > From: Charles Clancy [mailto:clancy@cs.umd.edu] > Sent: Saturday, March 31, 2007 11:58 AM > To: hokey@ietf.org > Subject: [HOKEY] consensus call: EAP-ER as HOKEY protocol > > HOKEY WG, > > The chairs are making a second consensus call request to adopt EAP-ER as > a WG document to satisfy our re-auth and hand-off deliverables. It > would serve as a starting point for development of the HOKEY protocol. > > Note that if accepted, it may be split into two WG documents, separating > the EAP-ER-Bootstrap into a second set of messages that could be > transported by any service to obtain a USRK or DSUSRK. > > Please respond by Friday, April 13. > _______________________________________________ HOKEY mailing list HOKEY@ietf.org https://www1.ietf.org/mailman/listinfo/hokey From hokey-bounces@ietf.org Mon Apr 02 23:14:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYZSw-0004ht-US; Mon, 02 Apr 2007 23:13:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYZSw-0004hD-Mo for hokey@ietf.org; Mon, 02 Apr 2007 23:13:50 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYZSr-0006SQ-4j for hokey@ietf.org; Mon, 02 Apr 2007 23:13:50 -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 l333DW5T012375 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 2 Apr 2007 20:13:32 -0700 Received: from [10.50.76.158] (qconnect-10-50-76-158.qualcomm.com [10.50.76.158]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l333DSBa027621 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 2 Apr 2007 20:13:29 -0700 Message-ID: <4611C658.7050603@qualcomm.com> Date: Mon, 02 Apr 2007 20:13:28 -0700 From: Lakshminath Dondeti User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: Madjid Nakhjiri Subject: Re: [HOKEY] consensus call: EAP-ER as HOKEY protocol References: <002701c7757c$ea5d0e30$2f01a8c0@china.huawei.com> In-Reply-To: <002701c7757c$ea5d0e30$2f01a8c0@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 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 Many of the active WG contributors were present at the interim meeting and there was a presentation and discussion on how reauthentication might work with new EAP types or codes. The consensus was that code-based approach works best and that consensus was subsequently verified on the list. Well, here we are. I am also looking forward to seeing your analysis on this topic. Changing the structure of the EAP Success message and also the transmission rules for EAP Success are quite drastic changes. If EAP Success needs to be reliably transmitted, authenticator behavior would have to change. Consider the following rules on EAP Success messages: "The peer MAY, in the event that an EAP Success is not received, conclude that the EAP Success packet was lost and that authentication concluded successfully." "Success and Failure packets MUST NOT contain additional data." "Because the Success and Failure packets are not acknowledged, they are not retransmitted by the authenticator, and may be potentially lost. A peer MUST allow for this circumstance as described in this note. " Anyway, I still want to see your analysis of this. thanks, Lakshminath PS: I understand your concern about EAP Identity Request and we can work on other alternatives for it where terminating the EAP state machine at the Authenticator and spawning an EAP-ER state machine is considered burdensome (there are other ways of looking at this and that is written in vidya-eap-er-02). Madjid Nakhjiri wrote: > Hi, > > I like to seek a clarification here first. > Have we put the discussion of use of EAP code versus EAP types to bed, > completely satisfied that EAP types will absolutely not solve the problems? > > Given that the Russ only first gave the few of us present in San Jose the > green light to change EAP, I feel that we did not quite discuss the impact > of adding new EAP codes versus other changes to an end. A simple analysis > shows (I have confirmed this with several EAP experts) that using a new EAP > type and adding some payload to EAP success you can easily achieve near 1 > roundtrip exchanges. I can forward that analysis in a separate email. > > It is not clear whether adding data to EAP success is more severe than the > changes that EAP-ER is suggesting, to name a few: > > 1) adding new codes even though 3748 mandates a discard code>4 > 2) change of authenticator state machine to treat EAP ER Request as a > response to EAP Identity request. This seems a lot more intrusive on the > massive scale of existing authenticators, than adding data to EAP success > intended for the peer. > > It seems that before fully deciding the EAP code versus EAP type options, it > is hard to make a judgement on a solution that is based on EAP code. After > that, there are issues such as identity exchanges that are needed for key > derivation according to the EMSK draft and it seems that EAP-ER is > considering those out of band or requires explicit additional signaling. > > Finally the other clarification I am seeking is regarding the second > document, don't we want to specify how the per-authenticator keys are > derived? It seems that it should be included in the second spec as well. > > R, > > Madjid > > -----Original Message----- > From: Charles Clancy [mailto:clancy@cs.umd.edu] > Sent: Saturday, March 31, 2007 11:58 AM > To: hokey@ietf.org > Subject: [HOKEY] consensus call: EAP-ER as HOKEY protocol > > HOKEY WG, > > The chairs are making a second consensus call request to adopt EAP-ER as > a WG document to satisfy our re-auth and hand-off deliverables. It > would serve as a starting point for development of the HOKEY protocol. > > Note that if accepted, it may be split into two WG documents, separating > the EAP-ER-Bootstrap into a second set of messages that could be > transported by any service to obtain a USRK or DSUSRK. > > Please respond by Friday, April 13. > _______________________________________________ HOKEY mailing list HOKEY@ietf.org https://www1.ietf.org/mailman/listinfo/hokey From hokey-bounces@ietf.org Tue Apr 03 09:46:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYjL1-0007Ir-Q1; Tue, 03 Apr 2007 09:46:19 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYjKz-0007IS-P0 for hokey@ietf.org; Tue, 03 Apr 2007 09:46:17 -0400 Received: from bws14.bridgewatersystems.com ([216.113.7.14]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HYjKy-0004BZ-3p for hokey@ietf.org; Tue, 03 Apr 2007 09:46:17 -0400 MIME-Version: 1.0 Subject: RE: [HOKEY] consensus call: EAP-ER as HOKEY protocol From: Avi Lior In-Reply-To: <4611C658.7050603@qualcomm.com> References: <002701c7757c$ea5d0e30$2f01a8c0@china.huawei.com>, <4611C658.7050603@qualcomm.com> To: Lakshminath Dondeti , Madjid Nakhjiri Message-ID: Date: Tue, 3 Apr 2007 09:47:43 -0400 X-Spam-Score: 1.7 (+) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 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="===============1741154249==" Errors-To: hokey-bounces@ietf.org --===============1741154249== Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [HOKEY] consensus call: EAP-ER as HOKEY pr= otocol
I for one thinks= we should look at allowing us to carry data in EAP success.  In fact,= it would be a good idea if we allowed EAP to carry data which is not part = of the method in all exchanges. 

Clearly there is a need to c= ommunicate with the Peer before and just after authentication.  There = is no other path to the Peer.  EAP should have addressed this.<= /DIV>
 
We already see this happening in= the Request Identity (as in Network Selection and other such usage), in th= e Repsonse Identity and now in the Success phase.
 
We can continue to "hack" EAP but we can also fix it.
 
I am not saying EAP-ER is a hack but it is not efficient bec= ause it works around the existing EAP semantics but hopefully we = could do better.
 
Avi Lior Office: +1 613 591-9104 x 6417 Cell : +1 613 796-4183
=

From: Lakshminath Dondeti
Sent: Mon 4/2/2007 11:13 PM
To: Madjid Nakhjiri
Cc: hokey@= ietf.org
Subject: Re: [HOKEY] consensus call: EAP-ER as HOKEY pro= tocol

Many of the active WG contributors were present at the in= terim meeting
and there was a presentation and discussion on how reauthe= ntication
might work with new EAP types or codes.  The consensus wa= s that
code-based approach works best and that consensus was subsequentl= y
verified on the list.

Well, here we are.  I am also lookin= g forward to seeing your analysis on
this topic.  Changing the stru= cture of the EAP Success message and also
the transmission rules for EAP= Success are quite drastic changes.  If
EAP Success needs to be rel= iably transmitted, authenticator behavior
would have to change.  Co= nsider the following rules on EAP Success messages:

"The peer
&nb= sp;   MAY, in the event that an EAP Success is not received, conc= lude that
    the EAP Success packet was lost and that au= thentication concluded
    successfully."

"Success= and Failure packets MUST NOT
    contain additional data= ."

"Because the Success and Failure packets are not
  &= nbsp; acknowledged, they are not retransmitted by the authenticator, and    may be potentially lost.  A peer MUST allow for th= is circumstance as
    described in this note. "

A= nyway, I still want to see your analysis of this.

thanks,
Lakshmi= nath

PS:  I understand your concern about EAP Identity Request = and we can
work on other alternatives for it where terminating the EAP s= tate
machine at the Authenticator and spawning an EAP-ER state machine i= s
considered burdensome (there are other ways of looking at this and tha= t
is written in vidya-eap-er-02).

Madjid Nakhjiri wrote:
> = Hi,
>
> I like to seek a clarification here first.
> Have= we put the discussion of use of EAP code versus EAP types to bed,
> = completely satisfied that EAP types will absolutely not solve the problems?=
>
> Given that the Russ only first gave the few of us present = in San Jose the
> green light to change EAP, I feel that we did not q= uite discuss the impact
> of adding new EAP codes versus other change= s to an end.  A simple analysis
> shows (I have confirmed this w= ith several EAP experts) that using a new EAP
> type and adding some = payload to EAP success you can easily achieve near 1
> roundtrip exch= anges. I can forward that analysis in a separate email.
>
> It = is not clear whether adding data to EAP success is more severe than the
= > changes that EAP-ER is suggesting, to name a few:
>
> 1) a= dding new codes even though 3748 mandates a discard code>4
> 2) ch= ange of authenticator state machine to treat EAP ER Request as a
> re= sponse to EAP Identity request. This seems a lot more intrusive on the
&= gt; massive scale of existing authenticators, than adding data to EAP succe= ss
> intended for the peer.
>
> It seems that before full= y deciding the EAP code versus EAP type options, it
> is hard to make= a judgement on a solution that is based on EAP code. After
> that, t= here are issues such as identity exchanges that are needed for key
> = derivation according to the EMSK draft and it seems that EAP-ER is
> = considering those out of band or requires explicit additional signaling.>
> Finally the other clarification I am seeking is regarding the= second
> document, don't we want to specify how the per-authenticato= r keys are
> derived? It seems that it should be included in the seco= nd spec as well.
>
> R,
>
> Madjid
>
> = -----Original Message-----
> From: Charles Clancy [mailto:clancy@cs.umd.edu]
> Se= nt: Saturday, March 31, 2007 11:58 AM
> To: hokey@ietf.org
> Su= bject: [HOKEY] consensus call: EAP-ER as HOKEY protocol
>
> HOK= EY WG,
>
> The chairs are making a second consensus call reques= t to adopt EAP-ER as
> a WG document to satisfy our re-auth and hand-= off deliverables.  It
> would serve as a starting point for deve= lopment of the HOKEY protocol.
>
> Note that if accepted, it ma= y be split into two WG documents, separating
> the EAP-ER-Bootstrap i= nto a second set of messages that could be
> transported by any servi= ce to obtain a USRK or DSUSRK.
>
> Please respond by Friday, Ap= ril 13.
>

_______________________________________________
H= OKEY mailing list
HOKEY@ietf.org
https://www1.ietf.org/mailman/listinfo= /hokey

--===============1741154249== 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 --===============1741154249==-- From hokey-bounces@ietf.org Tue Apr 03 12:39:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYm2j-0004uD-8h; Tue, 03 Apr 2007 12:39:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYm2d-0004ro-QE for hokey@ietf.org; Tue, 03 Apr 2007 12:39:31 -0400 Received: from mcfeely.cs.umd.edu ([128.8.128.218]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYlsX-0001nL-WB for hokey@ietf.org; Tue, 03 Apr 2007 12:29:07 -0400 Received: from mcfeely.cs.umd.edu (localhost [127.0.0.1]) by mcfeely.cs.umd.edu (8.12.11.20060308/8.12.5) with ESMTP id l33GSkRB009931; Tue, 3 Apr 2007 12:28:46 -0400 Received: (from apache@localhost) by mcfeely.cs.umd.edu (8.12.11.20060308/8.12.11/Submit) id l33GSks8009929; Tue, 3 Apr 2007 12:28:46 -0400 X-Authentication-Warning: mcfeely.cs.umd.edu: apache set sender to clancy@cs.umd.edu using -f Received: from 63.239.69.1 (SquirrelMail authenticated user clancy) by webmail.cs.umd.edu with HTTP; Tue, 3 Apr 2007 12:28:46 -0400 (EDT) Message-ID: <35963.63.239.69.1.1175617726.squirrel@webmail.cs.umd.edu> In-Reply-To: References: <002701c7757c$ea5d0e30$2f01a8c0@china.huawei.com>, <4611C658.7050603@qualcomm.com> Date: Tue, 3 Apr 2007 12:28:46 -0400 (EDT) Subject: RE: [HOKEY] consensus call: EAP-ER as HOKEY protocol From: "Charles Clancy" To: "Avi Lior" User-Agent: SquirrelMail/1.4.5 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Cc: 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 I think adding stuff to the EAP Success without doing a 3748bis would be a hack. Until both approaches have been implemented and tested with a mix legacy hardware, it's impossible to say which would be more likely to partially work in a partially-upgraded environment. I'd like to see how a legacy NAS deals with a payload-ified EAP-Success and type codes > 4. -- t. charles clancy, ph.d. <> tcc@umd.edu <> www.cs.umd.edu/~clancy On Tue, April 3, 2007 9:47 am, Avi Lior wrote: > Re: [HOKEY] consensus call: EAP-ER as HOKEY > protocol > >
>
I for one thinks we > should look at allowing us to carry data in EAP success.  In fact, it > would be a good idea if we allowed EAP to carry data which is not part of > the method in all exchanges. 
>

Clearly there is a need to > communicate with the Peer before and just after authentication.  > There is no other path to the Peer.  EAP should have addressed > this.
>
 
>
We already see this happening in the > Request Identity (as in Network Selection and other such usage), in the > Repsonse Identity and now in the Success phase.
>
 
>
We can continue to "hack" EAP but we can also fix it.
>
 
>
I am not saying EAP-ER is a hack but it is not efficient > because it works around the existing EAP semantics but > hopefully we could do better.
>
size=2> 
>
>
Avi Lior Office: +1 613 591-9104 x 6417 Cell : +1 613 > 796-4183

> 


> 

> From: Lakshminath Dondeti
Sent:
> Mon 4/2/2007 11:13 PM
To: Madjid Nakhjiri
Cc:
> hokey@ietf.org
Subject: Re: [HOKEY] consensus call: EAP-ER as
> HOKEY protocol


> 

> 
Many of the active WG contributors were present at the
> interim meeting
and there was a presentation and discussion on how
> reauthentication
might work with new EAP types or codes.  The
> consensus was that
code-based approach works best and that consensus
> was subsequently
verified on the list.

Well, here we are. 
> I am also looking forward to seeing your analysis on
this topic. 
> Changing the structure of the EAP Success message and also
the
> transmission rules for EAP Success are quite drastic changes. 
> If
EAP Success needs to be reliably transmitted, authenticator
> behavior
would have to change.  Consider the following rules on
> EAP Success messages:

"The peer
    MAY, in the
> event that an EAP Success is not received, conclude
> that
    the EAP Success packet was lost and that
> authentication concluded
   
> successfully."

"Success and Failure packets MUST
> NOT
    contain additional data."

"Because the
> Success and Failure packets are not
    acknowledged,
> they are not retransmitted by the authenticator, and
   
> may be potentially lost.  A peer MUST allow for this circumstance
> as
    described in this note. "

Anyway, I still
> want to see your analysis of
> this.

thanks,
Lakshminath

PS:  I understand your
> concern about EAP Identity Request and we can
work on other
> alternatives for it where terminating the EAP state
machine at the
> Authenticator and spawning an EAP-ER state machine is
considered
> burdensome (there are other ways of looking at this and that
is written
> in vidya-eap-er-02).

Madjid Nakhjiri wrote:
>
> Hi,
>
> I like to seek a clarification here first.
>
> Have we put the discussion of use of EAP code versus EAP types to
> bed,
> completely satisfied that EAP types will absolutely not solve
> the problems?
>
> Given that the Russ only first gave the few
> of us present in San Jose the
> green light to change EAP, I feel
> that we did not quite discuss the impact
> of adding new EAP codes
> versus other changes to an end.  A simple analysis
> shows (I
> have confirmed this with several EAP experts) that using a new EAP
>
> type and adding some payload to EAP success you can easily achieve near
> 1
> roundtrip exchanges. I can forward that analysis in a separate
> email.
>
> It is not clear whether adding data to EAP success
> is more severe than the
> changes that EAP-ER is suggesting, to name
> a few:
>
> 1) adding new codes even though 3748 mandates a
> discard code>4
> 2) change of authenticator state machine to
> treat EAP ER Request as a
> response to EAP Identity request. This
> seems a lot more intrusive on the
> massive scale of existing
> authenticators, than adding data to EAP success
> intended for the
> peer.
>
> It seems that before fully deciding the EAP code
> versus EAP type options, it
> is hard to make a judgement on a
> solution that is based on EAP code. After
> that, there are issues
> such as identity exchanges that are needed for key
> derivation
> according to the EMSK draft and it seems that EAP-ER is
>
> considering those out of band or requires explicit additional
> signaling.
>
> Finally the other clarification I am seeking is
> regarding the second
> document, don't we want to specify how the
> per-authenticator keys are
> derived? It seems that it should be
> included in the second spec as well.
>
> R,
>
>
> Madjid
>
> -----Original Message-----
> From: Charles
> Clancy [ target=_blank>mailto:clancy@cs.umd.edu]
> Sent: Saturday, March
> 31, 2007 11:58 AM
> To: hokey@ietf.org
> Subject: [HOKEY]
> consensus call: EAP-ER as HOKEY protocol
>
> HOKEY
> WG,
>
> The chairs are making a second consensus call request
> to adopt EAP-ER as
> a WG document to satisfy our re-auth and
> hand-off deliverables.  It
> would serve as a starting point
> for development of the HOKEY protocol.
>
> Note that if
> accepted, it may be split into two WG documents, separating
> the
> EAP-ER-Bootstrap into a second set of messages that could be
>
> transported by any service to obtain a USRK or DSUSRK.
>
>
> Please respond by Friday, April
> 13.
>

_______________________________________________
HOKEY
> mailing list
HOKEY@ietf.org
 href="https://www1.ietf.org/mailman/listinfo/hokey"
> target=_blank>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 Tue Apr 03 13:01:39 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HYmO3-0005PI-2c; Tue, 03 Apr 2007 13:01:39 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HYmO1-0005OQ-LN
	for hokey@ietf.org; Tue, 03 Apr 2007 13:01:37 -0400
Received: from bws14.bridgewatersystems.com ([216.113.7.14])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYmNx-0004K7-TQ
	for hokey@ietf.org; Tue, 03 Apr 2007 13:01:37 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [HOKEY] consensus call: EAP-ER as HOKEY protocol
Date: Tue, 3 Apr 2007 13:02:10 -0400
Message-ID: 
In-Reply-To: <35963.63.239.69.1.1175617726.squirrel@webmail.cs.umd.edu>
References: <002701c7757c$ea5d0e30$2f01a8c0@china.huawei.com>,
	<4611C658.7050603@qualcomm.com>
	
	<35963.63.239.69.1.1175617726.squirrel@webmail.cs.umd.edu>
From: "Avi Lior" 
To: "Charles Clancy" 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 995b2e24d23b953c94bac5288c432399
Cc: 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

I understand your concern.

If you were coding EAP verbatim then we should not be surprised to see a
legacy NAS puke when the length is greater then 4.=20

I agree that we would have to go to a 3748bis unless we found another
clever way to do this.  A way of learning what the Peers, Authenticator
and Authentication-Server capabilities are.

So we could for instance come up with two solutions, one for the old
legacy deployments and one for the new deployments.

So here is a question, is HOKEY designed for old legacy deployments?  I
would argue that most likely not.  Therefore for example, in WiMAX and
3GPP2 we could insist that EAP-Success will be allowed to carry
additional payloads.

But I think that we would want to do this in the IETF.

There is lots of evidence now that we didn't get EAP right. And by the
way, there were proposals in the past for carrying additional attributes
in EAP but nobody could see into the future so the work was not done.


-----Original Message-----
From: Charles Clancy [mailto:clancy@cs.umd.edu]=20
Sent: Tuesday, April 03, 2007 12:29 PM
To: Avi Lior
Cc: Lakshminath Dondeti; Madjid Nakhjiri; hokey@ietf.org
Subject: RE: [HOKEY] consensus call: EAP-ER as HOKEY protocol


I think adding stuff to the EAP Success without doing a 3748bis would be
a hack.  Until both approaches have been implemented and tested with a
mix legacy hardware, it's impossible to say which would be more likely
to partially work in a partially-upgraded environment.  I'd like to see
how a legacy NAS deals with a payload-ified EAP-Success and type codes >
4.


--

t. charles clancy, ph.d.  <>  tcc@umd.edu  <>  www.cs.umd.edu/~clancy

On Tue, April 3, 2007 9:47 am, Avi Lior wrote:
> Re: [HOKEY] consensus call: EAP-ER as =
HOKEY

> protocol  
=20
> 
I for one =
thinks we

> should look at allowing us to carry data in EAP success.  In=20
> fact, it would be a good idea if we allowed EAP to carry data which is

> not part of the method in all exchanges. 
  dir=3Dltr>
Clearly there is a need to=20
> communicate with the Peer before and just after authentication. =20
> There is no other path to the Peer.  EAP should have addressed=20
> this.
 
 size=3D2> 
 
We=20
> already see this happening in the Request Identity (as in Network=20
> Selection and other such usage), in the Repsonse Identity and now in=20
> the Success phase.
 
 Roman" size=3D3> 
 
We can continue to=20
> "hack" EAP but we can also fix it.
 
 
=20
> 
I am not saying EAP-ER is a hack but it is not =
efficient=20
> because it works around the existing EAP semantics but=20
> hopefully we could do better.
 
 color=3D#000000 size=3D2> 
  id=3DidSignature6710> 
Avi Lior Office: +1 613 591-9104 x 6417=20
> Cell : +1 613 796-4183
 

  tabIndex=3D-1> From: Lakshminath=20
> Dondeti
Sent: Mon 4/2/2007 11:13 PM
To: Madjid=20
> Nakhjiri
Cc: hokey@ietf.org
Subject: Re: [HOKEY]=20
> consensus call: EAP-ER as HOKEY protocol

 
=20
> 
Many of the active WG contributors were present at =
the

> interim meeting
and there was a presentation and discussion on how=20
> reauthentication
might work with new EAP types or codes.  The=20
> consensus was that
code-based approach works best and that=20
> consensus was subsequently
verified on the list.

Well, here=20
> we are.  I am also looking forward to seeing your analysis=20
> on
this topic.  Changing the structure of the EAP Success=20
> message and also
the transmission rules for EAP Success are quite=20
> drastic changes.  If
EAP Success needs to be reliably=20
> transmitted, authenticator behavior
would have to change. =20
> Consider the following rules on EAP Success messages:

"The=20
> peer
    MAY, in the event that an EAP Success is=20
> not received, conclude that
    the EAP Success=20
> packet was lost and that authentication=20
> concluded
    successfully."

"Success and=20
> Failure packets MUST NOT
    contain additional=20
> data."

"Because the Success and Failure packets are=20
> not
    acknowledged, they are not retransmitted by=20
> the authenticator, and
    may be potentially=20
> lost.  A peer MUST allow for this circumstance=20
> as
    described in this note. "

Anyway, I=20
> still want to see your analysis of=20
> this.

thanks,
Lakshminath

PS:  I understand your

> concern about EAP Identity Request and we can
work on other=20
> alternatives for it where terminating the EAP state
machine at the=20
> Authenticator and spawning an EAP-ER state machine is
considered=20
> burdensome (there are other ways of looking at this and that
is=20
> written in vidya-eap-er-02).

Madjid Nakhjiri wrote:
>=20
> Hi,
>
> I like to seek a clarification here first.
>

> Have we put the discussion of use of EAP code versus EAP types to=20
> bed,
> completely satisfied that EAP types will absolutely not=20
> solve the problems?
>
> Given that the Russ only first=20
> gave the few of us present in San Jose the
> green light to=20
> change EAP, I feel that we did not quite discuss the impact
> of

> adding new EAP codes versus other changes to an end.  A simple=20
> analysis
> shows (I have confirmed this with several EAP=20
> experts) that using a new EAP
> type and adding some payload to=20
> EAP success you can easily achieve near 1
> roundtrip exchanges.

> I can forward that analysis in a separate email.
>
> It is

> not clear whether adding data to EAP success is more severe than=20
> the
> changes that EAP-ER is suggesting, to name a=20
> few:
>
> 1) adding new codes even though 3748 mandates a=20
> discard code>4
> 2) change of authenticator state machine to=20
> treat EAP ER Request as a
> response to EAP Identity request.=20
> This seems a lot more intrusive on the
> massive scale of=20
> existing authenticators, than adding data to EAP success
>=20
> intended for the peer.
>
> It seems that before fully=20
> deciding the EAP code versus EAP type options, it
> is hard to=20
> make a judgement on a solution that is based on EAP code.=20
> After
> that, there are issues such as identity exchanges that=20
> are needed for key
> derivation according to the EMSK draft and=20
> it seems that EAP-ER is
> considering those out of band or=20
> requires explicit additional signaling.
>
> Finally the=20
> other clarification I am seeking is regarding the second
>=20
> document, don't we want to specify how the per-authenticator keys=20
> are
> derived? It seems that it should be included in the second
spec as well.
>
> R,
>
> Madjid
>
>
-----Original Message-----
> From: Charles Clancy [ target=3D_blank>mailto:clancy@cs.umd.edu]
> Sent: Saturday,=20
> March 31, 2007 11:58 AM
> To: hokey@ietf.org
> Subject:=20
> [HOKEY] consensus call: EAP-ER as HOKEY protocol
>
> HOKEY

> WG,
>
> The chairs are making a second consensus call=20
> request to adopt EAP-ER as
> a WG document to satisfy our=20
> re-auth and hand-off deliverables.  It
> would serve as a=20
> starting point for development of the HOKEY protocol.
>
>=20
> Note that if accepted, it may be split into two WG documents,=20
> separating
> the EAP-ER-Bootstrap into a second set of messages=20
> that could be
> transported by any service to obtain a USRK or=20
> DSUSRK.
>
> Please respond by Friday, April=20
> 13.
>

_______________________________________________

> HOKEY
> mailing list
HOKEY@ietf.org
 href=3D"https://www1.ietf.org/mailman/listinfo/hokey"
> =
target=3D_blank>https://www1.ietf.org/mailman/listinfo/hokey
 NT>

>
> _______________________________________________
> 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 Apr 03 13:06:56 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HYmT8-0008Sa-J9; Tue, 03 Apr 2007 13:06:54 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HYmT6-0008K2-Pp
	for hokey@ietf.org; Tue, 03 Apr 2007 13:06:52 -0400
Received: from ithilien.qualcomm.com ([129.46.51.59])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYmT5-0005gi-5w
	for hokey@ietf.org; Tue, 03 Apr 2007 13:06:52 -0400
Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158])
	by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id
	l33H6hAx011750
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 3 Apr 2007 10:06:44 -0700
Received: from [129.46.78.141] (ldondeti.na.qualcomm.com [129.46.78.141])
	by totoro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l33H6gEH015356
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Tue, 3 Apr 2007 10:06:43 -0700 (PDT)
Message-ID: <461289A3.3000901@qualcomm.com>
Date: Tue, 03 Apr 2007 10:06:43 -0700
From: Lakshminath Dondeti 
User-Agent: Thunderbird 2.0b2 (Windows/20070116)
MIME-Version: 1.0
To: Avi Lior 
Subject: Re: [HOKEY] consensus call: EAP-ER as HOKEY protocol
References: <002701c7757c$ea5d0e30$2f01a8c0@china.huawei.com>,
	<4611C658.7050603@qualcomm.com>
	
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 33cc095b503da4365ce57c727e553cf1
Cc: 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

Hi Avi,

I find some of your arguments counter-intuitive and so would like to 
understand your line of thinking on this topic.  Modifications to a 
protocol to my knowledge would be hacks and extensions are well, 
extensions.  For instance, the EAP Request/Identity message suspension 
in EAP-ER, as much as I would like to defend it, is somewhat of a hack. 
  It is the cleanest Vidya and I could come up with in the sense that 
the message itself is not modified, but we need something like it to 
make sure that the L2 connection is not closed if the retransmission 
time expires.  Perhaps the wider community might find a better approach.

Next, some notes on 4284 since that has come up here:

3748 says "Some EAP implementations piggy-back various options into the
       Identity Request after a NUL-character. "

4284 uses that provision.  In any event, 4284 is somewhat of a hack and 
is an informational RFC for the purposes of 3GPP's use.

Please see inline for some questions:

Avi Lior wrote:
> I for one thinks we should look at allowing us to carry data in EAP 
> success.  In fact, it would be a good idea if we allowed EAP to carry 
> data which is not part of the method in all exchanges. 

If the data is not part of the method, which entity needs to send such 
data and how is it protected?

> 
> Clearly there is a need to communicate with the Peer before and just 
> after authentication.  There is no other path to the Peer.  EAP should 
> have addressed this.

Again which entity needs to communicate with the Peer?

>  
> We already see this happening in the Request Identity (as in Network 
> Selection and other such usage), in the Repsonse Identity and now in the 
> Success phase.
>  
> We can continue to "hack" EAP but we can also fix it.

I am lost here, so please help me out :).  The network selection 
solution of 4284 is a hack IMO.  If you are saying we should revise 
3748, I might agree with you in principle.  But, practically speaking 
that is not happening anytime soon.

Next, RFC 3748 has clear guidance on allocating new packet codes in 
Section 6.1.  Defining new codes is a natural way of extending EAP.  If 
the goal is backward compatibility, adding stuff to EAP Success doesn't 
help either.  As I have noted before, EAP Success packets are not 
retransmitted by authenticators and that would have to change if we add 
anything crucial to Success packets.

I appreciate any clarifications you might provide to help me understand 
your point of view here.  Thanks.

regards,
Lakshminath

>  
> I am not saying EAP-ER is a hack but it is not efficient because it 
> works around the existing EAP semantics but hopefully we could do better.
>  
> Avi Lior Office: +1 613 591-9104 x 6417 Cell : +1 613 796-4183
> 
> 
> ------------------------------------------------------------------------
> *From:* Lakshminath Dondeti
> *Sent:* Mon 4/2/2007 11:13 PM
> *To:* Madjid Nakhjiri
> *Cc:* hokey@ietf.org
> *Subject:* Re: [HOKEY] consensus call: EAP-ER as HOKEY protocol
> 
> Many of the active WG contributors were present at the interim meeting
> and there was a presentation and discussion on how reauthentication
> might work with new EAP types or codes.  The consensus was that
> code-based approach works best and that consensus was subsequently
> verified on the list.
> 
> Well, here we are.  I am also looking forward to seeing your analysis on
> this topic.  Changing the structure of the EAP Success message and also
> the transmission rules for EAP Success are quite drastic changes.  If
> EAP Success needs to be reliably transmitted, authenticator behavior
> would have to change.  Consider the following rules on EAP Success messages:
> 
> "The peer
>     MAY, in the event that an EAP Success is not received, conclude that
>     the EAP Success packet was lost and that authentication concluded
>     successfully."
> 
> "Success and Failure packets MUST NOT
>     contain additional data."
> 
> "Because the Success and Failure packets are not
>     acknowledged, they are not retransmitted by the authenticator, and
>     may be potentially lost.  A peer MUST allow for this circumstance as
>     described in this note. "
> 
> Anyway, I still want to see your analysis of this.
> 
> thanks,
> Lakshminath
> 
> PS:  I understand your concern about EAP Identity Request and we can
> work on other alternatives for it where terminating the EAP state
> machine at the Authenticator and spawning an EAP-ER state machine is
> considered burdensome (there are other ways of looking at this and that
> is written in vidya-eap-er-02).
> 
> Madjid Nakhjiri wrote:
>  > Hi,
>  >
>  > I like to seek a clarification here first.
>  > Have we put the discussion of use of EAP code versus EAP types to bed,
>  > completely satisfied that EAP types will absolutely not solve the 
> problems?
>  >
>  > Given that the Russ only first gave the few of us present in San Jose the
>  > green light to change EAP, I feel that we did not quite discuss the 
> impact
>  > of adding new EAP codes versus other changes to an end.  A simple 
> analysis
>  > shows (I have confirmed this with several EAP experts) that using a 
> new EAP
>  > type and adding some payload to EAP success you can easily achieve near 1
>  > roundtrip exchanges. I can forward that analysis in a separate email.
>  >
>  > It is not clear whether adding data to EAP success is more severe 
> than the
>  > changes that EAP-ER is suggesting, to name a few:
>  >
>  > 1) adding new codes even though 3748 mandates a discard code>4
>  > 2) change of authenticator state machine to treat EAP ER Request as a
>  > response to EAP Identity request. This seems a lot more intrusive on the
>  > massive scale of existing authenticators, than adding data to EAP success
>  > intended for the peer.
>  >
>  > It seems that before fully deciding the EAP code versus EAP type 
> options, it
>  > is hard to make a judgement on a solution that is based on EAP code. 
> After
>  > that, there are issues such as identity exchanges that are needed for key
>  > derivation according to the EMSK draft and it seems that EAP-ER is
>  > considering those out of band or requires explicit additional signaling.
>  >
>  > Finally the other clarification I am seeking is regarding the second
>  > document, don't we want to specify how the per-authenticator keys are
>  > derived? It seems that it should be included in the second spec as well.
>  >
>  > R,
>  >
>  > Madjid
>  >
>  > -----Original Message-----
>  > From: Charles Clancy [mailto:clancy@cs.umd.edu]
>  > Sent: Saturday, March 31, 2007 11:58 AM
>  > To: hokey@ietf.org
>  > Subject: [HOKEY] consensus call: EAP-ER as HOKEY protocol
>  >
>  > HOKEY WG,
>  >
>  > The chairs are making a second consensus call request to adopt EAP-ER as
>  > a WG document to satisfy our re-auth and hand-off deliverables.  It
>  > would serve as a starting point for development of the HOKEY protocol.
>  >
>  > Note that if accepted, it may be split into two WG documents, separating
>  > the EAP-ER-Bootstrap into a second set of messages that could be
>  > transported by any service to obtain a USRK or DSUSRK.
>  >
>  > Please respond by Friday, April 13.
>  >
> 
> _______________________________________________
> 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 Apr 03 13:56:24 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HYnEy-0004ak-8I; Tue, 03 Apr 2007 13:56:20 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HYnEw-0004aB-Om
	for hokey@ietf.org; Tue, 03 Apr 2007 13:56:18 -0400
Received: from bws14.bridgewatersystems.com ([216.113.7.14])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYnEv-0003Tw-2U
	for hokey@ietf.org; Tue, 03 Apr 2007 13:56:18 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [HOKEY] consensus call: EAP-ER as HOKEY protocol
Date: Tue, 3 Apr 2007 13:56:51 -0400
Message-ID: 
In-Reply-To: <461289A3.3000901@qualcomm.com>
References: <002701c7757c$ea5d0e30$2f01a8c0@china.huawei.com>,
	<4611C658.7050603@qualcomm.com>
	
	<461289A3.3000901@qualcomm.com>
From: "Avi Lior" 
To: "Lakshminath Dondeti" 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 03fb21b15d5177c512a4caa19876f30a
Cc: 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

I agree with everything you say.

So lets fix it so that we don't hack -- we are talking about good hacks
here (which are workarounds).

Or at least come up with a workaround that will solve problems in
general so we can apply it for other problems.=20

-----Original Message-----
From: Lakshminath Dondeti [mailto:ldondeti@qualcomm.com]=20
Sent: Tuesday, April 03, 2007 1:07 PM
To: Avi Lior
Cc: Madjid Nakhjiri; hokey@ietf.org
Subject: Re: [HOKEY] consensus call: EAP-ER as HOKEY protocol

Hi Avi,

I find some of your arguments counter-intuitive and so would like to
understand your line of thinking on this topic.  Modifications to a
protocol to my knowledge would be hacks and extensions are well,
extensions.  For instance, the EAP Request/Identity message suspension
in EAP-ER, as much as I would like to defend it, is somewhat of a hack.

[Avi] People get upset with hacks. Call it a workaround, and I am
suggesting to avoid future work around that we extend the protocol to
elliminate or incorporate the workaround into the protocol.

=20
  It is the cleanest Vidya and I could come up with in the sense that
the message itself is not modified, but we need something like it to
make sure that the L2 connection is not closed if the retransmission
time expires.  Perhaps the wider community might find a better approach.

[Avi] Perhaps. And perhaps we can use this opportunity to fix other
problems as well.

Next, some notes on 4284 since that has come up here:

3748 says "Some EAP implementations piggy-back various options into the
       Identity Request after a NUL-character. "

4284 uses that provision.  In any event, 4284 is somewhat of a hack and
is an informational RFC for the purposes of 3GPP's use.

[Avi] Okay. People feel it's a hack but why? 3748 allows for that and
the approach taken in 4284 accomodates future extensions by introducing
AVPs and delimeters.
The problem with 3748 was that it says you can put something after a
NULL but it stopped too short. It should have said, after the null you
can put AVP formatted in a certain way.

Please see inline for some questions:

Avi Lior wrote:
> I for one thinks we should look at allowing us to carry data in EAP=20
> success.  In fact, it would be a good idea if we allowed EAP to carry=20
> data which is not part of the method in all exchanges.

If the data is not part of the method, which entity needs to send such
data and how is it protected?

[Avi] As to which entity It's a good question, and I think we can work
out the details to this.   For 4284 who is the target entity?  It's not
for the EAP method.  It's for the entity that makes a decision on which
network to select and how to formulate the NAI that is delivered in the
EAP response identity.

[Avi]Not all data has to be protected, but where protection is needed we
can design for that.  There were proposals to do this in the past.
Certainly in the EAP success payload one could envision that some of
that payload could be protected betweent the EAP-AuthServer and the MS
using a key derived from EMSK and some attributes can be prtoected
between the Authentication and the MS using a key derived from the MSK.


>=20
> Clearly there is a need to communicate with the Peer before and just=20
> after authentication.  There is no other path to the Peer.  EAP should

> have addressed this.

Again which entity needs to communicate with the Peer?
[Avi]Again we can figure that out.

> =20
> We already see this happening in the Request Identity (as in Network=20
> Selection and other such usage), in the Repsonse Identity and now in=20
> the Success phase.
> =20
> We can continue to "hack" EAP but we can also fix it.

I am lost here, so please help me out :).  The network selection
solution of 4284 is a hack IMO.  If you are saying we should revise
3748, I might agree with you in principle.  But, practically speaking
that is not happening anytime soon.

[Avi] Why not???  Or perhaps we can do something here without revising
3748 perhaps we can overlay something ontop.

Next, RFC 3748 has clear guidance on allocating new packet codes in
Section 6.1.  Defining new codes is a natural way of extending EAP.  If
the goal is backward compatibility, adding stuff to EAP Success doesn't
help either.  As I have noted before, EAP Success packets are not
retransmitted by authenticators and that would have to change if we add
anything crucial to Success packets.

[Avi] I understand this but it is not necessarily the best way to extend
-- and eventhough EAP does offer an extension mechanism it is not
sufficient as you pointed out by the workarounds  you had to do. And yes
if we are adding stuff to the EAP Success packets we would have to
address retransmission of that packet.

I appreciate any clarifications you might provide to help me understand
your point of view here.  Thanks.

[Avi] I don't think I gave you the necessary clarifications.  I am not
trying to come up with a solution but rather point out that maybe we
need to address this in a more general way. And yes, maybe nothing will
happen and we will continue to hack EAP. =20

[Avi] As with any twelve step program, the first step is to admit we
have a problem. So do we have a problem?

regards,
Lakshminath

> =20
> I am not saying EAP-ER is a hack but it is not efficient because it=20
> works around the existing EAP semantics but hopefully we could do
better.
> =20
> Avi Lior Office: +1 613 591-9104 x 6417 Cell : +1 613 796-4183
>=20
>=20
> ----------------------------------------------------------------------
> --
> *From:* Lakshminath Dondeti
> *Sent:* Mon 4/2/2007 11:13 PM
> *To:* Madjid Nakhjiri
> *Cc:* hokey@ietf.org
> *Subject:* Re: [HOKEY] consensus call: EAP-ER as HOKEY protocol
>=20
> Many of the active WG contributors were present at the interim meeting

> and there was a presentation and discussion on how reauthentication=20
> might work with new EAP types or codes.  The consensus was that=20
> code-based approach works best and that consensus was subsequently=20
> verified on the list.
>=20
> Well, here we are.  I am also looking forward to seeing your analysis=20
> on this topic.  Changing the structure of the EAP Success message and=20
> also the transmission rules for EAP Success are quite drastic changes.

> If EAP Success needs to be reliably transmitted, authenticator=20
> behavior would have to change.  Consider the following rules on EAP
Success messages:
>=20
> "The peer
>     MAY, in the event that an EAP Success is not received, conclude
that
>     the EAP Success packet was lost and that authentication concluded
>     successfully."
>=20
> "Success and Failure packets MUST NOT
>     contain additional data."
>=20
> "Because the Success and Failure packets are not
>     acknowledged, they are not retransmitted by the authenticator, and
>     may be potentially lost.  A peer MUST allow for this circumstance
as
>     described in this note. "
>=20
> Anyway, I still want to see your analysis of this.
>=20
> thanks,
> Lakshminath
>=20
> PS:  I understand your concern about EAP Identity Request and we can=20
> work on other alternatives for it where terminating the EAP state=20
> machine at the Authenticator and spawning an EAP-ER state machine is=20
> considered burdensome (there are other ways of looking at this and=20
> that is written in vidya-eap-er-02).
>=20
> Madjid Nakhjiri wrote:
>  > Hi,
>  >
>  > I like to seek a clarification here first.
>  > Have we put the discussion of use of EAP code versus EAP types to=20
> bed,  > completely satisfied that EAP types will absolutely not solve=20
> the problems?
>  >
>  > Given that the Russ only first gave the few of us present in San=20
> Jose the  > green light to change EAP, I feel that we did not quite=20
> discuss the impact  > of adding new EAP codes versus other changes to=20
> an end.  A simple analysis  > shows (I have confirmed this with=20
> several EAP experts) that using a new EAP  > type and adding some=20
> payload to EAP success you can easily achieve near 1  > roundtrip=20
> exchanges. I can forward that analysis in a separate email.
>  >
>  > It is not clear whether adding data to EAP success is more severe=20
> than the  > changes that EAP-ER is suggesting, to name a few:
>  >
>  > 1) adding new codes even though 3748 mandates a discard code>4  >=20
> 2) change of authenticator state machine to treat EAP ER Request as a

> > response to EAP Identity request. This seems a lot more intrusive on

> the  > massive scale of existing authenticators, than adding data to=20
> EAP success  > intended for the peer.
>  >
>  > It seems that before fully deciding the EAP code versus EAP type=20
> options, it  > is hard to make a judgement on a solution that is based

> on EAP code.
> After
>  > that, there are issues such as identity exchanges that are needed=20
> for key  > derivation according to the EMSK draft and it seems that=20
> EAP-ER is  > considering those out of band or requires explicit
additional signaling.
>  >
>  > Finally the other clarification I am seeking is regarding the=20
> second  > document, don't we want to specify how the per-authenticator

> keys are  > derived? It seems that it should be included in the second
spec as well.
>  >
>  > R,
>  >
>  > Madjid
>  >
>  > -----Original Message-----
>  > From: Charles Clancy [mailto:clancy@cs.umd.edu]  > Sent: Saturday,=20
> March 31, 2007 11:58 AM  > To: hokey@ietf.org  > Subject: [HOKEY]=20
> consensus call: EAP-ER as HOKEY protocol  >  > HOKEY WG,  >  > The=20
> chairs are making a second consensus call request to adopt EAP-ER as =20
> > a WG document to satisfy our re-auth and hand-off deliverables.  It

> > would serve as a starting point for development of the HOKEY
protocol.
>  >
>  > Note that if accepted, it may be split into two WG documents,=20
> separating  > the EAP-ER-Bootstrap into a second set of messages that=20
> could be  > transported by any service to obtain a USRK or DSUSRK.
>  >
>  > Please respond by Friday, April 13.
>  >
>=20
> _______________________________________________
> HOKEY mailing list
> HOKEY@ietf.org
> https://www1.ietf.org/mailman/listinfo/hokey
>=20

_______________________________________________
HOKEY mailing list
HOKEY@ietf.org
https://www1.ietf.org/mailman/listinfo/hokey



From hokey-bounces@ietf.org Tue Apr 03 14:31: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 1HYnmZ-0004oF-SU; Tue, 03 Apr 2007 14:31:03 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HYnmY-0004mk-I6
	for hokey@ietf.org; Tue, 03 Apr 2007 14:31:02 -0400
Received: from web54406.mail.yahoo.com ([206.190.49.136])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HYnmU-0007yu-Pu
	for hokey@ietf.org; Tue, 03 Apr 2007 14:31:02 -0400
Received: (qmail 58984 invoked by uid 60001); 3 Apr 2007 18:30:58 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com;
	h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Message-ID;
	b=c3iV3VwGwUjPwib1rSjp+KjamqGtOM5SnG4vF9359mLVy26Sp453/Oy8DyHvoUKuaWVCoNRx7M0+JLbkFyPJ2qfyoAclsDa8pWEt7c2556YMOkuXy2co798jn3cCVgPT6agrJyezrq+PjVSVGt4BuPLleKEuVTVx7dlmceDPlg4=;
X-YMail-OSG: r1bHRowVM1mumUUDVSzYlpQdgH5_xY_NQLzkKSi1NdDob8Qol4FoXLF4gsX0KiYQwJyZEo1CaqmEyfTLiX0WjptEZGOXpyvDmZTw
Received: from [67.181.58.13] by web54406.mail.yahoo.com via HTTP;
	Tue, 03 Apr 2007 11:30:58 PDT
X-Mailer: YahooMailRC/476 YahooMailWebService/0.7.41.8
Date: Tue, 3 Apr 2007 11:30:58 -0700 (PDT)
From: "M. Vanderveen" 
Subject: Re: [HOKEY] consensus call: EAP-ER as HOKEY protocol
To: Avi Lior ,
	Lakshminath Dondeti ,
	Madjid Nakhjiri 
MIME-Version: 1.0
Message-ID: <665490.56904.qm@web54406.mail.yahoo.com>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 7a0494a0224ca59418dd8f92694c1fdb
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="===============1594234762=="
Errors-To: hokey-bounces@ietf.org

--===============1594234762==
Content-Type: multipart/alternative; boundary="0-14202823-1175625058=:56904"

--0-14202823-1175625058=:56904
Content-Type: text/plain; charset=ascii

Regarding carrying data on the EAP-Success. Let's not forget that the previous EAP RFC2284 allowed carrying data in the EAP Success. Consequently methods deployed between 1998 and 2004 could have very well already carried data in it. In fact there is relatively wide deployment in Europe of an EAP method that does just that.

If I recall correctly the reason for banning data in the EAP-Success was because it should be protected, and we did not have a method-independent way to do that. 

An important point I would like to make regards implementation/deployment:
Folks with experience implementing and maintaining servers (not NASes/BSs) claim that it would be much easier to modify EAP behavior by adding data onto the EAP-Success than by adding new Codes.  That is because adding new methods is something that is WELL-UNDERSTOOD and done frequently. Adding something under the EAP method layer is not.  They fear a lot of implementation complexity and ongoing test efforts with the addition of EAP-ER onto existing EAP server implementations. 



Michaela


----- Original Message ----
From: Avi Lior 
To: Lakshminath Dondeti ; Madjid Nakhjiri 
Cc: hokey@ietf.org
Sent: Tuesday, April 3, 2007 6:47:43 AM
Subject: RE: [HOKEY] consensus call: EAP-ER as HOKEY protocol


I for one thinks we should look at allowing us to carry data in EAP success.  In fact, it would be a good idea if we allowed EAP to carry data which is not part of the method in all exchanges. 

Clearly there is a need to communicate with the Peer before and just after authentication.  There is no other path to the Peer.  EAP should have addressed this.
 
We already see this happening in the Request Identity (as in Network Selection and other such usage), in the Repsonse Identity and now in the Success phase.
 
We can continue to "hack" EAP but we can also fix it.
 
I am not saying EAP-ER is a hack but it is not efficient because it works around the existing EAP semantics but hopefully we could do better.
 
Avi Lior Office: +1 613 591-9104 x 6417 Cell : +1 613 796-4183




From: Lakshminath Dondeti
Sent: Mon 4/2/2007 11:13 PM
To: Madjid Nakhjiri
Cc: hokey@ietf.org
Subject: Re: [HOKEY] consensus call: EAP-ER as HOKEY protocol


Many of the active WG contributors were present at the interim meeting
and there was a presentation and discussion on how reauthentication
might work with new EAP types or codes.  The consensus was that
code-based approach works best and that consensus was subsequently
verified on the list.

Well, here we are.  I am also looking forward to seeing your analysis on
this topic.  Changing the structure of the EAP Success message and also
the transmission rules for EAP Success are quite drastic changes.  If
EAP Success needs to be reliably transmitted, authenticator behavior
would have to change.  Consider the following rules on EAP Success messages:

"The peer
    MAY, in the event that an EAP Success is not received, conclude that
    the EAP Success packet was lost and that authentication concluded
    successfully."

"Success and Failure packets MUST NOT
    contain additional data."

"Because the Success and Failure packets are not
    acknowledged, they are not retransmitted by the authenticator, and
    may be potentially lost.  A peer MUST allow for this circumstance as
    described in this note. "

Anyway, I still want to see your analysis of this.

thanks,
Lakshminath

PS:  I understand your concern about EAP Identity Request and we can
work on other alternatives for it where terminating the EAP state
machine at the Authenticator and spawning an EAP-ER state machine is
considered burdensome (there are other ways of looking at this and that
is written in vidya-eap-er-02).

Madjid Nakhjiri wrote:
> Hi,
>
> I like to seek a clarification here first.
> Have we put the discussion of use of EAP code versus EAP types to bed,
> completely satisfied that EAP types will absolutely not solve the problems?
>
> Given that the Russ only first gave the few of us present in San Jose the
> green light to change EAP, I feel that we did not quite discuss the impact
> of adding new EAP codes versus other changes to an end.  A simple analysis
> shows (I have confirmed this with several EAP experts) that using a new EAP
> type and adding some payload to EAP success you can easily achieve near 1
> roundtrip exchanges. I can forward that analysis in a separate email.
>
> It is not clear whether adding data to EAP success is more severe than the
> changes that EAP-ER is suggesting, to name a few:
>
> 1) adding new codes even though 3748 mandates a discard code>4
> 2) change of authenticator state machine to treat EAP ER Request as a
> response to EAP Identity request. This seems a lot more intrusive on the
> massive scale of existing authenticators, than adding data to EAP success
> intended for the peer.
>
> It seems that before fully deciding the EAP code versus EAP type options, it
> is hard to make a judgement on a solution that is based on EAP code. After
> that, there are issues such as identity exchanges that are needed for key
> derivation according to the EMSK draft and it seems that EAP-ER is
> considering those out of band or requires explicit additional signaling.
>
> Finally the other clarification I am seeking is regarding the second
> document, don't we want to specify how the per-authenticator keys are
> derived? It seems that it should be included in the second spec as well.
>
> R,
>
> Madjid
>
> -----Original Message-----
> From: Charles Clancy [mailto:clancy@cs.umd.edu]
> Sent: Saturday, March 31, 2007 11:58 AM
> To: hokey@ietf.org
> Subject: [HOKEY] consensus call: EAP-ER as HOKEY protocol
>
> HOKEY WG,
>
> The chairs are making a second consensus call request to adopt EAP-ER as
> a WG document to satisfy our re-auth and hand-off deliverables.  It
> would serve as a starting point for development of the HOKEY protocol.
>
> Note that if accepted, it may be split into two WG documents, separating
> the EAP-ER-Bootstrap into a second set of messages that could be
> transported by any service to obtain a USRK or DSUSRK.
>
> Please respond by Friday, April 13.
>

_______________________________________________
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


 
____________________________________________________________________________________
Don't get soaked.  Take a quick peek at the forecast
with the Yahoo! Search weather shortcut.
http://tools.search.yahoo.com/shortcuts/#loc_weather
--0-14202823-1175625058=:56904
Content-Type: text/html; charset=ascii


Regarding carrying data on the EAP-Success. Let's not forget that the previous EAP RFC2284 allowed carrying data in the EAP Success. Consequently methods deployed between 1998 and 2004 could have very well already carried data in it. In fact there is relatively wide deployment in Europe of an EAP method that does just that.


 


If I recall correctly the reason for banning data in the EAP-Success was because it should be protected, and we did not have a method-independent way to do that. 


 


An important point I would like to make regards implementation/deployment:


Folks with experience implementing and maintaining servers (not NASes/BSs) claim that it would be much easier to modify EAP behavior by adding data onto the EAP-Success than by adding new Codes.  That is because adding new methods is something that is WELL-UNDERSTOOD and done frequently. Adding something under the EAP method layer is not.  They fear a lot of implementation complexity and ongoing test efforts with the addition of EAP-ER onto existing EAP server implementations. 


 


 


 


Michaela



----- Original Message ----
From: Avi Lior <avi@bridgewatersystems.com>
To: Lakshminath Dondeti <ldondeti@qualcomm.com>; Madjid Nakhjiri <mnakhjiri@huawei.com>
Cc: hokey@ietf.org
Sent: Tuesday, April 3, 2007 6:47:43 AM
Subject: RE: [HOKEY] consensus call: EAP-ER as HOKEY protocol





I for one thinks we should look at allowing us to carry data in EAP success.  In fact, it would be a good idea if we allowed EAP to carry data which is not part of the method in all exchanges. 



Clearly there is a need to communicate with the Peer before and just after authentication.  There is no other path to the Peer.  EAP should have addressed this.


 


We already see this happening in the Request Identity (as in Network Selection and other such usage), in the Repsonse Identity and now in the Success phase.


 


We can continue to "hack" EAP but we can also fix it.


 


I am not saying EAP-ER is a hack but it is not efficient because it works around the existing EAP semantics but hopefully we could do better.


 




Avi Lior Office: +1 613 591-9104 x 6417 Cell : +1 613 796-4183






From: Lakshminath Dondeti
Sent: Mon 4/2/2007 11:13 PM
To: Madjid Nakhjiri
Cc: hokey@ietf.org
Subject: Re: [HOKEY] consensus call: EAP-ER as HOKEY protocol





Many of the active WG contributors were present at the interim meeting
and there was a presentation and discussion on how reauthentication
might work with new EAP types or codes.  The consensus was that
code-based approach works best and that consensus was subsequently
verified on the list.

Well, here we are.  I am also looking forward to seeing your analysis on
this topic.  Changing the structure of the EAP Success message and also
the transmission rules for EAP Success are quite drastic changes.  If
EAP Success needs to be reliably transmitted, authenticator behavior
would have to change.  Consider the following rules on EAP Success messages:

"The peer
    MAY, in the event that an EAP Success is not received, conclude that
    the EAP Success packet was lost and that authentication concluded
    successfully."

"Success and Failure
 packets MUST NOT
    contain additional data."

"Because the Success and Failure packets are not
    acknowledged, they are not retransmitted by the authenticator, and
    may be potentially lost.  A peer MUST allow for this circumstance as
    described in this note. "

Anyway, I still want to see your analysis of this.

thanks,
Lakshminath

PS:  I understand your concern about EAP Identity Request and we can
work on other alternatives for it where terminating the EAP state
machine at the Authenticator and spawning an EAP-ER state machine is
considered burdensome (there are other ways of looking at this and that
is written in vidya-eap-er-02).

Madjid Nakhjiri wrote:
> Hi,
>
> I like to seek a clarification here first.
> Have we put the discussion of use of EAP code versus EAP types to bed,
> completely satisfied that
 EAP types will absolutely not solve the problems?
>
> Given that the Russ only first gave the few of us present in San Jose the
> green light to change EAP, I feel that we did not quite discuss the impact
> of adding new EAP codes versus other changes to an end.  A simple analysis
> shows (I have confirmed this with several EAP experts) that using a new EAP
> type and adding some payload to EAP success you can easily achieve near 1
> roundtrip exchanges. I can forward that analysis in a separate email.
>
> It is not clear whether adding data to EAP success is more severe than the
> changes that EAP-ER is suggesting, to name a few:
>
> 1) adding new codes even though 3748 mandates a discard code>4
> 2) change of authenticator state machine to treat EAP ER Request as a
> response to EAP Identity request. This seems a lot more intrusive on the
> massive scale of existing
 authenticators, than adding data to EAP success
> intended for the peer.
>
> It seems that before fully deciding the EAP code versus EAP type options, it
> is hard to make a judgement on a solution that is based on EAP code. After
> that, there are issues such as identity exchanges that are needed for key
> derivation according to the EMSK draft and it seems that EAP-ER is
> considering those out of band or requires explicit additional signaling.
>
> Finally the other clarification I am seeking is regarding the second
> document, don't we want to specify how the per-authenticator keys are
> derived? It seems that it should be included in the second spec as well.
>
> R,
>
> Madjid
>
> -----Original Message-----
> From: Charles Clancy [mailto:clancy@cs.umd.edu]
> Sent: Saturday, March 31, 2007
 11:58 AM
> To: hokey@ietf.org
> Subject: [HOKEY] consensus call: EAP-ER as HOKEY protocol
>
> HOKEY WG,
>
> The chairs are making a second consensus call request to adopt EAP-ER as
> a WG document to satisfy our re-auth and hand-off deliverables.  It
> would serve as a starting point for development of the HOKEY protocol.
>
> Note that if accepted, it may be split into two WG documents, separating
> the EAP-ER-Bootstrap into a second set of messages that could be
> transported by any service to obtain a USRK or DSUSRK.
>
> Please respond by Friday, April 13.
>

_______________________________________________
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







The fish are biting.

 Get more visitors on your site using Yahoo! Search Marketing.
--0-14202823-1175625058=:56904--


--===============1594234762==
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

--===============1594234762==--




From hokey-bounces@ietf.org Tue Apr 03 14:52: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 1HYo7N-0003K9-FC; Tue, 03 Apr 2007 14:52:33 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HYo7M-0003K1-OM
	for hokey@ietf.org; Tue, 03 Apr 2007 14:52:32 -0400
Received: from numenor.qualcomm.com ([129.46.51.58])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYo7B-0007Fy-NS
	for hokey@ietf.org; Tue, 03 Apr 2007 14:52:32 -0400
Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158])
	by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id
	l33IqFtg020462
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 3 Apr 2007 11:52:15 -0700
Received: from [129.46.78.141] (ldondeti.na.qualcomm.com [129.46.78.141])
	by totoro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l33IqEGS000860
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Tue, 3 Apr 2007 11:52:14 -0700 (PDT)
Message-ID: <4612A25E.3090700@qualcomm.com>
Date: Tue, 03 Apr 2007 11:52:14 -0700
From: Lakshminath Dondeti 
User-Agent: Thunderbird 2.0b2 (Windows/20070116)
MIME-Version: 1.0
To: "M. Vanderveen" 
Subject: Re: [HOKEY] consensus call: EAP-ER as HOKEY protocol
References: <665490.56904.qm@web54406.mail.yahoo.com>
In-Reply-To: <665490.56904.qm@web54406.mail.yahoo.com>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bf422c85703d3d847fb014987125ac48
Cc: Madjid Nakhjiri , 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 for offlist clarification Michaela, the relevant note is from 
Appendix A of 3748 and it says

"In Section 4.2, it has been clarified that Success and Failure
       packets must not contain additional data, and the implementation
       note has been expanded.  A subsection giving requirements on
       processing of success and failure packets has been added."

The keyword being clarified.  It was never allowed.

2284 just as 3748 says EAP Success is of length 4.  What part of that is 
unclear really?

Lakshminath

M. Vanderveen wrote:
> Regarding carrying data on the EAP-Success. Let's not forget that the 
> previous EAP RFC2284 allowed carrying data in the EAP Success. 
> Consequently methods deployed between 1998 and 2004 could have very well 
> already carried data in it. In fact there is relatively wide deployment 
> in Europe of an EAP method that does just that.
>  
> If I recall correctly the reason for banning data in the EAP-Success was 
> because it should be protected, and we did not have a method-independent 
> way to do that.
>  
> An important point I would like to make regards implementation/deployment:
> Folks with experience implementing and maintaining servers (not 
> NASes/BSs) claim that it would be much easier to modify EAP behavior by 
> adding data onto the EAP-Success than by adding new Codes.  That is 
> because adding new methods is something that is WELL-UNDERSTOOD and done 
> frequently. Adding something under the EAP method layer is not.  They 
> fear a lot of implementation complexity and ongoing test efforts with 
> the addition of EAP-ER onto existing EAP server implementations.
>  
>  
>  
> Michaela
> 
> ----- Original Message ----
> From: Avi Lior 
> To: Lakshminath Dondeti ; Madjid Nakhjiri 
> 
> Cc: hokey@ietf.org
> Sent: Tuesday, April 3, 2007 6:47:43 AM
> Subject: RE: [HOKEY] consensus call: EAP-ER as HOKEY protocol
> 
> I for one thinks we should look at allowing us to carry data in EAP 
> success.  In fact, it would be a good idea if we allowed EAP to carry 
> data which is not part of the method in all exchanges. 
> 
> Clearly there is a need to communicate with the Peer before and just 
> after authentication.  There is no other path to the Peer.  EAP should 
> have addressed this.
>  
> We already see this happening in the Request Identity (as in Network 
> Selection and other such usage), in the Repsonse Identity and now in the 
> Success phase.
>  
> We can continue to "hack" EAP but we can also fix it.
>  
> I am not saying EAP-ER is a hack but it is not efficient because it 
> works around the existing EAP semantics but hopefully we could do better.
>  
> Avi Lior Office: +1 613 591-9104 x 6417 Cell : +1 613 796-4183
> 
> 
> ------------------------------------------------------------------------
> *From:* Lakshminath Dondeti
> *Sent:* Mon 4/2/2007 11:13 PM
> *To:* Madjid Nakhjiri
> *Cc:* hokey@ietf.org
> *Subject:* Re: [HOKEY] consensus call: EAP-ER as HOKEY protocol
> 
> Many of the active WG contributors were present at the interim meeting
> and there was a presentation and discussion on how reauthentication
> might work with new EAP types or codes.  The consensus was that
> code-based approach works best and that consensus was subsequently
> verified on the list.
> 
> Well, here we are.  I am also looking forward to seeing your analysis on
> this topic.  Changing the structure of the EAP Success message and also
> the transmission rules for EAP Success are quite drastic changes.  If
> EAP Success needs to be reliably transmitted, authenticator behavior
> would have to change.  Consider the following rules on EAP Success messages:
> 
> "The peer
>     MAY, in the event that an EAP Success is not received, conclude that
>     the EAP Success packet was lost and that authentication concluded
>     successfully."
> 
> "Success and Failure packets MUST NOT
>     contain additional data."
> 
> "Because the Success and Failure packets are not
>     acknowledged, they are not retransmitted by the authenticator, and
>     may be potentially lost.  A peer MUST allow for this circumstance as
>     described in this note. "
> 
> Anyway, I still want to see your analysis of this.
> 
> thanks,
> Lakshminath
> 
> PS:  I understand your concern about EAP Identity Request and we can
> work on other alternatives for it where terminating the EAP state
> machine at the Authenticator and spawning an EAP-ER state machine is
> considered burdensome (there are other ways of looking at this and that
> is written in vidya-eap-er-02).
> 
> Madjid Nakhjiri wrote:
>  > Hi,
>  >
>  > I like to seek a clarification here first.
>  > Have we put the discussion of use of EAP code versus EAP types to bed,
>  > completely satisfied that EAP types will absolutely not solve the 
> problems?
>  >
>  > Given that the Russ only first gave the few of us present in San Jose the
>  > green light to change EAP, I feel that we did not quite discuss the 
> impact
>  > of adding new EAP codes versus other changes to an end.  A simple 
> analysis
>  > shows (I have confirmed this with several EAP experts) that using a 
> new EAP
>  > type and adding some payload to EAP success you can easily achieve near 1
>  > roundtrip exchanges. I can forward that analysis in a separate email.
>  >
>  > It is not clear whether adding data to EAP success is more severe 
> than the
>  > changes that EAP-ER is suggesting, to name a few:
>  >
>  > 1) adding new codes even though 3748 mandates a discard code>4
>  > 2) change of authenticator state machine to treat EAP ER Request as a
>  > response to EAP Identity request. This seems a lot more intrusive on the
>  > massive scale of existing authenticators, than adding data to EAP success
>  > intended for the peer.
>  >
>  > It seems that before fully deciding the EAP code versus EAP type 
> options, it
>  > is hard to make a judgement on a solution that is based on EAP code. 
> After
>  > that, there are issues such as identity exchanges that are needed for key
>  > derivation according to the EMSK draft and it seems that EAP-ER is
>  > considering those out of band or requires explicit additional signaling.
>  >
>  > Finally the other clarification I am seeking is regarding the second
>  > document, don't we want to specify how the per-authenticator keys are
>  > derived? It seems that it should be included in the second spec as well.
>  >
>  > R,
>  >
>  > Madjid
>  >
>  > -----Original Message-----
>  > From: Charles Clancy [mailto:clancy@cs.umd.edu]
>  > Sent: Saturday, March 31, 2007 11:58 AM
>  > To: hokey@ietf.org
>  > Subject: [HOKEY] consensus call: EAP-ER as HOKEY protocol
>  >
>  > HOKEY WG,
>  >
>  > The chairs are making a second consensus call request to adopt EAP-ER as
>  > a WG document to satisfy our re-auth and hand-off deliverables.  It
>  > would serve as a starting point for development of the HOKEY protocol.
>  >
>  > Note that if accepted, it may be split into two WG documents, separating
>  > the EAP-ER-Bootstrap into a second set of messages that could be
>  > transported by any service to obtain a USRK or DSUSRK.
>  >
>  > Please respond by Friday, April 13.
>  >
> 
> _______________________________________________
> 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
> 
> 
> ------------------------------------------------------------------------
> The fish are biting.
> Get more visitors 
>  
> on your site using Yahoo! Search Marketing. < 
> http://us.rd.yahoo.com/evt=49679/*http://searchmarketing.yahoo.com/arp/sponsoredsearch_v2.php?o=US2140&cmp=Yahoo&ctv=Q107Tagline&s=Y&s2=EM&b=50>

_______________________________________________
HOKEY mailing list
HOKEY@ietf.org
https://www1.ietf.org/mailman/listinfo/hokey



From hokey-bounces@ietf.org Tue Apr 03 15:06:29 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HYoKn-0005tO-Dg; Tue, 03 Apr 2007 15:06:25 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HYoKm-0005t5-Lx
	for hokey@ietf.org; Tue, 03 Apr 2007 15:06:24 -0400
Received: from rtp-iport-2.cisco.com ([64.102.122.149])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYoKl-0001rO-3y
	for hokey@ietf.org; Tue, 03 Apr 2007 15:06:24 -0400
Received: from rtp-dkim-1.cisco.com ([64.102.121.158])
	by rtp-iport-2.cisco.com with ESMTP; 03 Apr 2007 15:06:23 -0400
Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12])
	by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l33J6Mmx012014; 
	Tue, 3 Apr 2007 15:06:22 -0400
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com
	[64.102.31.12])
	by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l33J6IGd010947; 
	Tue, 3 Apr 2007 19:06:18 GMT
Received: from xmb-rtp-212.amer.cisco.com ([64.102.31.111]) by
	xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 3 Apr 2007 15:06:17 -0400
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] consensus call: EAP-ER as HOKEY protocol
Date: Tue, 3 Apr 2007 15:06:16 -0400
Message-ID: <9958B444368E884DBB215F3FEF36F5B7041F9D64@xmb-rtp-212.amer.cisco.com>
In-Reply-To: <461289A3.3000901@qualcomm.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [HOKEY] consensus call: EAP-ER as HOKEY protocol
Thread-Index: Acd2Eo8Jp6qnVT1/QuCv4YtraK6otwADVuVw
References: <002701c7757c$ea5d0e30$2f01a8c0@china.huawei.com>,
	<4611C658.7050603@qualcomm.com>
	<461289A3.3000901@qualcomm.com>
From: "Hao Zhou \(hzhou\)" 
To: "Lakshminath Dondeti" ,
	"Avi Lior" 
X-OriginalArrivalTime: 03 Apr 2007 19:06:17.0880 (UTC)
	FILETIME=[2880A180:01C77623]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=11071; t=1175627182;
	x=1176491182; c=relaxed/simple; s=rtpdkim1001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=hzhou@cisco.com;
	z=From:=20=22Hao=20Zhou=20\(hzhou\)=22=20
	|Subject:=20RE=3A=20[HOKEY]=20consensus=20call=3A=20EAP-ER=20as=20HOKEY=2
	0protocol |Sender:=20
	|To:=20=22Lakshminath=20Dondeti=22=20,
	=0A=20=20=20
	=20=20=20=20=20=22Avi=20Lior=22=20;
	bh=BOezyn6fs+QL1ZJqi8AcSAj9lvZ5epNbXmj6hS7RLWo=;
	b=WFV3m6HLgA5PvYVDguhCINEWGFlCqUHlQ8rTltWCg8IORWPFblz8UZ+aaE6YX51ctU6Bzr8K
	j1WPKM1GAtRxemfUNYGhH9Hdg0KT2wOY1FSu8YHMIBgKuO9pM1P+gHOW;
Authentication-Results: rtp-dkim-1; header.From=hzhou@cisco.com; dkim=pass (
	sig from cisco.com/rtpdkim1001 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f8184d7d4d1b986353eb58ea3e887935
Cc: 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

I have been soliciting with a few others about the idea of using
existing EAP codes to do HOAKEY, instead of creating new EAP codes. The
idea is roughly like this:

1. NAS still sends out EAP-Identity request, with something in the
request to indicate HOAKEY support. Something similar to how network
selection RFC utilizing the space after NULL character. The extra data
would include HOAKEY capability, as well as any other information
needed, e.g., domain ID, etc.

2. Client send back normal EAP-Identity Response, piggybacking any
HOAKEY data needed, e.g., agreement to do HOAKEY and any HOAKEY keying
materials.

3. If the NAS determine that client wants to do HOAKEY, then it forwards
the HOAKEY data to the HOAKEY server. Otherwise, it starts the normal
full EAP authentication.

4. After HOAKEY server sends back the server data, NAS sends EAP-Success
with additional HOAKEY data, which allows the client to verify and
authenticate the NAS.

The benefits of using this approach are:

1. Maximum backward compatibility with legacy NAS and client. Existing
client should work with new HOAKEY NAS and existing NAS would work with
new HOAKEY capable client.
2. Less changes on the EAP lower layer on both the client and NAS. The
only change is to allow additional data to be piggy-backed on
EAP-Success, vs. current EAP-ER proposal of two new EAP codes.
3. HOAKEY capability negotiation and domain ID transmission is also
included this way, instead of being mandated to be added to lower layer.
The lower layer is probably harder to change.
4. I don't think the half round trip for EAP-Identity request and
response would hurt performance too much and critical, as it is local
between the client and NAS. Modifying the lower layer to allow client
initiating exchange might be too much for some lower layer.=20
5. Even if piggybacking data on EAP-Success is determined to be
impossible and we need a new EAP code, we should still just create a
single new code for the EAP-Success with optional data, this way, only
the new HOAKEY capable NAS and client needs to understand and support
it. I would recommend still using the EAP-Identity request-response
exchange for the first part. The goal is to minimize changes to EAP flow
and state machine and EAP lower layer as little as possible.=20

> -----Original Message-----
> From: Lakshminath Dondeti [mailto:ldondeti@qualcomm.com]=20
> Sent: Tuesday, April 03, 2007 1:07 PM
> To: Avi Lior
> Cc: hokey@ietf.org; Madjid Nakhjiri
> Subject: Re: [HOKEY] consensus call: EAP-ER as HOKEY protocol
>=20
> Hi Avi,
>=20
> I find some of your arguments counter-intuitive and so would=20
> like to understand your line of thinking on this topic. =20
> Modifications to a protocol to my knowledge would be hacks=20
> and extensions are well, extensions.  For instance, the EAP=20
> Request/Identity message suspension in EAP-ER, as much as I=20
> would like to defend it, is somewhat of a hack.=20
>   It is the cleanest Vidya and I could come up with in the=20
> sense that the message itself is not modified, but we need=20
> something like it to make sure that the L2 connection is not=20
> closed if the retransmission time expires.  Perhaps the wider=20
> community might find a better approach.
>=20
> Next, some notes on 4284 since that has come up here:
>=20
> 3748 says "Some EAP implementations piggy-back various=20
> options into the
>        Identity Request after a NUL-character. "
>=20
> 4284 uses that provision.  In any event, 4284 is somewhat of=20
> a hack and is an informational RFC for the purposes of 3GPP's use.
>=20
> Please see inline for some questions:
>=20
> Avi Lior wrote:
> > I for one thinks we should look at allowing us to carry data in EAP=20
> > success.  In fact, it would be a good idea if we allowed=20
> EAP to carry=20
> > data which is not part of the method in all exchanges.
>=20
> If the data is not part of the method, which entity needs to=20
> send such data and how is it protected?
>=20
> >=20
> > Clearly there is a need to communicate with the Peer before=20
> and just=20
> > after authentication.  There is no other path to the Peer. =20
> EAP should=20
> > have addressed this.
>=20
> Again which entity needs to communicate with the Peer?
>=20
> > =20
> > We already see this happening in the Request Identity (as=20
> in Network=20
> > Selection and other such usage), in the Repsonse Identity=20
> and now in=20
> > the Success phase.
> > =20
> > We can continue to "hack" EAP but we can also fix it.
>=20
> I am lost here, so please help me out :).  The network=20
> selection solution of 4284 is a hack IMO.  If you are saying=20
> we should revise 3748, I might agree with you in principle. =20
> But, practically speaking that is not happening anytime soon.
>=20
> Next, RFC 3748 has clear guidance on allocating new packet=20
> codes in Section 6.1.  Defining new codes is a natural way of=20
> extending EAP.  If the goal is backward compatibility, adding=20
> stuff to EAP Success doesn't help either.  As I have noted=20
> before, EAP Success packets are not retransmitted by=20
> authenticators and that would have to change if we add=20
> anything crucial to Success packets.
>=20
> I appreciate any clarifications you might provide to help me=20
> understand your point of view here.  Thanks.
>=20
> regards,
> Lakshminath
>=20
> > =20
> > I am not saying EAP-ER is a hack but it is not efficient because it=20
> > works around the existing EAP semantics but hopefully we=20
> could do better.
> > =20
> > Avi Lior Office: +1 613 591-9104 x 6417 Cell : +1 613 796-4183
> >=20
> >=20
> >=20
> ----------------------------------------------------------------------
> > --
> > *From:* Lakshminath Dondeti
> > *Sent:* Mon 4/2/2007 11:13 PM
> > *To:* Madjid Nakhjiri
> > *Cc:* hokey@ietf.org
> > *Subject:* Re: [HOKEY] consensus call: EAP-ER as HOKEY protocol
> >=20
> > Many of the active WG contributors were present at the=20
> interim meeting=20
> > and there was a presentation and discussion on how reauthentication=20
> > might work with new EAP types or codes.  The consensus was that=20
> > code-based approach works best and that consensus was subsequently=20
> > verified on the list.
> >=20
> > Well, here we are.  I am also looking forward to seeing=20
> your analysis=20
> > on this topic.  Changing the structure of the EAP Success=20
> message and=20
> > also the transmission rules for EAP Success are quite=20
> drastic changes. =20
> > If EAP Success needs to be reliably transmitted, authenticator=20
> > behavior would have to change.  Consider the following=20
> rules on EAP Success messages:
> >=20
> > "The peer
> >     MAY, in the event that an EAP Success is not received,=20
> conclude that
> >     the EAP Success packet was lost and that authentication=20
> concluded
> >     successfully."
> >=20
> > "Success and Failure packets MUST NOT
> >     contain additional data."
> >=20
> > "Because the Success and Failure packets are not
> >     acknowledged, they are not retransmitted by the=20
> authenticator, and
> >     may be potentially lost.  A peer MUST allow for this=20
> circumstance as
> >     described in this note. "
> >=20
> > Anyway, I still want to see your analysis of this.
> >=20
> > thanks,
> > Lakshminath
> >=20
> > PS:  I understand your concern about EAP Identity Request=20
> and we can=20
> > work on other alternatives for it where terminating the EAP state=20
> > machine at the Authenticator and spawning an EAP-ER state=20
> machine is=20
> > considered burdensome (there are other ways of looking at this and=20
> > that is written in vidya-eap-er-02).
> >=20
> > Madjid Nakhjiri wrote:
> >  > Hi,
> >  >
> >  > I like to seek a clarification here first.
> >  > Have we put the discussion of use of EAP code versus EAP=20
> types to=20
> > bed,  > completely satisfied that EAP types will absolutely=20
> not solve=20
> > the problems?
> >  >
> >  > Given that the Russ only first gave the few of us present in San=20
> > Jose the  > green light to change EAP, I feel that we did not quite=20
> > discuss the impact  > of adding new EAP codes versus other=20
> changes to=20
> > an end.  A simple analysis  > shows (I have confirmed this with=20
> > several EAP experts) that using a new EAP  > type and adding some=20
> > payload to EAP success you can easily achieve near 1  > roundtrip=20
> > exchanges. I can forward that analysis in a separate email.
> >  >
> >  > It is not clear whether adding data to EAP success is=20
> more severe=20
> > than the  > changes that EAP-ER is suggesting, to name a few:
> >  >
> >  > 1) adding new codes even though 3748 mandates a discard=20
> code>4  >=20
> > 2) change of authenticator state machine to treat EAP ER=20
> Request as a =20
> > > response to EAP Identity request. This seems a lot more=20
> intrusive on=20
> > the  > massive scale of existing authenticators, than=20
> adding data to=20
> > EAP success  > intended for the peer.
> >  >
> >  > It seems that before fully deciding the EAP code versus EAP type=20
> > options, it  > is hard to make a judgement on a solution=20
> that is based=20
> > on EAP code.
> > After
> >  > that, there are issues such as identity exchanges that=20
> are needed=20
> > for key  > derivation according to the EMSK draft and it seems that=20
> > EAP-ER is  > considering those out of band or requires=20
> explicit additional signaling.
> >  >
> >  > Finally the other clarification I am seeking is regarding the=20
> > second  > document, don't we want to specify how the=20
> per-authenticator=20
> > keys are  > derived? It seems that it should be included in=20
> the second spec as well.
> >  >
> >  > R,
> >  >
> >  > Madjid
> >  >
> >  > -----Original Message-----
> >  > From: Charles Clancy [mailto:clancy@cs.umd.edu]  > Sent:=20
> Saturday,=20
> > March 31, 2007 11:58 AM  > To: hokey@ietf.org  > Subject: [HOKEY]=20
> > consensus call: EAP-ER as HOKEY protocol  >  > HOKEY WG,  >  > The=20
> > chairs are making a second consensus call request to adopt=20
> EAP-ER as =20
> > > a WG document to satisfy our re-auth and hand-off=20
> deliverables.  It =20
> > > would serve as a starting point for development of the=20
> HOKEY protocol.
> >  >
> >  > Note that if accepted, it may be split into two WG documents,=20
> > separating  > the EAP-ER-Bootstrap into a second set of=20
> messages that=20
> > could be  > transported by any service to obtain a USRK or DSUSRK.
> >  >
> >  > Please respond by Friday, April 13.
> >  >
> >=20
> > _______________________________________________
> > HOKEY mailing list
> > HOKEY@ietf.org
> > https://www1.ietf.org/mailman/listinfo/hokey
> >=20
>=20
> _______________________________________________
> HOKEY mailing list
> HOKEY@ietf.org
> https://www1.ietf.org/mailman/listinfo/hokey
>=20

_______________________________________________
HOKEY mailing list
HOKEY@ietf.org
https://www1.ietf.org/mailman/listinfo/hokey



From hokey-bounces@ietf.org Tue Apr 03 16:15: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 1HYpPs-0005ll-Fl; Tue, 03 Apr 2007 16:15:44 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HYpPq-0005lV-UL
	for hokey@ietf.org; Tue, 03 Apr 2007 16:15:42 -0400
Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYpPp-0000SW-Ga
	for hokey@ietf.org; Tue, 03 Apr 2007 16:15:42 -0400
Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145])
	by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id
	l33KFNg7024601; Tue, 3 Apr 2007 23:15:33 +0300
Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by
	esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 3 Apr 2007 23:15:22 +0300
Received: from daebe103.NOE.Nokia.com ([10.241.35.24]) by
	daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 3 Apr 2007 15:15:09 -0500
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [HOKEY] consensus call: EAP-ER as HOKEY protocol
Date: Tue, 3 Apr 2007 15:15:08 -0500
Message-ID: <2198383E1141814486F0B881B3260CF5E07CFA@daebe103.NOE.Nokia.com>
In-Reply-To: <9958B444368E884DBB215F3FEF36F5B7041F9D64@xmb-rtp-212.amer.cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [HOKEY] consensus call: EAP-ER as HOKEY protocol
Thread-Index: Acd2Eo8Jp6qnVT1/QuCv4YtraK6otwADVuVwAAIpPEA=
References: <002701c7757c$ea5d0e30$2f01a8c0@china.huawei.com>,
	<4611C658.7050603@qualcomm.com><461289A3.3000901@qualcomm.com>
	<9958B444368E884DBB215F3FEF36F5B7041F9D64@xmb-rtp-212.amer.cisco.com>
From: 
To: , , 
X-OriginalArrivalTime: 03 Apr 2007 20:15:09.0499 (UTC)
	FILETIME=[C723A8B0:01C7762C]
X-eXpurgate-Category: 1/0
X-eXpurgate-ID: 149371::070403231533-5FCB9BB0-5DC91C63/0-0/0-1
X-Nokia-AV: Clean
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a
Cc: 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

=20

-----Original Message-----
From: ext Hao Zhou (hzhou) [mailto:hzhou@cisco.com]=20
Sent: Tuesday, April 03, 2007 3:06 PM
To: Lakshminath Dondeti; Avi Lior
Cc: hokey@ietf.org; Madjid Nakhjiri
Subject: RE: [HOKEY] consensus call: EAP-ER as HOKEY protocol

Snip...

>3. HOAKEY capability negotiation and domain ID transmission is also
included this way, instead of >being mandated to be added to lower
layer.
>The lower layer is probably harder to change.

Within IEEE 802.21 there is a mechanism to advertise information such as
network capabilities or domains either before or after authentication.
This method was adopted in 802.16g and is in process within 802.11 in
TGu.

Currently any information that is passed before authentication through
the point-of-attachment is unsecure.

Best Regards,
Michael


_______________________________________________
HOKEY mailing list
HOKEY@ietf.org
https://www1.ietf.org/mailman/listinfo/hokey



From hokey-bounces@ietf.org Tue Apr 03 16:57:28 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HYq3y-0003iu-AY; Tue, 03 Apr 2007 16:57:10 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HYq3v-0003if-KJ
	for hokey@ietf.org; Tue, 03 Apr 2007 16:57:07 -0400
Received: from ithilien.qualcomm.com ([129.46.51.59])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYq3n-00038j-1X
	for hokey@ietf.org; Tue, 03 Apr 2007 16:57:07 -0400
Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157])
	by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id
	l33Kunmm010296
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 3 Apr 2007 13:56:49 -0700
Received: from [129.46.78.141] (ldondeti.na.qualcomm.com [129.46.78.141])
	by hamtaro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id
	l33KumMJ020796
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Tue, 3 Apr 2007 13:56:48 -0700 (PDT)
Message-ID: <4612BF90.3080901@qualcomm.com>
Date: Tue, 03 Apr 2007 13:56:48 -0700
From: Lakshminath Dondeti 
User-Agent: Thunderbird 2.0b2 (Windows/20070116)
MIME-Version: 1.0
To: "Hao Zhou (hzhou)" 
Subject: Re: [HOKEY] consensus call: EAP-ER as HOKEY protocol
References: <002701c7757c$ea5d0e30$2f01a8c0@china.huawei.com>,
	<4611C658.7050603@qualcomm.com>
	<461289A3.3000901@qualcomm.com>
	<9958B444368E884DBB215F3FEF36F5B7041F9D64@xmb-rtp-212.amer.cisco.com>
In-Reply-To: <9958B444368E884DBB215F3FEF36F5B7041F9D64@xmb-rtp-212.amer.cisco.com>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7118f330e2af0a096ba071c5e99ca10e
Cc: Madjid Nakhjiri , 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 Hao,

Thanks for proposing the detailed solution.  On a first look, it might 
seem to offer the benefits you list, but a closer look reveals serious 
problems:

1. EAP-Request/Identity does have a provision to carry stuff after the 
NUL character.  There seems to be contention by various use cases for 
that space.  That is a problem.  More specifically, 4284 cannot be used 
with reauthentication.

2. EAP-Response/Identity does not have a provision to carry additional 
data.  That is a change to 3748's text.

3. EAP Success retransmission semantics need to change.  This means 
changes to the authenticator.  So, backward compatibility arguments are 
not applicable.

Bottomline is the authenticator behavior is going to be changed one way 
or another.  We reviewed all of this at the interim meeting.  As to one 
new code vs. two, one of the older versions of EAP-ER did have one code. 
  The current version is a result of the discussions at the interim 
meeting.  I think the minutes covered the reasoning.

As to minimizing lower layer changes and being able to signal HOKEY 
capability in EAP, let's talk about that separately.

My goals here are to minimize modifications to the EAP state machine. 
Additions are always better and cleaner than modifying the protocol 
behavior.  Suppose some other use case comes along in the future and 
modifies EAP in a different way.  What happens then?

thanks,
Lakshminath

Hao Zhou (hzhou) wrote:
> I have been soliciting with a few others about the idea of using
> existing EAP codes to do HOAKEY, instead of creating new EAP codes. The
> idea is roughly like this:
> 
> 1. NAS still sends out EAP-Identity request, with something in the
> request to indicate HOAKEY support. Something similar to how network
> selection RFC utilizing the space after NULL character. The extra data
> would include HOAKEY capability, as well as any other information
> needed, e.g., domain ID, etc.
> 
> 2. Client send back normal EAP-Identity Response, piggybacking any
> HOAKEY data needed, e.g., agreement to do HOAKEY and any HOAKEY keying
> materials.
> 
> 3. If the NAS determine that client wants to do HOAKEY, then it forwards
> the HOAKEY data to the HOAKEY server. Otherwise, it starts the normal
> full EAP authentication.
> 
> 4. After HOAKEY server sends back the server data, NAS sends EAP-Success
> with additional HOAKEY data, which allows the client to verify and
> authenticate the NAS.
> 
> The benefits of using this approach are:
> 
> 1. Maximum backward compatibility with legacy NAS and client. Existing
> client should work with new HOAKEY NAS and existing NAS would work with
> new HOAKEY capable client.
> 2. Less changes on the EAP lower layer on both the client and NAS. The
> only change is to allow additional data to be piggy-backed on
> EAP-Success, vs. current EAP-ER proposal of two new EAP codes.
> 3. HOAKEY capability negotiation and domain ID transmission is also
> included this way, instead of being mandated to be added to lower layer.
> The lower layer is probably harder to change.
> 4. I don't think the half round trip for EAP-Identity request and
> response would hurt performance too much and critical, as it is local
> between the client and NAS. Modifying the lower layer to allow client
> initiating exchange might be too much for some lower layer. 
> 5. Even if piggybacking data on EAP-Success is determined to be
> impossible and we need a new EAP code, we should still just create a
> single new code for the EAP-Success with optional data, this way, only
> the new HOAKEY capable NAS and client needs to understand and support
> it. I would recommend still using the EAP-Identity request-response
> exchange for the first part. The goal is to minimize changes to EAP flow
> and state machine and EAP lower layer as little as possible. 
> 
>> -----Original Message-----
>> From: Lakshminath Dondeti [mailto:ldondeti@qualcomm.com] 
>> Sent: Tuesday, April 03, 2007 1:07 PM
>> To: Avi Lior
>> Cc: hokey@ietf.org; Madjid Nakhjiri
>> Subject: Re: [HOKEY] consensus call: EAP-ER as HOKEY protocol
>>
>> Hi Avi,
>>
>> I find some of your arguments counter-intuitive and so would 
>> like to understand your line of thinking on this topic.  
>> Modifications to a protocol to my knowledge would be hacks 
>> and extensions are well, extensions.  For instance, the EAP 
>> Request/Identity message suspension in EAP-ER, as much as I 
>> would like to defend it, is somewhat of a hack. 
>>   It is the cleanest Vidya and I could come up with in the 
>> sense that the message itself is not modified, but we need 
>> something like it to make sure that the L2 connection is not 
>> closed if the retransmission time expires.  Perhaps the wider 
>> community might find a better approach.
>>
>> Next, some notes on 4284 since that has come up here:
>>
>> 3748 says "Some EAP implementations piggy-back various 
>> options into the
>>        Identity Request after a NUL-character. "
>>
>> 4284 uses that provision.  In any event, 4284 is somewhat of 
>> a hack and is an informational RFC for the purposes of 3GPP's use.
>>
>> Please see inline for some questions:
>>
>> Avi Lior wrote:
>>> I for one thinks we should look at allowing us to carry data in EAP 
>>> success.  In fact, it would be a good idea if we allowed 
>> EAP to carry 
>>> data which is not part of the method in all exchanges.
>> If the data is not part of the method, which entity needs to 
>> send such data and how is it protected?
>>
>>> Clearly there is a need to communicate with the Peer before 
>> and just 
>>> after authentication.  There is no other path to the Peer.  
>> EAP should 
>>> have addressed this.
>> Again which entity needs to communicate with the Peer?
>>
>>>  
>>> We already see this happening in the Request Identity (as 
>> in Network 
>>> Selection and other such usage), in the Repsonse Identity 
>> and now in 
>>> the Success phase.
>>>  
>>> We can continue to "hack" EAP but we can also fix it.
>> I am lost here, so please help me out :).  The network 
>> selection solution of 4284 is a hack IMO.  If you are saying 
>> we should revise 3748, I might agree with you in principle.  
>> But, practically speaking that is not happening anytime soon.
>>
>> Next, RFC 3748 has clear guidance on allocating new packet 
>> codes in Section 6.1.  Defining new codes is a natural way of 
>> extending EAP.  If the goal is backward compatibility, adding 
>> stuff to EAP Success doesn't help either.  As I have noted 
>> before, EAP Success packets are not retransmitted by 
>> authenticators and that would have to change if we add 
>> anything crucial to Success packets.
>>
>> I appreciate any clarifications you might provide to help me 
>> understand your point of view here.  Thanks.
>>
>> regards,
>> Lakshminath
>>
>>>  
>>> I am not saying EAP-ER is a hack but it is not efficient because it 
>>> works around the existing EAP semantics but hopefully we 
>> could do better.
>>>  
>>> Avi Lior Office: +1 613 591-9104 x 6417 Cell : +1 613 796-4183
>>>
>>>
>>>
>> ----------------------------------------------------------------------
>>> --
>>> *From:* Lakshminath Dondeti
>>> *Sent:* Mon 4/2/2007 11:13 PM
>>> *To:* Madjid Nakhjiri
>>> *Cc:* hokey@ietf.org
>>> *Subject:* Re: [HOKEY] consensus call: EAP-ER as HOKEY protocol
>>>
>>> Many of the active WG contributors were present at the 
>> interim meeting 
>>> and there was a presentation and discussion on how reauthentication 
>>> might work with new EAP types or codes.  The consensus was that 
>>> code-based approach works best and that consensus was subsequently 
>>> verified on the list.
>>>
>>> Well, here we are.  I am also looking forward to seeing 
>> your analysis 
>>> on this topic.  Changing the structure of the EAP Success 
>> message and 
>>> also the transmission rules for EAP Success are quite 
>> drastic changes.  
>>> If EAP Success needs to be reliably transmitted, authenticator 
>>> behavior would have to change.  Consider the following 
>> rules on EAP Success messages:
>>> "The peer
>>>     MAY, in the event that an EAP Success is not received, 
>> conclude that
>>>     the EAP Success packet was lost and that authentication 
>> concluded
>>>     successfully."
>>>
>>> "Success and Failure packets MUST NOT
>>>     contain additional data."
>>>
>>> "Because the Success and Failure packets are not
>>>     acknowledged, they are not retransmitted by the 
>> authenticator, and
>>>     may be potentially lost.  A peer MUST allow for this 
>> circumstance as
>>>     described in this note. "
>>>
>>> Anyway, I still want to see your analysis of this.
>>>
>>> thanks,
>>> Lakshminath
>>>
>>> PS:  I understand your concern about EAP Identity Request 
>> and we can 
>>> work on other alternatives for it where terminating the EAP state 
>>> machine at the Authenticator and spawning an EAP-ER state 
>> machine is 
>>> considered burdensome (there are other ways of looking at this and 
>>> that is written in vidya-eap-er-02).
>>>
>>> Madjid Nakhjiri wrote:
>>>  > Hi,
>>>  >
>>>  > I like to seek a clarification here first.
>>>  > Have we put the discussion of use of EAP code versus EAP 
>> types to 
>>> bed,  > completely satisfied that EAP types will absolutely 
>> not solve 
>>> the problems?
>>>  >
>>>  > Given that the Russ only first gave the few of us present in San 
>>> Jose the  > green light to change EAP, I feel that we did not quite 
>>> discuss the impact  > of adding new EAP codes versus other 
>> changes to 
>>> an end.  A simple analysis  > shows (I have confirmed this with 
>>> several EAP experts) that using a new EAP  > type and adding some 
>>> payload to EAP success you can easily achieve near 1  > roundtrip 
>>> exchanges. I can forward that analysis in a separate email.
>>>  >
>>>  > It is not clear whether adding data to EAP success is 
>> more severe 
>>> than the  > changes that EAP-ER is suggesting, to name a few:
>>>  >
>>>  > 1) adding new codes even though 3748 mandates a discard 
>> code>4  > 
>>> 2) change of authenticator state machine to treat EAP ER 
>> Request as a  
>>>> response to EAP Identity request. This seems a lot more 
>> intrusive on 
>>> the  > massive scale of existing authenticators, than 
>> adding data to 
>>> EAP success  > intended for the peer.
>>>  >
>>>  > It seems that before fully deciding the EAP code versus EAP type 
>>> options, it  > is hard to make a judgement on a solution 
>> that is based 
>>> on EAP code.
>>> After
>>>  > that, there are issues such as identity exchanges that 
>> are needed 
>>> for key  > derivation according to the EMSK draft and it seems that 
>>> EAP-ER is  > considering those out of band or requires 
>> explicit additional signaling.
>>>  >
>>>  > Finally the other clarification I am seeking is regarding the 
>>> second  > document, don't we want to specify how the 
>> per-authenticator 
>>> keys are  > derived? It seems that it should be included in 
>> the second spec as well.
>>>  >
>>>  > R,
>>>  >
>>>  > Madjid
>>>  >
>>>  > -----Original Message-----
>>>  > From: Charles Clancy [mailto:clancy@cs.umd.edu]  > Sent: 
>> Saturday, 
>>> March 31, 2007 11:58 AM  > To: hokey@ietf.org  > Subject: [HOKEY] 
>>> consensus call: EAP-ER as HOKEY protocol  >  > HOKEY WG,  >  > The 
>>> chairs are making a second consensus call request to adopt 
>> EAP-ER as  
>>>> a WG document to satisfy our re-auth and hand-off 
>> deliverables.  It  
>>>> would serve as a starting point for development of the 
>> HOKEY protocol.
>>>  >
>>>  > Note that if accepted, it may be split into two WG documents, 
>>> separating  > the EAP-ER-Bootstrap into a second set of 
>> messages that 
>>> could be  > transported by any service to obtain a USRK or DSUSRK.
>>>  >
>>>  > Please respond by Friday, April 13.
>>>  >
>>>
>>> _______________________________________________
>>> 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 Tue Apr 03 19:09:28 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HYs7w-0002BR-0f; Tue, 03 Apr 2007 19:09:24 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HYs7v-0002BM-3A
	for hokey@ietf.org; Tue, 03 Apr 2007 19:09:23 -0400
Received: from bws14.bridgewatersystems.com ([216.113.7.14])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYs7t-0001qi-Pc
	for hokey@ietf.org; Tue, 03 Apr 2007 19:09:23 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [HOKEY] consensus call: EAP-ER as HOKEY protocol
Date: Tue, 3 Apr 2007 19:09:40 -0400
Message-ID: 
In-Reply-To: <4612BF90.3080901@qualcomm.com>
References: <002701c7757c$ea5d0e30$2f01a8c0@china.huawei.com>,
	<4611C658.7050603@qualcomm.com>
	<461289A3.3000901@qualcomm.com>
	<9958B444368E884DBB215F3FEF36F5B7041F9D64@xmb-rtp-212.amer.cisco.com>
	<4612BF90.3080901@qualcomm.com>
From: "Avi Lior" 
To: "Lakshminath Dondeti" ,
	"Hao Zhou \(hzhou\)" 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad
Cc: 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

See inline:=20

Snip...

2. EAP-Response/Identity does not have a provision to carry additional
data.  That is a change to 3748's text.

[Avi] True but in reality the extra data is carried in the NAI.  That is
another hack that is commonly used.  This comes in all forms:
EAP-AKA uses it to signal fast-reauthentication; we see examples of this
for service selection; and the list goes on and on.



_______________________________________________
HOKEY mailing list
HOKEY@ietf.org
https://www1.ietf.org/mailman/listinfo/hokey



From hokey-bounces@ietf.org Tue Apr 03 20:31: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 1HYtPA-0001Y0-VN; Tue, 03 Apr 2007 20:31:16 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HYtP9-0001Xq-SV
	for hokey@ietf.org; Tue, 03 Apr 2007 20:31:15 -0400
Received: from ithilien.qualcomm.com ([129.46.51.59])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYtP6-0001mA-Ec
	for hokey@ietf.org; Tue, 03 Apr 2007 20:31:15 -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
	l340V7LS003728
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 3 Apr 2007 17:31:07 -0700
Received: from [129.46.78.141] (ldondeti.na.qualcomm.com [129.46.78.141])
	by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id
	l340V60Z016562
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Tue, 3 Apr 2007 17:31:07 -0700
Message-ID: <4612F1CA.7090805@qualcomm.com>
Date: Tue, 03 Apr 2007 17:31:06 -0700
From: Lakshminath Dondeti 
User-Agent: Thunderbird 2.0b2 (Windows/20070116)
MIME-Version: 1.0
To: Avi Lior 
Subject: Re: [HOKEY] consensus call: EAP-ER as HOKEY protocol
References: <002701c7757c$ea5d0e30$2f01a8c0@china.huawei.com>,
	<4611C658.7050603@qualcomm.com>
	<461289A3.3000901@qualcomm.com>
	<9958B444368E884DBB215F3FEF36F5B7041F9D64@xmb-rtp-212.amer.cisco.com>
	<4612BF90.3080901@qualcomm.com>
	
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a
Cc: 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

Avi Lior wrote:
> See inline: 
> 
> Snip...
> 
> 2. EAP-Response/Identity does not have a provision to carry additional
> data.  That is a change to 3748's text.
> 
> [Avi] True but in reality the extra data is carried in the NAI.  That is
> another hack that is commonly used.  This comes in all forms:
> EAP-AKA uses it to signal fast-reauthentication; 

Are you referring to the fast re-authentication identity?  If so, that 
is not too different from the permanent identity or the pseudonym 
identity.  At least I don't count that as "extra" data.  It is the 
identity that allows for routing and identifying the re-auth 
"credential" (or state) and so serves the same purpose as the NAI.

>we see examples of this
> for service selection; and the list goes on and on.

Could you point me to this use case of service selection?  Is it 
additional data after the "identity"?  Which entity parses it and how?

thanks,
Lakshminath

> 
> 
> 

_______________________________________________
HOKEY mailing list
HOKEY@ietf.org
https://www1.ietf.org/mailman/listinfo/hokey



From hokey-bounces@ietf.org Tue Apr 03 21:26: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 1HYuGL-0005oI-LV; Tue, 03 Apr 2007 21:26:13 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HYuGK-0005jv-3u
	for hokey@ietf.org; Tue, 03 Apr 2007 21:26:12 -0400
Received: from numenor.qualcomm.com ([129.46.51.58])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYuGB-00071a-Fu
	for hokey@ietf.org; Tue, 03 Apr 2007 21:26:12 -0400
Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158])
	by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id
	l341PsB0031639
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 3 Apr 2007 18:25:55 -0700
Received: from SANEXCAS02.na.qualcomm.com (sanexcas02.qualcomm.com
	[172.30.36.176])
	by totoro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l341PrQJ021802;
	Tue, 3 Apr 2007 18:25:54 -0700 (PDT)
Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by
	SANEXCAS02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 3 Apr 2007 18:25:53 -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
Subject: RE: [HOKEY] consensus call: key distribution security requirement
Date: Tue, 3 Apr 2007 18:25:52 -0700
Message-ID: 
In-Reply-To: <460EB36E.5010604@cs.umd.edu>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [HOKEY] consensus call: key distribution security requirement
Thread-Index: AcdzyRp11KSpHAQXTNmwLPmQfTvBugCjXtDw
References: <460EB36E.5010604@cs.umd.edu>
From: "Narayanan, Vidya" 
To: "Charles Clancy" , 
X-OriginalArrivalTime: 04 Apr 2007 01:25:53.0783 (UTC)
	FILETIME=[2FFFA070:01C77658]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4
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

I'm barely caught up on all the email after having been on vacation
until now, so, pardon me if I'm bringing up stuff that's already been
discussed here.=20

I share some of Glen's concerns about "requiring" peer consent and a
3-party protocol and about how practically deployable that is. In my
conversations with Dan in Prague, it seemed like we were on the same
page about including channel binding information in the HOKEY protocol
between the peer and server. I think such channel binding information
must be optional and not required. In some systems, there are no adverse
effects of distribution of key material without explicit peer consent
and there is no reason to place upper layer identity advertisement
requirements on the lower layers for such systems. In some other
systems, it may be a good idea to do so and having the capability to do
that in the protocol would be useful there.=20

To specifically answer your question, I don't believe we need to update
the problem statement. It already captures the channel binding stuff and
the explicit data that the peer and authenticator may include is one way
of providing channel binding.=20

Vidya

> -----Original Message-----
> From: Charles Clancy [mailto:clancy@cs.umd.edu]=20
> Sent: Saturday, March 31, 2007 12:16 PM
> To: hokey@ietf.org
> Subject: [HOKEY] consensus call: key distribution security requirement
>=20
> HOKEY WG,
>=20
> The 3-party protocol proposal at IETF 68 listed a variety of=20
> protocol requirements, some of which went beyond those=20
> currently specified in the problem statements draft.  The=20
> main extension was a requirement for stronger key=20
> distribution security.
>=20
> Discussion: The problem statements document currently=20
> requires channel bindings to allow clients to authenticate=20
> the network to which they are connecting, and prevent the=20
> lying NAS problem.  However one possible implementation of=20
> channel bindings would allow keys to be distributed prior to=20
> the network being authenticated by the peer.  While the peer=20
> may decide to not use a network after it's validated its=20
> identity, network entities could retain the keying material. =20
> There has been much debate on the list as to whether or not=20
> network entities could maliciously use this keying material,=20
> and the intent here is to not rehash all that discussion.
>=20
> Question: Should additional text be added to the problem=20
> statement draft
>   to require peer authorization for distributing keying material?
>=20
> Protocol Implications: If "yes" then a 3-party protocol would=20
> be need, and would require L2 advertisement of the NAS-ID and=20
> local AAA domain name.  If "no" then channel bindings where=20
> identities are hashed into the key derivation would be sufficient.
>=20
> --
> t. charles clancy, ph.d.  <>  tcc@umd.edu  <>  www.cs.umd.edu/~clancy
>=20
>=20
> _______________________________________________
> HOKEY mailing list
> HOKEY@ietf.org
> https://www1.ietf.org/mailman/listinfo/hokey
>=20

_______________________________________________
HOKEY mailing list
HOKEY@ietf.org
https://www1.ietf.org/mailman/listinfo/hokey



From hokey-bounces@ietf.org Tue Apr 03 21:53: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 1HYuhC-0008EZ-0C; Tue, 03 Apr 2007 21:53:58 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HYuhA-0008DP-7o
	for hokey@ietf.org; Tue, 03 Apr 2007 21:53:56 -0400
Received: from numenor.qualcomm.com ([129.46.51.58])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYuh1-0000Ca-Dj
	for hokey@ietf.org; Tue, 03 Apr 2007 21:53:56 -0400
Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150])
	by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id
	l341rdKq001196
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 3 Apr 2007 18:53:40 -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
	l341rdj3001120; Tue, 3 Apr 2007 18:53:39 -0700
Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by
	SANEXCAS03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 3 Apr 2007 18:53:39 -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
Subject: RE: [HOKEY] consensus call: EAP-ER as HOKEY protocol
Date: Tue, 3 Apr 2007 18:53:37 -0700
Message-ID: 
In-Reply-To: <9958B444368E884DBB215F3FEF36F5B7041F9D64@xmb-rtp-212.amer.cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [HOKEY] consensus call: EAP-ER as HOKEY protocol
Thread-Index: Acd2Eo8Jp6qnVT1/QuCv4YtraK6otwADVuVwAA6S7eA=
References: <002701c7757c$ea5d0e30$2f01a8c0@china.huawei.com>,
	<4611C658.7050603@qualcomm.com><461289A3.3000901@qualcomm.com>
	<9958B444368E884DBB215F3FEF36F5B7041F9D64@xmb-rtp-212.amer.cisco.com>
From: "Narayanan, Vidya" 
To: "Hao Zhou \(hzhou\)" ,
	"Dondeti, Lakshminath" ,
	"Avi Lior" 
X-OriginalArrivalTime: 04 Apr 2007 01:53:39.0353 (UTC)
	FILETIME=[10C17090:01C7765C]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6437e26f1586b9f35812ea5ebeedf4ad
Cc: 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

Hi Hao,
We had discussed an approach like you describe below with a few people
prior to writing the EAP-ER document and had run into a bunch of issues.
Many of the issues have been pointed out in Lakshminath's email. The
bottomline was that if this is not run with an EAP-method based
transport, there is really no backwards compatibility with
authenticators and modifying existing messages seems to be much more of
a hack than extending EAP with new codes.=20

The discussion at the interim meeting focused on a code-based
method-based transport approach  and the consensus was on the code-based
approach. What you suggest below is still a code-based approach, except
it overloads the existing codes with new stuff. That seems like a
dangerous path to go down on, to me. Specifically, I see a number of
issues and no real backwards compatibility in that approach. The peer,
authenticator and the server - all have to be "HOKEY" capable to do
this. The only point for a method-based transport was that it could run
over legacy authenticators - but, due to the inefficiency in that
approach, it was dropped.=20

In this case you outline below, what specific backwards compatibility do
you see?=20

Vidya

> -----Original Message-----
> From: Hao Zhou (hzhou) [mailto:hzhou@cisco.com]=20
> Sent: Tuesday, April 03, 2007 12:06 PM
> To: Dondeti, Lakshminath; Avi Lior
> Cc: hokey@ietf.org; Madjid Nakhjiri
> Subject: RE: [HOKEY] consensus call: EAP-ER as HOKEY protocol
>=20
> I have been soliciting with a few others about the idea of=20
> using existing EAP codes to do HOAKEY, instead of creating=20
> new EAP codes. The idea is roughly like this:
>=20
> 1. NAS still sends out EAP-Identity request, with something=20
> in the request to indicate HOAKEY support. Something similar=20
> to how network selection RFC utilizing the space after NULL=20
> character. The extra data would include HOAKEY capability, as=20
> well as any other information needed, e.g., domain ID, etc.
>=20
> 2. Client send back normal EAP-Identity Response,=20
> piggybacking any HOAKEY data needed, e.g., agreement to do=20
> HOAKEY and any HOAKEY keying materials.
>=20
> 3. If the NAS determine that client wants to do HOAKEY, then=20
> it forwards the HOAKEY data to the HOAKEY server. Otherwise,=20
> it starts the normal full EAP authentication.
>=20
> 4. After HOAKEY server sends back the server data, NAS sends=20
> EAP-Success with additional HOAKEY data, which allows the=20
> client to verify and authenticate the NAS.
>=20
> The benefits of using this approach are:
>=20
> 1. Maximum backward compatibility with legacy NAS and client.=20
> Existing client should work with new HOAKEY NAS and existing=20
> NAS would work with new HOAKEY capable client.
> 2. Less changes on the EAP lower layer on both the client and=20
> NAS. The only change is to allow additional data to be=20
> piggy-backed on EAP-Success, vs. current EAP-ER proposal of=20
> two new EAP codes.
> 3. HOAKEY capability negotiation and domain ID transmission=20
> is also included this way, instead of being mandated to be=20
> added to lower layer.
> The lower layer is probably harder to change.
> 4. I don't think the half round trip for EAP-Identity request=20
> and response would hurt performance too much and critical, as=20
> it is local between the client and NAS. Modifying the lower=20
> layer to allow client initiating exchange might be too much=20
> for some lower layer.=20
> 5. Even if piggybacking data on EAP-Success is determined to=20
> be impossible and we need a new EAP code, we should still=20
> just create a single new code for the EAP-Success with=20
> optional data, this way, only the new HOAKEY capable NAS and=20
> client needs to understand and support it. I would recommend=20
> still using the EAP-Identity request-response exchange for=20
> the first part. The goal is to minimize changes to EAP flow=20
> and state machine and EAP lower layer as little as possible.=20
>=20
> > -----Original Message-----
> > From: Lakshminath Dondeti [mailto:ldondeti@qualcomm.com]
> > Sent: Tuesday, April 03, 2007 1:07 PM
> > To: Avi Lior
> > Cc: hokey@ietf.org; Madjid Nakhjiri
> > Subject: Re: [HOKEY] consensus call: EAP-ER as HOKEY protocol
> >=20
> > Hi Avi,
> >=20
> > I find some of your arguments counter-intuitive and so=20
> would like to=20
> > understand your line of thinking on this topic.
> > Modifications to a protocol to my knowledge would be hacks and=20
> > extensions are well, extensions.  For instance, the EAP=20
> > Request/Identity message suspension in EAP-ER, as much as I=20
> would like=20
> > to defend it, is somewhat of a hack.
> >   It is the cleanest Vidya and I could come up with in the=20
> sense that=20
> > the message itself is not modified, but we need something=20
> like it to=20
> > make sure that the L2 connection is not closed if the=20
> retransmission=20
> > time expires.  Perhaps the wider community might find a better=20
> > approach.
> >=20
> > Next, some notes on 4284 since that has come up here:
> >=20
> > 3748 says "Some EAP implementations piggy-back various options into=20
> > the
> >        Identity Request after a NUL-character. "
> >=20
> > 4284 uses that provision.  In any event, 4284 is somewhat of a hack=20
> > and is an informational RFC for the purposes of 3GPP's use.
> >=20
> > Please see inline for some questions:
> >=20
> > Avi Lior wrote:
> > > I for one thinks we should look at allowing us to carry=20
> data in EAP=20
> > > success.  In fact, it would be a good idea if we allowed
> > EAP to carry
> > > data which is not part of the method in all exchanges.
> >=20
> > If the data is not part of the method, which entity needs=20
> to send such=20
> > data and how is it protected?
> >=20
> > >=20
> > > Clearly there is a need to communicate with the Peer before
> > and just
> > > after authentication.  There is no other path to the Peer. =20
> > EAP should
> > > have addressed this.
> >=20
> > Again which entity needs to communicate with the Peer?
> >=20
> > > =20
> > > We already see this happening in the Request Identity (as
> > in Network
> > > Selection and other such usage), in the Repsonse Identity
> > and now in
> > > the Success phase.
> > > =20
> > > We can continue to "hack" EAP but we can also fix it.
> >=20
> > I am lost here, so please help me out :).  The network selection=20
> > solution of 4284 is a hack IMO.  If you are saying we should revise=20
> > 3748, I might agree with you in principle.
> > But, practically speaking that is not happening anytime soon.
> >=20
> > Next, RFC 3748 has clear guidance on allocating new packet codes in=20
> > Section 6.1.  Defining new codes is a natural way of=20
> extending EAP. =20
> > If the goal is backward compatibility, adding stuff to EAP Success=20
> > doesn't help either.  As I have noted before, EAP Success=20
> packets are=20
> > not retransmitted by authenticators and that would have to=20
> change if=20
> > we add anything crucial to Success packets.
> >=20
> > I appreciate any clarifications you might provide to help me=20
> > understand your point of view here.  Thanks.
> >=20
> > regards,
> > Lakshminath
> >=20
> > > =20
> > > I am not saying EAP-ER is a hack but it is not efficient=20
> because it=20
> > > works around the existing EAP semantics but hopefully we
> > could do better.
> > > =20
> > > Avi Lior Office: +1 613 591-9104 x 6417 Cell : +1 613 796-4183
> > >=20
> > >=20
> > >=20
> >=20
> ----------------------------------------------------------------------
> > > --
> > > *From:* Lakshminath Dondeti
> > > *Sent:* Mon 4/2/2007 11:13 PM
> > > *To:* Madjid Nakhjiri
> > > *Cc:* hokey@ietf.org
> > > *Subject:* Re: [HOKEY] consensus call: EAP-ER as HOKEY protocol
> > >=20
> > > Many of the active WG contributors were present at the
> > interim meeting
> > > and there was a presentation and discussion on how=20
> reauthentication=20
> > > might work with new EAP types or codes.  The consensus was that=20
> > > code-based approach works best and that consensus was=20
> subsequently=20
> > > verified on the list.
> > >=20
> > > Well, here we are.  I am also looking forward to seeing
> > your analysis
> > > on this topic.  Changing the structure of the EAP Success
> > message and
> > > also the transmission rules for EAP Success are quite
> > drastic changes. =20
> > > If EAP Success needs to be reliably transmitted, authenticator=20
> > > behavior would have to change.  Consider the following
> > rules on EAP Success messages:
> > >=20
> > > "The peer
> > >     MAY, in the event that an EAP Success is not received,
> > conclude that
> > >     the EAP Success packet was lost and that authentication
> > concluded
> > >     successfully."
> > >=20
> > > "Success and Failure packets MUST NOT
> > >     contain additional data."
> > >=20
> > > "Because the Success and Failure packets are not
> > >     acknowledged, they are not retransmitted by the
> > authenticator, and
> > >     may be potentially lost.  A peer MUST allow for this
> > circumstance as
> > >     described in this note. "
> > >=20
> > > Anyway, I still want to see your analysis of this.
> > >=20
> > > thanks,
> > > Lakshminath
> > >=20
> > > PS:  I understand your concern about EAP Identity Request
> > and we can
> > > work on other alternatives for it where terminating the EAP state=20
> > > machine at the Authenticator and spawning an EAP-ER state
> > machine is
> > > considered burdensome (there are other ways of looking at=20
> this and=20
> > > that is written in vidya-eap-er-02).
> > >=20
> > > Madjid Nakhjiri wrote:
> > >  > Hi,
> > >  >
> > >  > I like to seek a clarification here first.
> > >  > Have we put the discussion of use of EAP code versus EAP
> > types to
> > > bed,  > completely satisfied that EAP types will absolutely
> > not solve
> > > the problems?
> > >  >
> > >  > Given that the Russ only first gave the few of us=20
> present in San=20
> > > Jose the  > green light to change EAP, I feel that we did=20
> not quite=20
> > > discuss the impact  > of adding new EAP codes versus other
> > changes to
> > > an end.  A simple analysis  > shows (I have confirmed this with=20
> > > several EAP experts) that using a new EAP  > type and adding some=20
> > > payload to EAP success you can easily achieve near 1  > roundtrip=20
> > > exchanges. I can forward that analysis in a separate email.
> > >  >
> > >  > It is not clear whether adding data to EAP success is
> > more severe
> > > than the  > changes that EAP-ER is suggesting, to name a few:
> > >  >
> > >  > 1) adding new codes even though 3748 mandates a discard
> > code>4  >
> > > 2) change of authenticator state machine to treat EAP ER
> > Request as a
> > > > response to EAP Identity request. This seems a lot more
> > intrusive on
> > > the  > massive scale of existing authenticators, than
> > adding data to
> > > EAP success  > intended for the peer.
> > >  >
> > >  > It seems that before fully deciding the EAP code=20
> versus EAP type=20
> > > options, it  > is hard to make a judgement on a solution
> > that is based
> > > on EAP code.
> > > After
> > >  > that, there are issues such as identity exchanges that
> > are needed
> > > for key  > derivation according to the EMSK draft and it=20
> seems that=20
> > > EAP-ER is  > considering those out of band or requires
> > explicit additional signaling.
> > >  >
> > >  > Finally the other clarification I am seeking is regarding the=20
> > > second  > document, don't we want to specify how the
> > per-authenticator
> > > keys are  > derived? It seems that it should be included in
> > the second spec as well.
> > >  >
> > >  > R,
> > >  >
> > >  > Madjid
> > >  >
> > >  > -----Original Message-----
> > >  > From: Charles Clancy [mailto:clancy@cs.umd.edu]  > Sent:=20
> > Saturday,
> > > March 31, 2007 11:58 AM  > To: hokey@ietf.org  > Subject: [HOKEY]=20
> > > consensus call: EAP-ER as HOKEY protocol  >  > HOKEY WG, =20
> >  > The=20
> > > chairs are making a second consensus call request to adopt
> > EAP-ER as
> > > > a WG document to satisfy our re-auth and hand-off
> > deliverables.  It
> > > > would serve as a starting point for development of the
> > HOKEY protocol.
> > >  >
> > >  > Note that if accepted, it may be split into two WG documents,=20
> > > separating  > the EAP-ER-Bootstrap into a second set of
> > messages that
> > > could be  > transported by any service to obtain a USRK or DSUSRK.
> > >  >
> > >  > Please respond by Friday, April 13.
> > >  >
> > >=20
> > > _______________________________________________
> > > HOKEY mailing list
> > > HOKEY@ietf.org
> > > https://www1.ietf.org/mailman/listinfo/hokey
> > >=20
> >=20
> > _______________________________________________
> > HOKEY mailing list
> > HOKEY@ietf.org
> > https://www1.ietf.org/mailman/listinfo/hokey
> >=20
>=20
> _______________________________________________
> HOKEY mailing list
> HOKEY@ietf.org
> https://www1.ietf.org/mailman/listinfo/hokey
>=20

_______________________________________________
HOKEY mailing list
HOKEY@ietf.org
https://www1.ietf.org/mailman/listinfo/hokey



From hokey-bounces@ietf.org Tue Apr 03 22:46: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 1HYvWB-0001D0-R9; Tue, 03 Apr 2007 22:46:39 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HYvWB-0001Cq-1g
	for hokey@ietf.org; Tue, 03 Apr 2007 22:46:39 -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 1HYvVG-00071y-CL
	for hokey@ietf.org; Tue, 03 Apr 2007 22:45:43 -0400
Received: from localhost (toshi17.tari.toshiba.com [172.30.24.10])
	by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id
	l342irVV020079; Tue, 3 Apr 2007 22:44:53 -0400 (EDT)
	(envelope-from yohba@tari.toshiba.com)
Date: Tue, 3 Apr 2007 22:44:53 -0400
To: "Narayanan, Vidya" 
Subject: Re: [HOKEY] consensus call: key distribution security requirement
Message-ID: <20070404024453.GA18289@steelhead>
References: <460EB36E.5010604@cs.umd.edu>
	
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-2022-jp
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.13 (2006-08-11)
From: Yoshihiro Ohba 
X-Dispatcher: imput version 20050308(IM148)
Lines: 87
X-Spam-Score: -2.4 (--)
X-Scan-Signature: 73734d43604d52d23b3eba644a169745
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 Vidya,

Can you please explain why channel binding information must be
optional?

Can you also explain in which system there are no adverse effects in
key distribution without explicit peer consent?

Regards,
Yoshihiro Ohba


On Tue, Apr 03, 2007 at 06:25:52PM -0700, Narayanan, Vidya wrote:
> I'm barely caught up on all the email after having been on vacation
> until now, so, pardon me if I'm bringing up stuff that's already been
> discussed here. 
> 
> I share some of Glen's concerns about "requiring" peer consent and a
> 3-party protocol and about how practically deployable that is. In my
> conversations with Dan in Prague, it seemed like we were on the same
> page about including channel binding information in the HOKEY protocol
> between the peer and server. I think such channel binding information
> must be optional and not required. In some systems, there are no adverse
> effects of distribution of key material without explicit peer consent
> and there is no reason to place upper layer identity advertisement
> requirements on the lower layers for such systems. In some other
> systems, it may be a good idea to do so and having the capability to do
> that in the protocol would be useful there. 
> 
> To specifically answer your question, I don't believe we need to update
> the problem statement. It already captures the channel binding stuff and
> the explicit data that the peer and authenticator may include is one way
> of providing channel binding. 
> 
> Vidya
> 
> > -----Original Message-----
> > From: Charles Clancy [mailto:clancy@cs.umd.edu] 
> > Sent: Saturday, March 31, 2007 12:16 PM
> > To: hokey@ietf.org
> > Subject: [HOKEY] consensus call: key distribution security requirement
> > 
> > HOKEY WG,
> > 
> > The 3-party protocol proposal at IETF 68 listed a variety of 
> > protocol requirements, some of which went beyond those 
> > currently specified in the problem statements draft.  The 
> > main extension was a requirement for stronger key 
> > distribution security.
> > 
> > Discussion: The problem statements document currently 
> > requires channel bindings to allow clients to authenticate 
> > the network to which they are connecting, and prevent the 
> > lying NAS problem.  However one possible implementation of 
> > channel bindings would allow keys to be distributed prior to 
> > the network being authenticated by the peer.  While the peer 
> > may decide to not use a network after it's validated its 
> > identity, network entities could retain the keying material.  
> > There has been much debate on the list as to whether or not 
> > network entities could maliciously use this keying material, 
> > and the intent here is to not rehash all that discussion.
> > 
> > Question: Should additional text be added to the problem 
> > statement draft
> >   to require peer authorization for distributing keying material?
> > 
> > Protocol Implications: If "yes" then a 3-party protocol would 
> > be need, and would require L2 advertisement of the NAS-ID and 
> > local AAA domain name.  If "no" then channel bindings where 
> > identities are hashed into the key derivation would be sufficient.
> > 
> > --
> > t. charles clancy, ph.d.  <>  tcc@umd.edu  <>  www.cs.umd.edu/~clancy
> > 
> > 
> > _______________________________________________
> > 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 Tue Apr 03 22:49:59 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HYvZO-0002AR-W1; Tue, 03 Apr 2007 22:49:58 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HYvZO-0002AD-0J
	for hokey@ietf.org; Tue, 03 Apr 2007 22:49:58 -0400
Received: from rwcrmhc15.comcast.net ([216.148.227.155])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYvZM-0001Ln-8Q
	for hokey@ietf.org; Tue, 03 Apr 2007 22:49:57 -0400
Received: from [192.168.0.4]
	(c-68-49-199-146.hsd1.md.comcast.net[68.49.199.146])
	by comcast.net (rwcrmhc15) with ESMTP
	id <20070404024954m15007jsjte>; Wed, 4 Apr 2007 02:49:55 +0000
Message-ID: <46130889.1060808@cs.umd.edu>
Date: Tue, 03 Apr 2007 22:08:09 -0400
From: Charles Clancy 
User-Agent: Thunderbird 1.5.0.4 (X11/20060516)
MIME-Version: 1.0
To: "Narayanan, Vidya" 
Subject: Re: [HOKEY] consensus call: EAP-ER as HOKEY protocol
References: <002701c7757c$ea5d0e30$2f01a8c0@china.huawei.com>,
	<4611C658.7050603@qualcomm.com><461289A3.3000901@qualcomm.com>	<9958B444368E884DBB215F3FEF36F5B7041F9D64@xmb-rtp-212.amer.cisco.com>
	
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 872695ea777a517bf5717e5acc69f8be
Cc: Madjid Nakhjiri , 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

Just to reiterate one of my earlier posts...

My concern is that the overloaded approach's backward compatibility 
seems to rely on legacy NASes having not properly followed the EAP spec. 
  It's only backward compatible if NASes don't drop EAP-Successes with 
length > 4.  EAP-ER is backward compatible if NASes don't check EAP code 
values.  It seems to me that neither can claim backward compatibility, 
so if backward compatibility is going to be used to decide which is 
better, someone should test legacy NASes and see how they behave.

--
t. charles clancy, ph.d.  |  tcc@umd.edu  |  www.cs.umd.edu/~clancy


Narayanan, Vidya wrote:
> Hi Hao,
> We had discussed an approach like you describe below with a few people
> prior to writing the EAP-ER document and had run into a bunch of issues.
> Many of the issues have been pointed out in Lakshminath's email. The
> bottomline was that if this is not run with an EAP-method based
> transport, there is really no backwards compatibility with
> authenticators and modifying existing messages seems to be much more of
> a hack than extending EAP with new codes. 
> 
> The discussion at the interim meeting focused on a code-based
> method-based transport approach  and the consensus was on the code-based
> approach. What you suggest below is still a code-based approach, except
> it overloads the existing codes with new stuff. That seems like a
> dangerous path to go down on, to me. Specifically, I see a number of
> issues and no real backwards compatibility in that approach. The peer,
> authenticator and the server - all have to be "HOKEY" capable to do
> this. The only point for a method-based transport was that it could run
> over legacy authenticators - but, due to the inefficiency in that
> approach, it was dropped. 
> 
> In this case you outline below, what specific backwards compatibility do
> you see? 
> 
> Vidya
> 
>> -----Original Message-----
>> From: Hao Zhou (hzhou) [mailto:hzhou@cisco.com] 
>> Sent: Tuesday, April 03, 2007 12:06 PM
>> To: Dondeti, Lakshminath; Avi Lior
>> Cc: hokey@ietf.org; Madjid Nakhjiri
>> Subject: RE: [HOKEY] consensus call: EAP-ER as HOKEY protocol
>>
>> I have been soliciting with a few others about the idea of 
>> using existing EAP codes to do HOAKEY, instead of creating 
>> new EAP codes. The idea is roughly like this:
>>
>> 1. NAS still sends out EAP-Identity request, with something 
>> in the request to indicate HOAKEY support. Something similar 
>> to how network selection RFC utilizing the space after NULL 
>> character. The extra data would include HOAKEY capability, as 
>> well as any other information needed, e.g., domain ID, etc.
>>
>> 2. Client send back normal EAP-Identity Response, 
>> piggybacking any HOAKEY data needed, e.g., agreement to do 
>> HOAKEY and any HOAKEY keying materials.
>>
>> 3. If the NAS determine that client wants to do HOAKEY, then 
>> it forwards the HOAKEY data to the HOAKEY server. Otherwise, 
>> it starts the normal full EAP authentication.
>>
>> 4. After HOAKEY server sends back the server data, NAS sends 
>> EAP-Success with additional HOAKEY data, which allows the 
>> client to verify and authenticate the NAS.
>>
>> The benefits of using this approach are:
>>
>> 1. Maximum backward compatibility with legacy NAS and client. 
>> Existing client should work with new HOAKEY NAS and existing 
>> NAS would work with new HOAKEY capable client.
>> 2. Less changes on the EAP lower layer on both the client and 
>> NAS. The only change is to allow additional data to be 
>> piggy-backed on EAP-Success, vs. current EAP-ER proposal of 
>> two new EAP codes.
>> 3. HOAKEY capability negotiation and domain ID transmission 
>> is also included this way, instead of being mandated to be 
>> added to lower layer.
>> The lower layer is probably harder to change.
>> 4. I don't think the half round trip for EAP-Identity request 
>> and response would hurt performance too much and critical, as 
>> it is local between the client and NAS. Modifying the lower 
>> layer to allow client initiating exchange might be too much 
>> for some lower layer. 
>> 5. Even if piggybacking data on EAP-Success is determined to 
>> be impossible and we need a new EAP code, we should still 
>> just create a single new code for the EAP-Success with 
>> optional data, this way, only the new HOAKEY capable NAS and 
>> client needs to understand and support it. I would recommend 
>> still using the EAP-Identity request-response exchange for 
>> the first part. The goal is to minimize changes to EAP flow 
>> and state machine and EAP lower layer as little as possible. 
>>
>>> -----Original Message-----
>>> From: Lakshminath Dondeti [mailto:ldondeti@qualcomm.com]
>>> Sent: Tuesday, April 03, 2007 1:07 PM
>>> To: Avi Lior
>>> Cc: hokey@ietf.org; Madjid Nakhjiri
>>> Subject: Re: [HOKEY] consensus call: EAP-ER as HOKEY protocol
>>>
>>> Hi Avi,
>>>
>>> I find some of your arguments counter-intuitive and so 
>> would like to 
>>> understand your line of thinking on this topic.
>>> Modifications to a protocol to my knowledge would be hacks and 
>>> extensions are well, extensions.  For instance, the EAP 
>>> Request/Identity message suspension in EAP-ER, as much as I 
>> would like 
>>> to defend it, is somewhat of a hack.
>>>   It is the cleanest Vidya and I could come up with in the 
>> sense that 
>>> the message itself is not modified, but we need something 
>> like it to 
>>> make sure that the L2 connection is not closed if the 
>> retransmission 
>>> time expires.  Perhaps the wider community might find a better 
>>> approach.
>>>
>>> Next, some notes on 4284 since that has come up here:
>>>
>>> 3748 says "Some EAP implementations piggy-back various options into 
>>> the
>>>        Identity Request after a NUL-character. "
>>>
>>> 4284 uses that provision.  In any event, 4284 is somewhat of a hack 
>>> and is an informational RFC for the purposes of 3GPP's use.
>>>
>>> Please see inline for some questions:
>>>
>>> Avi Lior wrote:
>>>> I for one thinks we should look at allowing us to carry 
>> data in EAP 
>>>> success.  In fact, it would be a good idea if we allowed
>>> EAP to carry
>>>> data which is not part of the method in all exchanges.
>>> If the data is not part of the method, which entity needs 
>> to send such 
>>> data and how is it protected?
>>>
>>>> Clearly there is a need to communicate with the Peer before
>>> and just
>>>> after authentication.  There is no other path to the Peer.  
>>> EAP should
>>>> have addressed this.
>>> Again which entity needs to communicate with the Peer?
>>>
>>>>  
>>>> We already see this happening in the Request Identity (as
>>> in Network
>>>> Selection and other such usage), in the Repsonse Identity
>>> and now in
>>>> the Success phase.
>>>>  
>>>> We can continue to "hack" EAP but we can also fix it.
>>> I am lost here, so please help me out :).  The network selection 
>>> solution of 4284 is a hack IMO.  If you are saying we should revise 
>>> 3748, I might agree with you in principle.
>>> But, practically speaking that is not happening anytime soon.
>>>
>>> Next, RFC 3748 has clear guidance on allocating new packet codes in 
>>> Section 6.1.  Defining new codes is a natural way of 
>> extending EAP.  
>>> If the goal is backward compatibility, adding stuff to EAP Success 
>>> doesn't help either.  As I have noted before, EAP Success 
>> packets are 
>>> not retransmitted by authenticators and that would have to 
>> change if 
>>> we add anything crucial to Success packets.
>>>
>>> I appreciate any clarifications you might provide to help me 
>>> understand your point of view here.  Thanks.
>>>
>>> regards,
>>> Lakshminath
>>>
>>>>  
>>>> I am not saying EAP-ER is a hack but it is not efficient 
>> because it 
>>>> works around the existing EAP semantics but hopefully we
>>> could do better.
>>>>  
>>>> Avi Lior Office: +1 613 591-9104 x 6417 Cell : +1 613 796-4183
>>>>
>>>>
>>>>
>> ----------------------------------------------------------------------
>>>> --
>>>> *From:* Lakshminath Dondeti
>>>> *Sent:* Mon 4/2/2007 11:13 PM
>>>> *To:* Madjid Nakhjiri
>>>> *Cc:* hokey@ietf.org
>>>> *Subject:* Re: [HOKEY] consensus call: EAP-ER as HOKEY protocol
>>>>
>>>> Many of the active WG contributors were present at the
>>> interim meeting
>>>> and there was a presentation and discussion on how 
>> reauthentication 
>>>> might work with new EAP types or codes.  The consensus was that 
>>>> code-based approach works best and that consensus was 
>> subsequently 
>>>> verified on the list.
>>>>
>>>> Well, here we are.  I am also looking forward to seeing
>>> your analysis
>>>> on this topic.  Changing the structure of the EAP Success
>>> message and
>>>> also the transmission rules for EAP Success are quite
>>> drastic changes.  
>>>> If EAP Success needs to be reliably transmitted, authenticator 
>>>> behavior would have to change.  Consider the following
>>> rules on EAP Success messages:
>>>> "The peer
>>>>     MAY, in the event that an EAP Success is not received,
>>> conclude that
>>>>     the EAP Success packet was lost and that authentication
>>> concluded
>>>>     successfully."
>>>>
>>>> "Success and Failure packets MUST NOT
>>>>     contain additional data."
>>>>
>>>> "Because the Success and Failure packets are not
>>>>     acknowledged, they are not retransmitted by the
>>> authenticator, and
>>>>     may be potentially lost.  A peer MUST allow for this
>>> circumstance as
>>>>     described in this note. "
>>>>
>>>> Anyway, I still want to see your analysis of this.
>>>>
>>>> thanks,
>>>> Lakshminath
>>>>
>>>> PS:  I understand your concern about EAP Identity Request
>>> and we can
>>>> work on other alternatives for it where terminating the EAP state 
>>>> machine at the Authenticator and spawning an EAP-ER state
>>> machine is
>>>> considered burdensome (there are other ways of looking at 
>> this and 
>>>> that is written in vidya-eap-er-02).
>>>>
>>>> Madjid Nakhjiri wrote:
>>>>  > Hi,
>>>>  >
>>>>  > I like to seek a clarification here first.
>>>>  > Have we put the discussion of use of EAP code versus EAP
>>> types to
>>>> bed,  > completely satisfied that EAP types will absolutely
>>> not solve
>>>> the problems?
>>>>  >
>>>>  > Given that the Russ only first gave the few of us 
>> present in San 
>>>> Jose the  > green light to change EAP, I feel that we did 
>> not quite 
>>>> discuss the impact  > of adding new EAP codes versus other
>>> changes to
>>>> an end.  A simple analysis  > shows (I have confirmed this with 
>>>> several EAP experts) that using a new EAP  > type and adding some 
>>>> payload to EAP success you can easily achieve near 1  > roundtrip 
>>>> exchanges. I can forward that analysis in a separate email.
>>>>  >
>>>>  > It is not clear whether adding data to EAP success is
>>> more severe
>>>> than the  > changes that EAP-ER is suggesting, to name a few:
>>>>  >
>>>>  > 1) adding new codes even though 3748 mandates a discard
>>> code>4  >
>>>> 2) change of authenticator state machine to treat EAP ER
>>> Request as a
>>>>> response to EAP Identity request. This seems a lot more
>>> intrusive on
>>>> the  > massive scale of existing authenticators, than
>>> adding data to
>>>> EAP success  > intended for the peer.
>>>>  >
>>>>  > It seems that before fully deciding the EAP code 
>> versus EAP type 
>>>> options, it  > is hard to make a judgement on a solution
>>> that is based
>>>> on EAP code.
>>>> After
>>>>  > that, there are issues such as identity exchanges that
>>> are needed
>>>> for key  > derivation according to the EMSK draft and it 
>> seems that 
>>>> EAP-ER is  > considering those out of band or requires
>>> explicit additional signaling.
>>>>  >
>>>>  > Finally the other clarification I am seeking is regarding the 
>>>> second  > document, don't we want to specify how the
>>> per-authenticator
>>>> keys are  > derived? It seems that it should be included in
>>> the second spec as well.
>>>>  >
>>>>  > R,
>>>>  >
>>>>  > Madjid
>>>>  >
>>>>  > -----Original Message-----
>>>>  > From: Charles Clancy [mailto:clancy@cs.umd.edu]  > Sent: 
>>> Saturday,
>>>> March 31, 2007 11:58 AM  > To: hokey@ietf.org  > Subject: [HOKEY] 
>>>> consensus call: EAP-ER as HOKEY protocol  >  > HOKEY WG,  
>>>  > The 
>>>> chairs are making a second consensus call request to adopt
>>> EAP-ER as
>>>>> a WG document to satisfy our re-auth and hand-off
>>> deliverables.  It
>>>>> would serve as a starting point for development of the
>>> HOKEY protocol.
>>>>  >
>>>>  > Note that if accepted, it may be split into two WG documents, 
>>>> separating  > the EAP-ER-Bootstrap into a second set of
>>> messages that
>>>> could be  > transported by any service to obtain a USRK or DSUSRK.
>>>>  >
>>>>  > Please respond by Friday, April 13.
>>>>  >
>>>>
>>>> _______________________________________________
>>>> 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
>>
> 
> _______________________________________________
> 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 Apr 04 00:55:50 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HYxX8-0003Yv-2B; Wed, 04 Apr 2007 00:55:46 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HYxX7-0003Yk-ID
	for hokey@ietf.org; Wed, 04 Apr 2007 00:55:45 -0400
Received: from sj-iport-5.cisco.com ([171.68.10.87])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYxX6-0000CV-5t
	for hokey@ietf.org; Wed, 04 Apr 2007 00:55:45 -0400
Received: from sj-dkim-2.cisco.com ([171.71.179.186])
	by sj-iport-5.cisco.com with ESMTP; 03 Apr 2007 21:55:44 -0700
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 l344thRE019635; 
	Tue, 3 Apr 2007 21:55:43 -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 l344thEi016175;
	Wed, 4 Apr 2007 04:55:43 GMT
Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by
	xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 3 Apr 2007 21:55:43 -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
Subject: RE: [HOKEY] consensus call: key distribution security requirement
Date: Tue, 3 Apr 2007 21:55:33 -0700
Message-ID: 
In-Reply-To: <460EB36E.5010604@cs.umd.edu>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [HOKEY] consensus call: key distribution security requirement
Thread-Index: AcdzySTnpO0vSuFcROCvGdI11glMWwCqs/KQ
From: "Joseph Salowey \(jsalowey\)" 
To: "Charles Clancy" , 
X-OriginalArrivalTime: 04 Apr 2007 04:55:43.0168 (UTC)
	FILETIME=[7FDB5400:01C77675]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2404; t=1175662543;
	x=1176526543; c=relaxed/simple; s=sjdkim2002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=jsalowey@cisco.com;
	z=From:=20=22Joseph=20Salowey=20\(jsalowey\)=22=20
	|Subject:=20RE=3A=20[HOKEY]=20consensus=20call=3A=20key=20distribution=20
	security=20requirement |Sender:=20;
	bh=pYsxs0v6vTrTvNtlheNcboUDn4thEjP/dmIUw8yT63k=;
	b=jjdR2ma7MZsNBW79jsX4hKj8VDD6S1J4Zam9cUUe+Bptb33HOiSB5CiZiY/FeqpVVBMCSlty
	kpv1dsxXI9Kf/xJ259coZJ869ctXDDj4rrC4m8evTQYoAH/VlDvbtxXr;
Authentication-Results: sj-dkim-2; header.From=jsalowey@cisco.com; dkim=pass (
	sig from cisco.com/sjdkim2002 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8
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,=20

I see no reason to require the peer to explicitly authorize distribution
of key material.  =20

I'm not sure I understand how the protocol implications stated below
immediately follow.  It's not clear what "identities" you are going to
hash with the key, but whatever they are they must be known to the peer.
In addition I don't believe that explicit authorization requires a three
party protocol (but in any case I don't think it is necessary).  =20

Joe

> -----Original Message-----
> From: Charles Clancy [mailto:clancy@cs.umd.edu]=20
> Sent: Saturday, March 31, 2007 12:16 PM
> To: hokey@ietf.org
> Subject: [HOKEY] consensus call: key distribution security requirement
>=20
> HOKEY WG,
>=20
> The 3-party protocol proposal at IETF 68 listed a variety of=20
> protocol requirements, some of which went beyond those=20
> currently specified in the problem statements draft.  The=20
> main extension was a requirement for stronger key=20
> distribution security.
>=20
> Discussion: The problem statements document currently=20
> requires channel bindings to allow clients to authenticate=20
> the network to which they are connecting, and prevent the=20
> lying NAS problem.  However one possible implementation of=20
> channel bindings would allow keys to be distributed prior to=20
> the network being authenticated by the peer.  While the peer=20
> may decide to not use a network after it's validated its=20
> identity, network entities could retain the keying material. =20
> There has been much debate on the list as to whether or not=20
> network entities could maliciously use this keying material,=20
> and the intent here is to not rehash all that discussion.
>=20
> Question: Should additional text be added to the problem=20
> statement draft
>   to require peer authorization for distributing keying material?
>=20
> Protocol Implications: If "yes" then a 3-party protocol would=20
> be need, and would require L2 advertisement of the NAS-ID and=20
> local AAA domain name.  If "no" then channel bindings where=20
> identities are hashed into the key derivation would be sufficient.
>=20
> --
> t. charles clancy, ph.d.  <>  tcc@umd.edu  <>  www.cs.umd.edu/~clancy
>=20
>=20
> _______________________________________________
> HOKEY mailing list
> HOKEY@ietf.org
> https://www1.ietf.org/mailman/listinfo/hokey
>=20

_______________________________________________
HOKEY mailing list
HOKEY@ietf.org
https://www1.ietf.org/mailman/listinfo/hokey



From hokey-bounces@ietf.org Wed Apr 04 11:03: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 1HZ71C-0003qU-A7; Wed, 04 Apr 2007 11:03:26 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ71A-0003om-Gg
	for hokey@ietf.org; Wed, 04 Apr 2007 11:03:24 -0400
Received: from rtp-iport-1.cisco.com ([64.102.122.148])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZ718-00051B-Qp
	for hokey@ietf.org; Wed, 04 Apr 2007 11:03:24 -0400
Received: from rtp-dkim-1.cisco.com ([64.102.121.158])
	by rtp-iport-1.cisco.com with ESMTP; 04 Apr 2007 11:03:23 -0400
Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12])
	by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l34F3Mj6007931; 
	Wed, 4 Apr 2007 11:03:22 -0400
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com
	[64.102.31.12])
	by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l34F3EGd017090; 
	Wed, 4 Apr 2007 15:03:14 GMT
Received: from xmb-rtp-212.amer.cisco.com ([64.102.31.111]) by
	xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 4 Apr 2007 11:03:13 -0400
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] consensus call: EAP-ER as HOKEY protocol
Date: Wed, 4 Apr 2007 11:03:12 -0400
Message-ID: <9958B444368E884DBB215F3FEF36F5B7041F9F6F@xmb-rtp-212.amer.cisco.com>
In-Reply-To: <4612BF90.3080901@qualcomm.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [HOKEY] consensus call: EAP-ER as HOKEY protocol
Thread-Index: Acd2MpxKn+1L+x5RSrSJrJ4ORwLmcwAlMJwA
References: <002701c7757c$ea5d0e30$2f01a8c0@china.huawei.com>,
	<4611C658.7050603@qualcomm.com>
	<461289A3.3000901@qualcomm.com>
	<9958B444368E884DBB215F3FEF36F5B7041F9D64@xmb-rtp-212.amer.cisco.com>
	<4612BF90.3080901@qualcomm.com>
From: "Hao Zhou \(hzhou\)" 
To: "Lakshminath Dondeti" 
X-OriginalArrivalTime: 04 Apr 2007 15:03:13.0839 (UTC)
	FILETIME=[5E2653F0:01C776CA]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=15119; t=1175699002;
	x=1176563002; c=relaxed/simple; s=rtpdkim1001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=hzhou@cisco.com;
	z=From:=20=22Hao=20Zhou=20\(hzhou\)=22=20
	|Subject:=20RE=3A=20[HOKEY]=20consensus=20call=3A=20EAP-ER=20as=20HOKEY=2
	0protocol |Sender:=20
	|To:=20=22Lakshminath=20Dondeti=22=20;
	bh=CALjFjJ7yx89UR77K2uSS4UqMwcfNG8xQQu/qXA9Hto=;
	b=DW7xiFSVvZ7VrbZCM17n6wCFL4EY4VA4niPQZC0P2EP/KCYuEoJB+VNYrj1K+6upVwCbrMsr
	s35NFRAirS304Yi0IIaUDUYRPEN3YqHF2vHLBMb2RSlMFlD4SBUmoV9q;
Authentication-Results: rtp-dkim-1; header.From=hzhou@cisco.com; dkim=pass (
	sig from cisco.com/rtpdkim1001 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f460acdc4aacf7fc5e6f9bd32f8fd8c6
Cc: Madjid Nakhjiri , 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

Lakshminath:

Please see inline.=20

> -----Original Message-----
> From: Lakshminath Dondeti [mailto:ldondeti@qualcomm.com]=20
> Sent: Tuesday, April 03, 2007 4:57 PM
> To: Hao Zhou (hzhou)
> Cc: Avi Lior; hokey@ietf.org; Madjid Nakhjiri
> Subject: Re: [HOKEY] consensus call: EAP-ER as HOKEY protocol
>=20
> Hi Hao,
>=20
> Thanks for proposing the detailed solution.  On a first look,=20
> it might seem to offer the benefits you list, but a closer=20
> look reveals serious
> problems:
>=20
> 1. EAP-Request/Identity does have a provision to carry stuff=20
> after the NUL character.  There seems to be contention by=20
> various use cases for that space.  That is a problem.  More=20
> specifically, 4284 cannot be used with reauthentication.
>=20
[HZ] I don't see there is a contention, other than the size limitation.
RFC4284 defines it own syntax "NAIRealms=3D", for HOAKEY we can define =
our
own syntax. They can coexist. And we are not using RFC4284 (only using
idea similar to it) and thus not limited to initial authentication.

> 2. EAP-Response/Identity does not have a provision to carry=20
> additional data.  That is a change to 3748's text.
>=20
[HZ] I am talking about carry data inside the response, as part of the
response, like Avi pointed out. It doesn't conflict with RFC3748.

> 3. EAP Success retransmission semantics need to change.  This=20
> means changes to the authenticator.  So, backward=20
> compatibility arguments are not applicable.
>
[HZ] I guess you missed my point. Legacy authenticator and/or client
would never receive the EAP-Success with optional data, only the regular
EAP-Success, as HOAKEY will not happen for them and they will start a
normal EAP authentication. Only new client and NAS that are HOAKEY
capable will see this and know how to handle them.=20
=20
> Bottomline is the authenticator behavior is going to be=20
> changed one way or another.  We reviewed all of this at the=20
> interim meeting.  As to one new code vs. two, one of the=20
> older versions of EAP-ER did have one code.=20
>   The current version is a result of the discussions at the=20
> interim meeting.  I think the minutes covered the reasoning.
>=20
[HZ] Is your assumption that HOAKEY will only work on new EAP lower
layer, hence both client and authenticator will change and include
capability negotiation, and hence don't have to worry about legacy
client or authentication? My proposal works with legacy client and
authenticator.=20

> As to minimizing lower layer changes and being able to signal=20
> HOKEY capability in EAP, let's talk about that separately.
>=20
> My goals here are to minimize modifications to the EAP state machine.=20
[HZ] I don't see adding two new codes will minimize the modifications to
EAP state machine, vs. reusing the existing codes.

> Additions are always better and cleaner than modifying the=20
> protocol behavior.  Suppose some other use case comes along=20
> in the future and modifies EAP in a different way.  What happens then?
[HZ] If we really think of a solution to be more generic, then we
probably should look at extending the EAP packet, maybe allowing
carrying of other data, instead of creating two new codes just for
HOAKEY.

>=20
> thanks,
> Lakshminath
>=20
> Hao Zhou (hzhou) wrote:
> > I have been soliciting with a few others about the idea of using=20
> > existing EAP codes to do HOAKEY, instead of creating new EAP codes.=20
> > The idea is roughly like this:
> >=20
> > 1. NAS still sends out EAP-Identity request, with something in the=20
> > request to indicate HOAKEY support. Something similar to=20
> how network=20
> > selection RFC utilizing the space after NULL character. The=20
> extra data=20
> > would include HOAKEY capability, as well as any other information=20
> > needed, e.g., domain ID, etc.
> >=20
> > 2. Client send back normal EAP-Identity Response, piggybacking any=20
> > HOAKEY data needed, e.g., agreement to do HOAKEY and any=20
> HOAKEY keying=20
> > materials.
> >=20
> > 3. If the NAS determine that client wants to do HOAKEY, then it=20
> > forwards the HOAKEY data to the HOAKEY server. Otherwise, it starts=20
> > the normal full EAP authentication.
> >=20
> > 4. After HOAKEY server sends back the server data, NAS sends=20
> > EAP-Success with additional HOAKEY data, which allows the client to=20
> > verify and authenticate the NAS.
> >=20
> > The benefits of using this approach are:
> >=20
> > 1. Maximum backward compatibility with legacy NAS and=20
> client. Existing=20
> > client should work with new HOAKEY NAS and existing NAS would work=20
> > with new HOAKEY capable client.
> > 2. Less changes on the EAP lower layer on both the client=20
> and NAS. The=20
> > only change is to allow additional data to be piggy-backed on=20
> > EAP-Success, vs. current EAP-ER proposal of two new EAP codes.
> > 3. HOAKEY capability negotiation and domain ID transmission is also=20
> > included this way, instead of being mandated to be added to=20
> lower layer.
> > The lower layer is probably harder to change.
> > 4. I don't think the half round trip for EAP-Identity request and=20
> > response would hurt performance too much and critical, as=20
> it is local=20
> > between the client and NAS. Modifying the lower layer to=20
> allow client=20
> > initiating exchange might be too much for some lower layer.
> > 5. Even if piggybacking data on EAP-Success is determined to be=20
> > impossible and we need a new EAP code, we should still just=20
> create a=20
> > single new code for the EAP-Success with optional data,=20
> this way, only=20
> > the new HOAKEY capable NAS and client needs to understand=20
> and support=20
> > it. I would recommend still using the EAP-Identity request-response=20
> > exchange for the first part. The goal is to minimize changes to EAP=20
> > flow and state machine and EAP lower layer as little as possible.
> >=20
> >> -----Original Message-----
> >> From: Lakshminath Dondeti [mailto:ldondeti@qualcomm.com]
> >> Sent: Tuesday, April 03, 2007 1:07 PM
> >> To: Avi Lior
> >> Cc: hokey@ietf.org; Madjid Nakhjiri
> >> Subject: Re: [HOKEY] consensus call: EAP-ER as HOKEY protocol
> >>
> >> Hi Avi,
> >>
> >> I find some of your arguments counter-intuitive and so=20
> would like to=20
> >> understand your line of thinking on this topic.
> >> Modifications to a protocol to my knowledge would be hacks and=20
> >> extensions are well, extensions.  For instance, the EAP=20
> >> Request/Identity message suspension in EAP-ER, as much as I would=20
> >> like to defend it, is somewhat of a hack.
> >>   It is the cleanest Vidya and I could come up with in the=20
> sense that=20
> >> the message itself is not modified, but we need something=20
> like it to=20
> >> make sure that the L2 connection is not closed if the=20
> retransmission=20
> >> time expires.  Perhaps the wider community might find a better=20
> >> approach.
> >>
> >> Next, some notes on 4284 since that has come up here:
> >>
> >> 3748 says "Some EAP implementations piggy-back various=20
> options into=20
> >> the
> >>        Identity Request after a NUL-character. "
> >>
> >> 4284 uses that provision.  In any event, 4284 is somewhat=20
> of a hack=20
> >> and is an informational RFC for the purposes of 3GPP's use.
> >>
> >> Please see inline for some questions:
> >>
> >> Avi Lior wrote:
> >>> I for one thinks we should look at allowing us to carry=20
> data in EAP=20
> >>> success.  In fact, it would be a good idea if we allowed
> >> EAP to carry
> >>> data which is not part of the method in all exchanges.
> >> If the data is not part of the method, which entity needs to send=20
> >> such data and how is it protected?
> >>
> >>> Clearly there is a need to communicate with the Peer before
> >> and just
> >>> after authentication.  There is no other path to the Peer. =20
> >> EAP should
> >>> have addressed this.
> >> Again which entity needs to communicate with the Peer?
> >>
> >>> =20
> >>> We already see this happening in the Request Identity (as
> >> in Network
> >>> Selection and other such usage), in the Repsonse Identity
> >> and now in
> >>> the Success phase.
> >>> =20
> >>> We can continue to "hack" EAP but we can also fix it.
> >> I am lost here, so please help me out :).  The network selection=20
> >> solution of 4284 is a hack IMO.  If you are saying we=20
> should revise=20
> >> 3748, I might agree with you in principle.
> >> But, practically speaking that is not happening anytime soon.
> >>
> >> Next, RFC 3748 has clear guidance on allocating new packet=20
> codes in=20
> >> Section 6.1.  Defining new codes is a natural way of=20
> extending EAP. =20
> >> If the goal is backward compatibility, adding stuff to EAP Success=20
> >> doesn't help either.  As I have noted before, EAP Success=20
> packets are=20
> >> not retransmitted by authenticators and that would have to=20
> change if=20
> >> we add anything crucial to Success packets.
> >>
> >> I appreciate any clarifications you might provide to help me=20
> >> understand your point of view here.  Thanks.
> >>
> >> regards,
> >> Lakshminath
> >>
> >>> =20
> >>> I am not saying EAP-ER is a hack but it is not efficient=20
> because it=20
> >>> works around the existing EAP semantics but hopefully we
> >> could do better.
> >>> =20
> >>> Avi Lior Office: +1 613 591-9104 x 6417 Cell : +1 613 796-4183
> >>>
> >>>
> >>>
> >>=20
> ---------------------------------------------------------------------
> >> -
> >>> --
> >>> *From:* Lakshminath Dondeti
> >>> *Sent:* Mon 4/2/2007 11:13 PM
> >>> *To:* Madjid Nakhjiri
> >>> *Cc:* hokey@ietf.org
> >>> *Subject:* Re: [HOKEY] consensus call: EAP-ER as HOKEY protocol
> >>>
> >>> Many of the active WG contributors were present at the
> >> interim meeting
> >>> and there was a presentation and discussion on how=20
> reauthentication=20
> >>> might work with new EAP types or codes.  The consensus was that=20
> >>> code-based approach works best and that consensus was=20
> subsequently=20
> >>> verified on the list.
> >>>
> >>> Well, here we are.  I am also looking forward to seeing
> >> your analysis
> >>> on this topic.  Changing the structure of the EAP Success
> >> message and
> >>> also the transmission rules for EAP Success are quite
> >> drastic changes. =20
> >>> If EAP Success needs to be reliably transmitted, authenticator=20
> >>> behavior would have to change.  Consider the following
> >> rules on EAP Success messages:
> >>> "The peer
> >>>     MAY, in the event that an EAP Success is not received,
> >> conclude that
> >>>     the EAP Success packet was lost and that authentication
> >> concluded
> >>>     successfully."
> >>>
> >>> "Success and Failure packets MUST NOT
> >>>     contain additional data."
> >>>
> >>> "Because the Success and Failure packets are not
> >>>     acknowledged, they are not retransmitted by the
> >> authenticator, and
> >>>     may be potentially lost.  A peer MUST allow for this
> >> circumstance as
> >>>     described in this note. "
> >>>
> >>> Anyway, I still want to see your analysis of this.
> >>>
> >>> thanks,
> >>> Lakshminath
> >>>
> >>> PS:  I understand your concern about EAP Identity Request
> >> and we can
> >>> work on other alternatives for it where terminating the EAP state=20
> >>> machine at the Authenticator and spawning an EAP-ER state
> >> machine is
> >>> considered burdensome (there are other ways of looking at=20
> this and=20
> >>> that is written in vidya-eap-er-02).
> >>>
> >>> Madjid Nakhjiri wrote:
> >>>  > Hi,
> >>>  >
> >>>  > I like to seek a clarification here first.
> >>>  > Have we put the discussion of use of EAP code versus EAP
> >> types to
> >>> bed,  > completely satisfied that EAP types will absolutely
> >> not solve
> >>> the problems?
> >>>  >
> >>>  > Given that the Russ only first gave the few of us=20
> present in San=20
> >>> Jose the  > green light to change EAP, I feel that we did=20
> not quite=20
> >>> discuss the impact  > of adding new EAP codes versus other
> >> changes to
> >>> an end.  A simple analysis  > shows (I have confirmed this with=20
> >>> several EAP experts) that using a new EAP  > type and adding some=20
> >>> payload to EAP success you can easily achieve near 1  > roundtrip=20
> >>> exchanges. I can forward that analysis in a separate email.
> >>>  >
> >>>  > It is not clear whether adding data to EAP success is
> >> more severe
> >>> than the  > changes that EAP-ER is suggesting, to name a few:
> >>>  >
> >>>  > 1) adding new codes even though 3748 mandates a discard
> >> code>4  >
> >>> 2) change of authenticator state machine to treat EAP ER
> >> Request as a
> >>>> response to EAP Identity request. This seems a lot more
> >> intrusive on
> >>> the  > massive scale of existing authenticators, than
> >> adding data to
> >>> EAP success  > intended for the peer.
> >>>  >
> >>>  > It seems that before fully deciding the EAP code=20
> versus EAP type=20
> >>> options, it  > is hard to make a judgement on a solution
> >> that is based
> >>> on EAP code.
> >>> After
> >>>  > that, there are issues such as identity exchanges that
> >> are needed
> >>> for key  > derivation according to the EMSK draft and it=20
> seems that=20
> >>> EAP-ER is  > considering those out of band or requires
> >> explicit additional signaling.
> >>>  >
> >>>  > Finally the other clarification I am seeking is regarding the=20
> >>> second  > document, don't we want to specify how the
> >> per-authenticator
> >>> keys are  > derived? It seems that it should be included in
> >> the second spec as well.
> >>>  >
> >>>  > R,
> >>>  >
> >>>  > Madjid
> >>>  >
> >>>  > -----Original Message-----
> >>>  > From: Charles Clancy [mailto:clancy@cs.umd.edu]  > Sent:=20
> >> Saturday,
> >>> March 31, 2007 11:58 AM  > To: hokey@ietf.org  > Subject: [HOKEY]=20
> >>> consensus call: EAP-ER as HOKEY protocol  >  > HOKEY WG, =20
> >  > The=20
> >>> chairs are making a second consensus call request to adopt
> >> EAP-ER as
> >>>> a WG document to satisfy our re-auth and hand-off
> >> deliverables.  It
> >>>> would serve as a starting point for development of the
> >> HOKEY protocol.
> >>>  >
> >>>  > Note that if accepted, it may be split into two WG documents,=20
> >>> separating  > the EAP-ER-Bootstrap into a second set of
> >> messages that
> >>> could be  > transported by any service to obtain a USRK or DSUSRK.
> >>>  >
> >>>  > Please respond by Friday, April 13.
> >>>  >
> >>>
> >>> _______________________________________________
> >>> 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
> >>
> >=20
>=20

_______________________________________________
HOKEY mailing list
HOKEY@ietf.org
https://www1.ietf.org/mailman/listinfo/hokey



From hokey-bounces@ietf.org Wed Apr 04 12:40: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 1HZ8XQ-0005mk-4P; Wed, 04 Apr 2007 12:40:48 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ8XO-0005mY-Jz
	for hokey@ietf.org; Wed, 04 Apr 2007 12:40:46 -0400
Received: from numenor.qualcomm.com ([129.46.51.58])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZ8XH-0005QM-9V
	for hokey@ietf.org; Wed, 04 Apr 2007 12:40:46 -0400
Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158])
	by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id
	l34GeTtQ032640
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 4 Apr 2007 09:40:30 -0700
Received: from [10.50.77.81] (qconnect-10-50-77-81.qualcomm.com [10.50.77.81])
	by totoro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id
	l34GeSEn005588
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Wed, 4 Apr 2007 09:40:29 -0700 (PDT)
Message-ID: <4613D4FC.3060709@qualcomm.com>
Date: Wed, 04 Apr 2007 09:40:28 -0700
From: Lakshminath Dondeti 
User-Agent: Thunderbird 2.0b2 (Windows/20070116)
MIME-Version: 1.0
To: "Hao Zhou (hzhou)" 
Subject: Re: [HOKEY] consensus call: EAP-ER as HOKEY protocol
References: <002701c7757c$ea5d0e30$2f01a8c0@china.huawei.com>,
	<4611C658.7050603@qualcomm.com>
	<461289A3.3000901@qualcomm.com>
	<9958B444368E884DBB215F3FEF36F5B7041F9D64@xmb-rtp-212.amer.cisco.com>
	<4612BF90.3080901@qualcomm.com>
	<9958B444368E884DBB215F3FEF36F5B7041F9F6F@xmb-rtp-212.amer.cisco.com>
In-Reply-To: <9958B444368E884DBB215F3FEF36F5B7041F9F6F@xmb-rtp-212.amer.cisco.com>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 089da5e32269fece1072c9ff54523f20
Cc: Madjid Nakhjiri , 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

Hao,

Thanks for your clarifications.  Please see inline (there is a disconnect):

Hao Zhou (hzhou) wrote:
> Lakshminath:
> 
> Please see inline. 
> 
>> -----Original Message-----
>> From: Lakshminath Dondeti [mailto:ldondeti@qualcomm.com] 
>> Sent: Tuesday, April 03, 2007 4:57 PM
>> To: Hao Zhou (hzhou)
>> Cc: Avi Lior; hokey@ietf.org; Madjid Nakhjiri
>> Subject: Re: [HOKEY] consensus call: EAP-ER as HOKEY protocol
>>
>> Hi Hao,
>>
>> Thanks for proposing the detailed solution.  On a first look, 
>> it might seem to offer the benefits you list, but a closer 
>> look reveals serious
>> problems:
>>
>> 1. EAP-Request/Identity does have a provision to carry stuff 
>> after the NUL character.  There seems to be contention by 
>> various use cases for that space.  That is a problem.  More 
>> specifically, 4284 cannot be used with reauthentication.
>>
> [HZ] I don't see there is a contention, other than the size limitation.
> RFC4284 defines it own syntax "NAIRealms=", for HOAKEY we can define our
> own syntax. They can coexist. And we are not using RFC4284 (only using
> idea similar to it) and thus not limited to initial authentication.

There is of course contention for space :) .  As you note there is a 
size limitation and several different protocols may want to use that 
space; further, there is no clear format other than include text after 
the NUL character.  3748 documents some legacy uses (doesn't say what 
those are), there is the 4284 provision and now your proposal.  (Note 
draft-barany-eap-gee also considers the use of 4284 style hints).

All told, if there is a simple way of including HOKEY capability 
declaration in EAP Request/Identity messages, I am not opposed to that 
(at some point I may have even said that).  On the other hand, some 
lower layers have extensive capability negotiation; for those a simple 
maintenance extension for HOKEY is not out of the question.


> 
>> 2. EAP-Response/Identity does not have a provision to carry 
>> additional data.  That is a change to 3748's text.
>>
> [HZ] I am talking about carry data inside the response, as part of the
> response, like Avi pointed out. It doesn't conflict with RFC3748.

I asked Avi for clarification.  His notes so far indicate that he is 
talking about overloading the NAI payload.  It is not the same thing as 
you are talking about.  Next, 3748-compliant implementations won't know 
what to do.  That automatically means that a revision to 3748 is needed 
if this were to be the path HOKEY chooses.  Do you agree?

> 
>> 3. EAP Success retransmission semantics need to change.  This 
>> means changes to the authenticator.  So, backward 
>> compatibility arguments are not applicable.
>>
> [HZ] I guess you missed my point. Legacy authenticator and/or client
> would never receive the EAP-Success with optional data, only the regular
> EAP-Success, as HOAKEY will not happen for them and they will start a
> normal EAP authentication. Only new client and NAS that are HOAKEY
> capable will see this and know how to handle them. 

Ok, let's see:

Case 1: Legacy client, HOKEY capable authenticator:

Piggybacking approach: Client receives an EAP Request/Identity with 
HOKEY capability.  It may not be able to parse the new stuff and if it 
were to be gracious in what it accepts, sends a 3748-compliant EAP 
Response/Identity.  Full authentication occurs.  If the client were not 
gracious it may crash or discard the Request message.

EAP-ER: Client negotiates full EAP only at the lower layer; or, if we 
use the piggybacking approach will behave more or less the same as above.

Case 2: HOKEY capable client, legacy authenticator:

Piggybacking approach: Client receives an EAP Request/Identity without 
HOKEY capability.  There are at least two cases: in the first, 4284 
hints and other stuff has filled up the EAP Request/Identity packet 
capacity and the client has no way of knowing whether the authenticator 
supports HOKEY capability or not.  In the second, the client knows that 
the authenticator does or doesn't support HOKEY and carries out 
reauthentication or full authentication.

EAP-ER: Client knows based on lower layer negotiation whether EAP-ER is 
supported and proceeds to use reauthentication or full authentication.

It may be plausible to introduce an EAP-ER trigger: one such possibility 
is to use what you propose, i.e., send EAP Request/Identity with HOKEY 
capability.  The considerations I elaborated above apply.

So, I see the whole backward compatibility thing as a non issue.

>  
>> Bottomline is the authenticator behavior is going to be 
>> changed one way or another.  We reviewed all of this at the 
>> interim meeting.  As to one new code vs. two, one of the 
>> older versions of EAP-ER did have one code. 
>>   The current version is a result of the discussions at the 
>> interim meeting.  I think the minutes covered the reasoning.
>>
> [HZ] Is your assumption that HOAKEY will only work on new EAP lower
> layer, hence both client and authenticator will change and include
> capability negotiation, and hence don't have to worry about legacy
> client or authentication? My proposal works with legacy client and
> authenticator. 

Please see above.  Sure I appreciate the notion of adding 4284 style 
hints (my recollection is that it was mentioned before, but I am happy 
to call it your proposal), but there are limitations to it.  4284 itself 
was a semi-solution (that RFC says that much) or a semi-hack depending 
on how one looks at it.

> 
>> As to minimizing lower layer changes and being able to signal 
>> HOKEY capability in EAP, let's talk about that separately.
>>
>> My goals here are to minimize modifications to the EAP state machine. 
> [HZ] I don't see adding two new codes will minimize the modifications to
> EAP state machine, vs. reusing the existing codes.

That sentence was constructed with some care: note the words 
"modifications" and "EAP state machine".  Put another way, the idea is 
to "add" a new "EAP-ER state machine."

Consider the complexity in making EAP Success reliable.  Suppose the 
HOKEY-capable peer doesn't receive the Success message with the 
additional data; what does it do?

> 
>> Additions are always better and cleaner than modifying the 
>> protocol behavior.  Suppose some other use case comes along 
>> in the future and modifies EAP in a different way.  What happens then?
> [HZ] If we really think of a solution to be more generic, then we
> probably should look at extending the EAP packet, maybe allowing
> carrying of other data, instead of creating two new codes just for
> HOAKEY.

Like I said before, if the hangup is two vs. one, that can be discussed 
as part of WG proceedings.  We had that discussion once before.

Again, extensions to EAP packets have limitations and introduce serious 
complexity; we have at least two examples: on Request/Identity there is 
a space contention.  The other thing is extending Success is a can of 
worms.  One reason is the retransmission complexity and the other thing 
is other protocols may want to add stuff to that message.  Protected 
result indications via EAP come to mind.

Finally, we have space for 252 new codes.  Why is using 2 new codes for 
as important an application as HOKEY a big deal?  After all, the IETF 
chartered a whole new WG to do that work!

Many thanks for elaborating the ideas behind the piggybacking exchange. 
  It has been helpful to me to understand fully what it entails (I must 
say Vidya and I have debated about this in the past and ruled out this 
direction; for instance, one of the long and painful debates was on how 
one might make EAP success reliable.  Can it be done?  Yes.  But, it 
requires serious changes to 3748 behavior and I strongly think that 
those changes are not worthwhile.  The code based approach is definitely 
cleaner!)

regards,
Lakshminath

> 
>> thanks,
>> Lakshminath
>>
>> Hao Zhou (hzhou) wrote:
>>> I have been soliciting with a few others about the idea of using 
>>> existing EAP codes to do HOAKEY, instead of creating new EAP codes. 
>>> The idea is roughly like this:
>>>
>>> 1. NAS still sends out EAP-Identity request, with something in the 
>>> request to indicate HOAKEY support. Something similar to 
>> how network 
>>> selection RFC utilizing the space after NULL character. The 
>> extra data 
>>> would include HOAKEY capability, as well as any other information 
>>> needed, e.g., domain ID, etc.
>>>
>>> 2. Client send back normal EAP-Identity Response, piggybacking any 
>>> HOAKEY data needed, e.g., agreement to do HOAKEY and any 
>> HOAKEY keying 
>>> materials.
>>>
>>> 3. If the NAS determine that client wants to do HOAKEY, then it 
>>> forwards the HOAKEY data to the HOAKEY server. Otherwise, it starts 
>>> the normal full EAP authentication.
>>>
>>> 4. After HOAKEY server sends back the server data, NAS sends 
>>> EAP-Success with additional HOAKEY data, which allows the client to 
>>> verify and authenticate the NAS.
>>>
>>> The benefits of using this approach are:
>>>
>>> 1. Maximum backward compatibility with legacy NAS and 
>> client. Existing 
>>> client should work with new HOAKEY NAS and existing NAS would work 
>>> with new HOAKEY capable client.
>>> 2. Less changes on the EAP lower layer on both the client 
>> and NAS. The 
>>> only change is to allow additional data to be piggy-backed on 
>>> EAP-Success, vs. current EAP-ER proposal of two new EAP codes.
>>> 3. HOAKEY capability negotiation and domain ID transmission is also 
>>> included this way, instead of being mandated to be added to 
>> lower layer.
>>> The lower layer is probably harder to change.
>>> 4. I don't think the half round trip for EAP-Identity request and 
>>> response would hurt performance too much and critical, as 
>> it is local 
>>> between the client and NAS. Modifying the lower layer to 
>> allow client 
>>> initiating exchange might be too much for some lower layer.
>>> 5. Even if piggybacking data on EAP-Success is determined to be 
>>> impossible and we need a new EAP code, we should still just 
>> create a 
>>> single new code for the EAP-Success with optional data, 
>> this way, only 
>>> the new HOAKEY capable NAS and client needs to understand 
>> and support 
>>> it. I would recommend still using the EAP-Identity request-response 
>>> exchange for the first part. The goal is to minimize changes to EAP 
>>> flow and state machine and EAP lower layer as little as possible.
>>>
>>>> -----Original Message-----
>>>> From: Lakshminath Dondeti [mailto:ldondeti@qualcomm.com]
>>>> Sent: Tuesday, April 03, 2007 1:07 PM
>>>> To: Avi Lior
>>>> Cc: hokey@ietf.org; Madjid Nakhjiri
>>>> Subject: Re: [HOKEY] consensus call: EAP-ER as HOKEY protocol
>>>>
>>>> Hi Avi,
>>>>
>>>> I find some of your arguments counter-intuitive and so 
>> would like to 
>>>> understand your line of thinking on this topic.
>>>> Modifications to a protocol to my knowledge would be hacks and 
>>>> extensions are well, extensions.  For instance, the EAP 
>>>> Request/Identity message suspension in EAP-ER, as much as I would 
>>>> like to defend it, is somewhat of a hack.
>>>>   It is the cleanest Vidya and I could come up with in the 
>> sense that 
>>>> the message itself is not modified, but we need something 
>> like it to 
>>>> make sure that the L2 connection is not closed if the 
>> retransmission 
>>>> time expires.  Perhaps the wider community might find a better 
>>>> approach.
>>>>
>>>> Next, some notes on 4284 since that has come up here:
>>>>
>>>> 3748 says "Some EAP implementations piggy-back various 
>> options into 
>>>> the
>>>>        Identity Request after a NUL-character. "
>>>>
>>>> 4284 uses that provision.  In any event, 4284 is somewhat 
>> of a hack 
>>>> and is an informational RFC for the purposes of 3GPP's use.
>>>>
>>>> Please see inline for some questions:
>>>>
>>>> Avi Lior wrote:
>>>>> I for one thinks we should look at allowing us to carry 
>> data in EAP 
>>>>> success.  In fact, it would be a good idea if we allowed
>>>> EAP to carry
>>>>> data which is not part of the method in all exchanges.
>>>> If the data is not part of the method, which entity needs to send 
>>>> such data and how is it protected?
>>>>
>>>>> Clearly there is a need to communicate with the Peer before
>>>> and just
>>>>> after authentication.  There is no other path to the Peer.  
>>>> EAP should
>>>>> have addressed this.
>>>> Again which entity needs to communicate with the Peer?
>>>>
>>>>>  
>>>>> We already see this happening in the Request Identity (as
>>>> in Network
>>>>> Selection and other such usage), in the Repsonse Identity
>>>> and now in
>>>>> the Success phase.
>>>>>  
>>>>> We can continue to "hack" EAP but we can also fix it.
>>>> I am lost here, so please help me out :).  The network selection 
>>>> solution of 4284 is a hack IMO.  If you are saying we 
>> should revise 
>>>> 3748, I might agree with you in principle.
>>>> But, practically speaking that is not happening anytime soon.
>>>>
>>>> Next, RFC 3748 has clear guidance on allocating new packet 
>> codes in 
>>>> Section 6.1.  Defining new codes is a natural way of 
>> extending EAP.  
>>>> If the goal is backward compatibility, adding stuff to EAP Success 
>>>> doesn't help either.  As I have noted before, EAP Success 
>> packets are 
>>>> not retransmitted by authenticators and that would have to 
>> change if 
>>>> we add anything crucial to Success packets.
>>>>
>>>> I appreciate any clarifications you might provide to help me 
>>>> understand your point of view here.  Thanks.
>>>>
>>>> regards,
>>>> Lakshminath
>>>>
>>>>>  
>>>>> I am not saying EAP-ER is a hack but it is not efficient 
>> because it 
>>>>> works around the existing EAP semantics but hopefully we
>>>> could do better.
>>>>>  
>>>>> Avi Lior Office: +1 613 591-9104 x 6417 Cell : +1 613 796-4183
>>>>>
>>>>>
>>>>>
>> ---------------------------------------------------------------------
>>>> -
>>>>> --
>>>>> *From:* Lakshminath Dondeti
>>>>> *Sent:* Mon 4/2/2007 11:13 PM
>>>>> *To:* Madjid Nakhjiri
>>>>> *Cc:* hokey@ietf.org
>>>>> *Subject:* Re: [HOKEY] consensus call: EAP-ER as HOKEY protocol
>>>>>
>>>>> Many of the active WG contributors were present at the
>>>> interim meeting
>>>>> and there was a presentation and discussion on how 
>> reauthentication 
>>>>> might work with new EAP types or codes.  The consensus was that 
>>>>> code-based approach works best and that consensus was 
>> subsequently 
>>>>> verified on the list.
>>>>>
>>>>> Well, here we are.  I am also looking forward to seeing
>>>> your analysis
>>>>> on this topic.  Changing the structure of the EAP Success
>>>> message and
>>>>> also the transmission rules for EAP Success are quite
>>>> drastic changes.  
>>>>> If EAP Success needs to be reliably transmitted, authenticator 
>>>>> behavior would have to change.  Consider the following
>>>> rules on EAP Success messages:
>>>>> "The peer
>>>>>     MAY, in the event that an EAP Success is not received,
>>>> conclude that
>>>>>     the EAP Success packet was lost and that authentication
>>>> concluded
>>>>>     successfully."
>>>>>
>>>>> "Success and Failure packets MUST NOT
>>>>>     contain additional data."
>>>>>
>>>>> "Because the Success and Failure packets are not
>>>>>     acknowledged, they are not retransmitted by the
>>>> authenticator, and
>>>>>     may be potentially lost.  A peer MUST allow for this
>>>> circumstance as
>>>>>     described in this note. "
>>>>>
>>>>> Anyway, I still want to see your analysis of this.
>>>>>
>>>>> thanks,
>>>>> Lakshminath
>>>>>
>>>>> PS:  I understand your concern about EAP Identity Request
>>>> and we can
>>>>> work on other alternatives for it where terminating the EAP state 
>>>>> machine at the Authenticator and spawning an EAP-ER state
>>>> machine is
>>>>> considered burdensome (there are other ways of looking at 
>> this and 
>>>>> that is written in vidya-eap-er-02).
>>>>>
>>>>> Madjid Nakhjiri wrote:
>>>>>  > Hi,
>>>>>  >
>>>>>  > I like to seek a clarification here first.
>>>>>  > Have we put the discussion of use of EAP code versus EAP
>>>> types to
>>>>> bed,  > completely satisfied that EAP types will absolutely
>>>> not solve
>>>>> the problems?
>>>>>  >
>>>>>  > Given that the Russ only first gave the few of us 
>> present in San 
>>>>> Jose the  > green light to change EAP, I feel that we did 
>> not quite 
>>>>> discuss the impact  > of adding new EAP codes versus other
>>>> changes to
>>>>> an end.  A simple analysis  > shows (I have confirmed this with 
>>>>> several EAP experts) that using a new EAP  > type and adding some 
>>>>> payload to EAP success you can easily achieve near 1  > roundtrip 
>>>>> exchanges. I can forward that analysis in a separate email.
>>>>>  >
>>>>>  > It is not clear whether adding data to EAP success is
>>>> more severe
>>>>> than the  > changes that EAP-ER is suggesting, to name a few:
>>>>>  >
>>>>>  > 1) adding new codes even though 3748 mandates a discard
>>>> code>4  >
>>>>> 2) change of authenticator state machine to treat EAP ER
>>>> Request as a
>>>>>> response to EAP Identity request. This seems a lot more
>>>> intrusive on
>>>>> the  > massive scale of existing authenticators, than
>>>> adding data to
>>>>> EAP success  > intended for the peer.
>>>>>  >
>>>>>  > It seems that before fully deciding the EAP code 
>> versus EAP type 
>>>>> options, it  > is hard to make a judgement on a solution
>>>> that is based
>>>>> on EAP code.
>>>>> After
>>>>>  > that, there are issues such as identity exchanges that
>>>> are needed
>>>>> for key  > derivation according to the EMSK draft and it 
>> seems that 
>>>>> EAP-ER is  > considering those out of band or requires
>>>> explicit additional signaling.
>>>>>  >
>>>>>  > Finally the other clarification I am seeking is regarding the 
>>>>> second  > document, don't we want to specify how the
>>>> per-authenticator
>>>>> keys are  > derived? It seems that it should be included in
>>>> the second spec as well.
>>>>>  >
>>>>>  > R,
>>>>>  >
>>>>>  > Madjid
>>>>>  >
>>>>>  > -----Original Message-----
>>>>>  > From: Charles Clancy [mailto:clancy@cs.umd.edu]  > Sent: 
>>>> Saturday,
>>>>> March 31, 2007 11:58 AM  > To: hokey@ietf.org  > Subject: [HOKEY] 
>>>>> consensus call: EAP-ER as HOKEY protocol  >  > HOKEY WG,  
>>>  > The 
>>>>> chairs are making a second consensus call request to adopt
>>>> EAP-ER as
>>>>>> a WG document to satisfy our re-auth and hand-off
>>>> deliverables.  It
>>>>>> would serve as a starting point for development of the
>>>> HOKEY protocol.
>>>>>  >
>>>>>  > Note that if accepted, it may be split into two WG documents, 
>>>>> separating  > the EAP-ER-Bootstrap into a second set of
>>>> messages that
>>>>> could be  > transported by any service to obtain a USRK or DSUSRK.
>>>>>  >
>>>>>  > Please respond by Friday, April 13.
>>>>>  >
>>>>>
>>>>> _______________________________________________
>>>>> 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 Wed Apr 04 14:16: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 1HZA1y-0002eQ-2K; Wed, 04 Apr 2007 14:16:26 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HZA1x-0002eK-FF
	for hokey@ietf.org; Wed, 04 Apr 2007 14:16:25 -0400
Received: from numenor.qualcomm.com ([129.46.51.58])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HZA1u-00074e-9K
	for hokey@ietf.org; Wed, 04 Apr 2007 14:16:24 -0400
Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158])
	by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id
	l34IGBVV012897
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 4 Apr 2007 11:16:11 -0700
Received: from sanexcas01.na.qualcomm.com (sanexcas01.qualcomm.com
	[172.30.36.175])
	by totoro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l34IGAqY020645;
	Wed, 4 Apr 2007 11:16:10 -0700 (PDT)
Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by
	sanexcas01.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 4 Apr 2007 11:16:10 -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
Subject: RE: [HOKEY] consensus call: key distribution security requirement
Date: Wed, 4 Apr 2007 11:16:09 -0700
Message-ID: 
In-Reply-To: <20070404024453.GA18289@steelhead>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [HOKEY] consensus call: key distribution security requirement
Thread-Index: Acd2Y2I8lRlBrgBmT02uyEWI0+tVTwAgVBwA
References: <460EB36E.5010604@cs.umd.edu>
	
	<20070404024453.GA18289@steelhead>
From: "Narayanan, Vidya" 
To: "Yoshihiro Ohba" 
X-OriginalArrivalTime: 04 Apr 2007 18:16:10.0480 (UTC)
	FILETIME=[525D8F00:01C776E5]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab
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 Yoshi,=20

> -----Original Message-----
> From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com]=20
> Sent: Tuesday, April 03, 2007 7:45 PM
> To: Narayanan, Vidya
> Cc: Charles Clancy; hokey@ietf.org
> Subject: Re: [HOKEY] consensus call: key distribution=20
> security requirement
>=20
> Hi Vidya,
>=20
> Can you please explain why channel binding information must=20
> be optional?
>=20

Briefly, in many cases, as long as the peer receives a certain level of
service and is charged for the same, the identity of the network entity
providing the service is irrelevant. In some cases, it may be relevant
and hence, it would be good to have the capability to do channel
binding. But, for the other cases, there is no need to mandate the lower
layer to advertise identities.=20

> Can you also explain in which system there are no adverse=20
> effects in key distribution without explicit peer consent?
>=20

I have not seen any real loss of security properties in distribution of
keys without peer consent, as long as the keys are scoped correctly, not
shared and freshness is always ensured.=20

Please see
http://www.geocities.com/hellovidya/Authenticators_and_Identities.pdf if
you are interested in more details. I had put some slides together a
while ago on this identities issue.=20

Vidya

> Regards,
> Yoshihiro Ohba
>=20
>=20
> On Tue, Apr 03, 2007 at 06:25:52PM -0700, Narayanan, Vidya wrote:
> > I'm barely caught up on all the email after having been on vacation=20
> > until now, so, pardon me if I'm bringing up stuff that's=20
> already been=20
> > discussed here.
> >=20
> > I share some of Glen's concerns about "requiring" peer=20
> consent and a=20
> > 3-party protocol and about how practically deployable that=20
> is. In my=20
> > conversations with Dan in Prague, it seemed like we were on=20
> the same=20
> > page about including channel binding information in the=20
> HOKEY protocol=20
> > between the peer and server. I think such channel binding=20
> information=20
> > must be optional and not required. In some systems, there are no=20
> > adverse effects of distribution of key material without=20
> explicit peer=20
> > consent and there is no reason to place upper layer identity=20
> > advertisement requirements on the lower layers for such systems. In=20
> > some other systems, it may be a good idea to do so and having the=20
> > capability to do that in the protocol would be useful there.
> >=20
> > To specifically answer your question, I don't believe we need to=20
> > update the problem statement. It already captures the=20
> channel binding=20
> > stuff and the explicit data that the peer and authenticator may=20
> > include is one way of providing channel binding.
> >=20
> > Vidya
> >=20
> > > -----Original Message-----
> > > From: Charles Clancy [mailto:clancy@cs.umd.edu]
> > > Sent: Saturday, March 31, 2007 12:16 PM
> > > To: hokey@ietf.org
> > > Subject: [HOKEY] consensus call: key distribution security=20
> > > requirement
> > >=20
> > > HOKEY WG,
> > >=20
> > > The 3-party protocol proposal at IETF 68 listed a variety of=20
> > > protocol requirements, some of which went beyond those currently=20
> > > specified in the problem statements draft.  The main=20
> extension was a=20
> > > requirement for stronger key distribution security.
> > >=20
> > > Discussion: The problem statements document currently requires=20
> > > channel bindings to allow clients to authenticate the network to=20
> > > which they are connecting, and prevent the lying NAS problem. =20
> > > However one possible implementation of channel bindings=20
> would allow=20
> > > keys to be distributed prior to the network being=20
> authenticated by=20
> > > the peer.  While the peer may decide to not use a network=20
> after it's=20
> > > validated its identity, network entities could retain the keying=20
> > > material.
> > > There has been much debate on the list as to whether or=20
> not network=20
> > > entities could maliciously use this keying material, and=20
> the intent=20
> > > here is to not rehash all that discussion.
> > >=20
> > > Question: Should additional text be added to the problem=20
> statement=20
> > > draft
> > >   to require peer authorization for distributing keying material?
> > >=20
> > > Protocol Implications: If "yes" then a 3-party protocol would be=20
> > > need, and would require L2 advertisement of the NAS-ID=20
> and local AAA=20
> > > domain name.  If "no" then channel bindings where identities are=20
> > > hashed into the key derivation would be sufficient.
> > >=20
> > > --
> > > t. charles clancy, ph.d.  <>  tcc@umd.edu  <> =20
> > > www.cs.umd.edu/~clancy
> > >=20
> > >=20
> > > _______________________________________________
> > > HOKEY mailing list
> > > HOKEY@ietf.org
> > > https://www1.ietf.org/mailman/listinfo/hokey
> > >=20
> >=20
> > _______________________________________________
> > HOKEY mailing list
> > HOKEY@ietf.org
> > https://www1.ietf.org/mailman/listinfo/hokey
> >=20
> >=20
>=20

_______________________________________________
HOKEY mailing list
HOKEY@ietf.org
https://www1.ietf.org/mailman/listinfo/hokey



From hokey-bounces@ietf.org Wed Apr 04 19:24:34 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HZEq2-0004qH-G2; Wed, 04 Apr 2007 19:24:26 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HZEq1-0004q9-6e
	for hokey@ietf.org; Wed, 04 Apr 2007 19:24:25 -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 1HZEpy-0001y1-Lq
	for hokey@ietf.org; Wed, 04 Apr 2007 19:24:25 -0400
Received: from www.trepanning.net (localhost [127.0.0.1])
	by mail1.trepanning.net (Postfix) with ESMTP id 855241FA674A;
	Wed,  4 Apr 2007 16:24:10 -0700 (PDT)
Received: from 12.108.168.179
	(SquirrelMail authenticated user dharkins@lounge.org)
	by www.trepanning.net with HTTP; Wed, 4 Apr 2007 16:24:11 -0700 (PDT)
Message-ID: <7030.12.108.168.179.1175729051.squirrel@www.trepanning.net>
In-Reply-To: 
References: <460EB36E.5010604@cs.umd.edu>
	
	<20070404024453.GA18289@steelhead>
	
Date: Wed, 4 Apr 2007 16:24:11 -0700 (PDT)
Subject: RE: [HOKEY] consensus call: key distribution security requirement
From: "Dan Harkins" 
To: "Narayanan, Vidya" 
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: 9af087f15dbdd4c64ae6bbcdbc5b1d44
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 Vidya,

  As I explained to you previously the issue of "peer detects mismatch
during secure association protocol" (slide 5 of your deck) doesn't work
because these are symmetric keys and the "middle entity" can impersonate
the client now. Every single property that you want to give to the key
being distributed is lost.

  Of course you may not view that as a problem but I think that has more
to do with what you want to do then with whether it's secure or not.

  Can you please explain how to ensure that keys are properly scoped
if you do not bind the scoping information to the exchange that distribut=
es
the key? How can the peer have any assurance that the key is "not shared"
(one of the qualifiers you mention) if it did not take part in the
distribution of its key?

  Why not just send the EMSK to every entity that the AS thinks it has a
security association with? I mean, in many cases as long as the peer
receives a certain level of service and is charged for same then the
identity of the entity receiving the EMSK is irrelevant and channel
binding isn't important and as long as we scope the key properly
(everyone with whom the AS shares a security association-- aka "the
network") then it's OK. After all, nothing matters as long as the peer
is satisfied and "if the peer is not satisfied or there is a billing
issue, it contacts its home network and tries to get service from some
other node instead" (to quote from slide #6).

  Dan.

On Wed, April 4, 2007 11:16 am, Narayanan, Vidya wrote:
> Hi Yoshi,
>
>> -----Original Message-----
>> From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com]
>> Sent: Tuesday, April 03, 2007 7:45 PM
>> To: Narayanan, Vidya
>> Cc: Charles Clancy; hokey@ietf.org
>> Subject: Re: [HOKEY] consensus call: key distribution
>> security requirement
>>
>> Hi Vidya,
>>
>> Can you please explain why channel binding information must
>> be optional?
>>
>
> Briefly, in many cases, as long as the peer receives a certain level of
> service and is charged for the same, the identity of the network entity
> providing the service is irrelevant. In some cases, it may be relevant
> and hence, it would be good to have the capability to do channel
> binding. But, for the other cases, there is no need to mandate the lowe=
r
> layer to advertise identities.
>
>> Can you also explain in which system there are no adverse
>> effects in key distribution without explicit peer consent?
>>
>
> I have not seen any real loss of security properties in distribution of
> keys without peer consent, as long as the keys are scoped correctly, no=
t
> shared and freshness is always ensured.
>
> Please see
> http://www.geocities.com/hellovidya/Authenticators_and_Identities.pdf i=
f
> you are interested in more details. I had put some slides together a
> while ago on this identities issue.
>
> Vidya
>
>> Regards,
>> Yoshihiro Ohba
>>
>>
>> On Tue, Apr 03, 2007 at 06:25:52PM -0700, Narayanan, Vidya wrote:
>> > I'm barely caught up on all the email after having been on vacation
>> > until now, so, pardon me if I'm bringing up stuff that's
>> already been
>> > discussed here.
>> >
>> > I share some of Glen's concerns about "requiring" peer
>> consent and a
>> > 3-party protocol and about how practically deployable that
>> is. In my
>> > conversations with Dan in Prague, it seemed like we were on
>> the same
>> > page about including channel binding information in the
>> HOKEY protocol
>> > between the peer and server. I think such channel binding
>> information
>> > must be optional and not required. In some systems, there are no
>> > adverse effects of distribution of key material without
>> explicit peer
>> > consent and there is no reason to place upper layer identity
>> > advertisement requirements on the lower layers for such systems. In
>> > some other systems, it may be a good idea to do so and having the
>> > capability to do that in the protocol would be useful there.
>> >
>> > To specifically answer your question, I don't believe we need to
>> > update the problem statement. It already captures the
>> channel binding
>> > stuff and the explicit data that the peer and authenticator may
>> > include is one way of providing channel binding.
>> >
>> > Vidya
>> >
>> > > -----Original Message-----
>> > > From: Charles Clancy [mailto:clancy@cs.umd.edu]
>> > > Sent: Saturday, March 31, 2007 12:16 PM
>> > > To: hokey@ietf.org
>> > > Subject: [HOKEY] consensus call: key distribution security
>> > > requirement
>> > >
>> > > HOKEY WG,
>> > >
>> > > The 3-party protocol proposal at IETF 68 listed a variety of
>> > > protocol requirements, some of which went beyond those currently
>> > > specified in the problem statements draft.  The main
>> extension was a
>> > > requirement for stronger key distribution security.
>> > >
>> > > Discussion: The problem statements document currently requires
>> > > channel bindings to allow clients to authenticate the network to
>> > > which they are connecting, and prevent the lying NAS problem.
>> > > However one possible implementation of channel bindings
>> would allow
>> > > keys to be distributed prior to the network being
>> authenticated by
>> > > the peer.  While the peer may decide to not use a network
>> after it's
>> > > validated its identity, network entities could retain the keying
>> > > material.
>> > > There has been much debate on the list as to whether or
>> not network
>> > > entities could maliciously use this keying material, and
>> the intent
>> > > here is to not rehash all that discussion.
>> > >
>> > > Question: Should additional text be added to the problem
>> statement
>> > > draft
>> > >   to require peer authorization for distributing keying material?
>> > >
>> > > Protocol Implications: If "yes" then a 3-party protocol would be
>> > > need, and would require L2 advertisement of the NAS-ID
>> and local AAA
>> > > domain name.  If "no" then channel bindings where identities are
>> > > hashed into the key derivation would be sufficient.
>> > >
>> > > --
>> > > t. charles clancy, ph.d.  <>  tcc@umd.edu  <>
>> > > www.cs.umd.edu/~clancy
>> > >
>> > >
>> > > _______________________________________________
>> > > 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
>



_______________________________________________
HOKEY mailing list
HOKEY@ietf.org
https://www1.ietf.org/mailman/listinfo/hokey



From hokey-bounces@ietf.org Wed Apr 04 19:26:22 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HZErt-0005E1-VC; Wed, 04 Apr 2007 19:26:21 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HZErt-0005D2-3H
	for hokey@ietf.org; Wed, 04 Apr 2007 19:26:21 -0400
Received: from usaga01-in.huawei.com ([206.16.17.211])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZErq-000357-81
	for hokey@ietf.org; Wed, 04 Apr 2007 19:26:21 -0400
Received: from huawei.com (usaga01-in [172.18.4.6])
	by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTP id <0JFZ00LZEYFTHF@usaga01-in.huawei.com> for
	hokey@ietf.org; Wed, 04 Apr 2007 16:26:18 -0700 (PDT)
Received: from N737011
	(pool-71-112-121-192.sttlwa.dsl-w.verizon.net [71.112.121.192])
	by usaga01-in.huawei.com
	(iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar  3 2004))
	with ESMTPA id <0JFZ00J9LYFPIK@usaga01-in.huawei.com> for
	hokey@ietf.org; Wed, 04 Apr 2007 16:26:17 -0700 (PDT)
Date: Wed, 04 Apr 2007 16:26:18 -0700
From: Madjid Nakhjiri 
Subject: RE: [HOKEY] consensus call: key distribution security requirement
In-reply-to: <460EB36E.5010604@cs.umd.edu>
To: 'Charles Clancy' , hokey@ietf.org
Message-id: <002401c77710$a653a470$2f01a8c0@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962
X-Mailer: Microsoft Office Outlook 11
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Thread-index: AcdzyRdOsQHSZTw3R5ql8QnWAWvaPADRb81A
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024
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,

The 3party key distribution protocol provide somewhere around 8-9
requirements, the peer consent being only one of them, there are other
requirements that are IMO undoubtedly important for the mechanisms HOKEY is
dealing with. For example (using the numbers in the draft):

1-Confidentiality --avoiding disclosure of the keying material to passive
       and active attackers.
3-Validation of credential source -- the recipient must prove where the
credential came from and what context it was delivered for.
4-Validation of authorization -- the scope (intended users) of the
       network access credential MUST be distributed as part of the
       credential and MUST be protected to the same degree as the
       credential itself.

Some of these requirements are simply reflections of Housley document and to
me are met through a channel binding procedure.

Treating all the requirements based on the most controversial one seems to
be equivalent of pointing to one bunny (no offense to peer consent
opponents) tied next to other 7 huskies tied to a sled and then dismissing
all the huskies.

In my opinion we should treat each of these requirements individually and
not just the peer consent one and I think we will then can judge whether the
3 party distribution adds any value.

And finally to give you my personal opinion the above 3 requirements are at
least should be added to the PS document, or we should discuss to see
whether the existing PS requirements do cover these somehow.

R,

Madjid



-----Original Message-----
From: Charles Clancy [mailto:clancy@cs.umd.edu] 
Sent: Saturday, March 31, 2007 12:16 PM
To: hokey@ietf.org
Subject: [HOKEY] consensus call: key distribution security requirement

HOKEY WG,

The 3-party protocol proposal at IETF 68 listed a variety of protocol 
requirements, some of which went beyond those currently specified in the 
problem statements draft.  The main extension was a requirement for 
stronger key distribution security.

Discussion: The problem statements document currently requires channel 
bindings to allow clients to authenticate the network to which they are 
connecting, and prevent the lying NAS problem.  However one possible 
implementation of channel bindings would allow keys to be distributed 
prior to the network being authenticated by the peer.  While the peer 
may decide to not use a network after it's validated its identity, 
network entities could retain the keying material.  There has been much 
debate on the list as to whether or not network entities could 
maliciously use this keying material, and the intent here is to not 
rehash all that discussion.

Question: Should additional text be added to the problem statement draft 
  to require peer authorization for distributing keying material?

Protocol Implications: If "yes" then a 3-party protocol would be need, 
and would require L2 advertisement of the NAS-ID and local AAA domain 
name.  If "no" then channel bindings where identities are hashed into 
the key derivation would be sufficient.

-- 
t. charles clancy, ph.d.  <>  tcc@umd.edu  <>  www.cs.umd.edu/~clancy


_______________________________________________
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 Apr 04 19:32: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 1HZEy1-000536-Uf; Wed, 04 Apr 2007 19:32:41 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HZEy1-00052y-7W
	for hokey@ietf.org; Wed, 04 Apr 2007 19:32:41 -0400
Received: from usaga01-in.huawei.com ([206.16.17.211])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZExz-0007Ni-Sj
	for hokey@ietf.org; Wed, 04 Apr 2007 19:32:41 -0400
Received: from huawei.com (usaga01-in [172.18.4.6])
	by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTP id <0JFZ00LCMYQFHF@usaga01-in.huawei.com> for
	hokey@ietf.org; Wed, 04 Apr 2007 16:32:39 -0700 (PDT)
Received: from N737011
	(pool-71-112-121-192.sttlwa.dsl-w.verizon.net [71.112.121.192])
	by usaga01-in.huawei.com
	(iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar  3 2004))
	with ESMTPA id <0JFZ00JIUYQAIK@usaga01-in.huawei.com> for
	hokey@ietf.org; Wed, 04 Apr 2007 16:32:39 -0700 (PDT)
Date: Wed, 04 Apr 2007 16:32:40 -0700
From: Madjid Nakhjiri 
Subject: RE: [HOKEY] consensus call: key distribution security requirement
In-reply-to: 
To: "'Joseph Salowey (jsalowey)'" ,
	'Charles Clancy' , hokey@ietf.org
Message-id: <002501c77711$89c61d00$2f01a8c0@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962
X-Mailer: Microsoft Office Outlook 11
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Thread-index: AcdzySTnpO0vSuFcROCvGdI11glMWwCqs/KQACc3VtA=
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f66b12316365a3fe519e75911daf28a8
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

I agree with Joe here. I personally am not quite convinced that peer
explicit authorization is needed, as long as the peer and the server both
agree that they are talking to the same authenticator, we should be fine.
And some additional assurance is provided while deriving TSKs later on.

I also think that you need the identities to arrive at keys for various
domains or various authenticators (if we are still talking about key
hierarchy based on HRK, of course). In that case I don't see how the
identities can be used in key derivation, if the peer and server don't
notify each other of their own ids and don't agree on the identities that
are used in the derivations.

The 3 party process seems to be addressing a number of other requirements,
not just peer consent (which seems to be the most implicit requirement the 3
party is addressing).

R,

Madjid

-----Original Message-----
From: Joseph Salowey (jsalowey) [mailto:jsalowey@cisco.com] 
Sent: Tuesday, April 03, 2007 9:56 PM
To: Charles Clancy; hokey@ietf.org
Subject: RE: [HOKEY] consensus call: key distribution security requirement

Hi Charles, 

I see no reason to require the peer to explicitly authorize distribution
of key material.   

I'm not sure I understand how the protocol implications stated below
immediately follow.  It's not clear what "identities" you are going to
hash with the key, but whatever they are they must be known to the peer.
In addition I don't believe that explicit authorization requires a three
party protocol (but in any case I don't think it is necessary).   

Joe

> -----Original Message-----
> From: Charles Clancy [mailto:clancy@cs.umd.edu] 
> Sent: Saturday, March 31, 2007 12:16 PM
> To: hokey@ietf.org
> Subject: [HOKEY] consensus call: key distribution security requirement
> 
> HOKEY WG,
> 
> The 3-party protocol proposal at IETF 68 listed a variety of 
> protocol requirements, some of which went beyond those 
> currently specified in the problem statements draft.  The 
> main extension was a requirement for stronger key 
> distribution security.
> 
> Discussion: The problem statements document currently 
> requires channel bindings to allow clients to authenticate 
> the network to which they are connecting, and prevent the 
> lying NAS problem.  However one possible implementation of 
> channel bindings would allow keys to be distributed prior to 
> the network being authenticated by the peer.  While the peer 
> may decide to not use a network after it's validated its 
> identity, network entities could retain the keying material.  
> There has been much debate on the list as to whether or not 
> network entities could maliciously use this keying material, 
> and the intent here is to not rehash all that discussion.
> 
> Question: Should additional text be added to the problem 
> statement draft
>   to require peer authorization for distributing keying material?
> 
> Protocol Implications: If "yes" then a 3-party protocol would 
> be need, and would require L2 advertisement of the NAS-ID and 
> local AAA domain name.  If "no" then channel bindings where 
> identities are hashed into the key derivation would be sufficient.
> 
> --
> t. charles clancy, ph.d.  <>  tcc@umd.edu  <>  www.cs.umd.edu/~clancy
> 
> 
> _______________________________________________
> 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 Wed Apr 04 19:37:27 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HZF2Z-0008UK-Ak; Wed, 04 Apr 2007 19:37:23 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HZF2Y-0008UD-KD
	for hokey@ietf.org; Wed, 04 Apr 2007 19:37:22 -0400
Received: from sccrmhc13.comcast.net ([63.240.77.83])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZF2X-0001U2-Cx
	for hokey@ietf.org; Wed, 04 Apr 2007 19:37:22 -0400
Received: from [192.168.0.52]
	(c-68-49-199-146.hsd1.md.comcast.net[68.49.199.146])
	by comcast.net (sccrmhc13) with ESMTP
	id <20070404233720013003gkgbe>; Wed, 4 Apr 2007 23:37:21 +0000
Message-ID: <4614453D.9070503@cs.umd.edu>
Date: Wed, 04 Apr 2007 19:39:25 -0500
From: Charles Clancy 
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: Madjid Nakhjiri 
Subject: Re: [HOKEY] consensus call: key distribution security requirement
References: <002401c77710$a653a470$2f01a8c0@china.huawei.com>
In-Reply-To: <002401c77710$a653a470$2f01a8c0@china.huawei.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 97adf591118a232206bdb5a27b217034
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

Madjid,

My opinion was that they were all already covered by the problem 
statement in one way or another.

 > 1-Confidentiality --avoiding disclosure of the keying material to
 > passive and active attackers.

Covered by saying we must conform to I-D.housley-aaa-key-mgmt.  I have 
no problem adding that as an explicit thing in section 6 though.

 > 3-Validation of credential source -- the recipient must prove where
 > the credential came from and what context it was delivered for.

Prove to whom?  Regardless, that information should be included in the 
key scope and context -- section 6.1.

 > 4-Validation of authorization -- the scope (intended users) of the
 >        network access credential MUST be distributed as part of the
 >        credential and MUST be protected to the same degree as the
 >        credential itself.

See section 6.1 of the current PS.

 > Some of these requirements are simply reflections of Housley document
 > and to me are met through a channel binding procedure.

Exactly, and CB is already in the PS.

Feel free to send me text if you think section 6.1 should be modified.

-- 
t. charles clancy, ph.d.  |  tcc@umd.edu  |  www.cs.umd.edu/~clancy


_______________________________________________
HOKEY mailing list
HOKEY@ietf.org
https://www1.ietf.org/mailman/listinfo/hokey



From hokey-bounces@ietf.org Wed Apr 04 19:41:53 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HZF6v-0003zq-CT; Wed, 04 Apr 2007 19:41:53 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HZF6u-0003zg-5A
	for hokey@ietf.org; Wed, 04 Apr 2007 19:41:52 -0400
Received: from usaga01-in.huawei.com ([206.16.17.211])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZF6s-00047Q-Gx
	for hokey@ietf.org; Wed, 04 Apr 2007 19:41:52 -0400
Received: from huawei.com (usaga01-in [172.18.4.6])
	by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTP id <0JFZ00LRIZ5QHF@usaga01-in.huawei.com> for
	hokey@ietf.org; Wed, 04 Apr 2007 16:41:50 -0700 (PDT)
Received: from N737011
	(pool-71-112-121-192.sttlwa.dsl-w.verizon.net [71.112.121.192])
	by usaga01-in.huawei.com
	(iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar  3 2004))
	with ESMTPA id <0JFZ00JUZZ5LIK@usaga01-in.huawei.com> for
	hokey@ietf.org; Wed, 04 Apr 2007 16:41:49 -0700 (PDT)
Date: Wed, 04 Apr 2007 16:41:51 -0700
From: Madjid Nakhjiri 
Subject: RE: [HOKEY] consensus call: EAP-ER as HOKEY protocol
In-reply-to: <4611B937.4080204@cs.umd.edu>
To: 'Charles Clancy' 
Message-id: <002601c77712$d22894a0$2f01a8c0@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962
X-Mailer: Microsoft Office Outlook 11
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Thread-index: Acd1ljnhjCi2PdysSnuTD2vMeqPNQwBe4UNA
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 34d35111647d654d033d58d318c0d21a
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, I guess I am sort of fuzzy on the _whole point_ of the separation
then:) we have an EMSK hierarchy draft that will show/shows USRK and USDSRK
derivation, but is not supposed to go into any specific usage, and leaves
that to other SDOs.

Then we need to have a spec that deals with HOKEY as a usage and shows HRK
and its child keys. Per-authenticator keys are part of that. I am not
talking about non-HOKEY usages, but when it comes to HOKEY, we need to
specify the whole hierarchy, no?

Am I missing something?

Madjid


-----Original Message-----
From: Charles Clancy [mailto:clancy@cs.umd.edu] 
Sent: Monday, April 02, 2007 7:17 PM
To: Madjid Nakhjiri
Cc: hokey@ietf.org
Subject: Re: [HOKEY] consensus call: EAP-ER as HOKEY protocol

Madjid,

In response to your second question about the additional document -- the 
whole point is to separate out the part of HOKEY that would could be 
reused by another application to obtain a USRK.  The per-authenticator 
keying has nothing to do with other services or their ability to obtain 
a USRK, so I don't think it should be included in the second document.

-- 
t. charles clancy, ph.d.  <>  tcc@umd.edu  <>  www.cs.umd.edu/~clancy

Madjid Nakhjiri wrote:
> Hi, 
> 
> I like to seek a clarification here first.
> Have we put the discussion of use of EAP code versus EAP types to bed,
> completely satisfied that EAP types will absolutely not solve the
problems?
> 
> Given that the Russ only first gave the few of us present in San Jose the
> green light to change EAP, I feel that we did not quite discuss the impact
> of adding new EAP codes versus other changes to an end.  A simple analysis
> shows (I have confirmed this with several EAP experts) that using a new
EAP
> type and adding some payload to EAP success you can easily achieve near 1
> roundtrip exchanges. I can forward that analysis in a separate email.
> 
> It is not clear whether adding data to EAP success is more severe than the
> changes that EAP-ER is suggesting, to name a few:
> 
> 1) adding new codes even though 3748 mandates a discard code>4 
> 2) change of authenticator state machine to treat EAP ER Request as a
> response to EAP Identity request. This seems a lot more intrusive on the
> massive scale of existing authenticators, than adding data to EAP success
> intended for the peer.
> 
> It seems that before fully deciding the EAP code versus EAP type options,
it
> is hard to make a judgement on a solution that is based on EAP code. After
> that, there are issues such as identity exchanges that are needed for key
> derivation according to the EMSK draft and it seems that EAP-ER is
> considering those out of band or requires explicit additional signaling.
> 
> Finally the other clarification I am seeking is regarding the second
> document, don't we want to specify how the per-authenticator keys are
> derived? It seems that it should be included in the second spec as well.
> 
> R,
> 
> Madjid
> 
> -----Original Message-----
> From: Charles Clancy [mailto:clancy@cs.umd.edu] 
> Sent: Saturday, March 31, 2007 11:58 AM
> To: hokey@ietf.org
> Subject: [HOKEY] consensus call: EAP-ER as HOKEY protocol
> 
> HOKEY WG,
> 
> The chairs are making a second consensus call request to adopt EAP-ER as 
> a WG document to satisfy our re-auth and hand-off deliverables.  It 
> would serve as a starting point for development of the HOKEY protocol.
> 
> Note that if accepted, it may be split into two WG documents, separating 
> the EAP-ER-Bootstrap into a second set of messages that could be 
> transported by any service to obtain a USRK or DSUSRK.
> 
> Please respond by Friday, April 13.
> 





_______________________________________________
HOKEY mailing list
HOKEY@ietf.org
https://www1.ietf.org/mailman/listinfo/hokey



From hokey-bounces@ietf.org Wed Apr 04 19:50:57 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HZFFb-0002Zk-A4; Wed, 04 Apr 2007 19:50:51 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HZFFa-0002Zc-Mn
	for hokey@ietf.org; Wed, 04 Apr 2007 19:50:50 -0400
Received: from usaga01-in.huawei.com ([206.16.17.211])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZFFZ-0005Zf-AL
	for hokey@ietf.org; Wed, 04 Apr 2007 19:50:50 -0400
Received: from huawei.com (usaga01-in [172.18.4.6])
	by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTP id <0JFZ00L7FZKOHF@usaga01-in.huawei.com> for
	hokey@ietf.org; Wed, 04 Apr 2007 16:50:49 -0700 (PDT)
Received: from N737011
	(pool-71-112-121-192.sttlwa.dsl-w.verizon.net [71.112.121.192])
	by usaga01-in.huawei.com
	(iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar  3 2004))
	with ESMTPA id <0JFZ00J6WZKKIK@usaga01-in.huawei.com> for
	hokey@ietf.org; Wed, 04 Apr 2007 16:50:48 -0700 (PDT)
Date: Wed, 04 Apr 2007 16:50:49 -0700
From: Madjid Nakhjiri 
Subject: RE: [HOKEY] consensus call: EAP-ER as HOKEY protocol
In-reply-to: <4611C658.7050603@qualcomm.com>
To: 'Lakshminath Dondeti' 
Message-id: <002a01c77714$1319fcf0$2f01a8c0@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962
X-Mailer: Microsoft Office Outlook 11
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Thread-index: Acd1nha7+XIFXIleR/aXyIzKU3NlNgBdNVJQ
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243
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

IETF has specific rules about the Interims and consensus and those are
public so I am going to simply refer you to those.

I don't know the meaning of "drastic" as it is indicated here. 

Everybody agrees that a major problem with EAP is that it does not provide
much protection for result indication. So here we are claiming we are
overhauling EAP, but don't want to deal with lost result indication?

Today the SDOs are struggling to carry the information indicated by the AAA
server to the authenticator, further to the EAP peer. AAA services are
getting more and more ubiquitous usage and hinging lots of this stuff to the
initial EAP process is as ubiquitious, so adding information to EAP success
is a very good thing to end a network access control process.

Adding data to EAP success has almost no effect on the authenticators, much
less than requiring the authenticators to treat responses as requests as the
code based method is suggesting.

I will send the analysis, but it seems that Hao has already sent a similar
one.


Madjid


-----Original Message-----
From: Lakshminath Dondeti [mailto:ldondeti@qualcomm.com] 
Sent: Monday, April 02, 2007 8:13 PM
To: Madjid Nakhjiri
Cc: 'Charles Clancy'; hokey@ietf.org
Subject: Re: [HOKEY] consensus call: EAP-ER as HOKEY protocol

Many of the active WG contributors were present at the interim meeting 
and there was a presentation and discussion on how reauthentication 
might work with new EAP types or codes.  The consensus was that 
code-based approach works best and that consensus was subsequently 
verified on the list.

Well, here we are.  I am also looking forward to seeing your analysis on 
this topic.  Changing the structure of the EAP Success message and also 
the transmission rules for EAP Success are quite drastic changes.  If 
EAP Success needs to be reliably transmitted, authenticator behavior 
would have to change.  Consider the following rules on EAP Success messages:

"The peer
    MAY, in the event that an EAP Success is not received, conclude that
    the EAP Success packet was lost and that authentication concluded
    successfully."

"Success and Failure packets MUST NOT
    contain additional data."

"Because the Success and Failure packets are not
    acknowledged, they are not retransmitted by the authenticator, and
    may be potentially lost.  A peer MUST allow for this circumstance as
    described in this note. "

Anyway, I still want to see your analysis of this.

thanks,
Lakshminath

PS:  I understand your concern about EAP Identity Request and we can 
work on other alternatives for it where terminating the EAP state 
machine at the Authenticator and spawning an EAP-ER state machine is 
considered burdensome (there are other ways of looking at this and that 
is written in vidya-eap-er-02).

Madjid Nakhjiri wrote:
> Hi, 
> 
> I like to seek a clarification here first.
> Have we put the discussion of use of EAP code versus EAP types to bed,
> completely satisfied that EAP types will absolutely not solve the
problems?
> 
> Given that the Russ only first gave the few of us present in San Jose the
> green light to change EAP, I feel that we did not quite discuss the impact
> of adding new EAP codes versus other changes to an end.  A simple analysis
> shows (I have confirmed this with several EAP experts) that using a new
EAP
> type and adding some payload to EAP success you can easily achieve near 1
> roundtrip exchanges. I can forward that analysis in a separate email.
> 
> It is not clear whether adding data to EAP success is more severe than the
> changes that EAP-ER is suggesting, to name a few:
> 
> 1) adding new codes even though 3748 mandates a discard code>4 
> 2) change of authenticator state machine to treat EAP ER Request as a
> response to EAP Identity request. This seems a lot more intrusive on the
> massive scale of existing authenticators, than adding data to EAP success
> intended for the peer.
> 
> It seems that before fully deciding the EAP code versus EAP type options,
it
> is hard to make a judgement on a solution that is based on EAP code. After
> that, there are issues such as identity exchanges that are needed for key
> derivation according to the EMSK draft and it seems that EAP-ER is
> considering those out of band or requires explicit additional signaling.
> 
> Finally the other clarification I am seeking is regarding the second
> document, don't we want to specify how the per-authenticator keys are
> derived? It seems that it should be included in the second spec as well.
> 
> R,
> 
> Madjid
> 
> -----Original Message-----
> From: Charles Clancy [mailto:clancy@cs.umd.edu] 
> Sent: Saturday, March 31, 2007 11:58 AM
> To: hokey@ietf.org
> Subject: [HOKEY] consensus call: EAP-ER as HOKEY protocol
> 
> HOKEY WG,
> 
> The chairs are making a second consensus call request to adopt EAP-ER as 
> a WG document to satisfy our re-auth and hand-off deliverables.  It 
> would serve as a starting point for development of the HOKEY protocol.
> 
> Note that if accepted, it may be split into two WG documents, separating 
> the EAP-ER-Bootstrap into a second set of messages that could be 
> transported by any service to obtain a USRK or DSUSRK.
> 
> Please respond by Friday, April 13.
> 



_______________________________________________
HOKEY mailing list
HOKEY@ietf.org
https://www1.ietf.org/mailman/listinfo/hokey



From hokey-bounces@ietf.org Wed Apr 04 20:02:41 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HZFQz-0000JV-R9; Wed, 04 Apr 2007 20:02:37 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HZFQy-0000JN-CT
	for hokey@ietf.org; Wed, 04 Apr 2007 20:02:36 -0400
Received: from usaga01-in.huawei.com ([206.16.17.211])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZFQw-0004Fs-Qe
	for hokey@ietf.org; Wed, 04 Apr 2007 20:02:36 -0400
Received: from huawei.com (usaga01-in [172.18.4.6])
	by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTP id <0JG000LSM04AHF@usaga01-in.huawei.com> for
	hokey@ietf.org; Wed, 04 Apr 2007 17:02:34 -0700 (PDT)
Received: from N737011
	(pool-71-112-121-192.sttlwa.dsl-w.verizon.net [71.112.121.192])
	by usaga01-in.huawei.com
	(iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar  3 2004))
	with ESMTPA id <0JG000JLS046IK@usaga01-in.huawei.com> for
	hokey@ietf.org; Wed, 04 Apr 2007 17:02:34 -0700 (PDT)
Date: Wed, 04 Apr 2007 17:02:35 -0700
From: Madjid Nakhjiri 
Subject: RE: [HOKEY] consensus call: EAP-ER as HOKEY protocol
In-reply-to: <35963.63.239.69.1.1175617726.squirrel@webmail.cs.umd.edu>
To: 'Charles Clancy' ,
	'Avi Lior' 
Message-id: <002b01c77715$b7ca1040$2f01a8c0@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962
X-Mailer: Microsoft Office Outlook 11
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Thread-index: Acd2DS+vfA0ssPTQTVucOf/8KvYAzABByXEg
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba
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

As I once said less metaphorically, working in another SDO, we flipped the
EAP-keying steak everywhere we could and hit bones and that is why we
started HOKEY, now we are hitting the same issues with EAP 3748. Either it
is ok to change EAP or it is not, so why do we point 3748 sentences to each
other? 

3748 was written for authentication not for key distribution, or for
carrying network authorization data for the peer.

So as you are saying it is really the implementations that matter, not the
sentences in EAP 3748.

But currently, we are discussing a solution that requires the authenticator
to sends an EAP Identity request, but receives an EAP code>4 and treats that
as an EAP response. Plus what about a peer that uses MSK with the first
authenticator but MDMSK (I called the per-authenticator key, mobility domain
MSK) with the following ones.
I wonder if that is more severe than having EAP success to carry some data
(which is btw for the peer not for the authenticator).


Madjid

-----Original Message-----
From: Charles Clancy [mailto:clancy@cs.umd.edu] 
Sent: Tuesday, April 03, 2007 9:29 AM
To: Avi Lior
Cc: Lakshminath Dondeti; Madjid Nakhjiri; hokey@ietf.org
Subject: RE: [HOKEY] consensus call: EAP-ER as HOKEY protocol


I think adding stuff to the EAP Success without doing a 3748bis would be a
hack.  Until both approaches have been implemented and tested with a mix
legacy hardware, it's impossible to say which would be more likely to
partially work in a partially-upgraded environment.  I'd like to see how a
legacy NAS deals with a payload-ified EAP-Success and type codes > 4.


-- 
t. charles clancy, ph.d.  <>  tcc@umd.edu  <>  www.cs.umd.edu/~clancy

On Tue, April 3, 2007 9:47 am, Avi Lior wrote:
> Re: [HOKEY] consensus call: EAP-ER as HOKEY
> protocol
> 
> 

> 
I for one thinks we
> should look at allowing us to carry data in EAP success.  In fact, it
> would be a good idea if we allowed EAP to carry data which is not part of
> the method in all exchanges. 

> 

Clearly there is a need to
> communicate with the Peer before and just after authentication. 
> There is no other path to the Peer.  EAP should have addressed
> this.

> 
 

> 
We already see this happening in the
> Request Identity (as in Network Selection and other such usage), in the
> Repsonse Identity and now in the Success phase.

> 
 

> 
We can continue to "hack" EAP but we can also fix it.

> 
 

> 
I am not saying EAP-ER is a hack but it is not efficient
> because it works around the existing EAP semantics but
> hopefully we could do better.

> 
 size=2> 

> 

> 
Avi Lior Office: +1 613 591-9104 x 6417 Cell : +1 613
> 796-4183

> 


> 

> From: Lakshminath Dondeti
Sent:
> Mon 4/2/2007 11:13 PM
To: Madjid Nakhjiri
Cc:
> hokey@ietf.org
Subject: Re: [HOKEY] consensus call: EAP-ER as
> HOKEY protocol


> 

> 
Many of the active WG contributors were present at the
> interim meeting
and there was a presentation and discussion on how
> reauthentication
might work with new EAP types or codes.  The
> consensus was that
code-based approach works best and that consensus
> was subsequently
verified on the list.

Well, here we are. 
> I am also looking forward to seeing your analysis on
this topic. 
> Changing the structure of the EAP Success message and also
the
> transmission rules for EAP Success are quite drastic changes. 
> If
EAP Success needs to be reliably transmitted, authenticator
> behavior
would have to change.  Consider the following rules on
> EAP Success messages:

"The peer
    MAY, in the
> event that an EAP Success is not received, conclude
> that
    the EAP Success packet was lost and that
> authentication concluded
   
> successfully."

"Success and Failure packets MUST
> NOT
    contain additional data."

"Because the
> Success and Failure packets are not
    acknowledged,
> they are not retransmitted by the authenticator, and
   
> may be potentially lost.  A peer MUST allow for this circumstance
> as
    described in this note. "

Anyway, I still
> want to see your analysis of
> this.

thanks,
Lakshminath

PS:  I understand your
> concern about EAP Identity Request and we can
work on other
> alternatives for it where terminating the EAP state
machine at the
> Authenticator and spawning an EAP-ER state machine is
considered
> burdensome (there are other ways of looking at this and that
is written
> in vidya-eap-er-02).

Madjid Nakhjiri wrote:
>
> Hi,
>
> I like to seek a clarification here first.
>
> Have we put the discussion of use of EAP code versus EAP types to
> bed,
> completely satisfied that EAP types will absolutely not solve
> the problems?
>
> Given that the Russ only first gave the few
> of us present in San Jose the
> green light to change EAP, I feel
> that we did not quite discuss the impact
> of adding new EAP codes
> versus other changes to an end.  A simple analysis
> shows (I
> have confirmed this with several EAP experts) that using a new EAP
>
> type and adding some payload to EAP success you can easily achieve near
> 1
> roundtrip exchanges. I can forward that analysis in a separate
> email.
>
> It is not clear whether adding data to EAP success
> is more severe than the
> changes that EAP-ER is suggesting, to name
> a few:
>
> 1) adding new codes even though 3748 mandates a
> discard code>4
> 2) change of authenticator state machine to
> treat EAP ER Request as a
> response to EAP Identity request. This
> seems a lot more intrusive on the
> massive scale of existing
> authenticators, than adding data to EAP success
> intended for the
> peer.
>
> It seems that before fully deciding the EAP code
> versus EAP type options, it
> is hard to make a judgement on a
> solution that is based on EAP code. After
> that, there are issues
> such as identity exchanges that are needed for key
> derivation
> according to the EMSK draft and it seems that EAP-ER is
>
> considering those out of band or requires explicit additional
> signaling.
>
> Finally the other clarification I am seeking is
> regarding the second
> document, don't we want to specify how the
> per-authenticator keys are
> derived? It seems that it should be
> included in the second spec as well.
>
> R,
>
>
> Madjid
>
> -----Original Message-----
> From: Charles
> Clancy [ target=_blank>mailto:clancy@cs.umd.edu]
> Sent: Saturday, March
> 31, 2007 11:58 AM
> To: hokey@ietf.org
> Subject: [HOKEY]
> consensus call: EAP-ER as HOKEY protocol
>
> HOKEY
> WG,
>
> The chairs are making a second consensus call request
> to adopt EAP-ER as
> a WG document to satisfy our re-auth and
> hand-off deliverables.  It
> would serve as a starting point
> for development of the HOKEY protocol.
>
> Note that if
> accepted, it may be split into two WG documents, separating
> the
> EAP-ER-Bootstrap into a second set of messages that could be
>
> transported by any service to obtain a USRK or DSUSRK.
>
>
> Please respond by Friday, April
>
13.
>

_______________________________________________
HOKEY
> mailing list
HOKEY@ietf.org
 href="https://www1.ietf.org/mailman/listinfo/hokey"
>
target=_blank>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 Wed Apr 04 20:25: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 1HZFmv-0004M2-EI; Wed, 04 Apr 2007 20:25:17 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HZFmu-0004Lx-BC
	for hokey@ietf.org; Wed, 04 Apr 2007 20:25:16 -0400
Received: from sccrmhc15.comcast.net ([63.240.77.85])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZFmt-0003gf-4a
	for hokey@ietf.org; Wed, 04 Apr 2007 20:25:16 -0400
Received: from [192.168.0.52]
	(c-68-49-199-146.hsd1.md.comcast.net[68.49.199.146])
	by comcast.net (sccrmhc15) with ESMTP
	id <20070405002514015008k7nie>; Thu, 5 Apr 2007 00:25:14 +0000
Message-ID: <46145077.5020000@cs.umd.edu>
Date: Wed, 04 Apr 2007 20:27:19 -0500
From: Charles Clancy 
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: hokey@ietf.org
Subject: Re: [HOKEY] consensus call: key distribution security requirement
References: <002501c77711$89c61d00$2f01a8c0@china.huawei.com>
In-Reply-To: <002501c77711$89c61d00$2f01a8c0@china.huawei.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2
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,

I think we need to look at the protocols.  To compare...

3-party protocol (Dan's proposal, slightly simplified assuming AAA 
provides the necessary transport security):

    1) A->B: A, {A, B, Na}Kas
    2) B->S: A, B, {A, B, Na}Kas
    3) S->B: {B, Na}Kas, {A, Kab}Kbs
    4) B->A: {B, Na}Kas

EAP-ER (translated to above notation and assuming AAA transport):

    1) A->B: A, {A, Na}Kas
    2) B->S: A, B, {A, Na}Kas
    3) S->B: {Na}Kas, {Kab}Kbs
    4) B->A: {Na}Kas

EAP-ER+CB (my proposal for adding channel binding to EAP-ER):

    1) A->B: A, {A, Na}Kas
    2) B->S: A, B, {A, Na}Kas
    3) S->B: {B, Na}Kas, {A, Kab}Kbs
    4) B->A: {B, Na}Kas

So, we've added "A" and "B" in messages 3 and 4, but not added "B" in 
message 1.  I feel this satisfies everything *but* peer consent, and 
doesn't require A to know "B" at the beginning.

-- 
t. charles clancy, ph.d.  |  tcc@umd.edu  |  www.cs.umd.edu/~clancy


_______________________________________________
HOKEY mailing list
HOKEY@ietf.org
https://www1.ietf.org/mailman/listinfo/hokey



From hokey-bounces@ietf.org Wed Apr 04 20:31: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 1HZFt3-0008HP-22; Wed, 04 Apr 2007 20:31:37 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HZFt2-0008HK-7X
	for hokey@ietf.org; Wed, 04 Apr 2007 20:31:36 -0400
Received: from sccrmhc11.comcast.net ([63.240.77.81])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZFt1-0005of-0N
	for hokey@ietf.org; Wed, 04 Apr 2007 20:31:36 -0400
Received: from [192.168.0.52]
	(c-68-49-199-146.hsd1.md.comcast.net[68.49.199.146])
	by comcast.net (sccrmhc11) with ESMTP
	id <2007040500313401100fli1je>; Thu, 5 Apr 2007 00:31:34 +0000
Message-ID: <461451F0.5050304@cs.umd.edu>
Date: Wed, 04 Apr 2007 20:33:36 -0500
From: Charles Clancy 
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: Madjid Nakhjiri 
Subject: Re: [HOKEY] consensus call: EAP-ER as HOKEY protocol
References: <002601c77712$d22894a0$2f01a8c0@china.huawei.com>
In-Reply-To: <002601c77712$d22894a0$2f01a8c0@china.huawei.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b
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

Indeed HOKEY is a specific usage.  As a part of that, it needs to define 
a protocol to get a USRK=HRK to the HOKEY server (in EAP-ER this is the 
bootstrap phase).  I was hoping that we could define a generic protocol 
that other services could use too, after defining their own transport 
for the protocol.  This way we could enforce certain security properties.

-- 
t. charles clancy, ph.d.  |  tcc@umd.edu  |  www.cs.umd.edu/~clancy

Madjid Nakhjiri wrote:
> Well, I guess I am sort of fuzzy on the _whole point_ of the separation
> then:) we have an EMSK hierarchy draft that will show/shows USRK and USDSRK
> derivation, but is not supposed to go into any specific usage, and leaves
> that to other SDOs.
> 
> Then we need to have a spec that deals with HOKEY as a usage and shows HRK
> and its child keys. Per-authenticator keys are part of that. I am not
> talking about non-HOKEY usages, but when it comes to HOKEY, we need to
> specify the whole hierarchy, no?
> 
> Am I missing something?
> 
> Madjid
> 
> 
> -----Original Message-----
> From: Charles Clancy [mailto:clancy@cs.umd.edu] 
> Sent: Monday, April 02, 2007 7:17 PM
> To: Madjid Nakhjiri
> Cc: hokey@ietf.org
> Subject: Re: [HOKEY] consensus call: EAP-ER as HOKEY protocol
> 
> Madjid,
> 
> In response to your second question about the additional document -- the 
> whole point is to separate out the part of HOKEY that would could be 
> reused by another application to obtain a USRK.  The per-authenticator 
> keying has nothing to do with other services or their ability to obtain 
> a USRK, so I don't think it should be included in the second document.
> 

_______________________________________________
HOKEY mailing list
HOKEY@ietf.org
https://www1.ietf.org/mailman/listinfo/hokey



From hokey-bounces@ietf.org Wed Apr 04 20:38: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 1HZFzZ-0005Li-GD; Wed, 04 Apr 2007 20:38:21 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HZFzY-0005LY-FH
	for hokey@ietf.org; Wed, 04 Apr 2007 20:38:20 -0400
Received: from numenor.qualcomm.com ([129.46.51.58])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZFzW-00068A-QM
	for hokey@ietf.org; Wed, 04 Apr 2007 20:38:20 -0400
Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149])
	by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id
	l350c81F022028
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 4 Apr 2007 17:38:08 -0700
Received: from [129.46.78.141] (ldondeti.na.qualcomm.com [129.46.78.141])
	by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id
	l350c7Sx027806
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Wed, 4 Apr 2007 17:38:07 -0700
Message-ID: <461444EE.4000103@qualcomm.com>
Date: Wed, 04 Apr 2007 17:38:06 -0700
From: Lakshminath Dondeti 
User-Agent: Thunderbird 2.0b2 (Windows/20070116)
MIME-Version: 1.0
To: Madjid Nakhjiri 
Subject: Re: [HOKEY] consensus call: EAP-ER as HOKEY protocol
References: <002a01c77714$1319fcf0$2f01a8c0@china.huawei.com>
In-Reply-To: <002a01c77714$1319fcf0$2f01a8c0@china.huawei.com>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172
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

Madjid Nakhjiri wrote:
> IETF has specific rules about the Interims and consensus and those are
> public so I am going to simply refer you to those.

Yes, and my interpretation of those rules as applied to this situation 
is that we have consensus on Code vs. Type.  The rule is that consensus 
is to be verified on the list and it was.

The rest of your message is completely off-topic.

Lakshminath

> 
> I don't know the meaning of "drastic" as it is indicated here. 
> 
> Everybody agrees that a major problem with EAP is that it does not provide
> much protection for result indication. So here we are claiming we are
> overhauling EAP, but don't want to deal with lost result indication?
> 
> Today the SDOs are struggling to carry the information indicated by the AAA
> server to the authenticator, further to the EAP peer. AAA services are
> getting more and more ubiquitous usage and hinging lots of this stuff to the
> initial EAP process is as ubiquitious, so adding information to EAP success
> is a very good thing to end a network access control process.
> 
> Adding data to EAP success has almost no effect on the authenticators, much
> less than requiring the authenticators to treat responses as requests as the
> code based method is suggesting.
> 
> I will send the analysis, but it seems that Hao has already sent a similar
> one.
> 
> 
> Madjid
> 
> 
> -----Original Message-----
> From: Lakshminath Dondeti [mailto:ldondeti@qualcomm.com] 
> Sent: Monday, April 02, 2007 8:13 PM
> To: Madjid Nakhjiri
> Cc: 'Charles Clancy'; hokey@ietf.org
> Subject: Re: [HOKEY] consensus call: EAP-ER as HOKEY protocol
> 
> Many of the active WG contributors were present at the interim meeting 
> and there was a presentation and discussion on how reauthentication 
> might work with new EAP types or codes.  The consensus was that 
> code-based approach works best and that consensus was subsequently 
> verified on the list.
> 
> Well, here we are.  I am also looking forward to seeing your analysis on 
> this topic.  Changing the structure of the EAP Success message and also 
> the transmission rules for EAP Success are quite drastic changes.  If 
> EAP Success needs to be reliably transmitted, authenticator behavior 
> would have to change.  Consider the following rules on EAP Success messages:
> 
> "The peer
>     MAY, in the event that an EAP Success is not received, conclude that
>     the EAP Success packet was lost and that authentication concluded
>     successfully."
> 
> "Success and Failure packets MUST NOT
>     contain additional data."
> 
> "Because the Success and Failure packets are not
>     acknowledged, they are not retransmitted by the authenticator, and
>     may be potentially lost.  A peer MUST allow for this circumstance as
>     described in this note. "
> 
> Anyway, I still want to see your analysis of this.
> 
> thanks,
> Lakshminath
> 
> PS:  I understand your concern about EAP Identity Request and we can 
> work on other alternatives for it where terminating the EAP state 
> machine at the Authenticator and spawning an EAP-ER state machine is 
> considered burdensome (there are other ways of looking at this and that 
> is written in vidya-eap-er-02).
> 
> Madjid Nakhjiri wrote:
>> Hi, 
>>
>> I like to seek a clarification here first.
>> Have we put the discussion of use of EAP code versus EAP types to bed,
>> completely satisfied that EAP types will absolutely not solve the
> problems?
>> Given that the Russ only first gave the few of us present in San Jose the
>> green light to change EAP, I feel that we did not quite discuss the impact
>> of adding new EAP codes versus other changes to an end.  A simple analysis
>> shows (I have confirmed this with several EAP experts) that using a new
> EAP
>> type and adding some payload to EAP success you can easily achieve near 1
>> roundtrip exchanges. I can forward that analysis in a separate email.
>>
>> It is not clear whether adding data to EAP success is more severe than the
>> changes that EAP-ER is suggesting, to name a few:
>>
>> 1) adding new codes even though 3748 mandates a discard code>4 
>> 2) change of authenticator state machine to treat EAP ER Request as a
>> response to EAP Identity request. This seems a lot more intrusive on the
>> massive scale of existing authenticators, than adding data to EAP success
>> intended for the peer.
>>
>> It seems that before fully deciding the EAP code versus EAP type options,
> it
>> is hard to make a judgement on a solution that is based on EAP code. After
>> that, there are issues such as identity exchanges that are needed for key
>> derivation according to the EMSK draft and it seems that EAP-ER is
>> considering those out of band or requires explicit additional signaling.
>>
>> Finally the other clarification I am seeking is regarding the second
>> document, don't we want to specify how the per-authenticator keys are
>> derived? It seems that it should be included in the second spec as well.
>>
>> R,
>>
>> Madjid
>>
>> -----Original Message-----
>> From: Charles Clancy [mailto:clancy@cs.umd.edu] 
>> Sent: Saturday, March 31, 2007 11:58 AM
>> To: hokey@ietf.org
>> Subject: [HOKEY] consensus call: EAP-ER as HOKEY protocol
>>
>> HOKEY WG,
>>
>> The chairs are making a second consensus call request to adopt EAP-ER as 
>> a WG document to satisfy our re-auth and hand-off deliverables.  It 
>> would serve as a starting point for development of the HOKEY protocol.
>>
>> Note that if accepted, it may be split into two WG documents, separating 
>> the EAP-ER-Bootstrap into a second set of messages that could be 
>> transported by any service to obtain a USRK or DSUSRK.
>>
>> Please respond by Friday, April 13.
>>
> 
> 
> 

_______________________________________________
HOKEY mailing list
HOKEY@ietf.org
https://www1.ietf.org/mailman/listinfo/hokey



From hokey-bounces@ietf.org Wed Apr 04 21:01:10 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HZGLW-0004e6-BT; Wed, 04 Apr 2007 21:01:02 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HZGLV-0004dx-CN
	for hokey@ietf.org; Wed, 04 Apr 2007 21:01:01 -0400
Received: from ithilien.qualcomm.com ([129.46.51.59])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZGLT-00006g-Vu
	for hokey@ietf.org; Wed, 04 Apr 2007 21:01:01 -0400
Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157])
	by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id
	l3510lsJ002321
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 4 Apr 2007 18:00:47 -0700
Received: from [129.46.78.141] (ldondeti.na.qualcomm.com [129.46.78.141])
	by hamtaro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id
	l3510kZU021523
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Wed, 4 Apr 2007 18:00:46 -0700 (PDT)
Message-ID: <46144A3C.4040705@qualcomm.com>
Date: Wed, 04 Apr 2007 18:00:44 -0700
From: Lakshminath Dondeti 
User-Agent: Thunderbird 2.0b2 (Windows/20070116)
MIME-Version: 1.0
To: Madjid Nakhjiri 
Subject: Re: [HOKEY] consensus call: EAP-ER as HOKEY protocol
References: <002b01c77715$b7ca1040$2f01a8c0@china.huawei.com>
In-Reply-To: <002b01c77715$b7ca1040$2f01a8c0@china.huawei.com>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 25620135586de10c627e3628c432b04a
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

Madjid,

"> So as you are saying it is really the implementations that matter, 
not the
 > sentences in EAP 3748."

Did you really mean that?  We simply have a fundamental disagreement 
then!  I will disregard any of your opinions that are based on that 
principle of yours.

We write specifications at the IETF and expect that implementations 
comply so we have interoperability.  If the specifications got it wrong, 
the specification is to be revised (which is a serious process since we 
don't want to penalize people who actually complied with the 
specification).  If implementors were lazy and used hacks (I am guilty 
of that for example, but I will fix my implementation rather than 
demanding that we revise the relevant RFCs), well that is their problem. 
  It is also a slippery slope since there is no representative 
population of the implementors on this list or any list in the IETF.

Next, there are at least two ways protocols are "changed" at the IETF.

We revise them: e.g., RFC 2284 --> draft 2284bis --> RFC 3748 (some 
behavior has actually changed)

We extend/update them: e.g, RFC 3830;  RFC 4738, Updates RFC 3830. 
(3830 behavior itself is still fine)

So, no we cannot say that "changing" EAP is the same thing in all cases. 
  There are instances where protocols are indeed revised/changed and 
there are cases where they are simply extended.

regards,
Lakshminath

Madjid Nakhjiri wrote:
> As I once said less metaphorically, working in another SDO, we flipped the
> EAP-keying steak everywhere we could and hit bones and that is why we
> started HOKEY, now we are hitting the same issues with EAP 3748. Either it
> is ok to change EAP or it is not, so why do we point 3748 sentences to each
> other? 
> 
> 3748 was written for authentication not for key distribution, or for
> carrying network authorization data for the peer.
> 
> So as you are saying it is really the implementations that matter, not the
> sentences in EAP 3748.
> 
> But currently, we are discussing a solution that requires the authenticator
> to sends an EAP Identity request, but receives an EAP code>4 and treats that
> as an EAP response. Plus what about a peer that uses MSK with the first
> authenticator but MDMSK (I called the per-authenticator key, mobility domain
> MSK) with the following ones.
> I wonder if that is more severe than having EAP success to carry some data
> (which is btw for the peer not for the authenticator).
> 
> 
> Madjid
> 
> -----Original Message-----
> From: Charles Clancy [mailto:clancy@cs.umd.edu] 
> Sent: Tuesday, April 03, 2007 9:29 AM
> To: Avi Lior
> Cc: Lakshminath Dondeti; Madjid Nakhjiri; hokey@ietf.org
> Subject: RE: [HOKEY] consensus call: EAP-ER as HOKEY protocol
> 
> 
> I think adding stuff to the EAP Success without doing a 3748bis would be a
> hack.  Until both approaches have been implemented and tested with a mix
> legacy hardware, it's impossible to say which would be more likely to
> partially work in a partially-upgraded environment.  I'd like to see how a
> legacy NAS deals with a payload-ified EAP-Success and type codes > 4.
> 
> 

_______________________________________________
HOKEY mailing list
HOKEY@ietf.org
https://www1.ietf.org/mailman/listinfo/hokey



From hokey-bounces@ietf.org Wed Apr 04 21:20:29 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HZGeL-0005Wu-Om; Wed, 04 Apr 2007 21:20:29 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HZGeK-0005Wp-IR
	for hokey@ietf.org; Wed, 04 Apr 2007 21:20:28 -0400
Received: from numenor.qualcomm.com ([129.46.51.58])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZGeI-0002If-UX
	for hokey@ietf.org; Wed, 04 Apr 2007 21:20:28 -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
	l351KPe1025719
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 4 Apr 2007 18:20:26 -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
	l351KPxW027297; Wed, 4 Apr 2007 18:20:25 -0700 (PDT)
Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by
	SANEXCAS03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 4 Apr 2007 18:20:25 -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
Subject: RE: [HOKEY] consensus call: key distribution security requirement
Date: Wed, 4 Apr 2007 18:20:21 -0700
Message-ID: 
In-Reply-To: <7030.12.108.168.179.1175729051.squirrel@www.trepanning.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [HOKEY] consensus call: key distribution security requirement
Thread-Index: Acd3EGMDciBkvAG1RhyQ3WDkcNDuAAAD8CPg
References: <460EB36E.5010604@cs.umd.edu>
	
	<20070404024453.GA18289@steelhead>
	
	<7030.12.108.168.179.1175729051.squirrel@www.trepanning.net>
From: "Narayanan, Vidya" 
To: "Dan Harkins" 
X-OriginalArrivalTime: 05 Apr 2007 01:20:25.0342 (UTC)
	FILETIME=[96A541E0:01C77720]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a743e34ab8eb08259de9a7307caed594
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 Dan,
As we talked about this before, there is no attack, when every key
handed out is fresh and unique across any two key fetches from the
server. So, the scoping of keys necessary is about ensuring that the
same key is never ever given out again, even to the (seemingly) same
entity.=20

Vidya

> -----Original Message-----
> From: Dan Harkins [mailto:dharkins@lounge.org]=20
> Sent: Wednesday, April 04, 2007 4:24 PM
> To: Narayanan, Vidya
> Cc: Yoshihiro Ohba; hokey@ietf.org
> Subject: RE: [HOKEY] consensus call: key distribution=20
> security requirement
>=20
>=20
>   Hi Vidya,
>=20
>   As I explained to you previously the issue of "peer detects=20
> mismatch during secure association protocol" (slide 5 of your=20
> deck) doesn't work because these are symmetric keys and the=20
> "middle entity" can impersonate the client now. Every single=20
> property that you want to give to the key being distributed is lost.
>=20
>   Of course you may not view that as a problem but I think=20
> that has more to do with what you want to do then with=20
> whether it's secure or not.
>=20
>   Can you please explain how to ensure that keys are properly=20
> scoped if you do not bind the scoping information to the=20
> exchange that distributes the key? How can the peer have any=20
> assurance that the key is "not shared"
> (one of the qualifiers you mention) if it did not take part=20
> in the distribution of its key?
>=20
>   Why not just send the EMSK to every entity that the AS=20
> thinks it has a security association with? I mean, in many=20
> cases as long as the peer receives a certain level of service=20
> and is charged for same then the identity of the entity=20
> receiving the EMSK is irrelevant and channel binding isn't=20
> important and as long as we scope the key properly (everyone=20
> with whom the AS shares a security association-- aka "the
> network") then it's OK. After all, nothing matters as long as=20
> the peer is satisfied and "if the peer is not satisfied or=20
> there is a billing issue, it contacts its home network and=20
> tries to get service from some other node instead" (to quote=20
> from slide #6).
>=20
>   Dan.
>=20
> On Wed, April 4, 2007 11:16 am, Narayanan, Vidya wrote:
> > Hi Yoshi,
> >
> >> -----Original Message-----
> >> From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com]
> >> Sent: Tuesday, April 03, 2007 7:45 PM
> >> To: Narayanan, Vidya
> >> Cc: Charles Clancy; hokey@ietf.org
> >> Subject: Re: [HOKEY] consensus call: key distribution security=20
> >> requirement
> >>
> >> Hi Vidya,
> >>
> >> Can you please explain why channel binding information must be=20
> >> optional?
> >>
> >
> > Briefly, in many cases, as long as the peer receives a=20
> certain level=20
> > of service and is charged for the same, the identity of the network=20
> > entity providing the service is irrelevant. In some cases,=20
> it may be=20
> > relevant and hence, it would be good to have the capability to do=20
> > channel binding. But, for the other cases, there is no need=20
> to mandate=20
> > the lower layer to advertise identities.
> >
> >> Can you also explain in which system there are no adverse=20
> effects in=20
> >> key distribution without explicit peer consent?
> >>
> >
> > I have not seen any real loss of security properties in=20
> distribution=20
> > of keys without peer consent, as long as the keys are scoped=20
> > correctly, not shared and freshness is always ensured.
> >
> > Please see
> >=20
> http://www.geocities.com/hellovidya/Authenticators_and_Identities.pdf=20
> > if you are interested in more details. I had put some=20
> slides together=20
> > a while ago on this identities issue.
> >
> > Vidya
> >
> >> Regards,
> >> Yoshihiro Ohba
> >>
> >>
> >> On Tue, Apr 03, 2007 at 06:25:52PM -0700, Narayanan, Vidya wrote:
> >> > I'm barely caught up on all the email after having been=20
> on vacation=20
> >> > until now, so, pardon me if I'm bringing up stuff that's
> >> already been
> >> > discussed here.
> >> >
> >> > I share some of Glen's concerns about "requiring" peer
> >> consent and a
> >> > 3-party protocol and about how practically deployable that
> >> is. In my
> >> > conversations with Dan in Prague, it seemed like we were on
> >> the same
> >> > page about including channel binding information in the
> >> HOKEY protocol
> >> > between the peer and server. I think such channel binding
> >> information
> >> > must be optional and not required. In some systems, there are no=20
> >> > adverse effects of distribution of key material without
> >> explicit peer
> >> > consent and there is no reason to place upper layer identity=20
> >> > advertisement requirements on the lower layers for such=20
> systems. In=20
> >> > some other systems, it may be a good idea to do so and=20
> having the=20
> >> > capability to do that in the protocol would be useful there.
> >> >
> >> > To specifically answer your question, I don't believe we need to=20
> >> > update the problem statement. It already captures the
> >> channel binding
> >> > stuff and the explicit data that the peer and authenticator may=20
> >> > include is one way of providing channel binding.
> >> >
> >> > Vidya
> >> >
> >> > > -----Original Message-----
> >> > > From: Charles Clancy [mailto:clancy@cs.umd.edu]
> >> > > Sent: Saturday, March 31, 2007 12:16 PM
> >> > > To: hokey@ietf.org
> >> > > Subject: [HOKEY] consensus call: key distribution security=20
> >> > > requirement
> >> > >
> >> > > HOKEY WG,
> >> > >
> >> > > The 3-party protocol proposal at IETF 68 listed a variety of=20
> >> > > protocol requirements, some of which went beyond those=20
> currently=20
> >> > > specified in the problem statements draft.  The main
> >> extension was a
> >> > > requirement for stronger key distribution security.
> >> > >
> >> > > Discussion: The problem statements document currently requires=20
> >> > > channel bindings to allow clients to authenticate the=20
> network to=20
> >> > > which they are connecting, and prevent the lying NAS problem.
> >> > > However one possible implementation of channel bindings
> >> would allow
> >> > > keys to be distributed prior to the network being
> >> authenticated by
> >> > > the peer.  While the peer may decide to not use a network
> >> after it's
> >> > > validated its identity, network entities could retain=20
> the keying=20
> >> > > material.
> >> > > There has been much debate on the list as to whether or
> >> not network
> >> > > entities could maliciously use this keying material, and
> >> the intent
> >> > > here is to not rehash all that discussion.
> >> > >
> >> > > Question: Should additional text be added to the problem
> >> statement
> >> > > draft
> >> > >   to require peer authorization for distributing=20
> keying material?
> >> > >
> >> > > Protocol Implications: If "yes" then a 3-party=20
> protocol would be=20
> >> > > need, and would require L2 advertisement of the NAS-ID
> >> and local AAA
> >> > > domain name.  If "no" then channel bindings where=20
> identities are=20
> >> > > hashed into the key derivation would be sufficient.
> >> > >
> >> > > --
> >> > > t. charles clancy, ph.d.  <>  tcc@umd.edu  <>=20
> >> > > www.cs.umd.edu/~clancy
> >> > >
> >> > >
> >> > > _______________________________________________
> >> > > 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
> >
>=20
>=20
>=20

_______________________________________________
HOKEY mailing list
HOKEY@ietf.org
https://www1.ietf.org/mailman/listinfo/hokey



From hokey-bounces@ietf.org Thu Apr 05 09:32:57 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HZS57-0003Tc-Hh; Thu, 05 Apr 2007 09:32:53 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HZS56-0003TW-NI
	for hokey@ietf.org; Thu, 05 Apr 2007 09:32:52 -0400
Received: from inet-tsb5.toshiba.co.jp ([202.33.96.24])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZS55-0007z3-1t
	for hokey@ietf.org; Thu, 05 Apr 2007 09:32:52 -0400
Received: from tsb-wall.toshiba.co.jp ([133.199.160.134])
	by inet-tsb5.toshiba.co.jp  with ESMTP id l35DWkMW012563;
	Thu, 5 Apr 2007 22:32:46 +0900 (JST)
Received: (from root@localhost) by tsb-wall.toshiba.co.jp  id l35DWkRq006916;
	Thu, 5 Apr 2007 22:32:46 +0900 (JST)
Received: from ovp1.toshiba.co.jp [133.199.192.124] 
	by tsb-wall.toshiba.co.jp with ESMTP id YAA06915;
	Thu, 5 Apr 2007 22:32:46 +0900
Received: from mx.toshiba.co.jp (localhost [127.0.0.1])
	by ovp1.toshiba.co.jp  with ESMTP id l35DWjXI005685;
	Thu, 5 Apr 2007 22:32:45 +0900 (JST)
Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id l35DWjFW029569;
	Thu, 5 Apr 2007 22:32:45 +0900 (JST)
Received: from steelhead ([172.30.24.105])
	by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 (built
	Apr 28
	2004)) with ESMTPSA id <0JG100H6K1MIQS00@mail.po.toshiba.co.jp>; Thu,
	05 Apr 2007 22:32:45 +0900 (JST)
Received: from ohba by steelhead with local (Exim 4.63)
	(envelope-from )	id 1HZS4x-0004pe-3G; Thu,
	05 Apr 2007 06:32:43 -0700
Date: Thu, 05 Apr 2007 09:32:43 -0400
From: Yoshihiro Ohba 
Subject: Re: [HOKEY] consensus call: key distribution security requirement
In-reply-to: 
To: "Narayanan, Vidya" 
Message-id: <20070405133243.GA18558@steelhead>
MIME-version: 1.0
Content-type: text/plain; charset=iso-2022-jp
Content-disposition: inline
References: <460EB36E.5010604@cs.umd.edu>
	
	<20070404024453.GA18289@steelhead>
	
User-Agent: Mutt/1.5.13 (2006-08-11)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976
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 Vidya,

On Wed, Apr 04, 2007 at 11:16:09AM -0700, Narayanan, Vidya wrote:
> Hi Yoshi, 
> 
> > -----Original Message-----
> > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] 
> > Sent: Tuesday, April 03, 2007 7:45 PM
> > To: Narayanan, Vidya
> > Cc: Charles Clancy; hokey@ietf.org
> > Subject: Re: [HOKEY] consensus call: key distribution 
> > security requirement
> > 
> > Hi Vidya,
> > 
> > Can you please explain why channel binding information must 
> > be optional?
> > 
> 
> Briefly, in many cases, as long as the peer receives a certain level of
> service and is charged for the same, the identity of the network entity
> providing the service is irrelevant. In some cases, it may be relevant
> and hence, it would be good to have the capability to do channel
> binding. But, for the other cases, there is no need to mandate the lower
> layer to advertise identities. 

I don't understand what "many cases" are.  What is "a certain level of
service"?  What do you mean by "is charged for the same"?  I've read
your slides you indicated below (thanks for the pointer!), but
unfortunately, the slides do not contain detaied explanation on those
points.

> 
> > Can you also explain in which system there are no adverse 
> > effects in key distribution without explicit peer consent?
> > 
> 
> I have not seen any real loss of security properties in distribution of
> keys without peer consent, as long as the keys are scoped correctly, not
> shared and freshness is always ensured. 

At least I can see a DoS attack without peer consent.  An attacker can
generate a non-secured trigger that invokes key distribution procedure
that causes installation of a lot of keys to authenticators.

> 
> Please see
> http://www.geocities.com/hellovidya/Authenticators_and_Identities.pdf if
> you are interested in more details. I had put some slides together a
> while ago on this identities issue. 

I have specific comments on your slides:

Slide 6:

"- As long as the peer is satisfied, the identity of the network entity
providing the service is irrelevant"

How do you define peer's "satisfaction" from security point of view?

"- If peer is not satisfied or there is a billing issue, it contacts its home
network and tries to get service from some other node instead"

This does not seem to help, since some other node may also be
impersonating.


Slide 7:

"This cannot be detected using any type of channel binding"

This is not true.  If an appropriate 3-party key distribution protocol
is used, this can be detected.

"No security properties are lost"

Isn't channel binding a security property?

Regards,
Yoshihiro Ohba


_______________________________________________
HOKEY mailing list
HOKEY@ietf.org
https://www1.ietf.org/mailman/listinfo/hokey



From hokey-bounces@ietf.org Thu Apr 05 10:16: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 1HZSlH-0004py-AP; Thu, 05 Apr 2007 10:16:27 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HZSlG-0004pb-42
	for hokey@ietf.org; Thu, 05 Apr 2007 10:16:26 -0400
Received: from inet-tsb5.toshiba.co.jp ([202.33.96.24])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZSlE-0005yG-Cz
	for hokey@ietf.org; Thu, 05 Apr 2007 10:16:26 -0400
Received: from tsb-wall.toshiba.co.jp ([133.199.160.134])
	by inet-tsb5.toshiba.co.jp  with ESMTP id l35EGJeJ017265;
	Thu, 5 Apr 2007 23:16:19 +0900 (JST)
Received: (from root@localhost) by tsb-wall.toshiba.co.jp  id l35EGKeG016540;
	Thu, 5 Apr 2007 23:16:20 +0900 (JST)
Received: from ovp1.toshiba.co.jp [133.199.192.124] 
	by tsb-wall.toshiba.co.jp with ESMTP id ZAA16539;
	Thu, 5 Apr 2007 23:16:20 +0900
Received: from mx2.toshiba.co.jp (localhost [127.0.0.1])
	by ovp1.toshiba.co.jp  with ESMTP id l35EGJpm026161;
	Thu, 5 Apr 2007 23:16:19 +0900 (JST)
Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id l35EGJP2007507;
	Thu, 5 Apr 2007 23:16:19 +0900 (JST)
Received: from steelhead ([172.30.24.105])
	by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 (built
	Apr 28
	2004)) with ESMTPSA id <0JG100I423N41V10@mail.po.toshiba.co.jp>; Thu,
	05 Apr 2007 23:16:19 +0900 (JST)
Received: from ohba by steelhead with local (Exim 4.63)
	(envelope-from )	id 1HZSl7-0004xl-CF; Thu,
	05 Apr 2007 07:16:17 -0700
Date: Thu, 05 Apr 2007 10:16:17 -0400
From: Yoshihiro Ohba 
Subject: Re: [HOKEY] consensus call: key distribution security requirement
In-reply-to: <460EB36E.5010604@cs.umd.edu>
To: Charles Clancy 
Message-id: <20070405141617.GB18558@steelhead>
MIME-version: 1.0
Content-type: text/plain; charset=iso-2022-jp
Content-disposition: inline
References: <460EB36E.5010604@cs.umd.edu>
User-Agent: Mutt/1.5.13 (2006-08-11)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002
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

My answer is "yes".  I believe that peer consent is an important
requirement to prevent DoS attack on proactive key distribution.
Otherwise, an attacker can generate non-secured triggers by simply
spoofing the identities of authenticated peers, which can cause the
server to flood a number of keys to a number of authenticators.

BTW, I don't understand why channel bindings where identities are
hashed into the key derivation would be sufficient if the answer is
"no".

Yoshihiro Ohba


On Sat, Mar 31, 2007 at 03:15:58PM -0400, Charles Clancy wrote:
> HOKEY WG,
> 
> The 3-party protocol proposal at IETF 68 listed a variety of protocol 
> requirements, some of which went beyond those currently specified in the 
> problem statements draft.  The main extension was a requirement for 
> stronger key distribution security.
> 
> Discussion: The problem statements document currently requires channel 
> bindings to allow clients to authenticate the network to which they are 
> connecting, and prevent the lying NAS problem.  However one possible 
> implementation of channel bindings would allow keys to be distributed 
> prior to the network being authenticated by the peer.  While the peer 
> may decide to not use a network after it's validated its identity, 
> network entities could retain the keying material.  There has been much 
> debate on the list as to whether or not network entities could 
> maliciously use this keying material, and the intent here is to not 
> rehash all that discussion.
> 
> Question: Should additional text be added to the problem statement draft 
>  to require peer authorization for distributing keying material?
> 
> Protocol Implications: If "yes" then a 3-party protocol would be need, 
> and would require L2 advertisement of the NAS-ID and local AAA domain 
> name.  If "no" then channel bindings where identities are hashed into 
> the key derivation would be sufficient.
> 
> -- 
> t. charles clancy, ph.d.  <>  tcc@umd.edu  <>  www.cs.umd.edu/~clancy
> 
> 
> _______________________________________________
> 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 Apr 05 10:30: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 1HZSyf-00053Q-RX; Thu, 05 Apr 2007 10:30:17 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HZSye-0004vH-6J
	for hokey@ietf.org; Thu, 05 Apr 2007 10:30:16 -0400
Received: from imx12.toshiba.co.jp ([61.202.160.132])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZSyZ-0007sC-GF
	for hokey@ietf.org; Thu, 05 Apr 2007 10:30:16 -0400
Received: from wall11.toshiba.co.jp (wall11 [133.199.90.149])
	by imx12.toshiba.co.jp  with ESMTP id l35ETuJ9003721;
	Thu, 5 Apr 2007 23:29:56 +0900 (JST)
Received: (from root@localhost) by wall11.toshiba.co.jp  id l35ETubE021831;
	Thu, 5 Apr 2007 23:29:56 +0900 (JST)
Received: from ovp11.toshiba.co.jp [133.199.90.148] 
	by wall11.toshiba.co.jp with ESMTP id ZAA21830;
	Thu, 5 Apr 2007 23:29:56 +0900
Received: from mx.toshiba.co.jp (localhost [127.0.0.1])
	by ovp11.toshiba.co.jp  with ESMTP id l35ETt2N005489;
	Thu, 5 Apr 2007 23:29:56 +0900 (JST)
Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id l35ETtKo018274;
	Thu, 5 Apr 2007 23:29:55 +0900 (JST)
Received: from steelhead ([172.30.24.105])
	by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 (built
	Apr 28
	2004)) with ESMTPSA id <0JG100IDQ49S1V10@mail.po.toshiba.co.jp>; Thu,
	05 Apr 2007 23:29:55 +0900 (JST)
Received: from ohba by steelhead with local (Exim 4.63)
	(envelope-from )	id 1HZSyH-000502-61; Thu,
	05 Apr 2007 07:29:53 -0700
Date: Thu, 05 Apr 2007 10:29:53 -0400
From: Yoshihiro Ohba 
Subject: Re: [HOKEY] consensus call: key distribution security requirement
In-reply-to: <46145077.5020000@cs.umd.edu>
To: Charles Clancy 
Message-id: <20070405142953.GC18558@steelhead>
MIME-version: 1.0
Content-type: text/plain; charset=iso-2022-jp
Content-disposition: inline
References: <002501c77711$89c61d00$2f01a8c0@china.huawei.com>
	<46145077.5020000@cs.umd.edu>
User-Agent: Mutt/1.5.13 (2006-08-11)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c
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 Charles,

On Wed, Apr 04, 2007 at 08:27:19PM -0500, Charles Clancy wrote:
> All,
> 
> I think we need to look at the protocols.  To compare...
> 
> 3-party protocol (Dan's proposal, slightly simplified assuming AAA 
> provides the necessary transport security):
> 
>    1) A->B: A, {A, B, Na}Kas
>    2) B->S: A, B, {A, B, Na}Kas
>    3) S->B: {B, Na}Kas, {A, Kab}Kbs
>    4) B->A: {B, Na}Kas
> 
> EAP-ER (translated to above notation and assuming AAA transport):
> 
>    1) A->B: A, {A, Na}Kas
>    2) B->S: A, B, {A, Na}Kas
>    3) S->B: {Na}Kas, {Kab}Kbs
>    4) B->A: {Na}Kas
> 
> EAP-ER+CB (my proposal for adding channel binding to EAP-ER):
> 
>    1) A->B: A, {A, Na}Kas
>    2) B->S: A, B, {A, Na}Kas
>    3) S->B: {B, Na}Kas, {A, Kab}Kbs
>    4) B->A: {B, Na}Kas
> 
> So, we've added "A" and "B" in messages 3 and 4, but not added "B" in 
> message 1.  I feel this satisfies everything *but* peer consent, and 
> doesn't require A to know "B" at the beginning.

If step 3) and step 4) need to happen immediately after step 2), I
think peer consent requirement is satisfied in your proposal.  On the
other hand, this does not exempt NAS-ID from being advertised by lower
layer.

Yoshihiro Ohba


> 
> -- 
> t. charles clancy, ph.d.  |  tcc@umd.edu  |  www.cs.umd.edu/~clancy
> 
> 
> _______________________________________________
> 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 Apr 05 11:13:05 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HZTe1-0002Ht-It; Thu, 05 Apr 2007 11:13:01 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HZTdz-0002Hd-Jk
	for hokey@ietf.org; Thu, 05 Apr 2007 11:12:59 -0400
Received: from mcfeely.cs.umd.edu ([128.8.128.218])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZTdy-0005Ai-9W
	for hokey@ietf.org; Thu, 05 Apr 2007 11:12:59 -0400
Received: from mcfeely.cs.umd.edu (localhost [127.0.0.1])
	by mcfeely.cs.umd.edu (8.12.11.20060308/8.12.5) with ESMTP id
	l35FCwT7004930; Thu, 5 Apr 2007 11:12:58 -0400
Received: (from apache@localhost)
	by mcfeely.cs.umd.edu (8.12.11.20060308/8.12.11/Submit) id
	l35FCvRL004928; Thu, 5 Apr 2007 11:12:57 -0400
X-Authentication-Warning: mcfeely.cs.umd.edu: apache set sender to
	clancy@cs.umd.edu using -f
Received: from 63.239.69.1 (SquirrelMail authenticated user clancy)
	by webmail.cs.umd.edu with HTTP; Thu, 5 Apr 2007 11:12:57 -0400 (EDT)
Message-ID: <55084.63.239.69.1.1175785977.squirrel@webmail.cs.umd.edu>
In-Reply-To: <20070405142953.GC18558@steelhead>
References: <002501c77711$89c61d00$2f01a8c0@china.huawei.com>
	<46145077.5020000@cs.umd.edu> <20070405142953.GC18558@steelhead>
Date: Thu, 5 Apr 2007 11:12:57 -0400 (EDT)
Subject: Re: [HOKEY] consensus call: key distribution security requirement
From: "Charles Clancy" 
To: "Yoshihiro Ohba" 
User-Agent: SquirrelMail/1.4.5
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f
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

>> EAP-ER+CB (my proposal for adding channel binding to EAP-ER):
>>
>>    1) A->B: A, {A, Na}Kas
>>    2) B->S: A, B, {A, Na}Kas
>>    3) S->B: {B, Na}Kas, {A, Kab}Kbs
>>    4) B->A: {B, Na}Kas
>>
>> So, we've added "A" and "B" in messages 3 and 4, but not added "B" in
>> message 1.  I feel this satisfies everything *but* peer consent, and
>> doesn't require A to know "B" at the beginning.
>
> If step 3) and step 4) need to happen immediately after step 2), I
> think peer consent requirement is satisfied in your proposal.

The peer has consented that a key should be derived, but did not securely
specify "B" as the recipient of that key.  In message #4, the peer is
informed the recipient was "B".

> On the
> other hand, this does not exempt NAS-ID from being advertised by lower
> layer.

Correct.  However, if the peer doesn't care about the identity of the
network, then he can always accept the key without comparing "B" to
something advertised at L2.

I imagine that in many cases, the identity of "B" is important -- for
example in a WiFi network, where "B" could equal the SSID.  However in a
cellular network, you many not care whose network you're connecting to, so
long as they have the proper roaming relationship with your provider.  In
that case, perhaps checking "B" is less important.

I think this approach is the most flexible.

-- 
t. charles clancy, ph.d.  <>  tcc@umd.edu  <>  www.cs.umd.edu/~clancy


_______________________________________________
HOKEY mailing list
HOKEY@ietf.org
https://www1.ietf.org/mailman/listinfo/hokey



From hokey-bounces@ietf.org Thu Apr 05 11:27:12 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HZTrg-0004fe-H4; Thu, 05 Apr 2007 11:27:08 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HZTrg-0004fZ-3P
	for hokey@ietf.org; Thu, 05 Apr 2007 11:27:08 -0400
Received: from rtp-iport-1.cisco.com ([64.102.122.148])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZTrf-0006pV-0W
	for hokey@ietf.org; Thu, 05 Apr 2007 11:27:08 -0400
Received: from rtp-dkim-1.cisco.com ([64.102.121.158])
	by rtp-iport-1.cisco.com with ESMTP; 05 Apr 2007 11:27:07 -0400
Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13])
	by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l35FR6CY018958; 
	Thu, 5 Apr 2007 11:27:06 -0400
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com
	[64.102.31.12])
	by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l35FQZls012710; 
	Thu, 5 Apr 2007 15:27:06 GMT
Received: from xmb-rtp-212.amer.cisco.com ([64.102.31.111]) by
	xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 5 Apr 2007 11:26:55 -0400
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] consensus call: EAP-ER as HOKEY protocol
Date: Thu, 5 Apr 2007 11:26:52 -0400
Message-ID: <9958B444368E884DBB215F3FEF36F5B7042954C9@xmb-rtp-212.amer.cisco.com>
In-Reply-To: <4613D4FC.3060709@qualcomm.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [HOKEY] consensus call: EAP-ER as HOKEY protocol
Thread-Index: Acd21/siljmOv1LZR3625aGb/JIbQQAutdkg
References: <002701c7757c$ea5d0e30$2f01a8c0@china.huawei.com>,
	<4611C658.7050603@qualcomm.com>
	<461289A3.3000901@qualcomm.com>
	<9958B444368E884DBB215F3FEF36F5B7041F9D64@xmb-rtp-212.amer.cisco.com>
	<4612BF90.3080901@qualcomm.com>
	<9958B444368E884DBB215F3FEF36F5B7041F9F6F@xmb-rtp-212.amer.cisco.com>
	<4613D4FC.3060709@qualcomm.com>
From: "Hao Zhou \(hzhou\)" 
To: "Lakshminath Dondeti" 
X-OriginalArrivalTime: 05 Apr 2007 15:26:55.0014 (UTC)
	FILETIME=[D7A62C60:01C77796]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=23440; t=1175786826;
	x=1176650826; c=relaxed/simple; s=rtpdkim1001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=hzhou@cisco.com;
	z=From:=20=22Hao=20Zhou=20\(hzhou\)=22=20
	|Subject:=20RE=3A=20[HOKEY]=20consensus=20call=3A=20EAP-ER=20as=20HOKEY=2
	0protocol |Sender:=20
	|To:=20=22Lakshminath=20Dondeti=22=20;
	bh=MM2RLCgQJePWjrnxeC7PyhuVG+4van4jD/QM5mVunPw=;
	b=NVJA2vfkziF5Fhl/umCO1Qb8YE5LrSRkDbRahcJYLENgEK+3ybU/Snz7onZ7eN38x9hH9FLY
	tSJlBvZhNoSNAhI7LMpXnMufB+fiTyvqzyNy0+TOcEyo3+5rAW0vpqoY;
Authentication-Results: rtp-dkim-1; header.From=hzhou@cisco.com; dkim=pass (
	sig from cisco.com/rtpdkim1001 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8104b3fcabb4d2dfaed548848b9dc80f
Cc: Madjid Nakhjiri , 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

Lakshminath:

Please see inline.=20

> -----Original Message-----
> From: Lakshminath Dondeti [mailto:ldondeti@qualcomm.com]=20
> Sent: Wednesday, April 04, 2007 12:40 PM
> To: Hao Zhou (hzhou)
> Cc: Avi Lior; hokey@ietf.org; Madjid Nakhjiri
> Subject: Re: [HOKEY] consensus call: EAP-ER as HOKEY protocol
>=20
> Hao,
>=20
> Thanks for your clarifications.  Please see inline (there is=20
> a disconnect):
>=20
> Hao Zhou (hzhou) wrote:
> > Lakshminath:
> >=20
> > Please see inline.=20
> >=20
> >> -----Original Message-----
> >> From: Lakshminath Dondeti [mailto:ldondeti@qualcomm.com]
> >> Sent: Tuesday, April 03, 2007 4:57 PM
> >> To: Hao Zhou (hzhou)
> >> Cc: Avi Lior; hokey@ietf.org; Madjid Nakhjiri
> >> Subject: Re: [HOKEY] consensus call: EAP-ER as HOKEY protocol
> >>
> >> Hi Hao,
> >>
> >> Thanks for proposing the detailed solution.  On a first look, it=20
> >> might seem to offer the benefits you list, but a closer=20
> look reveals=20
> >> serious
> >> problems:
> >>
> >> 1. EAP-Request/Identity does have a provision to carry stuff after=20
> >> the NUL character.  There seems to be contention by=20
> various use cases=20
> >> for that space.  That is a problem.  More specifically,=20
> 4284 cannot=20
> >> be used with reauthentication.
> >>
> > [HZ] I don't see there is a contention, other than the size=20
> limitation.
> > RFC4284 defines it own syntax "NAIRealms=3D", for HOAKEY we=20
> can define=20
> > our own syntax. They can coexist. And we are not using=20
> RFC4284 (only=20
> > using idea similar to it) and thus not limited to initial=20
> authentication.
>=20
> There is of course contention for space :) .  As you note=20
> there is a size limitation and several different protocols=20
> may want to use that space; further, there is no clear format=20
> other than include text after the NUL character.  3748=20
> documents some legacy uses (doesn't say what those are),=20
> there is the 4284 provision and now your proposal.  (Note=20
> draft-barany-eap-gee also considers the use of 4284 style hints).
>=20
> All told, if there is a simple way of including HOKEY=20
> capability declaration in EAP Request/Identity messages, I am=20
> not opposed to that (at some point I may have even said=20
> that).  On the other hand, some lower layers have extensive=20
> capability negotiation; for those a simple maintenance=20
> extension for HOKEY is not out of the question.
>=20
>=20
> >=20
> >> 2. EAP-Response/Identity does not have a provision to carry=20
> >> additional data.  That is a change to 3748's text.
> >>
> > [HZ] I am talking about carry data inside the response, as=20
> part of the=20
> > response, like Avi pointed out. It doesn't conflict with RFC3748.
>=20
> I asked Avi for clarification.  His notes so far indicate=20
> that he is talking about overloading the NAI payload.  It is=20
> not the same thing as you are talking about.  Next,=20
> 3748-compliant implementations won't know what to do.  That=20
> automatically means that a revision to 3748 is needed if this=20
> were to be the path HOKEY chooses.  Do you agree?
>=20
[HZ] I think I am talking about overloading the response identity as
well. I don't think 3748 compliant implementation has any problem with
it, it just forwards it to AAA.=20

> >=20
> >> 3. EAP Success retransmission semantics need to change. =20
> This means=20
> >> changes to the authenticator.  So, backward compatibility=20
> arguments=20
> >> are not applicable.
> >>
> > [HZ] I guess you missed my point. Legacy authenticator=20
> and/or client=20
> > would never receive the EAP-Success with optional data, only the=20
> > regular EAP-Success, as HOAKEY will not happen for them and=20
> they will=20
> > start a normal EAP authentication. Only new client and NAS that are=20
> > HOAKEY capable will see this and know how to handle them.
>=20
> Ok, let's see:
>=20
> Case 1: Legacy client, HOKEY capable authenticator:
>=20
> Piggybacking approach: Client receives an EAP=20
> Request/Identity with HOKEY capability.  It may not be able=20
> to parse the new stuff and if it were to be gracious in what=20
> it accepts, sends a 3748-compliant EAP Response/Identity. =20
> Full authentication occurs.  If the client were not gracious=20
> it may crash or discard the Request message.
>=20
[HZ] Why would the client crash? If it doesn't behave well with data
after NULL, it would crash with RFC 4284 as well. Most clients I know
don't care about the data in the request at all.

> EAP-ER: Client negotiates full EAP only at the lower layer;=20
> or, if we use the piggybacking approach will behave more or=20
> less the same as above.
>=20
> Case 2: HOKEY capable client, legacy authenticator:
>=20
> Piggybacking approach: Client receives an EAP=20
> Request/Identity without HOKEY capability.  There are at=20
> least two cases: in the first, 4284 hints and other stuff has=20
> filled up the EAP Request/Identity packet capacity and the=20
> client has no way of knowing whether the authenticator=20
> supports HOKEY capability or not.  In the second, the client=20
> knows that the authenticator does or doesn't support HOKEY=20
> and carries out reauthentication or full authentication.
>=20
[HZ] If the client cannot tell from the Request Identity whether HOAKEY
is supported or not, then the design of advertising HOAKEY in Request
Identity is bad. I believe that we can design a syntax that can easily
distinguish 4284 hints and others from HOAKEY.=20

> EAP-ER: Client knows based on lower layer negotiation whether=20
> EAP-ER is supported and proceeds to use reauthentication or=20
> full authentication.
>=20
> It may be plausible to introduce an EAP-ER trigger: one such=20
> possibility is to use what you propose, i.e., send EAP=20
> Request/Identity with HOKEY capability.  The considerations I=20
> elaborated above apply.
>=20
> So, I see the whole backward compatibility thing as a non issue.
>
[HZ] No so fast. You assume that we can readily add to lower layer
capability to indicate HOAKEY support and pass other information needed.
I don't know if that assumption is correct or not. I like an approach
that self-contained within EAP and can work on existing lower layers
with minimum(or no) changes.
=20
> > =20
> >> Bottomline is the authenticator behavior is going to be=20
> changed one=20
> >> way or another.  We reviewed all of this at the interim=20
> meeting.  As=20
> >> to one new code vs. two, one of the older versions of=20
> EAP-ER did have=20
> >> one code.
> >>   The current version is a result of the discussions at=20
> the interim=20
> >> meeting.  I think the minutes covered the reasoning.
> >>
> > [HZ] Is your assumption that HOAKEY will only work on new EAP lower=20
> > layer, hence both client and authenticator will change and include=20
> > capability negotiation, and hence don't have to worry about legacy=20
> > client or authentication? My proposal works with legacy client and=20
> > authenticator.
>=20
> Please see above.  Sure I appreciate the notion of adding=20
> 4284 style hints (my recollection is that it was mentioned=20
> before, but I am happy to call it your proposal), but there=20
> are limitations to it.  4284 itself was a semi-solution (that=20
> RFC says that much) or a semi-hack depending on how one looks at it.
>=20
> >=20
> >> As to minimizing lower layer changes and being able to=20
> signal HOKEY=20
> >> capability in EAP, let's talk about that separately.
> >>
> >> My goals here are to minimize modifications to the EAP=20
> state machine.=20
> > [HZ] I don't see adding two new codes will minimize the=20
> modifications=20
> > to EAP state machine, vs. reusing the existing codes.
>=20
> That sentence was constructed with some care: note the words=20
> "modifications" and "EAP state machine".  Put another way,=20
> the idea is to "add" a new "EAP-ER state machine."
>=20
> Consider the complexity in making EAP Success reliable. =20
> Suppose the HOKEY-capable peer doesn't receive the Success=20
> message with the additional data; what does it do?
>=20
[HZ] I don't know why this is relevant in this discussion. You still
need to handle not receiving response if you use another EAP code.
Matter of fact, if you use the same EAP-Success code, the existing EAP
message timeout handling mechanism will still work.

> >=20
> >> Additions are always better and cleaner than modifying the=20
> protocol=20
> >> behavior.  Suppose some other use case comes along in the=20
> future and=20
> >> modifies EAP in a different way.  What happens then?
> > [HZ] If we really think of a solution to be more generic, then we=20
> > probably should look at extending the EAP packet, maybe allowing=20
> > carrying of other data, instead of creating two new codes just for=20
> > HOAKEY.
>=20
> Like I said before, if the hangup is two vs. one, that can be=20
> discussed as part of WG proceedings.  We had that discussion=20
> once before.
>=20
[HZ] I can live with one, but I prefer no new code for maximum backward
compatibility. Are you saying proposal of no new code is not part of the
WG proceedings? This whole discussion is part of the WG proceeding,
isn't it?

> Again, extensions to EAP packets have limitations and=20
> introduce serious complexity; we have at least two examples:=20
> on Request/Identity there is a space contention.  The other=20
> thing is extending Success is a can of worms.  One reason is=20
> the retransmission complexity and the other thing is other=20
> protocols may want to add stuff to that message.  Protected=20
> result indications via EAP come to mind.
>=20
> Finally, we have space for 252 new codes.  Why is using 2 new=20
> codes for as important an application as HOKEY a big deal? =20
> After all, the IETF chartered a whole new WG to do that work!
>=20
[HZ] I am not against creating new code, but I think we can create new
ones for more generic use, not just HOAKEY. For instance, if we decide
not to piggyback EAP-Success and creating a new code instead, I would
suggest creating a new EAP-Success code that allow additional data, such
as protected result, re-authentication, etc. Better is to creating new
EAP codes to allow piggyback data on all existing EAP codes, call it
EAPv2.=20

> Many thanks for elaborating the ideas behind the piggybacking=20
> exchange.=20
>   It has been helpful to me to understand fully what it=20
> entails (I must say Vidya and I have debated about this in=20
> the past and ruled out this direction; for instance, one of=20
> the long and painful debates was on how one might make EAP=20
> success reliable.  Can it be done?  Yes.  But, it requires=20
> serious changes to 3748 behavior and I strongly think that=20
> those changes are not worthwhile.  The code based approach is=20
> definitely
> cleaner!)
>=20
> regards,
> Lakshminath
>=20
> >=20
> >> thanks,
> >> Lakshminath
> >>
> >> Hao Zhou (hzhou) wrote:
> >>> I have been soliciting with a few others about the idea of using=20
> >>> existing EAP codes to do HOAKEY, instead of creating new=20
> EAP codes.
> >>> The idea is roughly like this:
> >>>
> >>> 1. NAS still sends out EAP-Identity request, with=20
> something in the=20
> >>> request to indicate HOAKEY support. Something similar to
> >> how network
> >>> selection RFC utilizing the space after NULL character. The
> >> extra data
> >>> would include HOAKEY capability, as well as any other information=20
> >>> needed, e.g., domain ID, etc.
> >>>
> >>> 2. Client send back normal EAP-Identity Response,=20
> piggybacking any=20
> >>> HOAKEY data needed, e.g., agreement to do HOAKEY and any
> >> HOAKEY keying
> >>> materials.
> >>>
> >>> 3. If the NAS determine that client wants to do HOAKEY, then it=20
> >>> forwards the HOAKEY data to the HOAKEY server. Otherwise,=20
> it starts=20
> >>> the normal full EAP authentication.
> >>>
> >>> 4. After HOAKEY server sends back the server data, NAS sends=20
> >>> EAP-Success with additional HOAKEY data, which allows the=20
> client to=20
> >>> verify and authenticate the NAS.
> >>>
> >>> The benefits of using this approach are:
> >>>
> >>> 1. Maximum backward compatibility with legacy NAS and
> >> client. Existing
> >>> client should work with new HOAKEY NAS and existing NAS=20
> would work=20
> >>> with new HOAKEY capable client.
> >>> 2. Less changes on the EAP lower layer on both the client
> >> and NAS. The
> >>> only change is to allow additional data to be piggy-backed on=20
> >>> EAP-Success, vs. current EAP-ER proposal of two new EAP codes.
> >>> 3. HOAKEY capability negotiation and domain ID=20
> transmission is also=20
> >>> included this way, instead of being mandated to be added to
> >> lower layer.
> >>> The lower layer is probably harder to change.
> >>> 4. I don't think the half round trip for EAP-Identity request and=20
> >>> response would hurt performance too much and critical, as
> >> it is local
> >>> between the client and NAS. Modifying the lower layer to
> >> allow client
> >>> initiating exchange might be too much for some lower layer.
> >>> 5. Even if piggybacking data on EAP-Success is determined to be=20
> >>> impossible and we need a new EAP code, we should still just
> >> create a
> >>> single new code for the EAP-Success with optional data,
> >> this way, only
> >>> the new HOAKEY capable NAS and client needs to understand
> >> and support
> >>> it. I would recommend still using the EAP-Identity=20
> request-response=20
> >>> exchange for the first part. The goal is to minimize=20
> changes to EAP=20
> >>> flow and state machine and EAP lower layer as little as possible.
> >>>
> >>>> -----Original Message-----
> >>>> From: Lakshminath Dondeti [mailto:ldondeti@qualcomm.com]
> >>>> Sent: Tuesday, April 03, 2007 1:07 PM
> >>>> To: Avi Lior
> >>>> Cc: hokey@ietf.org; Madjid Nakhjiri
> >>>> Subject: Re: [HOKEY] consensus call: EAP-ER as HOKEY protocol
> >>>>
> >>>> Hi Avi,
> >>>>
> >>>> I find some of your arguments counter-intuitive and so
> >> would like to
> >>>> understand your line of thinking on this topic.
> >>>> Modifications to a protocol to my knowledge would be hacks and=20
> >>>> extensions are well, extensions.  For instance, the EAP=20
> >>>> Request/Identity message suspension in EAP-ER, as much=20
> as I would=20
> >>>> like to defend it, is somewhat of a hack.
> >>>>   It is the cleanest Vidya and I could come up with in the
> >> sense that
> >>>> the message itself is not modified, but we need something
> >> like it to
> >>>> make sure that the L2 connection is not closed if the
> >> retransmission
> >>>> time expires.  Perhaps the wider community might find a better=20
> >>>> approach.
> >>>>
> >>>> Next, some notes on 4284 since that has come up here:
> >>>>
> >>>> 3748 says "Some EAP implementations piggy-back various
> >> options into
> >>>> the
> >>>>        Identity Request after a NUL-character. "
> >>>>
> >>>> 4284 uses that provision.  In any event, 4284 is somewhat
> >> of a hack
> >>>> and is an informational RFC for the purposes of 3GPP's use.
> >>>>
> >>>> Please see inline for some questions:
> >>>>
> >>>> Avi Lior wrote:
> >>>>> I for one thinks we should look at allowing us to carry
> >> data in EAP
> >>>>> success.  In fact, it would be a good idea if we allowed
> >>>> EAP to carry
> >>>>> data which is not part of the method in all exchanges.
> >>>> If the data is not part of the method, which entity=20
> needs to send=20
> >>>> such data and how is it protected?
> >>>>
> >>>>> Clearly there is a need to communicate with the Peer before
> >>>> and just
> >>>>> after authentication.  There is no other path to the Peer. =20
> >>>> EAP should
> >>>>> have addressed this.
> >>>> Again which entity needs to communicate with the Peer?
> >>>>
> >>>>> =20
> >>>>> We already see this happening in the Request Identity (as
> >>>> in Network
> >>>>> Selection and other such usage), in the Repsonse Identity
> >>>> and now in
> >>>>> the Success phase.
> >>>>> =20
> >>>>> We can continue to "hack" EAP but we can also fix it.
> >>>> I am lost here, so please help me out :).  The network selection=20
> >>>> solution of 4284 is a hack IMO.  If you are saying we
> >> should revise
> >>>> 3748, I might agree with you in principle.
> >>>> But, practically speaking that is not happening anytime soon.
> >>>>
> >>>> Next, RFC 3748 has clear guidance on allocating new packet
> >> codes in
> >>>> Section 6.1.  Defining new codes is a natural way of
> >> extending EAP. =20
> >>>> If the goal is backward compatibility, adding stuff to=20
> EAP Success=20
> >>>> doesn't help either.  As I have noted before, EAP Success
> >> packets are
> >>>> not retransmitted by authenticators and that would have to
> >> change if
> >>>> we add anything crucial to Success packets.
> >>>>
> >>>> I appreciate any clarifications you might provide to help me=20
> >>>> understand your point of view here.  Thanks.
> >>>>
> >>>> regards,
> >>>> Lakshminath
> >>>>
> >>>>> =20
> >>>>> I am not saying EAP-ER is a hack but it is not efficient
> >> because it
> >>>>> works around the existing EAP semantics but hopefully we
> >>>> could do better.
> >>>>> =20
> >>>>> Avi Lior Office: +1 613 591-9104 x 6417 Cell : +1 613 796-4183
> >>>>>
> >>>>>
> >>>>>
> >>=20
> ---------------------------------------------------------------------
> >>>> -
> >>>>> --
> >>>>> *From:* Lakshminath Dondeti
> >>>>> *Sent:* Mon 4/2/2007 11:13 PM
> >>>>> *To:* Madjid Nakhjiri
> >>>>> *Cc:* hokey@ietf.org
> >>>>> *Subject:* Re: [HOKEY] consensus call: EAP-ER as HOKEY protocol
> >>>>>
> >>>>> Many of the active WG contributors were present at the
> >>>> interim meeting
> >>>>> and there was a presentation and discussion on how
> >> reauthentication
> >>>>> might work with new EAP types or codes.  The consensus was that=20
> >>>>> code-based approach works best and that consensus was
> >> subsequently
> >>>>> verified on the list.
> >>>>>
> >>>>> Well, here we are.  I am also looking forward to seeing
> >>>> your analysis
> >>>>> on this topic.  Changing the structure of the EAP Success
> >>>> message and
> >>>>> also the transmission rules for EAP Success are quite
> >>>> drastic changes. =20
> >>>>> If EAP Success needs to be reliably transmitted, authenticator=20
> >>>>> behavior would have to change.  Consider the following
> >>>> rules on EAP Success messages:
> >>>>> "The peer
> >>>>>     MAY, in the event that an EAP Success is not received,
> >>>> conclude that
> >>>>>     the EAP Success packet was lost and that authentication
> >>>> concluded
> >>>>>     successfully."
> >>>>>
> >>>>> "Success and Failure packets MUST NOT
> >>>>>     contain additional data."
> >>>>>
> >>>>> "Because the Success and Failure packets are not
> >>>>>     acknowledged, they are not retransmitted by the
> >>>> authenticator, and
> >>>>>     may be potentially lost.  A peer MUST allow for this
> >>>> circumstance as
> >>>>>     described in this note. "
> >>>>>
> >>>>> Anyway, I still want to see your analysis of this.
> >>>>>
> >>>>> thanks,
> >>>>> Lakshminath
> >>>>>
> >>>>> PS:  I understand your concern about EAP Identity Request
> >>>> and we can
> >>>>> work on other alternatives for it where terminating the=20
> EAP state=20
> >>>>> machine at the Authenticator and spawning an EAP-ER state
> >>>> machine is
> >>>>> considered burdensome (there are other ways of looking at
> >> this and
> >>>>> that is written in vidya-eap-er-02).
> >>>>>
> >>>>> Madjid Nakhjiri wrote:
> >>>>>  > Hi,
> >>>>>  >
> >>>>>  > I like to seek a clarification here first.
> >>>>>  > Have we put the discussion of use of EAP code versus EAP
> >>>> types to
> >>>>> bed,  > completely satisfied that EAP types will absolutely
> >>>> not solve
> >>>>> the problems?
> >>>>>  >
> >>>>>  > Given that the Russ only first gave the few of us
> >> present in San
> >>>>> Jose the  > green light to change EAP, I feel that we did
> >> not quite
> >>>>> discuss the impact  > of adding new EAP codes versus other
> >>>> changes to
> >>>>> an end.  A simple analysis  > shows (I have confirmed this with=20
> >>>>> several EAP experts) that using a new EAP  > type and=20
> adding some=20
> >>>>> payload to EAP success you can easily achieve near 1  >=20
> roundtrip=20
> >>>>> exchanges. I can forward that analysis in a separate email.
> >>>>>  >
> >>>>>  > It is not clear whether adding data to EAP success is
> >>>> more severe
> >>>>> than the  > changes that EAP-ER is suggesting, to name a few:
> >>>>>  >
> >>>>>  > 1) adding new codes even though 3748 mandates a discard
> >>>> code>4  >
> >>>>> 2) change of authenticator state machine to treat EAP ER
> >>>> Request as a
> >>>>>> response to EAP Identity request. This seems a lot more
> >>>> intrusive on
> >>>>> the  > massive scale of existing authenticators, than
> >>>> adding data to
> >>>>> EAP success  > intended for the peer.
> >>>>>  >
> >>>>>  > It seems that before fully deciding the EAP code
> >> versus EAP type
> >>>>> options, it  > is hard to make a judgement on a solution
> >>>> that is based
> >>>>> on EAP code.
> >>>>> After
> >>>>>  > that, there are issues such as identity exchanges that
> >>>> are needed
> >>>>> for key  > derivation according to the EMSK draft and it
> >> seems that
> >>>>> EAP-ER is  > considering those out of band or requires
> >>>> explicit additional signaling.
> >>>>>  >
> >>>>>  > Finally the other clarification I am seeking is=20
> regarding the=20
> >>>>> second  > document, don't we want to specify how the
> >>>> per-authenticator
> >>>>> keys are  > derived? It seems that it should be included in
> >>>> the second spec as well.
> >>>>>  >
> >>>>>  > R,
> >>>>>  >
> >>>>>  > Madjid
> >>>>>  >
> >>>>>  > -----Original Message-----
> >>>>>  > From: Charles Clancy [mailto:clancy@cs.umd.edu]  > Sent:=20
> >>>> Saturday,
> >>>>> March 31, 2007 11:58 AM  > To: hokey@ietf.org  >=20
> Subject: [HOKEY]=20
> >>>>> consensus call: EAP-ER as HOKEY protocol  >  > HOKEY WG,
> >>>  > The
> >>>>> chairs are making a second consensus call request to adopt
> >>>> EAP-ER as
> >>>>>> a WG document to satisfy our re-auth and hand-off
> >>>> deliverables.  It
> >>>>>> would serve as a starting point for development of the
> >>>> HOKEY protocol.
> >>>>>  >
> >>>>>  > Note that if accepted, it may be split into two WG=20
> documents,=20
> >>>>> separating  > the EAP-ER-Bootstrap into a second set of
> >>>> messages that
> >>>>> could be  > transported by any service to obtain a USRK=20
> or DSUSRK.
> >>>>>  >
> >>>>>  > Please respond by Friday, April 13.
> >>>>>  >
> >>>>>
> >>>>> _______________________________________________
> >>>>> 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
> >>>>
> >=20
>=20

_______________________________________________
HOKEY mailing list
HOKEY@ietf.org
https://www1.ietf.org/mailman/listinfo/hokey



From hokey-bounces@ietf.org Thu Apr 05 13:03:10 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HZVMY-0006iU-Dr; Thu, 05 Apr 2007 13:03:06 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HZVMX-0006iO-E1
	for hokey@ietf.org; Thu, 05 Apr 2007 13:03:05 -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 1HZVMT-0002fD-MK
	for hokey@ietf.org; Thu, 05 Apr 2007 13:03:05 -0400
Received: from www.trepanning.net (localhost [127.0.0.1])
	by mail1.trepanning.net (Postfix) with ESMTP id 123E91FA6750;
	Thu,  5 Apr 2007 10:02:59 -0700 (PDT)
Received: from 69.12.173.8
	(SquirrelMail authenticated user dharkins@lounge.org)
	by www.trepanning.net with HTTP; Thu, 5 Apr 2007 10:02:59 -0700 (PDT)
Message-ID: <44325.69.12.173.8.1175792579.squirrel@www.trepanning.net>
In-Reply-To: 
References: <460EB36E.5010604@cs.umd.edu>
	
	<20070404024453.GA18289@steelhead>
	
	<7030.12.108.168.179.1175729051.squirrel@www.trepanning.net>
	
Date: Thu, 5 Apr 2007 10:02:59 -0700 (PDT)
Subject: RE: [HOKEY] consensus call: key distribution security requirement
From: "Dan Harkins" 
To: "Narayanan, Vidya" 
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: 6a45e05c1e4343200aa6b327df2c43fc
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


  Vidya,

  All you're addressing is "preventing the domino effect". That is not
scoping the key or binding context to a key.

  There is context for the key. For instance, "this is for a particular
authenticator." To quote from draft-housley-aaa-key-mgmt-09.txt:

         The context will include the peer and NAS identities in more
         than one form.  One (or more) name form is needed to identify
         these parties in the authentication exchange and the AAA
         protocol.

In addition if HOKEY is going to have some key hierarchy in which keys
are specific for a particular usage or a particular domain then that
is additional context that has to be bound to the key. You're just
throwing a counter or a nonce into the mix and thinking that solves
all problems. It doesn't.

  Dan.

On Wed, April 4, 2007 6:20 pm, Narayanan, Vidya wrote:
> Hi Dan,
> As we talked about this before, there is no attack, when every key
> handed out is fresh and unique across any two key fetches from the
> server. So, the scoping of keys necessary is about ensuring that the
> same key is never ever given out again, even to the (seemingly) same
> entity.
>
> Vidya
>
>> -----Original Message-----
>> From: Dan Harkins [mailto:dharkins@lounge.org]
>> Sent: Wednesday, April 04, 2007 4:24 PM
>> To: Narayanan, Vidya
>> Cc: Yoshihiro Ohba; hokey@ietf.org
>> Subject: RE: [HOKEY] consensus call: key distribution
>> security requirement
>>
>>
>>   Hi Vidya,
>>
>>   As I explained to you previously the issue of "peer detects
>> mismatch during secure association protocol" (slide 5 of your
>> deck) doesn't work because these are symmetric keys and the
>> "middle entity" can impersonate the client now. Every single
>> property that you want to give to the key being distributed is lost.
>>
>>   Of course you may not view that as a problem but I think
>> that has more to do with what you want to do then with
>> whether it's secure or not.
>>
>>   Can you please explain how to ensure that keys are properly
>> scoped if you do not bind the scoping information to the
>> exchange that distributes the key? How can the peer have any
>> assurance that the key is "not shared"
>> (one of the qualifiers you mention) if it did not take part
>> in the distribution of its key?
>>
>>   Why not just send the EMSK to every entity that the AS
>> thinks it has a security association with? I mean, in many
>> cases as long as the peer receives a certain level of service
>> and is charged for same then the identity of the entity
>> receiving the EMSK is irrelevant and channel binding isn't
>> important and as long as we scope the key properly (everyone
>> with whom the AS shares a security association-- aka "the
>> network") then it's OK. After all, nothing matters as long as
>> the peer is satisfied and "if the peer is not satisfied or
>> there is a billing issue, it contacts its home network and
>> tries to get service from some other node instead" (to quote
>> from slide #6).
>>
>>   Dan.
>>
>> On Wed, April 4, 2007 11:16 am, Narayanan, Vidya wrote:
>> > Hi Yoshi,
>> >
>> >> -----Original Message-----
>> >> From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com]
>> >> Sent: Tuesday, April 03, 2007 7:45 PM
>> >> To: Narayanan, Vidya
>> >> Cc: Charles Clancy; hokey@ietf.org
>> >> Subject: Re: [HOKEY] consensus call: key distribution security
>> >> requirement
>> >>
>> >> Hi Vidya,
>> >>
>> >> Can you please explain why channel binding information must be
>> >> optional?
>> >>
>> >
>> > Briefly, in many cases, as long as the peer receives a
>> certain level
>> > of service and is charged for the same, the identity of the network
>> > entity providing the service is irrelevant. In some cases,
>> it may be
>> > relevant and hence, it would be good to have the capability to do
>> > channel binding. But, for the other cases, there is no need
>> to mandate
>> > the lower layer to advertise identities.
>> >
>> >> Can you also explain in which system there are no adverse
>> effects in
>> >> key distribution without explicit peer consent?
>> >>
>> >
>> > I have not seen any real loss of security properties in
>> distribution
>> > of keys without peer consent, as long as the keys are scoped
>> > correctly, not shared and freshness is always ensured.
>> >
>> > Please see
>> >
>> http://www.geocities.com/hellovidya/Authenticators_and_Identities.pdf
>> > if you are interested in more details. I had put some
>> slides together
>> > a while ago on this identities issue.
>> >
>> > Vidya
>> >
>> >> Regards,
>> >> Yoshihiro Ohba
>> >>
>> >>
>> >> On Tue, Apr 03, 2007 at 06:25:52PM -0700, Narayanan, Vidya wrote:
>> >> > I'm barely caught up on all the email after having been
>> on vacation
>> >> > until now, so, pardon me if I'm bringing up stuff that's
>> >> already been
>> >> > discussed here.
>> >> >
>> >> > I share some of Glen's concerns about "requiring" peer
>> >> consent and a
>> >> > 3-party protocol and about how practically deployable that
>> >> is. In my
>> >> > conversations with Dan in Prague, it seemed like we were on
>> >> the same
>> >> > page about including channel binding information in the
>> >> HOKEY protocol
>> >> > between the peer and server. I think such channel binding
>> >> information
>> >> > must be optional and not required. In some systems, there are no
>> >> > adverse effects of distribution of key material without
>> >> explicit peer
>> >> > consent and there is no reason to place upper layer identity
>> >> > advertisement requirements on the lower layers for such
>> systems. In
>> >> > some other systems, it may be a good idea to do so and
>> having the
>> >> > capability to do that in the protocol would be useful there.
>> >> >
>> >> > To specifically answer your question, I don't believe we need to
>> >> > update the problem statement. It already captures the
>> >> channel binding
>> >> > stuff and the explicit data that the peer and authenticator may
>> >> > include is one way of providing channel binding.
>> >> >
>> >> > Vidya
>> >> >
>> >> > > -----Original Message-----
>> >> > > From: Charles Clancy [mailto:clancy@cs.umd.edu]
>> >> > > Sent: Saturday, March 31, 2007 12:16 PM
>> >> > > To: hokey@ietf.org
>> >> > > Subject: [HOKEY] consensus call: key distribution security
>> >> > > requirement
>> >> > >
>> >> > > HOKEY WG,
>> >> > >
>> >> > > The 3-party protocol proposal at IETF 68 listed a variety of
>> >> > > protocol requirements, some of which went beyond those
>> currently
>> >> > > specified in the problem statements draft.  The main
>> >> extension was a
>> >> > > requirement for stronger key distribution security.
>> >> > >
>> >> > > Discussion: The problem statements document currently requires
>> >> > > channel bindings to allow clients to authenticate the
>> network to
>> >> > > which they are connecting, and prevent the lying NAS problem.
>> >> > > However one possible implementation of channel bindings
>> >> would allow
>> >> > > keys to be distributed prior to the network being
>> >> authenticated by
>> >> > > the peer.  While the peer may decide to not use a network
>> >> after it's
>> >> > > validated its identity, network entities could retain
>> the keying
>> >> > > material.
>> >> > > There has been much debate on the list as to whether or
>> >> not network
>> >> > > entities could maliciously use this keying material, and
>> >> the intent
>> >> > > here is to not rehash all that discussion.
>> >> > >
>> >> > > Question: Should additional text be added to the problem
>> >> statement
>> >> > > draft
>> >> > >   to require peer authorization for distributing
>> keying material?
>> >> > >
>> >> > > Protocol Implications: If "yes" then a 3-party
>> protocol would be
>> >> > > need, and would require L2 advertisement of the NAS-ID
>> >> and local AAA
>> >> > > domain name.  If "no" then channel bindings where
>> identities are
>> >> > > hashed into the key derivation would be sufficient.
>> >> > >
>> >> > > --
>> >> > > t. charles clancy, ph.d.  <>  tcc@umd.edu  <>
>> >> > > www.cs.umd.edu/~clancy
>> >> > >
>> >> > >
>> >> > > _______________________________________________
>> >> > > 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
>> >
>>
>>
>>
>



_______________________________________________
HOKEY mailing list
HOKEY@ietf.org
https://www1.ietf.org/mailman/listinfo/hokey



From hokey-bounces@ietf.org Thu Apr 05 13:22:42 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HZVfN-00019k-NM; Thu, 05 Apr 2007 13:22:33 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HZVfM-00019d-HM
	for hokey@ietf.org; Thu, 05 Apr 2007 13:22:32 -0400
Received: from numenor.qualcomm.com ([129.46.51.58])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZVf1-0005R0-Bs
	for hokey@ietf.org; Thu, 05 Apr 2007 13:22:32 -0400
Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158])
	by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id
	l35HMAWU030067
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Thu, 5 Apr 2007 10:22:10 -0700
Received: from sanexcas01.na.qualcomm.com (sanexcas01.qualcomm.com
	[172.30.36.175])
	by totoro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l35HM9C2006166;
	Thu, 5 Apr 2007 10:22:09 -0700 (PDT)
Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by
	sanexcas01.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 5 Apr 2007 10:22:09 -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
Subject: RE: [HOKEY] consensus call: key distribution security requirement
Date: Thu, 5 Apr 2007 10:22:09 -0700
Message-ID: 
In-Reply-To: <44325.69.12.173.8.1175792579.squirrel@www.trepanning.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [HOKEY] consensus call: key distribution security requirement
Thread-Index: Acd3pEvugR1dRqz8QB+WaU6/Ey04MQAAncww
References: <460EB36E.5010604@cs.umd.edu>
	
	<20070404024453.GA18289@steelhead>
	
	<7030.12.108.168.179.1175729051.squirrel@www.trepanning.net>
	
	<44325.69.12.173.8.1175792579.squirrel@www.trepanning.net>
From: "Narayanan, Vidya" 
To: "Dan Harkins" 
X-OriginalArrivalTime: 05 Apr 2007 17:22:09.0060 (UTC)
	FILETIME=[F0BDDE40:01C777A6]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8d89ee9312a95de8ee48d1c94511f1bb
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

Dan,
Context (usage) is additional information that needs to be bound to the
key - we have no disagreement there. But, channel binding is of no help
for that either. As to scope, the keys must be scoped to a domain and
that has also been agreed upon.=20

Vidya=20

> -----Original Message-----
> From: Dan Harkins [mailto:dharkins@lounge.org]=20
> Sent: Thursday, April 05, 2007 10:03 AM
> To: Narayanan, Vidya
> Cc: Dan Harkins; Yoshihiro Ohba; hokey@ietf.org
> Subject: RE: [HOKEY] consensus call: key distribution=20
> security requirement
>=20
>=20
>   Vidya,
>=20
>   All you're addressing is "preventing the domino effect".=20
> That is not scoping the key or binding context to a key.
>=20
>   There is context for the key. For instance, "this is for a=20
> particular authenticator." To quote from=20
> draft-housley-aaa-key-mgmt-09.txt:
>=20
>          The context will include the peer and NAS identities in more
>          than one form.  One (or more) name form is needed to identify
>          these parties in the authentication exchange and the AAA
>          protocol.
>=20
> In addition if HOKEY is going to have some key hierarchy in=20
> which keys are specific for a particular usage or a=20
> particular domain then that is additional context that has to=20
> be bound to the key. You're just throwing a counter or a=20
> nonce into the mix and thinking that solves all problems. It doesn't.
>=20
>   Dan.
>=20
> On Wed, April 4, 2007 6:20 pm, Narayanan, Vidya wrote:
> > Hi Dan,
> > As we talked about this before, there is no attack, when every key=20
> > handed out is fresh and unique across any two key fetches from the=20
> > server. So, the scoping of keys necessary is about ensuring=20
> that the=20
> > same key is never ever given out again, even to the=20
> (seemingly) same=20
> > entity.
> >
> > Vidya
> >
> >> -----Original Message-----
> >> From: Dan Harkins [mailto:dharkins@lounge.org]
> >> Sent: Wednesday, April 04, 2007 4:24 PM
> >> To: Narayanan, Vidya
> >> Cc: Yoshihiro Ohba; hokey@ietf.org
> >> Subject: RE: [HOKEY] consensus call: key distribution security=20
> >> requirement
> >>
> >>
> >>   Hi Vidya,
> >>
> >>   As I explained to you previously the issue of "peer detects=20
> >> mismatch during secure association protocol" (slide 5 of your
> >> deck) doesn't work because these are symmetric keys and=20
> the "middle=20
> >> entity" can impersonate the client now. Every single property that=20
> >> you want to give to the key being distributed is lost.
> >>
> >>   Of course you may not view that as a problem but I think=20
> that has=20
> >> more to do with what you want to do then with whether it's=20
> secure or=20
> >> not.
> >>
> >>   Can you please explain how to ensure that keys are=20
> properly scoped=20
> >> if you do not bind the scoping information to the exchange that=20
> >> distributes the key? How can the peer have any assurance=20
> that the key=20
> >> is "not shared"
> >> (one of the qualifiers you mention) if it did not take part in the=20
> >> distribution of its key?
> >>
> >>   Why not just send the EMSK to every entity that the AS thinks it=20
> >> has a security association with? I mean, in many cases as=20
> long as the=20
> >> peer receives a certain level of service and is charged=20
> for same then=20
> >> the identity of the entity receiving the EMSK is irrelevant and=20
> >> channel binding isn't important and as long as we scope the key=20
> >> properly (everyone with whom the AS shares a security=20
> association--=20
> >> aka "the
> >> network") then it's OK. After all, nothing matters as long as the=20
> >> peer is satisfied and "if the peer is not satisfied or there is a=20
> >> billing issue, it contacts its home network and tries to=20
> get service=20
> >> from some other node instead" (to quote from slide #6).
> >>
> >>   Dan.
> >>
> >> On Wed, April 4, 2007 11:16 am, Narayanan, Vidya wrote:
> >> > Hi Yoshi,
> >> >
> >> >> -----Original Message-----
> >> >> From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com]
> >> >> Sent: Tuesday, April 03, 2007 7:45 PM
> >> >> To: Narayanan, Vidya
> >> >> Cc: Charles Clancy; hokey@ietf.org
> >> >> Subject: Re: [HOKEY] consensus call: key distribution security=20
> >> >> requirement
> >> >>
> >> >> Hi Vidya,
> >> >>
> >> >> Can you please explain why channel binding information must be=20
> >> >> optional?
> >> >>
> >> >
> >> > Briefly, in many cases, as long as the peer receives a
> >> certain level
> >> > of service and is charged for the same, the identity of=20
> the network=20
> >> > entity providing the service is irrelevant. In some cases,
> >> it may be
> >> > relevant and hence, it would be good to have the=20
> capability to do=20
> >> > channel binding. But, for the other cases, there is no need
> >> to mandate
> >> > the lower layer to advertise identities.
> >> >
> >> >> Can you also explain in which system there are no adverse
> >> effects in
> >> >> key distribution without explicit peer consent?
> >> >>
> >> >
> >> > I have not seen any real loss of security properties in
> >> distribution
> >> > of keys without peer consent, as long as the keys are scoped=20
> >> > correctly, not shared and freshness is always ensured.
> >> >
> >> > Please see
> >> >
> >>=20
> http://www.geocities.com/hellovidya/Authenticators_and_Identities.pdf
> >> > if you are interested in more details. I had put some
> >> slides together
> >> > a while ago on this identities issue.
> >> >
> >> > Vidya
> >> >
> >> >> Regards,
> >> >> Yoshihiro Ohba
> >> >>
> >> >>
> >> >> On Tue, Apr 03, 2007 at 06:25:52PM -0700, Narayanan,=20
> Vidya wrote:
> >> >> > I'm barely caught up on all the email after having been
> >> on vacation
> >> >> > until now, so, pardon me if I'm bringing up stuff that's
> >> >> already been
> >> >> > discussed here.
> >> >> >
> >> >> > I share some of Glen's concerns about "requiring" peer
> >> >> consent and a
> >> >> > 3-party protocol and about how practically deployable that
> >> >> is. In my
> >> >> > conversations with Dan in Prague, it seemed like we were on
> >> >> the same
> >> >> > page about including channel binding information in the
> >> >> HOKEY protocol
> >> >> > between the peer and server. I think such channel binding
> >> >> information
> >> >> > must be optional and not required. In some systems,=20
> there are no=20
> >> >> > adverse effects of distribution of key material without
> >> >> explicit peer
> >> >> > consent and there is no reason to place upper layer identity=20
> >> >> > advertisement requirements on the lower layers for such
> >> systems. In
> >> >> > some other systems, it may be a good idea to do so and
> >> having the
> >> >> > capability to do that in the protocol would be useful there.
> >> >> >
> >> >> > To specifically answer your question, I don't believe=20
> we need to=20
> >> >> > update the problem statement. It already captures the
> >> >> channel binding
> >> >> > stuff and the explicit data that the peer and=20
> authenticator may=20
> >> >> > include is one way of providing channel binding.
> >> >> >
> >> >> > Vidya
> >> >> >
> >> >> > > -----Original Message-----
> >> >> > > From: Charles Clancy [mailto:clancy@cs.umd.edu]
> >> >> > > Sent: Saturday, March 31, 2007 12:16 PM
> >> >> > > To: hokey@ietf.org
> >> >> > > Subject: [HOKEY] consensus call: key distribution security=20
> >> >> > > requirement
> >> >> > >
> >> >> > > HOKEY WG,
> >> >> > >
> >> >> > > The 3-party protocol proposal at IETF 68 listed a=20
> variety of=20
> >> >> > > protocol requirements, some of which went beyond those
> >> currently
> >> >> > > specified in the problem statements draft.  The main
> >> >> extension was a
> >> >> > > requirement for stronger key distribution security.
> >> >> > >
> >> >> > > Discussion: The problem statements document=20
> currently requires=20
> >> >> > > channel bindings to allow clients to authenticate the
> >> network to
> >> >> > > which they are connecting, and prevent the lying=20
> NAS problem.
> >> >> > > However one possible implementation of channel bindings
> >> >> would allow
> >> >> > > keys to be distributed prior to the network being
> >> >> authenticated by
> >> >> > > the peer.  While the peer may decide to not use a network
> >> >> after it's
> >> >> > > validated its identity, network entities could retain
> >> the keying
> >> >> > > material.
> >> >> > > There has been much debate on the list as to whether or
> >> >> not network
> >> >> > > entities could maliciously use this keying material, and
> >> >> the intent
> >> >> > > here is to not rehash all that discussion.
> >> >> > >
> >> >> > > Question: Should additional text be added to the problem
> >> >> statement
> >> >> > > draft
> >> >> > >   to require peer authorization for distributing
> >> keying material?
> >> >> > >
> >> >> > > Protocol Implications: If "yes" then a 3-party
> >> protocol would be
> >> >> > > need, and would require L2 advertisement of the NAS-ID
> >> >> and local AAA
> >> >> > > domain name.  If "no" then channel bindings where
> >> identities are
> >> >> > > hashed into the key derivation would be sufficient.
> >> >> > >
> >> >> > > --
> >> >> > > t. charles clancy, ph.d.  <>  tcc@umd.edu  <>=20
> >> >> > > www.cs.umd.edu/~clancy
> >> >> > >
> >> >> > >
> >> >> > > _______________________________________________
> >> >> > > 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
> >> >
> >>
> >>
> >>
> >
>=20
>=20
>=20

_______________________________________________
HOKEY mailing list
HOKEY@ietf.org
https://www1.ietf.org/mailman/listinfo/hokey



From hokey-bounces@ietf.org Thu Apr 05 14:19: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 1HZWYm-0000Aw-Tf; Thu, 05 Apr 2007 14:19:48 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HZWYm-0000Ak-1d
	for hokey@ietf.org; Thu, 05 Apr 2007 14:19:48 -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 1HZWYk-00062Z-Ac
	for hokey@ietf.org; Thu, 05 Apr 2007 14:19:48 -0400
Received: from www.trepanning.net (localhost [127.0.0.1])
	by mail1.trepanning.net (Postfix) with ESMTP id D48EF1FA6750;
	Thu,  5 Apr 2007 11:19:43 -0700 (PDT)
Received: from 69.12.173.8
	(SquirrelMail authenticated user dharkins@lounge.org)
	by www.trepanning.net with HTTP; Thu, 5 Apr 2007 11:19:43 -0700 (PDT)
Message-ID: <33754.69.12.173.8.1175797183.squirrel@www.trepanning.net>
In-Reply-To: 
References: <460EB36E.5010604@cs.umd.edu>
	
	<20070404024453.GA18289@steelhead>
	
	<7030.12.108.168.179.1175729051.squirrel@www.trepanning.net>
	
	<44325.69.12.173.8.1175792579.squirrel@www.trepanning.net>
	
Date: Thu, 5 Apr 2007 11:19:43 -0700 (PDT)
Subject: RE: [HOKEY] consensus call: key distribution security requirement
From: "Dan Harkins" 
To: "Narayanan, Vidya" 
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: 83867a50fd8f547996ccdaf89af24437
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


  Vidya,

  No, it is far from being "no help". Channel binding is the way to bind
all necessary context to the key.

  Dan.

On Thu, April 5, 2007 10:22 am, Narayanan, Vidya wrote:
> Dan,
> Context (usage) is additional information that needs to be bound to the
> key - we have no disagreement there. But, channel binding is of no help
> for that either. As to scope, the keys must be scoped to a domain and
> that has also been agreed upon.
>
> Vidya
>
>> -----Original Message-----
>> From: Dan Harkins [mailto:dharkins@lounge.org]
>> Sent: Thursday, April 05, 2007 10:03 AM
>> To: Narayanan, Vidya
>> Cc: Dan Harkins; Yoshihiro Ohba; hokey@ietf.org
>> Subject: RE: [HOKEY] consensus call: key distribution
>> security requirement
>>
>>
>>   Vidya,
>>
>>   All you're addressing is "preventing the domino effect".
>> That is not scoping the key or binding context to a key.
>>
>>   There is context for the key. For instance, "this is for a
>> particular authenticator." To quote from
>> draft-housley-aaa-key-mgmt-09.txt:
>>
>>          The context will include the peer and NAS identities in more
>>          than one form.  One (or more) name form is needed to identify
>>          these parties in the authentication exchange and the AAA
>>          protocol.
>>
>> In addition if HOKEY is going to have some key hierarchy in
>> which keys are specific for a particular usage or a
>> particular domain then that is additional context that has to
>> be bound to the key. You're just throwing a counter or a
>> nonce into the mix and thinking that solves all problems. It doesn't.
>>
>>   Dan.
>>
>> On Wed, April 4, 2007 6:20 pm, Narayanan, Vidya wrote:
>> > Hi Dan,
>> > As we talked about this before, there is no attack, when every key
>> > handed out is fresh and unique across any two key fetches from the
>> > server. So, the scoping of keys necessary is about ensuring
>> that the
>> > same key is never ever given out again, even to the
>> (seemingly) same
>> > entity.
>> >
>> > Vidya
>> >
>> >> -----Original Message-----
>> >> From: Dan Harkins [mailto:dharkins@lounge.org]
>> >> Sent: Wednesday, April 04, 2007 4:24 PM
>> >> To: Narayanan, Vidya
>> >> Cc: Yoshihiro Ohba; hokey@ietf.org
>> >> Subject: RE: [HOKEY] consensus call: key distribution security
>> >> requirement
>> >>
>> >>
>> >>   Hi Vidya,
>> >>
>> >>   As I explained to you previously the issue of "peer detects
>> >> mismatch during secure association protocol" (slide 5 of your
>> >> deck) doesn't work because these are symmetric keys and
>> the "middle
>> >> entity" can impersonate the client now. Every single property that
>> >> you want to give to the key being distributed is lost.
>> >>
>> >>   Of course you may not view that as a problem but I think
>> that has
>> >> more to do with what you want to do then with whether it's
>> secure or
>> >> not.
>> >>
>> >>   Can you please explain how to ensure that keys are
>> properly scoped
>> >> if you do not bind the scoping information to the exchange that
>> >> distributes the key? How can the peer have any assurance
>> that the key
>> >> is "not shared"
>> >> (one of the qualifiers you mention) if it did not take part in the
>> >> distribution of its key?
>> >>
>> >>   Why not just send the EMSK to every entity that the AS thinks it
>> >> has a security association with? I mean, in many cases as
>> long as the
>> >> peer receives a certain level of service and is charged
>> for same then
>> >> the identity of the entity receiving the EMSK is irrelevant and
>> >> channel binding isn't important and as long as we scope the key
>> >> properly (everyone with whom the AS shares a security
>> association--
>> >> aka "the
>> >> network") then it's OK. After all, nothing matters as long as the
>> >> peer is satisfied and "if the peer is not satisfied or there is a
>> >> billing issue, it contacts its home network and tries to
>> get service
>> >> from some other node instead" (to quote from slide #6).
>> >>
>> >>   Dan.
>> >>
>> >> On Wed, April 4, 2007 11:16 am, Narayanan, Vidya wrote:
>> >> > Hi Yoshi,
>> >> >
>> >> >> -----Original Message-----
>> >> >> From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com]
>> >> >> Sent: Tuesday, April 03, 2007 7:45 PM
>> >> >> To: Narayanan, Vidya
>> >> >> Cc: Charles Clancy; hokey@ietf.org
>> >> >> Subject: Re: [HOKEY] consensus call: key distribution security
>> >> >> requirement
>> >> >>
>> >> >> Hi Vidya,
>> >> >>
>> >> >> Can you please explain why channel binding information must be
>> >> >> optional?
>> >> >>
>> >> >
>> >> > Briefly, in many cases, as long as the peer receives a
>> >> certain level
>> >> > of service and is charged for the same, the identity of
>> the network
>> >> > entity providing the service is irrelevant. In some cases,
>> >> it may be
>> >> > relevant and hence, it would be good to have the
>> capability to do
>> >> > channel binding. But, for the other cases, there is no need
>> >> to mandate
>> >> > the lower layer to advertise identities.
>> >> >
>> >> >> Can you also explain in which system there are no adverse
>> >> effects in
>> >> >> key distribution without explicit peer consent?
>> >> >>
>> >> >
>> >> > I have not seen any real loss of security properties in
>> >> distribution
>> >> > of keys without peer consent, as long as the keys are scoped
>> >> > correctly, not shared and freshness is always ensured.
>> >> >
>> >> > Please see
>> >> >
>> >>
>> http://www.geocities.com/hellovidya/Authenticators_and_Identities.pdf
>> >> > if you are interested in more details. I had put some
>> >> slides together
>> >> > a while ago on this identities issue.
>> >> >
>> >> > Vidya
>> >> >
>> >> >> Regards,
>> >> >> Yoshihiro Ohba
>> >> >>
>> >> >>
>> >> >> On Tue, Apr 03, 2007 at 06:25:52PM -0700, Narayanan,
>> Vidya wrote:
>> >> >> > I'm barely caught up on all the email after having been
>> >> on vacation
>> >> >> > until now, so, pardon me if I'm bringing up stuff that's
>> >> >> already been
>> >> >> > discussed here.
>> >> >> >
>> >> >> > I share some of Glen's concerns about "requiring" peer
>> >> >> consent and a
>> >> >> > 3-party protocol and about how practically deployable that
>> >> >> is. In my
>> >> >> > conversations with Dan in Prague, it seemed like we were on
>> >> >> the same
>> >> >> > page about including channel binding information in the
>> >> >> HOKEY protocol
>> >> >> > between the peer and server. I think such channel binding
>> >> >> information
>> >> >> > must be optional and not required. In some systems,
>> there are no
>> >> >> > adverse effects of distribution of key material without
>> >> >> explicit peer
>> >> >> > consent and there is no reason to place upper layer identity
>> >> >> > advertisement requirements on the lower layers for such
>> >> systems. In
>> >> >> > some other systems, it may be a good idea to do so and
>> >> having the
>> >> >> > capability to do that in the protocol would be useful there.
>> >> >> >
>> >> >> > To specifically answer your question, I don't believe
>> we need to
>> >> >> > update the problem statement. It already captures the
>> >> >> channel binding
>> >> >> > stuff and the explicit data that the peer and
>> authenticator may
>> >> >> > include is one way of providing channel binding.
>> >> >> >
>> >> >> > Vidya
>> >> >> >
>> >> >> > > -----Original Message-----
>> >> >> > > From: Charles Clancy [mailto:clancy@cs.umd.edu]
>> >> >> > > Sent: Saturday, March 31, 2007 12:16 PM
>> >> >> > > To: hokey@ietf.org
>> >> >> > > Subject: [HOKEY] consensus call: key distribution security
>> >> >> > > requirement
>> >> >> > >
>> >> >> > > HOKEY WG,
>> >> >> > >
>> >> >> > > The 3-party protocol proposal at IETF 68 listed a
>> variety of
>> >> >> > > protocol requirements, some of which went beyond those
>> >> currently
>> >> >> > > specified in the problem statements draft.  The main
>> >> >> extension was a
>> >> >> > > requirement for stronger key distribution security.
>> >> >> > >
>> >> >> > > Discussion: The problem statements document
>> currently requires
>> >> >> > > channel bindings to allow clients to authenticate the
>> >> network to
>> >> >> > > which they are connecting, and prevent the lying
>> NAS problem.
>> >> >> > > However one possible implementation of channel bindings
>> >> >> would allow
>> >> >> > > keys to be distributed prior to the network being
>> >> >> authenticated by
>> >> >> > > the peer.  While the peer may decide to not use a network
>> >> >> after it's
>> >> >> > > validated its identity, network entities could retain
>> >> the keying
>> >> >> > > material.
>> >> >> > > There has been much debate on the list as to whether or
>> >> >> not network
>> >> >> > > entities could maliciously use this keying material, and
>> >> >> the intent
>> >> >> > > here is to not rehash all that discussion.
>> >> >> > >
>> >> >> > > Question: Should additional text be added to the problem
>> >> >> statement
>> >> >> > > draft
>> >> >> > >   to require peer authorization for distributing
>> >> keying material?
>> >> >> > >
>> >> >> > > Protocol Implications: If "yes" then a 3-party
>> >> protocol would be
>> >> >> > > need, and would require L2 advertisement of the NAS-ID
>> >> >> and local AAA
>> >> >> > > domain name.  If "no" then channel bindings where
>> >> identities are
>> >> >> > > hashed into the key derivation would be sufficient.
>> >> >> > >
>> >> >> > > --
>> >> >> > > t. charles clancy, ph.d.  <>  tcc@umd.edu  <>
>> >> >> > > www.cs.umd.edu/~clancy
>> >> >> > >
>> >> >> > >
>> >> >> > > _______________________________________________
>> >> >> > > 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
>> >> >
>> >>
>> >>
>> >>
>> >
>>
>>
>>
>



_______________________________________________
HOKEY mailing list
HOKEY@ietf.org
https://www1.ietf.org/mailman/listinfo/hokey



From hokey-bounces@ietf.org Thu Apr 05 19:23: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 1HZbIt-0001lT-28; Thu, 05 Apr 2007 19:23:43 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HZbIr-0001df-6y
	for hokey@ietf.org; Thu, 05 Apr 2007 19:23:41 -0400
Received: from ithilien.qualcomm.com ([129.46.51.59])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZbIp-0005MS-BP
	for hokey@ietf.org; Thu, 05 Apr 2007 19:23:41 -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
	l35NNar9019469
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Thu, 5 Apr 2007 16:23:37 -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
	l35NNZXE025594; Thu, 5 Apr 2007 16:23:36 -0700
Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by
	SANEXCAS03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 5 Apr 2007 16:23:35 -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
Subject: RE: [HOKEY] consensus call: key distribution security requirement
Date: Thu, 5 Apr 2007 16:23:29 -0700
Message-ID: 
In-Reply-To: <33754.69.12.173.8.1175797183.squirrel@www.trepanning.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [HOKEY] consensus call: key distribution security requirement
Thread-Index: Acd3rwZUlkdDaW2rTN2zurEPSNVPqQAKU78w
References: <460EB36E.5010604@cs.umd.edu>
	
	<20070404024453.GA18289@steelhead>
	
	<7030.12.108.168.179.1175729051.squirrel@www.trepanning.net>
	
	<44325.69.12.173.8.1175792579.squirrel@www.trepanning.net>
	
	<33754.69.12.173.8.1175797183.squirrel@www.trepanning.net>
From: "Narayanan, Vidya" 
To: "Dan Harkins" 
X-OriginalArrivalTime: 05 Apr 2007 23:23:35.0540 (UTC)
	FILETIME=[6EE41B40:01C777D9]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 90e8b0e368115979782f8b3d811b226b
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

Dan,
I think we simply have been using different definitions of channel
binding. I've been using the definitions present in RFC3748 and the EAP
keying document, which don't quite include binding of context and such.
I do, however, agree, that the definition of channel binding is rather
loose and we don't have one unified view on that.=20

Having said that, let me try another way of making progress here:=20

* Keys should be bound to the correct context/usage
* Keys should be scoped to the entities that need to use it
* Keys should be fresh=20
* Domino effect must be prevented=20

I'm on board with all of the above. Are we on the same page?=20

Vidya

> -----Original Message-----
> From: Dan Harkins [mailto:dharkins@lounge.org]=20
> Sent: Thursday, April 05, 2007 11:20 AM
> To: Narayanan, Vidya
> Cc: Dan Harkins; Yoshihiro Ohba; hokey@ietf.org
> Subject: RE: [HOKEY] consensus call: key distribution=20
> security requirement
>=20
>=20
>   Vidya,
>=20
>   No, it is far from being "no help". Channel binding is the=20
> way to bind all necessary context to the key.
>=20
>   Dan.
>=20
> On Thu, April 5, 2007 10:22 am, Narayanan, Vidya wrote:
> > Dan,
> > Context (usage) is additional information that needs to be bound to=20
> > the key - we have no disagreement there. But, channel=20
> binding is of no=20
> > help for that either. As to scope, the keys must be scoped=20
> to a domain=20
> > and that has also been agreed upon.
> >
> > Vidya
> >
> >> -----Original Message-----
> >> From: Dan Harkins [mailto:dharkins@lounge.org]
> >> Sent: Thursday, April 05, 2007 10:03 AM
> >> To: Narayanan, Vidya
> >> Cc: Dan Harkins; Yoshihiro Ohba; hokey@ietf.org
> >> Subject: RE: [HOKEY] consensus call: key distribution security=20
> >> requirement
> >>
> >>
> >>   Vidya,
> >>
> >>   All you're addressing is "preventing the domino effect".
> >> That is not scoping the key or binding context to a key.
> >>
> >>   There is context for the key. For instance, "this is for a=20
> >> particular authenticator." To quote from
> >> draft-housley-aaa-key-mgmt-09.txt:
> >>
> >>          The context will include the peer and NAS=20
> identities in more
> >>          than one form.  One (or more) name form is needed=20
> to identify
> >>          these parties in the authentication exchange and the AAA
> >>          protocol.
> >>
> >> In addition if HOKEY is going to have some key hierarchy in which=20
> >> keys are specific for a particular usage or a particular=20
> domain then=20
> >> that is additional context that has to be bound to the key. You're=20
> >> just throwing a counter or a nonce into the mix and thinking that=20
> >> solves all problems. It doesn't.
> >>
> >>   Dan.
> >>
> >> On Wed, April 4, 2007 6:20 pm, Narayanan, Vidya wrote:
> >> > Hi Dan,
> >> > As we talked about this before, there is no attack, when=20
> every key=20
> >> > handed out is fresh and unique across any two key=20
> fetches from the=20
> >> > server. So, the scoping of keys necessary is about ensuring
> >> that the
> >> > same key is never ever given out again, even to the
> >> (seemingly) same
> >> > entity.
> >> >
> >> > Vidya
> >> >
> >> >> -----Original Message-----
> >> >> From: Dan Harkins [mailto:dharkins@lounge.org]
> >> >> Sent: Wednesday, April 04, 2007 4:24 PM
> >> >> To: Narayanan, Vidya
> >> >> Cc: Yoshihiro Ohba; hokey@ietf.org
> >> >> Subject: RE: [HOKEY] consensus call: key distribution security=20
> >> >> requirement
> >> >>
> >> >>
> >> >>   Hi Vidya,
> >> >>
> >> >>   As I explained to you previously the issue of "peer detects=20
> >> >> mismatch during secure association protocol" (slide 5 of your
> >> >> deck) doesn't work because these are symmetric keys and
> >> the "middle
> >> >> entity" can impersonate the client now. Every single=20
> property that=20
> >> >> you want to give to the key being distributed is lost.
> >> >>
> >> >>   Of course you may not view that as a problem but I think
> >> that has
> >> >> more to do with what you want to do then with whether it's
> >> secure or
> >> >> not.
> >> >>
> >> >>   Can you please explain how to ensure that keys are
> >> properly scoped
> >> >> if you do not bind the scoping information to the exchange that=20
> >> >> distributes the key? How can the peer have any assurance
> >> that the key
> >> >> is "not shared"
> >> >> (one of the qualifiers you mention) if it did not take=20
> part in the=20
> >> >> distribution of its key?
> >> >>
> >> >>   Why not just send the EMSK to every entity that the=20
> AS thinks it=20
> >> >> has a security association with? I mean, in many cases as
> >> long as the
> >> >> peer receives a certain level of service and is charged
> >> for same then
> >> >> the identity of the entity receiving the EMSK is irrelevant and=20
> >> >> channel binding isn't important and as long as we scope the key=20
> >> >> properly (everyone with whom the AS shares a security
> >> association--
> >> >> aka "the
> >> >> network") then it's OK. After all, nothing matters as=20
> long as the=20
> >> >> peer is satisfied and "if the peer is not satisfied or=20
> there is a=20
> >> >> billing issue, it contacts its home network and tries to
> >> get service
> >> >> from some other node instead" (to quote from slide #6).
> >> >>
> >> >>   Dan.
> >> >>
> >> >> On Wed, April 4, 2007 11:16 am, Narayanan, Vidya wrote:
> >> >> > Hi Yoshi,
> >> >> >
> >> >> >> -----Original Message-----
> >> >> >> From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com]
> >> >> >> Sent: Tuesday, April 03, 2007 7:45 PM
> >> >> >> To: Narayanan, Vidya
> >> >> >> Cc: Charles Clancy; hokey@ietf.org
> >> >> >> Subject: Re: [HOKEY] consensus call: key=20
> distribution security=20
> >> >> >> requirement
> >> >> >>
> >> >> >> Hi Vidya,
> >> >> >>
> >> >> >> Can you please explain why channel binding=20
> information must be=20
> >> >> >> optional?
> >> >> >>
> >> >> >
> >> >> > Briefly, in many cases, as long as the peer receives a
> >> >> certain level
> >> >> > of service and is charged for the same, the identity of
> >> the network
> >> >> > entity providing the service is irrelevant. In some cases,
> >> >> it may be
> >> >> > relevant and hence, it would be good to have the
> >> capability to do
> >> >> > channel binding. But, for the other cases, there is no need
> >> >> to mandate
> >> >> > the lower layer to advertise identities.
> >> >> >
> >> >> >> Can you also explain in which system there are no adverse
> >> >> effects in
> >> >> >> key distribution without explicit peer consent?
> >> >> >>
> >> >> >
> >> >> > I have not seen any real loss of security properties in
> >> >> distribution
> >> >> > of keys without peer consent, as long as the keys are scoped=20
> >> >> > correctly, not shared and freshness is always ensured.
> >> >> >
> >> >> > Please see
> >> >> >
> >> >>
> >>=20
> http://www.geocities.com/hellovidya/Authenticators_and_Identities.pdf
> >> >> > if you are interested in more details. I had put some
> >> >> slides together
> >> >> > a while ago on this identities issue.
> >> >> >
> >> >> > Vidya
> >> >> >
> >> >> >> Regards,
> >> >> >> Yoshihiro Ohba
> >> >> >>
> >> >> >>
> >> >> >> On Tue, Apr 03, 2007 at 06:25:52PM -0700, Narayanan,
> >> Vidya wrote:
> >> >> >> > I'm barely caught up on all the email after having been
> >> >> on vacation
> >> >> >> > until now, so, pardon me if I'm bringing up stuff that's
> >> >> >> already been
> >> >> >> > discussed here.
> >> >> >> >
> >> >> >> > I share some of Glen's concerns about "requiring" peer
> >> >> >> consent and a
> >> >> >> > 3-party protocol and about how practically deployable that
> >> >> >> is. In my
> >> >> >> > conversations with Dan in Prague, it seemed like we were on
> >> >> >> the same
> >> >> >> > page about including channel binding information in the
> >> >> >> HOKEY protocol
> >> >> >> > between the peer and server. I think such channel binding
> >> >> >> information
> >> >> >> > must be optional and not required. In some systems,
> >> there are no
> >> >> >> > adverse effects of distribution of key material without
> >> >> >> explicit peer
> >> >> >> > consent and there is no reason to place upper=20
> layer identity=20
> >> >> >> > advertisement requirements on the lower layers for such
> >> >> systems. In
> >> >> >> > some other systems, it may be a good idea to do so and
> >> >> having the
> >> >> >> > capability to do that in the protocol would be=20
> useful there.
> >> >> >> >
> >> >> >> > To specifically answer your question, I don't believe
> >> we need to
> >> >> >> > update the problem statement. It already captures the
> >> >> >> channel binding
> >> >> >> > stuff and the explicit data that the peer and
> >> authenticator may
> >> >> >> > include is one way of providing channel binding.
> >> >> >> >
> >> >> >> > Vidya
> >> >> >> >
> >> >> >> > > -----Original Message-----
> >> >> >> > > From: Charles Clancy [mailto:clancy@cs.umd.edu]
> >> >> >> > > Sent: Saturday, March 31, 2007 12:16 PM
> >> >> >> > > To: hokey@ietf.org
> >> >> >> > > Subject: [HOKEY] consensus call: key=20
> distribution security=20
> >> >> >> > > requirement
> >> >> >> > >
> >> >> >> > > HOKEY WG,
> >> >> >> > >
> >> >> >> > > The 3-party protocol proposal at IETF 68 listed a
> >> variety of
> >> >> >> > > protocol requirements, some of which went beyond those
> >> >> currently
> >> >> >> > > specified in the problem statements draft.  The main
> >> >> >> extension was a
> >> >> >> > > requirement for stronger key distribution security.
> >> >> >> > >
> >> >> >> > > Discussion: The problem statements document
> >> currently requires
> >> >> >> > > channel bindings to allow clients to authenticate the
> >> >> network to
> >> >> >> > > which they are connecting, and prevent the lying
> >> NAS problem.
> >> >> >> > > However one possible implementation of channel bindings
> >> >> >> would allow
> >> >> >> > > keys to be distributed prior to the network being
> >> >> >> authenticated by
> >> >> >> > > the peer.  While the peer may decide to not use a network
> >> >> >> after it's
> >> >> >> > > validated its identity, network entities could retain
> >> >> the keying
> >> >> >> > > material.
> >> >> >> > > There has been much debate on the list as to whether or
> >> >> >> not network
> >> >> >> > > entities could maliciously use this keying material, and
> >> >> >> the intent
> >> >> >> > > here is to not rehash all that discussion.
> >> >> >> > >
> >> >> >> > > Question: Should additional text be added to the problem
> >> >> >> statement
> >> >> >> > > draft
> >> >> >> > >   to require peer authorization for distributing
> >> >> keying material?
> >> >> >> > >
> >> >> >> > > Protocol Implications: If "yes" then a 3-party
> >> >> protocol would be
> >> >> >> > > need, and would require L2 advertisement of the NAS-ID
> >> >> >> and local AAA
> >> >> >> > > domain name.  If "no" then channel bindings where
> >> >> identities are
> >> >> >> > > hashed into the key derivation would be sufficient.
> >> >> >> > >
> >> >> >> > > --
> >> >> >> > > t. charles clancy, ph.d.  <>  tcc@umd.edu  <>=20
> >> >> >> > > www.cs.umd.edu/~clancy
> >> >> >> > >
> >> >> >> > >
> >> >> >> > > _______________________________________________
> >> >> >> > > 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
> >> >> >
> >> >>
> >> >>
> >> >>
> >> >
> >>
> >>
> >>
> >
>=20
>=20
>=20

_______________________________________________
HOKEY mailing list
HOKEY@ietf.org
https://www1.ietf.org/mailman/listinfo/hokey



From hokey-bounces@ietf.org Fri Apr 06 12:46: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 1HZra3-0000oE-5s; Fri, 06 Apr 2007 12:46:31 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HZra1-0000o1-KB
	for hokey@ietf.org; Fri, 06 Apr 2007 12:46:29 -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 1HZrZz-00066c-RL
	for hokey@ietf.org; Fri, 06 Apr 2007 12:46:29 -0400
Received: from www.trepanning.net (localhost [127.0.0.1])
	by mail1.trepanning.net (Postfix) with ESMTP id 0F3C31FA671D;
	Fri,  6 Apr 2007 09:46:25 -0700 (PDT)
Received: from 69.12.173.8
	(SquirrelMail authenticated user dharkins@lounge.org)
	by www.trepanning.net with HTTP; Fri, 6 Apr 2007 09:46:25 -0700 (PDT)
Message-ID: <46386.69.12.173.8.1175877985.squirrel@www.trepanning.net>
In-Reply-To: 
References: <460EB36E.5010604@cs.umd.edu>
	
	<20070404024453.GA18289@steelhead>
	
	<7030.12.108.168.179.1175729051.squirrel@www.trepanning.net>
	
	<44325.69.12.173.8.1175792579.squirrel@www.trepanning.net>
	
	<33754.69.12.173.8.1175797183.squirrel@www.trepanning.net>
	
Date: Fri, 6 Apr 2007 09:46:25 -0700 (PDT)
Subject: RE: [HOKEY] consensus call: key distribution security requirement
From: "Dan Harkins" 
To: "Narayanan, Vidya" 
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: b058151374d77ee76edaac850f7449fb
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 Vidya,

  When EAP is used in "pass-thru" mode there is a problem. As you note
that problem, and a solution to it, is described in RFC3748 under the
heading of "Channel Binding". We have that same sort of problem in
spades here in HOKEY because we're distributing keys that must be for
a specific authenticator, for a specific usage, and I guess for a specifi=
c
domain. There is context that constrains who can use a key and how that
key can be used. So we need to solve that same sort of problem that EAP
has when used in "pass-thru" mode.

  Perhaps "Channel Binding" isn't a good term to use since it implies
something specific (RFC3748). How about "protected exchange"? That is
how RFC3748 describes "Channel Binding" anyway. So would something along
the lines of this be agreeable?

   HOKEY MUST include a protected exchange of context, usage, and
   identities that are bound to, and constrain, a key including but
   not limited to [enumerate the things needed]. This will make it
   possible to match the same properties provided by the authenticator
   via an out-of-band mechanism (like AAA) against those in the protected
   exchange in the HOKEY protocol.

To plagiarize^H^H^H^H^H^H paraphrase RFC3748.

  Dan.

On Thu, April 5, 2007 4:23 pm, Narayanan, Vidya wrote:
> Dan,
> I think we simply have been using different definitions of channel
> binding. I've been using the definitions present in RFC3748 and the EAP
> keying document, which don't quite include binding of context and such.
> I do, however, agree, that the definition of channel binding is rather
> loose and we don't have one unified view on that.
>
> Having said that, let me try another way of making progress here:
>
> * Keys should be bound to the correct context/usage
> * Keys should be scoped to the entities that need to use it
> * Keys should be fresh
> * Domino effect must be prevented
>
> I'm on board with all of the above. Are we on the same page?
>
> Vidya
>
>> -----Original Message-----
>> From: Dan Harkins [mailto:dharkins@lounge.org]
>> Sent: Thursday, April 05, 2007 11:20 AM
>> To: Narayanan, Vidya
>> Cc: Dan Harkins; Yoshihiro Ohba; hokey@ietf.org
>> Subject: RE: [HOKEY] consensus call: key distribution
>> security requirement
>>
>>
>>   Vidya,
>>
>>   No, it is far from being "no help". Channel binding is the
>> way to bind all necessary context to the key.
>>
>>   Dan.
>>
>> On Thu, April 5, 2007 10:22 am, Narayanan, Vidya wrote:
>> > Dan,
>> > Context (usage) is additional information that needs to be bound to
>> > the key - we have no disagreement there. But, channel
>> binding is of no
>> > help for that either. As to scope, the keys must be scoped
>> to a domain
>> > and that has also been agreed upon.
>> >
>> > Vidya
>> >
>> >> -----Original Message-----
>> >> From: Dan Harkins [mailto:dharkins@lounge.org]
>> >> Sent: Thursday, April 05, 2007 10:03 AM
>> >> To: Narayanan, Vidya
>> >> Cc: Dan Harkins; Yoshihiro Ohba; hokey@ietf.org
>> >> Subject: RE: [HOKEY] consensus call: key distribution security
>> >> requirement
>> >>
>> >>
>> >>   Vidya,
>> >>
>> >>   All you're addressing is "preventing the domino effect".
>> >> That is not scoping the key or binding context to a key.
>> >>
>> >>   There is context for the key. For instance, "this is for a
>> >> particular authenticator." To quote from
>> >> draft-housley-aaa-key-mgmt-09.txt:
>> >>
>> >>          The context will include the peer and NAS
>> identities in more
>> >>          than one form.  One (or more) name form is needed
>> to identify
>> >>          these parties in the authentication exchange and the AAA
>> >>          protocol.
>> >>
>> >> In addition if HOKEY is going to have some key hierarchy in which
>> >> keys are specific for a particular usage or a particular
>> domain then
>> >> that is additional context that has to be bound to the key. You're
>> >> just throwing a counter or a nonce into the mix and thinking that
>> >> solves all problems. It doesn't.
>> >>
>> >>   Dan.
>> >>
>> >> On Wed, April 4, 2007 6:20 pm, Narayanan, Vidya wrote:
>> >> > Hi Dan,
>> >> > As we talked about this before, there is no attack, when
>> every key
>> >> > handed out is fresh and unique across any two key
>> fetches from the
>> >> > server. So, the scoping of keys necessary is about ensuring
>> >> that the
>> >> > same key is never ever given out again, even to the
>> >> (seemingly) same
>> >> > entity.
>> >> >
>> >> > Vidya
>> >> >
>> >> >> -----Original Message-----
>> >> >> From: Dan Harkins [mailto:dharkins@lounge.org]
>> >> >> Sent: Wednesday, April 04, 2007 4:24 PM
>> >> >> To: Narayanan, Vidya
>> >> >> Cc: Yoshihiro Ohba; hokey@ietf.org
>> >> >> Subject: RE: [HOKEY] consensus call: key distribution security
>> >> >> requirement
>> >> >>
>> >> >>
>> >> >>   Hi Vidya,
>> >> >>
>> >> >>   As I explained to you previously the issue of "peer detects
>> >> >> mismatch during secure association protocol" (slide 5 of your
>> >> >> deck) doesn't work because these are symmetric keys and
>> >> the "middle
>> >> >> entity" can impersonate the client now. Every single
>> property that
>> >> >> you want to give to the key being distributed is lost.
>> >> >>
>> >> >>   Of course you may not view that as a problem but I think
>> >> that has
>> >> >> more to do with what you want to do then with whether it's
>> >> secure or
>> >> >> not.
>> >> >>
>> >> >>   Can you please explain how to ensure that keys are
>> >> properly scoped
>> >> >> if you do not bind the scoping information to the exchange that
>> >> >> distributes the key? How can the peer have any assurance
>> >> that the key
>> >> >> is "not shared"
>> >> >> (one of the qualifiers you mention) if it did not take
>> part in the
>> >> >> distribution of its key?
>> >> >>
>> >> >>   Why not just send the EMSK to every entity that the
>> AS thinks it
>> >> >> has a security association with? I mean, in many cases as
>> >> long as the
>> >> >> peer receives a certain level of service and is charged
>> >> for same then
>> >> >> the identity of the entity receiving the EMSK is irrelevant and
>> >> >> channel binding isn't important and as long as we scope the key
>> >> >> properly (everyone with whom the AS shares a security
>> >> association--
>> >> >> aka "the
>> >> >> network") then it's OK. After all, nothing matters as
>> long as the
>> >> >> peer is satisfied and "if the peer is not satisfied or
>> there is a
>> >> >> billing issue, it contacts its home network and tries to
>> >> get service
>> >> >> from some other node instead" (to quote from slide #6).
>> >> >>
>> >> >>   Dan.
>> >> >>
>> >> >> On Wed, April 4, 2007 11:16 am, Narayanan, Vidya wrote:
>> >> >> > Hi Yoshi,
>> >> >> >
>> >> >> >> -----Original Message-----
>> >> >> >> From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com]
>> >> >> >> Sent: Tuesday, April 03, 2007 7:45 PM
>> >> >> >> To: Narayanan, Vidya
>> >> >> >> Cc: Charles Clancy; hokey@ietf.org
>> >> >> >> Subject: Re: [HOKEY] consensus call: key
>> distribution security
>> >> >> >> requirement
>> >> >> >>
>> >> >> >> Hi Vidya,
>> >> >> >>
>> >> >> >> Can you please explain why channel binding
>> information must be
>> >> >> >> optional?
>> >> >> >>
>> >> >> >
>> >> >> > Briefly, in many cases, as long as the peer receives a
>> >> >> certain level
>> >> >> > of service and is charged for the same, the identity of
>> >> the network
>> >> >> > entity providing the service is irrelevant. In some cases,
>> >> >> it may be
>> >> >> > relevant and hence, it would be good to have the
>> >> capability to do
>> >> >> > channel binding. But, for the other cases, there is no need
>> >> >> to mandate
>> >> >> > the lower layer to advertise identities.
>> >> >> >
>> >> >> >> Can you also explain in which system there are no adverse
>> >> >> effects in
>> >> >> >> key distribution without explicit peer consent?
>> >> >> >>
>> >> >> >
>> >> >> > I have not seen any real loss of security properties in
>> >> >> distribution
>> >> >> > of keys without peer consent, as long as the keys are scoped
>> >> >> > correctly, not shared and freshness is always ensured.
>> >> >> >
>> >> >> > Please see
>> >> >> >
>> >> >>
>> >>
>> http://www.geocities.com/hellovidya/Authenticators_and_Identities.pdf
>> >> >> > if you are interested in more details. I had put some
>> >> >> slides together
>> >> >> > a while ago on this identities issue.
>> >> >> >
>> >> >> > Vidya
>> >> >> >
>> >> >> >> Regards,
>> >> >> >> Yoshihiro Ohba
>> >> >> >>
>> >> >> >>
>> >> >> >> On Tue, Apr 03, 2007 at 06:25:52PM -0700, Narayanan,
>> >> Vidya wrote:
>> >> >> >> > I'm barely caught up on all the email after having been
>> >> >> on vacation
>> >> >> >> > until now, so, pardon me if I'm bringing up stuff that's
>> >> >> >> already been
>> >> >> >> > discussed here.
>> >> >> >> >
>> >> >> >> > I share some of Glen's concerns about "requiring" peer
>> >> >> >> consent and a
>> >> >> >> > 3-party protocol and about how practically deployable that
>> >> >> >> is. In my
>> >> >> >> > conversations with Dan in Prague, it seemed like we were on
>> >> >> >> the same
>> >> >> >> > page about including channel binding information in the
>> >> >> >> HOKEY protocol
>> >> >> >> > between the peer and server. I think such channel binding
>> >> >> >> information
>> >> >> >> > must be optional and not required. In some systems,
>> >> there are no
>> >> >> >> > adverse effects of distribution of key material without
>> >> >> >> explicit peer
>> >> >> >> > consent and there is no reason to place upper
>> layer identity
>> >> >> >> > advertisement requirements on the lower layers for such
>> >> >> systems. In
>> >> >> >> > some other systems, it may be a good idea to do so and
>> >> >> having the
>> >> >> >> > capability to do that in the protocol would be
>> useful there.
>> >> >> >> >
>> >> >> >> > To specifically answer your question, I don't believe
>> >> we need to
>> >> >> >> > update the problem statement. It already captures the
>> >> >> >> channel binding
>> >> >> >> > stuff and the explicit data that the peer and
>> >> authenticator may
>> >> >> >> > include is one way of providing channel binding.
>> >> >> >> >
>> >> >> >> > Vidya
>> >> >> >> >
>> >> >> >> > > -----Original Message-----
>> >> >> >> > > From: Charles Clancy [mailto:clancy@cs.umd.edu]
>> >> >> >> > > Sent: Saturday, March 31, 2007 12:16 PM
>> >> >> >> > > To: hokey@ietf.org
>> >> >> >> > > Subject: [HOKEY] consensus call: key
>> distribution security
>> >> >> >> > > requirement
>> >> >> >> > >
>> >> >> >> > > HOKEY WG,
>> >> >> >> > >
>> >> >> >> > > The 3-party protocol proposal at IETF 68 listed a
>> >> variety of
>> >> >> >> > > protocol requirements, some of which went beyond those
>> >> >> currently
>> >> >> >> > > specified in the problem statements draft.  The main
>> >> >> >> extension was a
>> >> >> >> > > requirement for stronger key distribution security.
>> >> >> >> > >
>> >> >> >> > > Discussion: The problem statements document
>> >> currently requires
>> >> >> >> > > channel bindings to allow clients to authenticate the
>> >> >> network to
>> >> >> >> > > which they are connecting, and prevent the lying
>> >> NAS problem.
>> >> >> >> > > However one possible implementation of channel bindings
>> >> >> >> would allow
>> >> >> >> > > keys to be distributed prior to the network being
>> >> >> >> authenticated by
>> >> >> >> > > the peer.  While the peer may decide to not use a network
>> >> >> >> after it's
>> >> >> >> > > validated its identity, network entities could retain
>> >> >> the keying
>> >> >> >> > > material.
>> >> >> >> > > There has been much debate on the list as to whether or
>> >> >> >> not network
>> >> >> >> > > entities could maliciously use this keying material, and
>> >> >> >> the intent
>> >> >> >> > > here is to not rehash all that discussion.
>> >> >> >> > >
>> >> >> >> > > Question: Should additional text be added to the problem
>> >> >> >> statement
>> >> >> >> > > draft
>> >> >> >> > >   to require peer authorization for distributing
>> >> >> keying material?
>> >> >> >> > >
>> >> >> >> > > Protocol Implications: If "yes" then a 3-party
>> >> >> protocol would be
>> >> >> >> > > need, and would require L2 advertisement of the NAS-ID
>> >> >> >> and local AAA
>> >> >> >> > > domain name.  If "no" then channel bindings where
>> >> >> identities are
>> >> >> >> > > hashed into the key derivation would be sufficient.
>> >> >> >> > >
>> >> >> >> > > --
>> >> >> >> > > t. charles clancy, ph.d.  <>  tcc@umd.edu  <>
>> >> >> >> > > www.cs.umd.edu/~clancy
>> >> >> >> > >
>> >> >> >> > >
>> >> >> >> > > _______________________________________________
>> >> >> >> > > 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
>> >> >> >
>> >> >>
>> >> >>
>> >> >>
>> >> >
>> >>
>> >>
>> >>
>> >
>>
>>
>>
>



_______________________________________________
HOKEY mailing list
HOKEY@ietf.org
https://www1.ietf.org/mailman/listinfo/hokey



From hokey-bounces@ietf.org Mon Apr 09 18:50: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 1Hb2gd-00025D-8K; Mon, 09 Apr 2007 18:50:11 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hb2gc-000254-0A
	for hokey@ietf.org; Mon, 09 Apr 2007 18:50:10 -0400
Received: from usaga01-in.huawei.com ([206.16.17.211])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hb2ga-00015v-HH
	for hokey@ietf.org; Mon, 09 Apr 2007 18:50:09 -0400
Received: from huawei.com (usaga01-in [172.18.4.6])
	by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTP id <0JG90070E63JLC@usaga01-in.huawei.com> for
	hokey@ietf.org; Mon, 09 Apr 2007 15:50:08 -0700 (PDT)
Received: from N737011
	(pool-71-112-121-192.sttlwa.dsl-w.verizon.net [71.112.121.192])
	by usaga01-in.huawei.com
	(iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar  3 2004))
	with ESMTPA id <0JG9007GR63F9G@usaga01-in.huawei.com> for
	hokey@ietf.org; Mon, 09 Apr 2007 15:50:07 -0700 (PDT)
Date: Mon, 09 Apr 2007 15:50:08 -0700
From: Madjid Nakhjiri 
In-reply-to: <460EAF24.7070506@cs.umd.edu>
To: 'Charles Clancy' , hokey@ietf.org
Message-id: <007201c77af9$6cecc490$2f01a8c0@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962
X-Mailer: Microsoft Office Outlook 11
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Thread-index: AcdzxrdXH0MDR7HiRu+gWh81a7SnMwHMFzOQ
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0cff8c3ec906d056784362c06f5f88c1
Cc: 
Subject: [HOKEY] Using an EAP method for HOKEY??: was: consensus call: EAP-ER
 as HOKEY protocol
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,

As promised earlier, I am providing an analysis of use of EAP method for
handover and re-authentication signaling. To me it seems that without
introducing a new EAP code, one can accomplish the signaling with very
little change to authenticator state machine, given that the authenticator
already does receive and transmit AAA attributes along with AAA messages
encapsulating EAP packets.

I have called this new method, EAP Handover and re-authentication method
(EAP-HR), which consists of 3 messages (if you count EAP Success as method
specific).
I have shown the 3-party key distribution exchange (KDE) can be carried over
the EAP-HR messages easily.
As you can see in most of cases (handover, re-authentication and even in
some cases for network setup), a trigger is easily available for the
authenticator to start with EAP-HR Req, just the way EAP-identity starts
from the authenticator. So the urgent need for peer-initiated messaging and
hence the need to create new EAP code may go away.



Peer             authenticator             server
	EAP-HR REQ
	(DID, AID)
  <-------------
	EAP-HR RESP
      KDE message 1 and 2 (PID, AID and tokens)
------------------------------------------------->
		EAP/Success
		 (KDE message 3 and 4)
<---------------------------------------------------

DID: domain ID (used for creating Domain keys)
AID: authenticator ID advertised by the authenticator 
(note this can be done as part of lower layer beacon advertisement), so
carrying data through EAP-HR Request is not 100% necessary the KDE.


FAQ
=====

Roundtrips: 
============
1.1 when trigger is available at authenticator
(assuming authenticator-peer trip~20% of server-peer trip).
1.5 when trigger needs to arrive from the server.


Cases where trigger is available at authenticator
a) in handover, this is available through a handover request from the peer.
b) in re-authentication, the authentication/ key status is typically
available at the authenticator as a result of previous AAA signaling (e.g.
Session-life-time attribute)
c) in network setup, the server may send a session-life-time=0 to
authenticator along with the previous EAP authentication Success, to
indicate the need to start HOKEY signaling.


EAP-HR versus EAP identity
======================
I have discussed this with several EAP experts and it seems that using EAP
Identity request/ response versus using a new EAP method (EAP-HR) are almost
identical.
The issue with EAP Identity is that it does not carry data.
IMO, modifying EAP Identity to carry data is more straight forward than
creating EAP-HR.



EAP Success:
==========
It seems that quite a number of people have already backed up the idea of
modifying EAP success to carry data: people brought up the fact that 2284
did allow EAP success carrying data and the only reason 3748 banned EAP
Success from carrying data was the inadequate method independent way of
carrying data. It seems to me that keys derived from the hierarchy can be
used to protect the EAP success and its data and this would allow for
protected result indication as well. 

The other reason to allow EAP Success carry data is to provide a natural
extension to the AAA (authorization, etc) signaling that currently does not
reach beyond the authenticator.

So with that in mind, I hope we don't rehash the previous emails citing
sentences from 3748 about EAP Success carrying data...

3 Party key distribution (KDE)
=======================
I have modified the 3 party key distribution slightly to accomodate the EAP
method signaling.

   0  Authenticator to peer: EAP(DAID, DID)

   1  Peer to Authenticator: EAP((PID, DAID, DID, Np,KNps), [PID, DAID,
      Np,KNps]Kps)

   2  Authenticator to Server: AAA(PID, UAID, [PID, UAID]Kas),
      AAA(EAP((PID, DAID, DID, Np,KNps), [PID, DAID, DID, Np,KNps]Kps))

   3  Server to Authenticator: AAA({PID,AID,KNpa, KLpa, Kpa}KEas),
      AAA(EAP(KNpa, KLpa, KNps, [PID, AID, DID, Np+1,KNpa,KLpa,
      KNps]Kps))

   4  Authenticator to Peer: EAP(KNpa, KLpa, KNps, [PID, AID, DID, Np+1,
      KNpa,KLpa, KNps]Kps])

PID: peer ID.  
   DID: Domain ID
   AID: Authenticator ID
   DAID: Authenticator ID as perceived by the peer (down link ID)
   UAID: Authenticator ID as perceived by the server (uplink ID)
   {X}K: X encrypted with key K
   [X]K: Message Authentication Code over X with key K.
   X(Y): Y carried with X protocol
   Kps: A symmetric key shared between peer and Server for signing (IK,
   provisioned by EAP/HOKEY hierarchy) and identified by KNps.

   KEps: A symmetric key shared between peer and Server for encryption
   (CK, provisioning by EAP/HOKEY hierarchy) and identified by KEpsid

   KEas: A symmetric key shared between authenticator and Server for
   encryption (provisioned out of band).

   Kas: A symmetric key between authentication and server for MDCs for
   signing (provisioned out of band).


 Kpa: A symmetric key to be shared between peer and authenticator (key
   to be distributed to authenticator, the MDMSK in this document).  The
   key is named as KNpa.

   KLx : Key lifetime for key x

   KNx: Key name for Key x, e.g.  KENas: key name for KEas

   Nx : Nonce provided by the party X

I have provided more the details in a draft. 
http://www.ietf.org/internet-drafts/draft-nakhjiri-hokey-hierarchy-04.txt

Regards,

Madjid

-----Original Message-----
From: Charles Clancy [mailto:clancy@cs.umd.edu] 
Sent: Saturday, March 31, 2007 11:58 AM
To: hokey@ietf.org
Subject: [HOKEY] consensus call: EAP-ER as HOKEY protocol

HOKEY WG,

The chairs are making a second consensus call request to adopt EAP-ER as 
a WG document to satisfy our re-auth and hand-off deliverables.  It 
would serve as a starting point for development of the HOKEY protocol.

Note that if accepted, it may be split into two WG documents, separating 
the EAP-ER-Bootstrap into a second set of messages that could be 
transported by any service to obtain a USRK or DSUSRK.

Please respond by Friday, April 13.

-- 
t. charles clancy, ph.d.  <>  tcc@umd.edu  <>  www.cs.umd.edu/~clancy


_______________________________________________
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 Apr 09 19:00:10 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hb2qI-0004SB-4H; Mon, 09 Apr 2007 19:00:10 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hb2qG-0004Rm-43
	for hokey@ietf.org; Mon, 09 Apr 2007 19:00:08 -0400
Received: from usaga01-in.huawei.com ([206.16.17.211])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hb2qE-0004aI-SD
	for hokey@ietf.org; Mon, 09 Apr 2007 19:00:08 -0400
Received: from huawei.com (usaga01-in [172.18.4.6])
	by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTP id <0JG90074S6K6LC@usaga01-in.huawei.com> for
	hokey@ietf.org; Mon, 09 Apr 2007 16:00:06 -0700 (PDT)
Received: from N737011
	(pool-71-112-121-192.sttlwa.dsl-w.verizon.net [71.112.121.192])
	by usaga01-in.huawei.com
	(iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar  3 2004))
	with ESMTPA id <0JG9007BO6K19G@usaga01-in.huawei.com> for
	hokey@ietf.org; Mon, 09 Apr 2007 16:00:06 -0700 (PDT)
Date: Mon, 09 Apr 2007 16:00:07 -0700
From: Madjid Nakhjiri 
In-reply-to: <460EAF24.7070506@cs.umd.edu>
To: 'Charles Clancy' , hokey@ietf.org,
	"'Glen Zorn (gwz)'" 
Message-id: <007301c77afa$d1d83a50$2f01a8c0@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962
X-Mailer: Microsoft Office Outlook 11
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Thread-index: AcdzxrdXH0MDR7HiRu+gWh81a7SnMwHMshgw
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a
Cc: 
Subject: [HOKEY] nakhjiri-hokey-hierarchy-04 available
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 Folks,

Trying to see how the various pieces of the puzzle from EAP signaling to key
hierarchy and 3 party key distribution fit together, I have updated the key
hierarchy draft. The draft tries to follow the new guidelines for use of
EMSK and is experimenting with use of EMSK in deriving the handover root key
for use in multiple domains.

The draft provides a suggestion for use an EAP method with the goal to show
an alternative to use of new EAP codes.

The draft also discusses the use of 3 party key distribution, the parameters
involved, the AAA attributes and EAP extensions.


The draft can be found at:

http://www.ietf.org/internet-drafts/draft-nakhjiri-hokey-hierarchy-04.txt

comments and discussions are welcome.

R,

Madjid




_______________________________________________
HOKEY mailing list
HOKEY@ietf.org
https://www1.ietf.org/mailman/listinfo/hokey



From hokey-bounces@ietf.org Mon Apr 09 19:00: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 1Hb2qn-0004a5-R1; Mon, 09 Apr 2007 19:00:41 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hb2qm-0004YA-7K
	for hokey@ietf.org; Mon, 09 Apr 2007 19:00:40 -0400
Received: from inet-tsb5.toshiba.co.jp ([202.33.96.24])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hb2ql-0004sI-DQ
	for hokey@ietf.org; Mon, 09 Apr 2007 19:00:40 -0400
Received: from tsb-wall.toshiba.co.jp ([133.199.160.134])
	by inet-tsb5.toshiba.co.jp  with ESMTP id l39N0WCA010962;
	Tue, 10 Apr 2007 08:00:32 +0900 (JST)
Received: (from root@localhost) by tsb-wall.toshiba.co.jp  id l39N0XOn020034;
	Tue, 10 Apr 2007 08:00:33 +0900 (JST)
Received: from ovp1.toshiba.co.jp [133.199.192.124] 
	by tsb-wall.toshiba.co.jp with ESMTP id JAA20033;
	Tue, 10 Apr 2007 08:00:33 +0900
Received: from mx2.toshiba.co.jp (localhost [127.0.0.1])
	by ovp1.toshiba.co.jp  with ESMTP id l39N0W53003809;
	Tue, 10 Apr 2007 08:00:32 +0900 (JST)
Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id l39N0UYm007355;
	Tue, 10 Apr 2007 08:00:30 +0900 (JST)
Received: from steelhead ([172.30.24.105])
	by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 (built
	Apr 28
	2004)) with ESMTPSA id <0JG900E7L6KR14J0@mail.po.toshiba.co.jp>; Tue,
	10 Apr 2007 08:00:30 +0900 (JST)
Received: from ohba by steelhead with local (Exim 4.63)
	(envelope-from )	id 1Hb2qa-0007NW-CJ; Mon,
	09 Apr 2007 16:00:28 -0700
Date: Mon, 09 Apr 2007 19:00:28 -0400
From: Yoshihiro Ohba 
Subject: Re: [HOKEY] Using an EAP method for HOKEY??: was: consensus call:
	EAP-ER as HOKEY protocol
In-reply-to: <007201c77af9$6cecc490$2f01a8c0@china.huawei.com>
To: Madjid Nakhjiri 
Message-id: <20070409230028.GD27511@steelhead>
MIME-version: 1.0
Content-type: text/plain; charset=iso-2022-jp
Content-disposition: inline
References: <460EAF24.7070506@cs.umd.edu>
	<007201c77af9$6cecc490$2f01a8c0@china.huawei.com>
User-Agent: Mutt/1.5.13 (2006-08-11)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a92270ba83d7ead10c5001bb42ec3221
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

Madjid,

How can key distribution by piggybacking data with EAP-Success work
when EAP-Success gets lost?  Note that EAP does not retransmit
EAP-Success.

Yoshihiro Ohba


On Mon, Apr 09, 2007 at 03:50:08PM -0700, Madjid Nakhjiri wrote:
> Hi,
> 
> As promised earlier, I am providing an analysis of use of EAP method for
> handover and re-authentication signaling. To me it seems that without
> introducing a new EAP code, one can accomplish the signaling with very
> little change to authenticator state machine, given that the authenticator
> already does receive and transmit AAA attributes along with AAA messages
> encapsulating EAP packets.
> 
> I have called this new method, EAP Handover and re-authentication method
> (EAP-HR), which consists of 3 messages (if you count EAP Success as method
> specific).
> I have shown the 3-party key distribution exchange (KDE) can be carried over
> the EAP-HR messages easily.
> As you can see in most of cases (handover, re-authentication and even in
> some cases for network setup), a trigger is easily available for the
> authenticator to start with EAP-HR Req, just the way EAP-identity starts
> from the authenticator. So the urgent need for peer-initiated messaging and
> hence the need to create new EAP code may go away.
> 
> 
> 
> Peer             authenticator             server
> 	EAP-HR REQ
> 	(DID, AID)
>   <-------------
> 	EAP-HR RESP
>       KDE message 1 and 2 (PID, AID and tokens)
> ------------------------------------------------->
> 		EAP/Success
> 		 (KDE message 3 and 4)
> <---------------------------------------------------
> 
> DID: domain ID (used for creating Domain keys)
> AID: authenticator ID advertised by the authenticator 
> (note this can be done as part of lower layer beacon advertisement), so
> carrying data through EAP-HR Request is not 100% necessary the KDE.
> 
> 
> FAQ
> =====
> 
> Roundtrips: 
> ============
> 1.1 when trigger is available at authenticator
> (assuming authenticator-peer trip~20% of server-peer trip).
> 1.5 when trigger needs to arrive from the server.
> 
> 
> Cases where trigger is available at authenticator
> a) in handover, this is available through a handover request from the peer.
> b) in re-authentication, the authentication/ key status is typically
> available at the authenticator as a result of previous AAA signaling (e.g.
> Session-life-time attribute)
> c) in network setup, the server may send a session-life-time=0 to
> authenticator along with the previous EAP authentication Success, to
> indicate the need to start HOKEY signaling.
> 
> 
> EAP-HR versus EAP identity
> ======================
> I have discussed this with several EAP experts and it seems that using EAP
> Identity request/ response versus using a new EAP method (EAP-HR) are almost
> identical.
> The issue with EAP Identity is that it does not carry data.
> IMO, modifying EAP Identity to carry data is more straight forward than
> creating EAP-HR.
> 
> 
> 
> EAP Success:
> ==========
> It seems that quite a number of people have already backed up the idea of
> modifying EAP success to carry data: people brought up the fact that 2284
> did allow EAP success carrying data and the only reason 3748 banned EAP
> Success from carrying data was the inadequate method independent way of
> carrying data. It seems to me that keys derived from the hierarchy can be
> used to protect the EAP success and its data and this would allow for
> protected result indication as well. 
> 
> The other reason to allow EAP Success carry data is to provide a natural
> extension to the AAA (authorization, etc) signaling that currently does not
> reach beyond the authenticator.
> 
> So with that in mind, I hope we don't rehash the previous emails citing
> sentences from 3748 about EAP Success carrying data...
> 
> 3 Party key distribution (KDE)
> =======================
> I have modified the 3 party key distribution slightly to accomodate the EAP
> method signaling.
> 
>    0  Authenticator to peer: EAP(DAID, DID)
> 
>    1  Peer to Authenticator: EAP((PID, DAID, DID, Np,KNps), [PID, DAID,
>       Np,KNps]Kps)
> 
>    2  Authenticator to Server: AAA(PID, UAID, [PID, UAID]Kas),
>       AAA(EAP((PID, DAID, DID, Np,KNps), [PID, DAID, DID, Np,KNps]Kps))
> 
>    3  Server to Authenticator: AAA({PID,AID,KNpa, KLpa, Kpa}KEas),
>       AAA(EAP(KNpa, KLpa, KNps, [PID, AID, DID, Np+1,KNpa,KLpa,
>       KNps]Kps))
> 
>    4  Authenticator to Peer: EAP(KNpa, KLpa, KNps, [PID, AID, DID, Np+1,
>       KNpa,KLpa, KNps]Kps])
> 
> PID: peer ID.  
>    DID: Domain ID
>    AID: Authenticator ID
>    DAID: Authenticator ID as perceived by the peer (down link ID)
>    UAID: Authenticator ID as perceived by the server (uplink ID)
>    {X}K: X encrypted with key K
>    [X]K: Message Authentication Code over X with key K.
>    X(Y): Y carried with X protocol
>    Kps: A symmetric key shared between peer and Server for signing (IK,
>    provisioned by EAP/HOKEY hierarchy) and identified by KNps.
> 
>    KEps: A symmetric key shared between peer and Server for encryption
>    (CK, provisioning by EAP/HOKEY hierarchy) and identified by KEpsid
> 
>    KEas: A symmetric key shared between authenticator and Server for
>    encryption (provisioned out of band).
> 
>    Kas: A symmetric key between authentication and server for MDCs for
>    signing (provisioned out of band).
> 
> 
>  Kpa: A symmetric key to be shared between peer and authenticator (key
>    to be distributed to authenticator, the MDMSK in this document).  The
>    key is named as KNpa.
> 
>    KLx : Key lifetime for key x
> 
>    KNx: Key name for Key x, e.g.  KENas: key name for KEas
> 
>    Nx : Nonce provided by the party X
> 
> I have provided more the details in a draft. 
> http://www.ietf.org/internet-drafts/draft-nakhjiri-hokey-hierarchy-04.txt
> 
> Regards,
> 
> Madjid
> 
> -----Original Message-----
> From: Charles Clancy [mailto:clancy@cs.umd.edu] 
> Sent: Saturday, March 31, 2007 11:58 AM
> To: hokey@ietf.org
> Subject: [HOKEY] consensus call: EAP-ER as HOKEY protocol
> 
> HOKEY WG,
> 
> The chairs are making a second consensus call request to adopt EAP-ER as 
> a WG document to satisfy our re-auth and hand-off deliverables.  It 
> would serve as a starting point for development of the HOKEY protocol.
> 
> Note that if accepted, it may be split into two WG documents, separating 
> the EAP-ER-Bootstrap into a second set of messages that could be 
> transported by any service to obtain a USRK or DSUSRK.
> 
> Please respond by Friday, April 13.
> 
> -- 
> t. charles clancy, ph.d.  <>  tcc@umd.edu  <>  www.cs.umd.edu/~clancy
> 
> 
> _______________________________________________
> 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 Mon Apr 09 19:12: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 1Hb31y-0006xy-7a; Mon, 09 Apr 2007 19:12:14 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hb31x-0006wD-Bp
	for hokey@ietf.org; Mon, 09 Apr 2007 19:12:13 -0400
Received: from usaga01-in.huawei.com ([206.16.17.211])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hb31w-0000Lf-Nf
	for hokey@ietf.org; Mon, 09 Apr 2007 19:12:13 -0400
Received: from huawei.com (usaga01-in [172.18.4.6])
	by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTP id <0JG9007JM74CLC@usaga01-in.huawei.com> for
	hokey@ietf.org; Mon, 09 Apr 2007 16:12:12 -0700 (PDT)
Received: from N737011
	(pool-71-112-121-192.sttlwa.dsl-w.verizon.net [71.112.121.192])
	by usaga01-in.huawei.com
	(iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar  3 2004))
	with ESMTPA id <0JG9007CK7479G@usaga01-in.huawei.com> for
	hokey@ietf.org; Mon, 09 Apr 2007 16:12:12 -0700 (PDT)
Date: Mon, 09 Apr 2007 16:12:13 -0700
From: Madjid Nakhjiri 
Subject: RE: [HOKEY] consensus call: EAP-ER as HOKEY protocol
In-reply-to: <9958B444368E884DBB215F3FEF36F5B7041F9D64@xmb-rtp-212.amer.cisco.com>
To: "'Hao Zhou (hzhou)'" ,
	'Avi Lior' 
Message-id: <007401c77afc$82444d10$2f01a8c0@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962
X-Mailer: Microsoft Office Outlook 11
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Thread-index: Acd2Eo8Jp6qnVT1/QuCv4YtraK6otwADVuVwATcDQUA=
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c0aa019322dfce838bd8604f5a841b57
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

Sorry for being really late on this one.

Thanks Hao for posting this. 

As I said in my other emails, I feel that either EAP identity or a new EAP
method request/response with loaded EAP Success is the least intrusive way,
given that almost all of the info in the EAP Success is destined for the
peer and not the authenticator, I don't really see a big impact on the
authenticators compared to the EAP code method which suggests swapping a
peer-initiated request and an EAP Response from the peer.

R,

Madjid

-----Original Message-----
From: Hao Zhou (hzhou) [mailto:hzhou@cisco.com] 
Sent: Tuesday, April 03, 2007 12:06 PM
To: Lakshminath Dondeti; Avi Lior
Cc: hokey@ietf.org; Madjid Nakhjiri
Subject: RE: [HOKEY] consensus call: EAP-ER as HOKEY protocol

I have been soliciting with a few others about the idea of using
existing EAP codes to do HOAKEY, instead of creating new EAP codes. The
idea is roughly like this:

1. NAS still sends out EAP-Identity request, with something in the
request to indicate HOAKEY support. Something similar to how network
selection RFC utilizing the space after NULL character. The extra data
would include HOAKEY capability, as well as any other information
needed, e.g., domain ID, etc.

2. Client send back normal EAP-Identity Response, piggybacking any
HOAKEY data needed, e.g., agreement to do HOAKEY and any HOAKEY keying
materials.

3. If the NAS determine that client wants to do HOAKEY, then it forwards
the HOAKEY data to the HOAKEY server. Otherwise, it starts the normal
full EAP authentication.

4. After HOAKEY server sends back the server data, NAS sends EAP-Success
with additional HOAKEY data, which allows the client to verify and
authenticate the NAS.

The benefits of using this approach are:

1. Maximum backward compatibility with legacy NAS and client. Existing
client should work with new HOAKEY NAS and existing NAS would work with
new HOAKEY capable client.
2. Less changes on the EAP lower layer on both the client and NAS. The
only change is to allow additional data to be piggy-backed on
EAP-Success, vs. current EAP-ER proposal of two new EAP codes.
3. HOAKEY capability negotiation and domain ID transmission is also
included this way, instead of being mandated to be added to lower layer.
The lower layer is probably harder to change.
4. I don't think the half round trip for EAP-Identity request and
response would hurt performance too much and critical, as it is local
between the client and NAS. Modifying the lower layer to allow client
initiating exchange might be too much for some lower layer. 
5. Even if piggybacking data on EAP-Success is determined to be
impossible and we need a new EAP code, we should still just create a
single new code for the EAP-Success with optional data, this way, only
the new HOAKEY capable NAS and client needs to understand and support
it. I would recommend still using the EAP-Identity request-response
exchange for the first part. The goal is to minimize changes to EAP flow
and state machine and EAP lower layer as little as possible. 

> -----Original Message-----
> From: Lakshminath Dondeti [mailto:ldondeti@qualcomm.com] 
> Sent: Tuesday, April 03, 2007 1:07 PM
> To: Avi Lior
> Cc: hokey@ietf.org; Madjid Nakhjiri
> Subject: Re: [HOKEY] consensus call: EAP-ER as HOKEY protocol
> 
> Hi Avi,
> 
> I find some of your arguments counter-intuitive and so would 
> like to understand your line of thinking on this topic.  
> Modifications to a protocol to my knowledge would be hacks 
> and extensions are well, extensions.  For instance, the EAP 
> Request/Identity message suspension in EAP-ER, as much as I 
> would like to defend it, is somewhat of a hack. 
>   It is the cleanest Vidya and I could come up with in the 
> sense that the message itself is not modified, but we need 
> something like it to make sure that the L2 connection is not 
> closed if the retransmission time expires.  Perhaps the wider 
> community might find a better approach.
> 
> Next, some notes on 4284 since that has come up here:
> 
> 3748 says "Some EAP implementations piggy-back various 
> options into the
>        Identity Request after a NUL-character. "
> 
> 4284 uses that provision.  In any event, 4284 is somewhat of 
> a hack and is an informational RFC for the purposes of 3GPP's use.
> 
> Please see inline for some questions:
> 
> Avi Lior wrote:
> > I for one thinks we should look at allowing us to carry data in EAP 
> > success.  In fact, it would be a good idea if we allowed 
> EAP to carry 
> > data which is not part of the method in all exchanges.
> 
> If the data is not part of the method, which entity needs to 
> send such data and how is it protected?
> 
> > 
> > Clearly there is a need to communicate with the Peer before 
> and just 
> > after authentication.  There is no other path to the Peer.  
> EAP should 
> > have addressed this.
> 
> Again which entity needs to communicate with the Peer?
> 
> >  
> > We already see this happening in the Request Identity (as 
> in Network 
> > Selection and other such usage), in the Repsonse Identity 
> and now in 
> > the Success phase.
> >  
> > We can continue to "hack" EAP but we can also fix it.
> 
> I am lost here, so please help me out :).  The network 
> selection solution of 4284 is a hack IMO.  If you are saying 
> we should revise 3748, I might agree with you in principle.  
> But, practically speaking that is not happening anytime soon.
> 
> Next, RFC 3748 has clear guidance on allocating new packet 
> codes in Section 6.1.  Defining new codes is a natural way of 
> extending EAP.  If the goal is backward compatibility, adding 
> stuff to EAP Success doesn't help either.  As I have noted 
> before, EAP Success packets are not retransmitted by 
> authenticators and that would have to change if we add 
> anything crucial to Success packets.
> 
> I appreciate any clarifications you might provide to help me 
> understand your point of view here.  Thanks.
> 
> regards,
> Lakshminath
> 
> >  
> > I am not saying EAP-ER is a hack but it is not efficient because it 
> > works around the existing EAP semantics but hopefully we 
> could do better.
> >  
> > Avi Lior Office: +1 613 591-9104 x 6417 Cell : +1 613 796-4183
> > 
> > 
> > 
> ----------------------------------------------------------------------
> > --
> > *From:* Lakshminath Dondeti
> > *Sent:* Mon 4/2/2007 11:13 PM
> > *To:* Madjid Nakhjiri
> > *Cc:* hokey@ietf.org
> > *Subject:* Re: [HOKEY] consensus call: EAP-ER as HOKEY protocol
> > 
> > Many of the active WG contributors were present at the 
> interim meeting 
> > and there was a presentation and discussion on how reauthentication 
> > might work with new EAP types or codes.  The consensus was that 
> > code-based approach works best and that consensus was subsequently 
> > verified on the list.
> > 
> > Well, here we are.  I am also looking forward to seeing 
> your analysis 
> > on this topic.  Changing the structure of the EAP Success 
> message and 
> > also the transmission rules for EAP Success are quite 
> drastic changes.  
> > If EAP Success needs to be reliably transmitted, authenticator 
> > behavior would have to change.  Consider the following 
> rules on EAP Success messages:
> > 
> > "The peer
> >     MAY, in the event that an EAP Success is not received, 
> conclude that
> >     the EAP Success packet was lost and that authentication 
> concluded
> >     successfully."
> > 
> > "Success and Failure packets MUST NOT
> >     contain additional data."
> > 
> > "Because the Success and Failure packets are not
> >     acknowledged, they are not retransmitted by the 
> authenticator, and
> >     may be potentially lost.  A peer MUST allow for this 
> circumstance as
> >     described in this note. "
> > 
> > Anyway, I still want to see your analysis of this.
> > 
> > thanks,
> > Lakshminath
> > 
> > PS:  I understand your concern about EAP Identity Request 
> and we can 
> > work on other alternatives for it where terminating the EAP state 
> > machine at the Authenticator and spawning an EAP-ER state 
> machine is 
> > considered burdensome (there are other ways of looking at this and 
> > that is written in vidya-eap-er-02).
> > 
> > Madjid Nakhjiri wrote:
> >  > Hi,
> >  >
> >  > I like to seek a clarification here first.
> >  > Have we put the discussion of use of EAP code versus EAP 
> types to 
> > bed,  > completely satisfied that EAP types will absolutely 
> not solve 
> > the problems?
> >  >
> >  > Given that the Russ only first gave the few of us present in San 
> > Jose the  > green light to change EAP, I feel that we did not quite 
> > discuss the impact  > of adding new EAP codes versus other 
> changes to 
> > an end.  A simple analysis  > shows (I have confirmed this with 
> > several EAP experts) that using a new EAP  > type and adding some 
> > payload to EAP success you can easily achieve near 1  > roundtrip 
> > exchanges. I can forward that analysis in a separate email.
> >  >
> >  > It is not clear whether adding data to EAP success is 
> more severe 
> > than the  > changes that EAP-ER is suggesting, to name a few:
> >  >
> >  > 1) adding new codes even though 3748 mandates a discard 
> code>4  > 
> > 2) change of authenticator state machine to treat EAP ER 
> Request as a  
> > > response to EAP Identity request. This seems a lot more 
> intrusive on 
> > the  > massive scale of existing authenticators, than 
> adding data to 
> > EAP success  > intended for the peer.
> >  >
> >  > It seems that before fully deciding the EAP code versus EAP type 
> > options, it  > is hard to make a judgement on a solution 
> that is based 
> > on EAP code.
> > After
> >  > that, there are issues such as identity exchanges that 
> are needed 
> > for key  > derivation according to the EMSK draft and it seems that 
> > EAP-ER is  > considering those out of band or requires 
> explicit additional signaling.
> >  >
> >  > Finally the other clarification I am seeking is regarding the 
> > second  > document, don't we want to specify how the 
> per-authenticator 
> > keys are  > derived? It seems that it should be included in 
> the second spec as well.
> >  >
> >  > R,
> >  >
> >  > Madjid
> >  >
> >  > -----Original Message-----
> >  > From: Charles Clancy [mailto:clancy@cs.umd.edu]  > Sent: 
> Saturday, 
> > March 31, 2007 11:58 AM  > To: hokey@ietf.org  > Subject: [HOKEY] 
> > consensus call: EAP-ER as HOKEY protocol  >  > HOKEY WG,  >  > The 
> > chairs are making a second consensus call request to adopt 
> EAP-ER as  
> > > a WG document to satisfy our re-auth and hand-off 
> deliverables.  It  
> > > would serve as a starting point for development of the 
> HOKEY protocol.
> >  >
> >  > Note that if accepted, it may be split into two WG documents, 
> > separating  > the EAP-ER-Bootstrap into a second set of 
> messages that 
> > could be  > transported by any service to obtain a USRK or DSUSRK.
> >  >
> >  > Please respond by Friday, April 13.
> >  >
> > 
> > _______________________________________________
> > 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 Mon Apr 09 19:26: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 1Hb3Fq-0003wH-JH; Mon, 09 Apr 2007 19:26:34 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hb3Fp-0003w9-Pl
	for hokey@ietf.org; Mon, 09 Apr 2007 19:26:33 -0400
Received: from usaga01-in.huawei.com ([206.16.17.211])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hb3Fj-0004bW-PO
	for hokey@ietf.org; Mon, 09 Apr 2007 19:26:33 -0400
Received: from huawei.com (usaga01-in [172.18.4.6])
	by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTP id <0JG9007B97S3LC@usaga01-in.huawei.com> for
	hokey@ietf.org; Mon, 09 Apr 2007 16:26:27 -0700 (PDT)
Received: from N737011
	(pool-71-112-121-192.sttlwa.dsl-w.verizon.net [71.112.121.192])
	by usaga01-in.huawei.com
	(iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar  3 2004))
	with ESMTPA id <0JG9007K57RX9G@usaga01-in.huawei.com> for
	hokey@ietf.org; Mon, 09 Apr 2007 16:26:27 -0700 (PDT)
Date: Mon, 09 Apr 2007 16:26:27 -0700
From: Madjid Nakhjiri 
Subject: RE: [HOKEY] consensus call: EAP-ER as HOKEY protocol
In-reply-to: <461444EE.4000103@qualcomm.com>
To: 'Lakshminath Dondeti' 
Message-id: <008601c77afe$801e9c00$2f01a8c0@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962
X-Mailer: Microsoft Office Outlook 11
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Thread-index: Acd3GrTUQmdUIreaTRuWU2/PfRjX9wD46LnA
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 827a2a57ca7ab0837847220f447e8d56
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

One of us must have seriously missed the point and subject of this thread:
"Consensus call".

Madjid

-----Original Message-----
From: Lakshminath Dondeti [mailto:ldondeti@qualcomm.com] 
Sent: Wednesday, April 04, 2007 5:38 PM
To: Madjid Nakhjiri
Cc: 'Charles Clancy'; hokey@ietf.org
Subject: Re: [HOKEY] consensus call: EAP-ER as HOKEY protocol

Madjid Nakhjiri wrote:
> IETF has specific rules about the Interims and consensus and those are
> public so I am going to simply refer you to those.

Yes, and my interpretation of those rules as applied to this situation 
is that we have consensus on Code vs. Type.  The rule is that consensus 
is to be verified on the list and it was.

The rest of your message is completely off-topic.

Lakshminath

> 
> I don't know the meaning of "drastic" as it is indicated here. 
> 
> Everybody agrees that a major problem with EAP is that it does not provide
> much protection for result indication. So here we are claiming we are
> overhauling EAP, but don't want to deal with lost result indication?
> 
> Today the SDOs are struggling to carry the information indicated by the
AAA
> server to the authenticator, further to the EAP peer. AAA services are
> getting more and more ubiquitous usage and hinging lots of this stuff to
the
> initial EAP process is as ubiquitious, so adding information to EAP
success
> is a very good thing to end a network access control process.
> 
> Adding data to EAP success has almost no effect on the authenticators,
much
> less than requiring the authenticators to treat responses as requests as
the
> code based method is suggesting.
> 
> I will send the analysis, but it seems that Hao has already sent a similar
> one.
> 
> 
> Madjid
> 
> 
> -----Original Message-----
> From: Lakshminath Dondeti [mailto:ldondeti@qualcomm.com] 
> Sent: Monday, April 02, 2007 8:13 PM
> To: Madjid Nakhjiri
> Cc: 'Charles Clancy'; hokey@ietf.org
> Subject: Re: [HOKEY] consensus call: EAP-ER as HOKEY protocol
> 
> Many of the active WG contributors were present at the interim meeting 
> and there was a presentation and discussion on how reauthentication 
> might work with new EAP types or codes.  The consensus was that 
> code-based approach works best and that consensus was subsequently 
> verified on the list.
> 
> Well, here we are.  I am also looking forward to seeing your analysis on 
> this topic.  Changing the structure of the EAP Success message and also 
> the transmission rules for EAP Success are quite drastic changes.  If 
> EAP Success needs to be reliably transmitted, authenticator behavior 
> would have to change.  Consider the following rules on EAP Success
messages:
> 
> "The peer
>     MAY, in the event that an EAP Success is not received, conclude that
>     the EAP Success packet was lost and that authentication concluded
>     successfully."
> 
> "Success and Failure packets MUST NOT
>     contain additional data."
> 
> "Because the Success and Failure packets are not
>     acknowledged, they are not retransmitted by the authenticator, and
>     may be potentially lost.  A peer MUST allow for this circumstance as
>     described in this note. "
> 
> Anyway, I still want to see your analysis of this.
> 
> thanks,
> Lakshminath
> 
> PS:  I understand your concern about EAP Identity Request and we can 
> work on other alternatives for it where terminating the EAP state 
> machine at the Authenticator and spawning an EAP-ER state machine is 
> considered burdensome (there are other ways of looking at this and that 
> is written in vidya-eap-er-02).
> 
> Madjid Nakhjiri wrote:
>> Hi, 
>>
>> I like to seek a clarification here first.
>> Have we put the discussion of use of EAP code versus EAP types to bed,
>> completely satisfied that EAP types will absolutely not solve the
> problems?
>> Given that the Russ only first gave the few of us present in San Jose the
>> green light to change EAP, I feel that we did not quite discuss the
impact
>> of adding new EAP codes versus other changes to an end.  A simple
analysis
>> shows (I have confirmed this with several EAP experts) that using a new
> EAP
>> type and adding some payload to EAP success you can easily achieve near 1
>> roundtrip exchanges. I can forward that analysis in a separate email.
>>
>> It is not clear whether adding data to EAP success is more severe than
the
>> changes that EAP-ER is suggesting, to name a few:
>>
>> 1) adding new codes even though 3748 mandates a discard code>4 
>> 2) change of authenticator state machine to treat EAP ER Request as a
>> response to EAP Identity request. This seems a lot more intrusive on the
>> massive scale of existing authenticators, than adding data to EAP success
>> intended for the peer.
>>
>> It seems that before fully deciding the EAP code versus EAP type options,
> it
>> is hard to make a judgement on a solution that is based on EAP code.
After
>> that, there are issues such as identity exchanges that are needed for key
>> derivation according to the EMSK draft and it seems that EAP-ER is
>> considering those out of band or requires explicit additional signaling.
>>
>> Finally the other clarification I am seeking is regarding the second
>> document, don't we want to specify how the per-authenticator keys are
>> derived? It seems that it should be included in the second spec as well.
>>
>> R,
>>
>> Madjid
>>
>> -----Original Message-----
>> From: Charles Clancy [mailto:clancy@cs.umd.edu] 
>> Sent: Saturday, March 31, 2007 11:58 AM
>> To: hokey@ietf.org
>> Subject: [HOKEY] consensus call: EAP-ER as HOKEY protocol
>>
>> HOKEY WG,
>>
>> The chairs are making a second consensus call request to adopt EAP-ER as 
>> a WG document to satisfy our re-auth and hand-off deliverables.  It 
>> would serve as a starting point for development of the HOKEY protocol.
>>
>> Note that if accepted, it may be split into two WG documents, separating 
>> the EAP-ER-Bootstrap into a second set of messages that could be 
>> transported by any service to obtain a USRK or DSUSRK.
>>
>> Please respond by Friday, April 13.
>>
> 
> 
> 



_______________________________________________
HOKEY mailing list
HOKEY@ietf.org
https://www1.ietf.org/mailman/listinfo/hokey



From hokey-bounces@ietf.org Mon Apr 09 21:00: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 1Hb4iV-00007H-HA; Mon, 09 Apr 2007 21:00:15 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hb4iT-000070-P9
	for hokey@ietf.org; Mon, 09 Apr 2007 21:00:13 -0400
Received: from ithilien.qualcomm.com ([129.46.51.59])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hb4iR-0001ck-Ql
	for hokey@ietf.org; Mon, 09 Apr 2007 21:00:13 -0400
Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158])
	by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id
	l3A10677024013
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 9 Apr 2007 18:00:06 -0700
Received: from SANEXCAS03.na.qualcomm.com (sanexcas03.qualcomm.com
	[172.30.32.65])
	by totoro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l3A105oj015657;
	Mon, 9 Apr 2007 18:00:05 -0700 (PDT)
Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by
	SANEXCAS03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 9 Apr 2007 18:00: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
Subject: RE: [HOKEY] consensus call: key distribution security requirement
Date: Mon, 9 Apr 2007 18:00:00 -0700
Message-ID: 
In-Reply-To: <46386.69.12.173.8.1175877985.squirrel@www.trepanning.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [HOKEY] consensus call: key distribution security requirement
Thread-Index: Acd4ayYX3feI+pDhSqSKgnvJE4yaygCndpEw
References: <460EB36E.5010604@cs.umd.edu>
	
	<20070404024453.GA18289@steelhead>
	
	<7030.12.108.168.179.1175729051.squirrel@www.trepanning.net>
	
	<44325.69.12.173.8.1175792579.squirrel@www.trepanning.net>
	
	<33754.69.12.173.8.1175797183.squirrel@www.trepanning.net>
	
	<46386.69.12.173.8.1175877985.squirrel@www.trepanning.net>
From: "Narayanan, Vidya" 
To: "Dan Harkins" 
X-OriginalArrivalTime: 10 Apr 2007 01:00:05.0635 (UTC)
	FILETIME=[93B57D30:01C77B0B]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4ec3642ae9025e273a4a263d640f3300
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 Dan,=20
Some notes inline.=20

> -----Original Message-----
> From: Dan Harkins [mailto:dharkins@lounge.org]=20
> Sent: Friday, April 06, 2007 9:46 AM
> To: Narayanan, Vidya
> Cc: Dan Harkins; Yoshihiro Ohba; hokey@ietf.org
> Subject: RE: [HOKEY] consensus call: key distribution=20
> security requirement
>=20
>=20
>   Hi Vidya,
>=20
>   When EAP is used in "pass-thru" mode there is a problem. As=20
> you note that problem, and a solution to it, is described in=20
> RFC3748 under the heading of "Channel Binding". We have that=20
> same sort of problem in spades here in HOKEY because we're=20
> distributing keys that must be for a specific authenticator,=20
> for a specific usage, and I guess for a specific domain.=20
> There is context that constrains who can use a key and how=20
> that key can be used. So we need to solve that same sort of=20
> problem that EAP has when used in "pass-thru" mode.
>=20
>   Perhaps "Channel Binding" isn't a good term to use since it=20
> implies something specific (RFC3748). How about "protected=20
> exchange"? That is how RFC3748 describes "Channel Binding"=20
> anyway. So would something along the lines of this be agreeable?
>=20
>    HOKEY MUST include a protected exchange of context, usage, and

What is the difference between context and usage?=20

>    identities=20

On identities, I believe the exchange may be needed in some cases and
not in other cases. So, having an optional exchange of identities would
be sufficient in my view.=20

Vidya

> that are bound to, and constrain, a key including but
>    not limited to [enumerate the things needed]. This will make it
>    possible to match the same properties provided by the authenticator
>    via an out-of-band mechanism (like AAA) against those in=20
> the protected
>    exchange in the HOKEY protocol.
>=20
> To plagiarize^H^H^H^H^H^H paraphrase RFC3748.
>=20
>   Dan.
>=20
> On Thu, April 5, 2007 4:23 pm, Narayanan, Vidya wrote:
> > Dan,
> > I think we simply have been using different definitions of channel=20
> > binding. I've been using the definitions present in RFC3748 and the=20
> > EAP keying document, which don't quite include binding of=20
> context and such.
> > I do, however, agree, that the definition of channel=20
> binding is rather=20
> > loose and we don't have one unified view on that.
> >
> > Having said that, let me try another way of making progress here:
> >
> > * Keys should be bound to the correct context/usage
> > * Keys should be scoped to the entities that need to use it
> > * Keys should be fresh
> > * Domino effect must be prevented
> >
> > I'm on board with all of the above. Are we on the same page?
> >
> > Vidya
> >
> >> -----Original Message-----
> >> From: Dan Harkins [mailto:dharkins@lounge.org]
> >> Sent: Thursday, April 05, 2007 11:20 AM
> >> To: Narayanan, Vidya
> >> Cc: Dan Harkins; Yoshihiro Ohba; hokey@ietf.org
> >> Subject: RE: [HOKEY] consensus call: key distribution security=20
> >> requirement
> >>
> >>
> >>   Vidya,
> >>
> >>   No, it is far from being "no help". Channel binding is=20
> the way to=20
> >> bind all necessary context to the key.
> >>
> >>   Dan.
> >>
> >> On Thu, April 5, 2007 10:22 am, Narayanan, Vidya wrote:
> >> > Dan,
> >> > Context (usage) is additional information that needs to=20
> be bound to=20
> >> > the key - we have no disagreement there. But, channel
> >> binding is of no
> >> > help for that either. As to scope, the keys must be scoped
> >> to a domain
> >> > and that has also been agreed upon.
> >> >
> >> > Vidya
> >> >
> >> >> -----Original Message-----
> >> >> From: Dan Harkins [mailto:dharkins@lounge.org]
> >> >> Sent: Thursday, April 05, 2007 10:03 AM
> >> >> To: Narayanan, Vidya
> >> >> Cc: Dan Harkins; Yoshihiro Ohba; hokey@ietf.org
> >> >> Subject: RE: [HOKEY] consensus call: key distribution security=20
> >> >> requirement
> >> >>
> >> >>
> >> >>   Vidya,
> >> >>
> >> >>   All you're addressing is "preventing the domino effect".
> >> >> That is not scoping the key or binding context to a key.
> >> >>
> >> >>   There is context for the key. For instance, "this is for a=20
> >> >> particular authenticator." To quote from
> >> >> draft-housley-aaa-key-mgmt-09.txt:
> >> >>
> >> >>          The context will include the peer and NAS
> >> identities in more
> >> >>          than one form.  One (or more) name form is needed
> >> to identify
> >> >>          these parties in the authentication exchange=20
> and the AAA
> >> >>          protocol.
> >> >>
> >> >> In addition if HOKEY is going to have some key=20
> hierarchy in which=20
> >> >> keys are specific for a particular usage or a particular
> >> domain then
> >> >> that is additional context that has to be bound to the=20
> key. You're=20
> >> >> just throwing a counter or a nonce into the mix and=20
> thinking that=20
> >> >> solves all problems. It doesn't.
> >> >>
> >> >>   Dan.
> >> >>
> >> >> On Wed, April 4, 2007 6:20 pm, Narayanan, Vidya wrote:
> >> >> > Hi Dan,
> >> >> > As we talked about this before, there is no attack, when
> >> every key
> >> >> > handed out is fresh and unique across any two key
> >> fetches from the
> >> >> > server. So, the scoping of keys necessary is about ensuring
> >> >> that the
> >> >> > same key is never ever given out again, even to the
> >> >> (seemingly) same
> >> >> > entity.
> >> >> >
> >> >> > Vidya
> >> >> >
> >> >> >> -----Original Message-----
> >> >> >> From: Dan Harkins [mailto:dharkins@lounge.org]
> >> >> >> Sent: Wednesday, April 04, 2007 4:24 PM
> >> >> >> To: Narayanan, Vidya
> >> >> >> Cc: Yoshihiro Ohba; hokey@ietf.org
> >> >> >> Subject: RE: [HOKEY] consensus call: key=20
> distribution security=20
> >> >> >> requirement
> >> >> >>
> >> >> >>
> >> >> >>   Hi Vidya,
> >> >> >>
> >> >> >>   As I explained to you previously the issue of=20
> "peer detects=20
> >> >> >> mismatch during secure association protocol" (slide 5 of your
> >> >> >> deck) doesn't work because these are symmetric keys and
> >> >> the "middle
> >> >> >> entity" can impersonate the client now. Every single
> >> property that
> >> >> >> you want to give to the key being distributed is lost.
> >> >> >>
> >> >> >>   Of course you may not view that as a problem but I think
> >> >> that has
> >> >> >> more to do with what you want to do then with whether it's
> >> >> secure or
> >> >> >> not.
> >> >> >>
> >> >> >>   Can you please explain how to ensure that keys are
> >> >> properly scoped
> >> >> >> if you do not bind the scoping information to the=20
> exchange that=20
> >> >> >> distributes the key? How can the peer have any assurance
> >> >> that the key
> >> >> >> is "not shared"
> >> >> >> (one of the qualifiers you mention) if it did not take
> >> part in the
> >> >> >> distribution of its key?
> >> >> >>
> >> >> >>   Why not just send the EMSK to every entity that the
> >> AS thinks it
> >> >> >> has a security association with? I mean, in many cases as
> >> >> long as the
> >> >> >> peer receives a certain level of service and is charged
> >> >> for same then
> >> >> >> the identity of the entity receiving the EMSK is=20
> irrelevant and=20
> >> >> >> channel binding isn't important and as long as we=20
> scope the key=20
> >> >> >> properly (everyone with whom the AS shares a security
> >> >> association--
> >> >> >> aka "the
> >> >> >> network") then it's OK. After all, nothing matters as
> >> long as the
> >> >> >> peer is satisfied and "if the peer is not satisfied or
> >> there is a
> >> >> >> billing issue, it contacts its home network and tries to
> >> >> get service
> >> >> >> from some other node instead" (to quote from slide #6).
> >> >> >>
> >> >> >>   Dan.
> >> >> >>
> >> >> >> On Wed, April 4, 2007 11:16 am, Narayanan, Vidya wrote:
> >> >> >> > Hi Yoshi,
> >> >> >> >
> >> >> >> >> -----Original Message-----
> >> >> >> >> From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com]
> >> >> >> >> Sent: Tuesday, April 03, 2007 7:45 PM
> >> >> >> >> To: Narayanan, Vidya
> >> >> >> >> Cc: Charles Clancy; hokey@ietf.org
> >> >> >> >> Subject: Re: [HOKEY] consensus call: key
> >> distribution security
> >> >> >> >> requirement
> >> >> >> >>
> >> >> >> >> Hi Vidya,
> >> >> >> >>
> >> >> >> >> Can you please explain why channel binding
> >> information must be
> >> >> >> >> optional?
> >> >> >> >>
> >> >> >> >
> >> >> >> > Briefly, in many cases, as long as the peer receives a
> >> >> >> certain level
> >> >> >> > of service and is charged for the same, the identity of
> >> >> the network
> >> >> >> > entity providing the service is irrelevant. In some cases,
> >> >> >> it may be
> >> >> >> > relevant and hence, it would be good to have the
> >> >> capability to do
> >> >> >> > channel binding. But, for the other cases, there is no need
> >> >> >> to mandate
> >> >> >> > the lower layer to advertise identities.
> >> >> >> >
> >> >> >> >> Can you also explain in which system there are no adverse
> >> >> >> effects in
> >> >> >> >> key distribution without explicit peer consent?
> >> >> >> >>
> >> >> >> >
> >> >> >> > I have not seen any real loss of security properties in
> >> >> >> distribution
> >> >> >> > of keys without peer consent, as long as the keys=20
> are scoped=20
> >> >> >> > correctly, not shared and freshness is always ensured.
> >> >> >> >
> >> >> >> > Please see
> >> >> >> >
> >> >> >>
> >> >>
> >>=20
> http://www.geocities.com/hellovidya/Authenticators_and_Identities.pdf
> >> >> >> > if you are interested in more details. I had put some
> >> >> >> slides together
> >> >> >> > a while ago on this identities issue.
> >> >> >> >
> >> >> >> > Vidya
> >> >> >> >
> >> >> >> >> Regards,
> >> >> >> >> Yoshihiro Ohba
> >> >> >> >>
> >> >> >> >>
> >> >> >> >> On Tue, Apr 03, 2007 at 06:25:52PM -0700, Narayanan,
> >> >> Vidya wrote:
> >> >> >> >> > I'm barely caught up on all the email after having been
> >> >> >> on vacation
> >> >> >> >> > until now, so, pardon me if I'm bringing up stuff that's
> >> >> >> >> already been
> >> >> >> >> > discussed here.
> >> >> >> >> >
> >> >> >> >> > I share some of Glen's concerns about "requiring" peer
> >> >> >> >> consent and a
> >> >> >> >> > 3-party protocol and about how practically=20
> deployable that
> >> >> >> >> is. In my
> >> >> >> >> > conversations with Dan in Prague, it seemed=20
> like we were=20
> >> >> >> >> > on
> >> >> >> >> the same
> >> >> >> >> > page about including channel binding information in the
> >> >> >> >> HOKEY protocol
> >> >> >> >> > between the peer and server. I think such=20
> channel binding
> >> >> >> >> information
> >> >> >> >> > must be optional and not required. In some systems,
> >> >> there are no
> >> >> >> >> > adverse effects of distribution of key material without
> >> >> >> >> explicit peer
> >> >> >> >> > consent and there is no reason to place upper
> >> layer identity
> >> >> >> >> > advertisement requirements on the lower layers for such
> >> >> >> systems. In
> >> >> >> >> > some other systems, it may be a good idea to do so and
> >> >> >> having the
> >> >> >> >> > capability to do that in the protocol would be
> >> useful there.
> >> >> >> >> >
> >> >> >> >> > To specifically answer your question, I don't believe
> >> >> we need to
> >> >> >> >> > update the problem statement. It already captures the
> >> >> >> >> channel binding
> >> >> >> >> > stuff and the explicit data that the peer and
> >> >> authenticator may
> >> >> >> >> > include is one way of providing channel binding.
> >> >> >> >> >
> >> >> >> >> > Vidya
> >> >> >> >> >
> >> >> >> >> > > -----Original Message-----
> >> >> >> >> > > From: Charles Clancy [mailto:clancy@cs.umd.edu]
> >> >> >> >> > > Sent: Saturday, March 31, 2007 12:16 PM
> >> >> >> >> > > To: hokey@ietf.org
> >> >> >> >> > > Subject: [HOKEY] consensus call: key
> >> distribution security
> >> >> >> >> > > requirement
> >> >> >> >> > >
> >> >> >> >> > > HOKEY WG,
> >> >> >> >> > >
> >> >> >> >> > > The 3-party protocol proposal at IETF 68 listed a
> >> >> variety of
> >> >> >> >> > > protocol requirements, some of which went beyond those
> >> >> >> currently
> >> >> >> >> > > specified in the problem statements draft.  The main
> >> >> >> >> extension was a
> >> >> >> >> > > requirement for stronger key distribution security.
> >> >> >> >> > >
> >> >> >> >> > > Discussion: The problem statements document
> >> >> currently requires
> >> >> >> >> > > channel bindings to allow clients to authenticate the
> >> >> >> network to
> >> >> >> >> > > which they are connecting, and prevent the lying
> >> >> NAS problem.
> >> >> >> >> > > However one possible implementation of=20
> channel bindings
> >> >> >> >> would allow
> >> >> >> >> > > keys to be distributed prior to the network being
> >> >> >> >> authenticated by
> >> >> >> >> > > the peer.  While the peer may decide to not use a=20
> >> >> >> >> > > network
> >> >> >> >> after it's
> >> >> >> >> > > validated its identity, network entities could retain
> >> >> >> the keying
> >> >> >> >> > > material.
> >> >> >> >> > > There has been much debate on the list as to=20
> whether or
> >> >> >> >> not network
> >> >> >> >> > > entities could maliciously use this keying=20
> material, and
> >> >> >> >> the intent
> >> >> >> >> > > here is to not rehash all that discussion.
> >> >> >> >> > >
> >> >> >> >> > > Question: Should additional text be added to=20
> the problem
> >> >> >> >> statement
> >> >> >> >> > > draft
> >> >> >> >> > >   to require peer authorization for distributing
> >> >> >> keying material?
> >> >> >> >> > >
> >> >> >> >> > > Protocol Implications: If "yes" then a 3-party
> >> >> >> protocol would be
> >> >> >> >> > > need, and would require L2 advertisement of the NAS-ID
> >> >> >> >> and local AAA
> >> >> >> >> > > domain name.  If "no" then channel bindings where
> >> >> >> identities are
> >> >> >> >> > > hashed into the key derivation would be sufficient.
> >> >> >> >> > >
> >> >> >> >> > > --
> >> >> >> >> > > t. charles clancy, ph.d.  <>  tcc@umd.edu  <>=20
> >> >> >> >> > > www.cs.umd.edu/~clancy
> >> >> >> >> > >
> >> >> >> >> > >
> >> >> >> >> > > _______________________________________________
> >> >> >> >> > > 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
> >> >> >> >
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >
> >> >>
> >> >>
> >> >>
> >> >
> >>
> >>
> >>
> >
>=20
>=20
>=20

_______________________________________________
HOKEY mailing list
HOKEY@ietf.org
https://www1.ietf.org/mailman/listinfo/hokey



From hokey-bounces@ietf.org Mon Apr 09 21:15: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 1Hb4xc-0004aO-I8; Mon, 09 Apr 2007 21:15:52 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hb4xb-0004Us-9B
	for hokey@ietf.org; Mon, 09 Apr 2007 21:15:51 -0400
Received: from numenor.qualcomm.com ([129.46.51.58])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hb4xZ-0004sI-TG
	for hokey@ietf.org; Mon, 09 Apr 2007 21:15:51 -0400
Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150])
	by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id
	l3A1FfPg009227
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 9 Apr 2007 18:15:42 -0700
Received: from sanexcas01.na.qualcomm.com (sanexcas01.qualcomm.com
	[172.30.36.175])
	by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id
	l3A1FAKw008079; Mon, 9 Apr 2007 18:15:41 -0700
Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by
	sanexcas01.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 9 Apr 2007 18:15:38 -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
Subject: RE: [HOKEY] consensus call: key distribution security requirement
Date: Mon, 9 Apr 2007 18:15:32 -0700
Message-ID: 
In-Reply-To: <20070405133243.GA18558@steelhead>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [HOKEY] consensus call: key distribution security requirement
Thread-Index: Acd3iFo3WgUfkqFfR7GV7dKszoAFbQDg0BMw
References: <460EB36E.5010604@cs.umd.edu>
	
	<20070404024453.GA18289@steelhead>
	
	<20070405133243.GA18558@steelhead>
From: "Narayanan, Vidya" 
To: "Yoshihiro Ohba" 
X-OriginalArrivalTime: 10 Apr 2007 01:15:38.0574 (UTC)
	FILETIME=[BFC8AEE0:01C77B0D]
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

Hi Yoshi,



>=20
> I don't understand what "many cases" are.  What is "a certain=20
> level of service"?  What do you mean by "is charged for the=20
> same"?  I've read your slides you indicated below (thanks for=20
> the pointer!), but unfortunately, the slides do not contain=20
> detaied explanation on those points.
>=20

As an example, if I was guaranteed 1Mbps and that's what I get and
that's what I pay for, the identity of the entity that gave me 1Mbps may
be irrelevant to me.=20



>=20
> I have specific comments on your slides:
>=20
> Slide 6:
>=20
> "- As long as the peer is satisfied, the identity of the=20
> network entity providing the service is irrelevant"
>=20
> How do you define peer's "satisfaction" from security point of view?
>=20

Again, this is what I've explained above. I may be looking for no
security guarantees from the network - i.e., I either don't care about
data security and exchange data in the clear through that network or do
care about it and use some end-to-end security for my data.=20

> "- If peer is not satisfied or there is a billing issue, it=20
> contacts its home network and tries to get service from some=20
> other node instead"
>=20
> This does not seem to help, since some other node may also be=20
> impersonating.
>=20

It doesn't matter if some entity is impersonating as long as I'm getting
what I want and I'm paying for what I get, in this case. All I'm saying
is that this is a very common case in wireles networks. I can see cases
of enterprise connectivity, where the identity of the node I'm attaching
to is of importance to me.=20

>=20
> Slide 7:
>=20
> "This cannot be detected using any type of channel binding"
>=20
> This is not true.  If an appropriate 3-party key distribution=20
> protocol is used, this can be detected.
>=20

I don't understand how 3-party key distribution is just channel binding.


> "No security properties are lost"
>=20
> Isn't channel binding a security property?
>=20

For anything we call as a "security property", we should be able to
clearly state what is lost when that property is not met. In reality,
for some cases, nothing is lost without channel bindings is the point I
am trying to get at. I don't argue that CB might be important for some
cases - I'm just showing why it is sufficient for CB to be optional.=20

Regards,
Vidya

> Regards,
> Yoshihiro Ohba
>=20
>=20

_______________________________________________
HOKEY mailing list
HOKEY@ietf.org
https://www1.ietf.org/mailman/listinfo/hokey



From hokey-bounces@ietf.org Mon Apr 09 21:55:34 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hb5Zy-00034u-4O; Mon, 09 Apr 2007 21:55:30 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hb5Zw-00034m-Lq
	for hokey@ietf.org; Mon, 09 Apr 2007 21:55:28 -0400
Received: from imx12.toshiba.co.jp ([61.202.160.132])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hb5Zr-0002bO-SN
	for hokey@ietf.org; Mon, 09 Apr 2007 21:55:28 -0400
Received: from wall11.toshiba.co.jp (wall11 [133.199.90.149])
	by imx12.toshiba.co.jp  with ESMTP id l3A1srpb024471;
	Tue, 10 Apr 2007 10:54:53 +0900 (JST)
Received: (from root@localhost) by wall11.toshiba.co.jp  id l3A1sqag006960;
	Tue, 10 Apr 2007 10:54:52 +0900 (JST)
Received: from ovp11.toshiba.co.jp [133.199.90.148] 
	by wall11.toshiba.co.jp with ESMTP id LAA06945;
	Tue, 10 Apr 2007 10:54:52 +0900
Received: from mx2.toshiba.co.jp (localhost [127.0.0.1])
	by ovp11.toshiba.co.jp  with ESMTP id l3A1spq9015290;
	Tue, 10 Apr 2007 10:54:51 +0900 (JST)
Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id l3A1soNj000709;
	Tue, 10 Apr 2007 10:54:51 +0900 (JST)
Received: from steelhead ([172.30.24.105])
	by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 (built
	Apr 28
	2004)) with ESMTPSA id <0JG900JJXENBKV80@mail.po.toshiba.co.jp>; Tue,
	10 Apr 2007 10:54:50 +0900 (JST)
Received: from ohba by steelhead with local (Exim 4.63)
	(envelope-from )	id 1Hb5ZI-0007eA-FT; Mon,
	09 Apr 2007 18:54:48 -0700
Date: Mon, 09 Apr 2007 21:54:48 -0400
From: Yoshihiro Ohba 
Subject: Re: [HOKEY] consensus call: key distribution security requirement
In-reply-to: 
To: "Narayanan, Vidya" 
Message-id: <20070410015448.GH27511@steelhead>
MIME-version: 1.0
Content-type: text/plain; charset=iso-2022-jp
Content-disposition: inline
References: <460EB36E.5010604@cs.umd.edu>
	
	<20070404024453.GA18289@steelhead>
	
	<20070405133243.GA18558@steelhead>
	
User-Agent: Mutt/1.5.13 (2006-08-11)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813
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

On Mon, Apr 09, 2007 at 06:15:32PM -0700, Narayanan, Vidya wrote:
> Hi Yoshi,
> 
> 
> 
> > 
> > I don't understand what "many cases" are.  What is "a certain 
> > level of service"?  What do you mean by "is charged for the 
> > same"?  I've read your slides you indicated below (thanks for 
> > the pointer!), but unfortunately, the slides do not contain 
> > detaied explanation on those points.
> > 
> 
> As an example, if I was guaranteed 1Mbps and that's what I get and
> that's what I pay for, the identity of the entity that gave me 1Mbps may
> be irrelevant to me. 

But this has nothing to do with security properties we are talking about.

> 
> 
> 
> > 
> > I have specific comments on your slides:
> > 
> > Slide 6:
> > 
> > "- As long as the peer is satisfied, the identity of the 
> > network entity providing the service is irrelevant"
> > 
> > How do you define peer's "satisfaction" from security point of view?
> > 
> 
> Again, this is what I've explained above. I may be looking for no
> security guarantees from the network - i.e., I either don't care about
> data security and exchange data in the clear through that network or do
> care about it and use some end-to-end security for my data. 

This sounds like sidetracking...

If what you are saying can justify making channel binding optional
feature for the above reason, why can't we just make link-layer
ciphering optional and recommend use of end-to-end security instead?

> > "- If peer is not satisfied or there is a billing issue, it 
> > contacts its home network and tries to get service from some 
> > other node instead"
> > 
> > This does not seem to help, since some other node may also be 
> > impersonating.
> > 
> 
> It doesn't matter if some entity is impersonating as long as I'm getting
> what I want and I'm paying for what I get, in this case. All I'm saying
> is that this is a very common case in wireles networks. I can see cases
> of enterprise connectivity, where the identity of the node I'm attaching
> to is of importance to me. 

Please see my comment above.

> 
> > 
> > Slide 7:
> > 
> > "This cannot be detected using any type of channel binding"
> > 
> > This is not true.  If an appropriate 3-party key distribution 
> > protocol is used, this can be detected.
> > 
> 
> I don't understand how 3-party key distribution is just channel binding.

3-party key distribution is more than just channel binding, and it
provides channel binding by satisfying certain requirements we listed
in 3party-keydist-ps draft.

> 
> 
> > "No security properties are lost"
> > 
> > Isn't channel binding a security property?
> > 
> 
> For anything we call as a "security property", we should be able to
> clearly state what is lost when that property is not met. In reality,
> for some cases, nothing is lost without channel bindings is the point I
> am trying to get at. I don't argue that CB might be important for some
> cases - I'm just showing why it is sufficient for CB to be optional. 

Without channel binding, a peer may connect to a network which is
different from the intended one, through an impersonating
authenticator.  As a result, the peer may happen to disclose
information that is supposed to be sent to the intended network only,
to the impersonating authenticator, and the impersonating
authenticator can obtain that information.  This is a threat if
channel binding is not provided.

Regards,
Yoshihiro Ohba


> 
> Regards,
> Vidya
> 
> > Regards,
> > Yoshihiro Ohba
> > 
> > 
> 
> 

_______________________________________________
HOKEY mailing list
HOKEY@ietf.org
https://www1.ietf.org/mailman/listinfo/hokey



From hokey-bounces@ietf.org Mon Apr 09 22:09: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 1Hb5n4-0002Ke-RI; Mon, 09 Apr 2007 22:09:02 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hb5n3-0002KT-5A
	for hokey@ietf.org; Mon, 09 Apr 2007 22:09:01 -0400
Received: from numenor.qualcomm.com ([129.46.51.58])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hb5n1-0006xB-OW
	for hokey@ietf.org; Mon, 09 Apr 2007 22:09:01 -0400
Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150])
	by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id
	l3A28peG012607
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 9 Apr 2007 19:08:52 -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
	l3A28pSS016689; Mon, 9 Apr 2007 19:08:51 -0700
Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by
	SANEXCAS03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 9 Apr 2007 19:08:51 -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
Subject: RE: [HOKEY] consensus call: key distribution security requirement
Date: Mon, 9 Apr 2007 19:08:47 -0700
Message-ID: 
In-Reply-To: <20070410015448.GH27511@steelhead>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [HOKEY] consensus call: key distribution security requirement
Thread-Index: Acd7FAVMicbS+2SeT+a5wl321kieYgAADQuA
References: <460EB36E.5010604@cs.umd.edu>
	
	<20070404024453.GA18289@steelhead>
	
	<20070405133243.GA18558@steelhead>
	
	<20070410015448.GH27511@steelhead>
From: "Narayanan, Vidya" 
To: "Yoshihiro Ohba" 
X-OriginalArrivalTime: 10 Apr 2007 02:08:51.0656 (UTC)
	FILETIME=[2F025480:01C77B15]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6
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

=20
> -----Original Message-----
> From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com]=20
> Sent: Monday, April 09, 2007 6:55 PM
> To: Narayanan, Vidya
> Cc: Yoshihiro Ohba; Charles Clancy; hokey@ietf.org
> Subject: Re: [HOKEY] consensus call: key distribution=20
> security requirement
>=20
> On Mon, Apr 09, 2007 at 06:15:32PM -0700, Narayanan, Vidya wrote:
> > Hi Yoshi,
> >=20
> > 
> >=20
> > >=20
> > > I don't understand what "many cases" are.  What is "a=20
> certain level=20
> > > of service"?  What do you mean by "is charged for the=20
> same"?  I've=20
> > > read your slides you indicated below (thanks for the=20
> pointer!), but=20
> > > unfortunately, the slides do not contain detaied explanation on=20
> > > those points.
> > >=20
> >=20
> > As an example, if I was guaranteed 1Mbps and that's what I get and=20
> > that's what I pay for, the identity of the entity that gave=20
> me 1Mbps=20
> > may be irrelevant to me.
>=20
> But this has nothing to do with security properties we are=20
> talking about.

Why not? =20

> >=20
> > 
> >=20
> > >=20
> > > I have specific comments on your slides:
> > >=20
> > > Slide 6:
> > >=20
> > > "- As long as the peer is satisfied, the identity of the network=20
> > > entity providing the service is irrelevant"
> > >=20
> > > How do you define peer's "satisfaction" from security=20
> point of view?
> > >=20
> >=20
> > Again, this is what I've explained above. I may be looking for no=20
> > security guarantees from the network - i.e., I either don't=20
> care about=20
> > data security and exchange data in the clear through that=20
> network or=20
> > do care about it and use some end-to-end security for my data.
>=20
> This sounds like sidetracking...
>=20
> If what you are saying can justify making channel binding=20
> optional feature for the above reason, why can't we just make=20
> link-layer ciphering optional and recommend use of end-to-end=20
> security instead?
>=20

We don't make link-layer ciphering mandatory here at the IETF. If a
network wants to do access control, it does that. EAP may provide the
keys necessary to do that. And, just integrity protection is sufficient
for access control.=20



>=20
> Without channel binding, a peer may connect to a network=20
> which is different from the intended one, through an=20
> impersonating authenticator.  As a result, the peer may=20
> happen to disclose information that is supposed to be sent to=20
> the intended network only, to the impersonating=20
> authenticator, and the impersonating authenticator can obtain=20
> that information.  This is a threat if channel binding is not=20
> provided.
>=20

This seems to be the point of disconnect. This is true when I treat my
data that way selectively - may be true when I want to exchange data in
the clear over an enterprise intranet, because I know I'm attached to an
enterprise intranet. Channel binding may be relevant there and can also
be done more effectively. When I'm attaching to an access point in
Starbucks, I don't care what its identity is; my data is either not
sensitive and I send it or I use end-to-end security for it. And, in
such cases, channel binding is of no use.=20

Vidya

> Regards,
> Yoshihiro Ohba
>=20
>=20
> >=20
> > Regards,
> > Vidya
> >=20
> > > Regards,
> > > Yoshihiro Ohba
> > >=20
> > >=20
> >=20
> >=20
>=20

_______________________________________________
HOKEY mailing list
HOKEY@ietf.org
https://www1.ietf.org/mailman/listinfo/hokey



From hokey-bounces@ietf.org Mon Apr 09 22:19:27 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hb5x5-0002vn-3V; Mon, 09 Apr 2007 22:19:23 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hb5x3-0002uO-92
	for hokey@ietf.org; Mon, 09 Apr 2007 22:19:21 -0400
Received: from mail.ltsnet.net ([65.127.220.12] helo=ltsnet.net)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hb5x0-0008SS-QI
	for hokey@ietf.org; Mon, 09 Apr 2007 22:19:21 -0400
Received: from [127.0.0.1] (office-nat.ltsnet.net [65.127.220.45])
	by ltsnet.net (8.13.8/8.13.5) with ESMTP id l3A23J2u008089;
	Mon, 9 Apr 2007 22:03:21 -0400
Message-ID: <461AF41F.4040707@cs.umd.edu>
Date: Mon, 09 Apr 2007 22:19:11 -0400
From: Charles Clancy 
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: Madjid Nakhjiri 
References: <007201c77af9$6cecc490$2f01a8c0@china.huawei.com>
In-Reply-To: <007201c77af9$6cecc490$2f01a8c0@china.huawei.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 140baa79ca42e6b0e2b4504291346186
Cc: hokey@ietf.org
Subject: [HOKEY] Re: Using an EAP method for HOKEY??: was: consensus call:
 EAP-ER as HOKEY protocol
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 protocols look something like:

  - MSG0: [optional peer<-auth: identity advertisements]
  - MSG1: peer->server: reauth-request
  - MSG2: peer<-server: reauth-response

possible transports:

  - MSG0: id-request, L2 beacon, method, code
  - MSG1: id-response, method, code
  - MSG2: code, success

Proposals:

  - EAP-ER: [L2 beacon], code, code
  - EAP-HR: method, method, success

Major points:

  - MSG0 is required if we do peer authorization, and can also make
    backward compatibility easier
  - All approaches will require either changes or additions to the peer,
    authenticator, and EAP server
  - L2 advertisement of parameters will require L2 support
  - Use of "success" requires redefining the success packet format and
    retransmission characteristics

In general, I think the implementation differences are insignificant. 
Just as id-request/response encoding is just as easy as method-based 
transport from an implementation standpoint, I suspect that method vs 
code transport is equally easy.

Personally I think we should go the direction that's the cleanest, 
adding to standards rather than changing or re-purposing them.  It would 
also be good to avoid changes to L2 (i.e. for MSG0).

-- 
t. charles clancy, ph.d.  <>  tcc@umd.edu  <>  www.cs.umd.edu/~clancy

Madjid Nakhjiri wrote:
> Hi,
> 
> As promised earlier, I am providing an analysis of use of EAP method for
> handover and re-authentication signaling. To me it seems that without
> introducing a new EAP code, one can accomplish the signaling with very
> little change to authenticator state machine, given that the authenticator
> already does receive and transmit AAA attributes along with AAA messages
> encapsulating EAP packets.
> 
> I have called this new method, EAP Handover and re-authentication method
> (EAP-HR), which consists of 3 messages (if you count EAP Success as method
> specific).
> I have shown the 3-party key distribution exchange (KDE) can be carried over
> the EAP-HR messages easily.
> As you can see in most of cases (handover, re-authentication and even in
> some cases for network setup), a trigger is easily available for the
> authenticator to start with EAP-HR Req, just the way EAP-identity starts
> from the authenticator. So the urgent need for peer-initiated messaging and
> hence the need to create new EAP code may go away.
> 
> 
> 
> Peer             authenticator             server
> 	EAP-HR REQ
> 	(DID, AID)
>   <-------------
> 	EAP-HR RESP
>       KDE message 1 and 2 (PID, AID and tokens)
> ------------------------------------------------->
> 		EAP/Success
> 		 (KDE message 3 and 4)
> <---------------------------------------------------
> 
> DID: domain ID (used for creating Domain keys)
> AID: authenticator ID advertised by the authenticator 
> (note this can be done as part of lower layer beacon advertisement), so
> carrying data through EAP-HR Request is not 100% necessary the KDE.
> 
> 
> FAQ
> =====
> 
> Roundtrips: 
> ============
> 1.1 when trigger is available at authenticator
> (assuming authenticator-peer trip~20% of server-peer trip).
> 1.5 when trigger needs to arrive from the server.
> 
> 
> Cases where trigger is available at authenticator
> a) in handover, this is available through a handover request from the peer.
> b) in re-authentication, the authentication/ key status is typically
> available at the authenticator as a result of previous AAA signaling (e.g.
> Session-life-time attribute)
> c) in network setup, the server may send a session-life-time=0 to
> authenticator along with the previous EAP authentication Success, to
> indicate the need to start HOKEY signaling.
> 
> 
> EAP-HR versus EAP identity
> ======================
> I have discussed this with several EAP experts and it seems that using EAP
> Identity request/ response versus using a new EAP method (EAP-HR) are almost
> identical.
> The issue with EAP Identity is that it does not carry data.
> IMO, modifying EAP Identity to carry data is more straight forward than
> creating EAP-HR.
> 
> 
> 
> EAP Success:
> ==========
> It seems that quite a number of people have already backed up the idea of
> modifying EAP success to carry data: people brought up the fact that 2284
> did allow EAP success carrying data and the only reason 3748 banned EAP
> Success from carrying data was the inadequate method independent way of
> carrying data. It seems to me that keys derived from the hierarchy can be
> used to protect the EAP success and its data and this would allow for
> protected result indication as well. 
> 
> The other reason to allow EAP Success carry data is to provide a natural
> extension to the AAA (authorization, etc) signaling that currently does not
> reach beyond the authenticator.
> 
> So with that in mind, I hope we don't rehash the previous emails citing
> sentences from 3748 about EAP Success carrying data...
> 
> 3 Party key distribution (KDE)
> =======================
> I have modified the 3 party key distribution slightly to accomodate the EAP
> method signaling.
> 
>    0  Authenticator to peer: EAP(DAID, DID)
> 
>    1  Peer to Authenticator: EAP((PID, DAID, DID, Np,KNps), [PID, DAID,
>       Np,KNps]Kps)
> 
>    2  Authenticator to Server: AAA(PID, UAID, [PID, UAID]Kas),
>       AAA(EAP((PID, DAID, DID, Np,KNps), [PID, DAID, DID, Np,KNps]Kps))
> 
>    3  Server to Authenticator: AAA({PID,AID,KNpa, KLpa, Kpa}KEas),
>       AAA(EAP(KNpa, KLpa, KNps, [PID, AID, DID, Np+1,KNpa,KLpa,
>       KNps]Kps))
> 
>    4  Authenticator to Peer: EAP(KNpa, KLpa, KNps, [PID, AID, DID, Np+1,
>       KNpa,KLpa, KNps]Kps])
> 
> PID: peer ID.  
>    DID: Domain ID
>    AID: Authenticator ID
>    DAID: Authenticator ID as perceived by the peer (down link ID)
>    UAID: Authenticator ID as perceived by the server (uplink ID)
>    {X}K: X encrypted with key K
>    [X]K: Message Authentication Code over X with key K.
>    X(Y): Y carried with X protocol
>    Kps: A symmetric key shared between peer and Server for signing (IK,
>    provisioned by EAP/HOKEY hierarchy) and identified by KNps.
> 
>    KEps: A symmetric key shared between peer and Server for encryption
>    (CK, provisioning by EAP/HOKEY hierarchy) and identified by KEpsid
> 
>    KEas: A symmetric key shared between authenticator and Server for
>    encryption (provisioned out of band).
> 
>    Kas: A symmetric key between authentication and server for MDCs for
>    signing (provisioned out of band).
> 
> 
>  Kpa: A symmetric key to be shared between peer and authenticator (key
>    to be distributed to authenticator, the MDMSK in this document).  The
>    key is named as KNpa.
> 
>    KLx : Key lifetime for key x
> 
>    KNx: Key name for Key x, e.g.  KENas: key name for KEas
> 
>    Nx : Nonce provided by the party X
> 
> I have provided more the details in a draft. 
> http://www.ietf.org/internet-drafts/draft-nakhjiri-hokey-hierarchy-04.txt
> 
> Regards,
> 
> Madjid
> 
> -----Original Message-----
> From: Charles Clancy [mailto:clancy@cs.umd.edu] 
> Sent: Saturday, March 31, 2007 11:58 AM
> To: hokey@ietf.org
> Subject: [HOKEY] consensus call: EAP-ER as HOKEY protocol
> 
> HOKEY WG,
> 
> The chairs are making a second consensus call request to adopt EAP-ER as 
> a WG document to satisfy our re-auth and hand-off deliverables.  It 
> would serve as a starting point for development of the HOKEY protocol.
> 
> Note that if accepted, it may be split into two WG documents, separating 
> the EAP-ER-Bootstrap into a second set of messages that could be 
> transported by any service to obtain a USRK or DSUSRK.
> 
> Please respond by Friday, April 13.
> 




_______________________________________________
HOKEY mailing list
HOKEY@ietf.org
https://www1.ietf.org/mailman/listinfo/hokey



From hokey-bounces@ietf.org Tue Apr 10 00:32:32 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hb81s-00063t-N2; Tue, 10 Apr 2007 00:32:28 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hb81s-00063m-9Q
	for hokey@ietf.org; Tue, 10 Apr 2007 00:32:28 -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 1Hb81j-0004wy-I3
	for hokey@ietf.org; Tue, 10 Apr 2007 00:32:28 -0400
Received: from localhost (toshi17.tari.toshiba.com [172.30.24.10])
	by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id
	l3A4VjaM045889; Tue, 10 Apr 2007 00:31:45 -0400 (EDT)
	(envelope-from yohba@tari.toshiba.com)
Date: Tue, 10 Apr 2007 00:31:46 -0400
To: "Narayanan, Vidya" 
Subject: Re: [HOKEY] consensus call: key distribution security requirement
Message-ID: <20070410043146.GC29462@steelhead>
References: <460EB36E.5010604@cs.umd.edu>
	
	<20070404024453.GA18289@steelhead>
	
	<20070405133243.GA18558@steelhead>
	
	<20070410015448.GH27511@steelhead>
	
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-2022-jp
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.13 (2006-08-11)
From: Yoshihiro Ohba 
X-Dispatcher: imput version 20050308(IM148)
Lines: 133
X-Spam-Score: -2.4 (--)
X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f
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

On Mon, Apr 09, 2007 at 07:08:47PM -0700, Narayanan, Vidya wrote:
>  
> > -----Original Message-----
> > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] 
> > Sent: Monday, April 09, 2007 6:55 PM
> > To: Narayanan, Vidya
> > Cc: Yoshihiro Ohba; Charles Clancy; hokey@ietf.org
> > Subject: Re: [HOKEY] consensus call: key distribution 
> > security requirement
> > 
> > On Mon, Apr 09, 2007 at 06:15:32PM -0700, Narayanan, Vidya wrote:
> > > Hi Yoshi,
> > > 
> > > 
> > > 
> > > > 
> > > > I don't understand what "many cases" are.  What is "a 
> > certain level 
> > > > of service"?  What do you mean by "is charged for the 
> > same"?  I've 
> > > > read your slides you indicated below (thanks for the 
> > pointer!), but 
> > > > unfortunately, the slides do not contain detaied explanation on 
> > > > those points.
> > > > 
> > > 
> > > As an example, if I was guaranteed 1Mbps and that's what I get and 
> > > that's what I pay for, the identity of the entity that gave 
> > me 1Mbps 
> > > may be irrelevant to me.
> > 
> > But this has nothing to do with security properties we are 
> > talking about.
> 
> Why not?  

Because any security property I know of does not depend on how much
bandwidth is guaranteed.

> 
> > > 
> > > 
> > > 
> > > > 
> > > > I have specific comments on your slides:
> > > > 
> > > > Slide 6:
> > > > 
> > > > "- As long as the peer is satisfied, the identity of the network 
> > > > entity providing the service is irrelevant"
> > > > 
> > > > How do you define peer's "satisfaction" from security 
> > point of view?
> > > > 
> > > 
> > > Again, this is what I've explained above. I may be looking for no 
> > > security guarantees from the network - i.e., I either don't 
> > care about 
> > > data security and exchange data in the clear through that 
> > network or 
> > > do care about it and use some end-to-end security for my data.
> > 
> > This sounds like sidetracking...
> > 
> > If what you are saying can justify making channel binding 
> > optional feature for the above reason, why can't we just make 
> > link-layer ciphering optional and recommend use of end-to-end 
> > security instead?
> > 
> 
> We don't make link-layer ciphering mandatory here at the IETF. If a
> network wants to do access control, it does that. EAP may provide the
> keys necessary to do that. And, just integrity protection is sufficient
> for access control. 

If you are talking about the case in which EAP does not provide keys
(e.g., wired Ethernet access with 802.1X), that is fine.  But as long
as keys are provided for link layer ciphering, I believe channel
binding is an important security property (and also see my comment below).

> 
> 
> 
> > 
> > Without channel binding, a peer may connect to a network 
> > which is different from the intended one, through an 
> > impersonating authenticator.  As a result, the peer may 
> > happen to disclose information that is supposed to be sent to 
> > the intended network only, to the impersonating 
> > authenticator, and the impersonating authenticator can obtain 
> > that information.  This is a threat if channel binding is not 
> > provided.
> > 
> 
> This seems to be the point of disconnect. This is true when I treat my
> data that way selectively - may be true when I want to exchange data in
> the clear over an enterprise intranet, because I know I'm attached to an
> enterprise intranet. Channel binding may be relevant there and can also
> be done more effectively. When I'm attaching to an access point in
> Starbucks, I don't care what its identity is; my data is either not
> sensitive and I send it or I use end-to-end security for it. And, in
> such cases, channel binding is of no use. 

Since Starbucks does not use EAP or link-layer ciphering, and I don't
see your point.

Finally, how your argument on making channel binding optional can fit
draft-housley-aaa-key-mgmt?

Yoshihiro Ohba



> 
> Vidya
> 
> > Regards,
> > Yoshihiro Ohba
> > 
> > 
> > > 
> > > Regards,
> > > Vidya
> > > 
> > > > Regards,
> > > > Yoshihiro Ohba
> > > > 
> > > > 
> > > 
> > > 
> > 
> 
> 

_______________________________________________
HOKEY mailing list
HOKEY@ietf.org
https://www1.ietf.org/mailman/listinfo/hokey



From hokey-bounces@ietf.org Tue Apr 10 11:29: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 1HbIHI-0007hH-A1; Tue, 10 Apr 2007 11:29:04 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HbIHH-0007h8-Cx
	for hokey@ietf.org; Tue, 10 Apr 2007 11:29:03 -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 1HbIHD-0002hD-NZ
	for hokey@ietf.org; Tue, 10 Apr 2007 11:29:03 -0400
Received: from www.trepanning.net (localhost [127.0.0.1])
	by mail1.trepanning.net (Postfix) with ESMTP id E1B131FA6788;
	Tue, 10 Apr 2007 08:28:52 -0700 (PDT)
Received: from 69.12.173.8
	(SquirrelMail authenticated user dharkins@lounge.org)
	by www.trepanning.net with HTTP;
	Tue, 10 Apr 2007 08:28:52 -0700 (PDT)
Message-ID: <46584.69.12.173.8.1176218932.squirrel@www.trepanning.net>
In-Reply-To: 
References: <460EB36E.5010604@cs.umd.edu>
	
	<20070404024453.GA18289@steelhead>
	
	<7030.12.108.168.179.1175729051.squirrel@www.trepanning.net>
	
	<44325.69.12.173.8.1175792579.squirrel@www.trepanning.net>
	
	<33754.69.12.173.8.1175797183.squirrel@www.trepanning.net>
	
	<46386.69.12.173.8.1175877985.squirrel@www.trepanning.net>
	
Date: Tue, 10 Apr 2007 08:28:52 -0700 (PDT)
Subject: RE: [HOKEY] consensus call: key distribution security requirement
From: "Dan Harkins" 
To: "Narayanan, Vidya" 
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: 52e1467c2184c31006318542db5614d5
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



On Mon, April 9, 2007 6:00 pm, Narayanan, Vidya wrote:
[snip]
>>   Perhaps "Channel Binding" isn't a good term to use since it
>> implies something specific (RFC3748). How about "protected
>> exchange"? That is how RFC3748 describes "Channel Binding"
>> anyway. So would something along the lines of this be agreeable?
>>
>>    HOKEY MUST include a protected exchange of context, usage, and
>
> What is the difference between context and usage?

  It's all the cruft you want to bind to the keys that aren't the usage.
Is there some specific VLAN this person is assigned to? Maybe there's a
lifetime associated with this key? I don't know.

  I honestly don't understand the "usage" thing (HOKEY doesn't need to be
a swiss army knife of access protocols) but it's in there so I included
it.

>>    identities
>
> On identities, I believe the exchange may be needed in some cases and
> not in other cases. So, having an optional exchange of identities would
> be sufficient in my view.

  It sounds like you have a particular deployment in mind and it's hard
for that particular deployment to solve this problem so you are saying
that it shoudn't have to. That seems like a bassackwards way to come up
with a protocol.

  Dan.




_______________________________________________
HOKEY mailing list
HOKEY@ietf.org
https://www1.ietf.org/mailman/listinfo/hokey



From hokey-bounces@ietf.org Tue Apr 10 11:30: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 1HbIIb-0008Df-3T; Tue, 10 Apr 2007 11:30:25 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HbIIZ-0008DI-B2
	for hokey@ietf.org; Tue, 10 Apr 2007 11:30:23 -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 1HbIIQ-00038x-Ha
	for hokey@ietf.org; Tue, 10 Apr 2007 11:30:23 -0400
Received: from www.trepanning.net (localhost [127.0.0.1])
	by mail1.trepanning.net (Postfix) with ESMTP id 2B9011FA6788;
	Tue, 10 Apr 2007 08:30:14 -0700 (PDT)
Received: from 69.12.173.8
	(SquirrelMail authenticated user dharkins@lounge.org)
	by www.trepanning.net with HTTP;
	Tue, 10 Apr 2007 08:30:14 -0700 (PDT)
Message-ID: <46585.69.12.173.8.1176219014.squirrel@www.trepanning.net>
In-Reply-To: 
References: <460EB36E.5010604@cs.umd.edu>
	
	<20070404024453.GA18289@steelhead>
	
	<20070405133243.GA18558@steelhead>
	
Date: Tue, 10 Apr 2007 08:30:14 -0700 (PDT)
Subject: RE: [HOKEY] consensus call: key distribution security requirement
From: "Dan Harkins" 
To: "Narayanan, Vidya" 
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: 08170828343bcf1325e4a0fb4584481c
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


  Vidya,

On Mon, April 9, 2007 6:15 pm, Narayanan, Vidya wrote:
> As an example, if I was guaranteed 1Mbps and that's what I get and
> that's what I pay for, the identity of the entity that gave me 1Mbps ma=
y
> be irrelevant to me.

  This sounds like the "evil twins R us" network.

  Dan.




_______________________________________________
HOKEY mailing list
HOKEY@ietf.org
https://www1.ietf.org/mailman/listinfo/hokey



From hokey-bounces@ietf.org Tue Apr 10 14:35: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 1HbLBs-0001Ro-SW; Tue, 10 Apr 2007 14:35:40 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HbLBq-0001R4-Q7
	for hokey@ietf.org; Tue, 10 Apr 2007 14:35:38 -0400
Received: from web54408.mail.yahoo.com ([206.190.49.138])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HbLBp-0001l6-IN
	for hokey@ietf.org; Tue, 10 Apr 2007 14:35:38 -0400
Received: (qmail 40696 invoked by uid 60001); 10 Apr 2007 18:35:37 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com;
	h=Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Message-ID;
	b=5TexcoqYlk5Q6zJfWcqDwiv11uqR2tcZCMetvSGxkXSXfN3Q2QZfU6K6UsVYjlt9jq08Zhmk4r1/nSArioGkeSCPsBZasQUufsYqttYAsk/dGjJ+EWhLbVaFxSfyeY8IIgnvyRFWa8pjJ4vRRYlrovW3o+ndugpDTJ7GKITCRTM=;
Received: from [160.81.2.142] by web54408.mail.yahoo.com via HTTP;
	Tue, 10 Apr 2007 11:35:37 PDT
X-Mailer: YahooMailRC/478 YahooMailWebService/0.7.41.10
Date: Tue, 10 Apr 2007 11:35:37 -0700 (PDT)
From: "M. Vanderveen" 
Subject: Re: [HOKEY] Re: Using an EAP method for HOKEY??: was: consensus call:
	EAP-ER as HOKEY protocol
To: Charles Clancy , Madjid Nakhjiri 
MIME-Version: 1.0
Message-ID: <419294.32713.qm@web54408.mail.yahoo.com>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228
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="===============0628357620=="
Errors-To: hokey-bounces@ietf.org

--===============0628357620==
Content-Type: multipart/alternative; boundary="0-1510175103-1176230137=:32713"

--0-1510175103-1176230137=:32713
Content-Type: text/plain; charset=ascii

Charles ..>
In general, I think the implementation differences are insignificant. 
Just as id-request/response encoding is just as easy as method-based 
transport from an implementation standpoint, I suspect that method vs 
code transport is equally easy.

>> Not sure whether you mean Authenticator implementation of EAP Server implementation, but regarding the latter the industry stand is that it is much easier to add another EAP method (even with EAP Success modified) than to add new codes. I have arrived at this conclusion strictly by asking EAP server implementors/vendors. To me implementation and maintenance ease is important enough to alone drive the decision, all other things being equal as you say. That is, if we wish for our work to see the light of day....

Michaela


       
____________________________________________________________________________________
Now that's room service!  Choose from over 150,000 hotels
in 45,000 destinations on Yahoo! Travel to find your fit.
http://farechase.yahoo.com/promo-generic-14795097
--0-1510175103-1176230137=:32713
Content-Type: text/html; charset=ascii








Charles ..>
In general, I think the implementation differences are insignificant. 
Just as id-request/response encoding is just as easy as method-based 
transport from an implementation standpoint, I suspect that method vs 
code transport is equally easy.

>> Not sure whether you mean Authenticator implementation of EAP Server implementation, but regarding the latter the industry stand is that it is much easier to add another EAP method (even with EAP Success modified) than to add new codes. I have arrived at this conclusion strictly by asking EAP server implementors/vendors. To me implementation and maintenance ease is important enough to alone drive the decision, all other things being equal as you say. That is, if we wish for our work to see the light of day....


 


Michaela




 
Looking for earth-friendly autos? 
 Browse Top Cars by "Green Rating" at Yahoo! Autos' Green Center.  
--0-1510175103-1176230137=:32713--


--===============0628357620==
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

--===============0628357620==--




From hokey-bounces@ietf.org Tue Apr 10 14:37:24 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HbLDU-00033J-6e; Tue, 10 Apr 2007 14:37:20 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HbLDS-00032U-Ex
	for hokey@ietf.org; Tue, 10 Apr 2007 14:37:18 -0400
Received: from usaga01-in.huawei.com ([206.16.17.211])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HbLDP-0004to-SU
	for hokey@ietf.org; Tue, 10 Apr 2007 14:37:18 -0400
Received: from huawei.com (usaga01-in [172.18.4.6])
	by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTP id <0JGA003KVP227B@usaga01-in.huawei.com> for
	hokey@ietf.org; Tue, 10 Apr 2007 11:37:14 -0700 (PDT)
Received: from N737011
	(pool-71-112-121-192.sttlwa.dsl-w.verizon.net [71.112.121.192])
	by usaga01-in.huawei.com
	(iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar  3 2004))
	with ESMTPA id <0JGA0010QP1YKS@usaga01-in.huawei.com> for
	hokey@ietf.org; Tue, 10 Apr 2007 11:37:14 -0700 (PDT)
Date: Tue, 10 Apr 2007 11:37:15 -0700
From: Madjid Nakhjiri 
Subject: RE: [HOKEY] Using an EAP method for HOKEY??: was: consensus call:
	EAP-ER as HOKEY protocol
In-reply-to: <20070409230028.GD27511@steelhead>
To: 'Yoshihiro Ohba' 
Message-id: <003701c77b9f$439bd0d0$2f01a8c0@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962
X-Mailer: Microsoft Office Outlook 11
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Thread-index: Acd6+uQPMewCZzolTzuQprEia9yppgAo9Vxg
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4b66a1e94d7d92973ece9e5da449ff80
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

Yoshi,

Please note the terminology, 

>    3  Server to Authenticator: AAA({PID,AID,KNpa, KLpa, Kpa}KEas),
>       AAA(EAP(KNpa, KLpa, KNps, [PID, AID, DID, Np+1,KNpa,KLpa,
>       KNps]Kps))

the key to be shared by peer and authenticator (Kpa) is carried by AAA
attributes "AAA(...)" to the authenticator and not by EAP Success. Although
AAA message carrying these attributes is sent simultaneous as the AAA
message carrying the EAP success, or possibly the same AAA message carries
the authenticator keys and the EAP success as different attributes. So the
reliability rules for AAA messages apply not the reliability rules for EAP
or EAP success.

R,

Madjid

-----Original Message-----
From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] 
Sent: Monday, April 09, 2007 4:00 PM
To: Madjid Nakhjiri
Cc: 'Charles Clancy'; hokey@ietf.org
Subject: Re: [HOKEY] Using an EAP method for HOKEY??: was: consensus call:
EAP-ER as HOKEY protocol

Madjid,

How can key distribution by piggybacking data with EAP-Success work
when EAP-Success gets lost?  Note that EAP does not retransmit
EAP-Success.

Yoshihiro Ohba


On Mon, Apr 09, 2007 at 03:50:08PM -0700, Madjid Nakhjiri wrote:
> Hi,
> 
> As promised earlier, I am providing an analysis of use of EAP method for
> handover and re-authentication signaling. To me it seems that without
> introducing a new EAP code, one can accomplish the signaling with very
> little change to authenticator state machine, given that the authenticator
> already does receive and transmit AAA attributes along with AAA messages
> encapsulating EAP packets.
> 
> I have called this new method, EAP Handover and re-authentication method
> (EAP-HR), which consists of 3 messages (if you count EAP Success as method
> specific).
> I have shown the 3-party key distribution exchange (KDE) can be carried
over
> the EAP-HR messages easily.
> As you can see in most of cases (handover, re-authentication and even in
> some cases for network setup), a trigger is easily available for the
> authenticator to start with EAP-HR Req, just the way EAP-identity starts
> from the authenticator. So the urgent need for peer-initiated messaging
and
> hence the need to create new EAP code may go away.
> 
> 
> 
> Peer             authenticator             server
> 	EAP-HR REQ
> 	(DID, AID)
>   <-------------
> 	EAP-HR RESP
>       KDE message 1 and 2 (PID, AID and tokens)
> ------------------------------------------------->
> 		EAP/Success
> 		 (KDE message 3 and 4)
> <---------------------------------------------------
> 
> DID: domain ID (used for creating Domain keys)
> AID: authenticator ID advertised by the authenticator 
> (note this can be done as part of lower layer beacon advertisement), so
> carrying data through EAP-HR Request is not 100% necessary the KDE.
> 
> 
> FAQ
> =====
> 
> Roundtrips: 
> ============
> 1.1 when trigger is available at authenticator
> (assuming authenticator-peer trip~20% of server-peer trip).
> 1.5 when trigger needs to arrive from the server.
> 
> 
> Cases where trigger is available at authenticator
> a) in handover, this is available through a handover request from the
peer.
> b) in re-authentication, the authentication/ key status is typically
> available at the authenticator as a result of previous AAA signaling (e.g.
> Session-life-time attribute)
> c) in network setup, the server may send a session-life-time=0 to
> authenticator along with the previous EAP authentication Success, to
> indicate the need to start HOKEY signaling.
> 
> 
> EAP-HR versus EAP identity
> ======================
> I have discussed this with several EAP experts and it seems that using EAP
> Identity request/ response versus using a new EAP method (EAP-HR) are
almost
> identical.
> The issue with EAP Identity is that it does not carry data.
> IMO, modifying EAP Identity to carry data is more straight forward than
> creating EAP-HR.
> 
> 
> 
> EAP Success:
> ==========
> It seems that quite a number of people have already backed up the idea of
> modifying EAP success to carry data: people brought up the fact that 2284
> did allow EAP success carrying data and the only reason 3748 banned EAP
> Success from carrying data was the inadequate method independent way of
> carrying data. It seems to me that keys derived from the hierarchy can be
> used to protect the EAP success and its data and this would allow for
> protected result indication as well. 
> 
> The other reason to allow EAP Success carry data is to provide a natural
> extension to the AAA (authorization, etc) signaling that currently does
not
> reach beyond the authenticator.
> 
> So with that in mind, I hope we don't rehash the previous emails citing
> sentences from 3748 about EAP Success carrying data...
> 
> 3 Party key distribution (KDE)
> =======================
> I have modified the 3 party key distribution slightly to accomodate the
EAP
> method signaling.
> 
>    0  Authenticator to peer: EAP(DAID, DID)
> 
>    1  Peer to Authenticator: EAP((PID, DAID, DID, Np,KNps), [PID, DAID,
>       Np,KNps]Kps)
> 
>    2  Authenticator to Server: AAA(PID, UAID, [PID, UAID]Kas),
>       AAA(EAP((PID, DAID, DID, Np,KNps), [PID, DAID, DID, Np,KNps]Kps))
> 
>    3  Server to Authenticator: AAA({PID,AID,KNpa, KLpa, Kpa}KEas),
>       AAA(EAP(KNpa, KLpa, KNps, [PID, AID, DID, Np+1,KNpa,KLpa,
>       KNps]Kps))
> 
>    4  Authenticator to Peer: EAP(KNpa, KLpa, KNps, [PID, AID, DID, Np+1,
>       KNpa,KLpa, KNps]Kps])
> 
> PID: peer ID.  
>    DID: Domain ID
>    AID: Authenticator ID
>    DAID: Authenticator ID as perceived by the peer (down link ID)
>    UAID: Authenticator ID as perceived by the server (uplink ID)
>    {X}K: X encrypted with key K
>    [X]K: Message Authentication Code over X with key K.
>    X(Y): Y carried with X protocol
>    Kps: A symmetric key shared between peer and Server for signing (IK,
>    provisioned by EAP/HOKEY hierarchy) and identified by KNps.
> 
>    KEps: A symmetric key shared between peer and Server for encryption
>    (CK, provisioning by EAP/HOKEY hierarchy) and identified by KEpsid
> 
>    KEas: A symmetric key shared between authenticator and Server for
>    encryption (provisioned out of band).
> 
>    Kas: A symmetric key between authentication and server for MDCs for
>    signing (provisioned out of band).
> 
> 
>  Kpa: A symmetric key to be shared between peer and authenticator (key
>    to be distributed to authenticator, the MDMSK in this document).  The
>    key is named as KNpa.
> 
>    KLx : Key lifetime for key x
> 
>    KNx: Key name for Key x, e.g.  KENas: key name for KEas
> 
>    Nx : Nonce provided by the party X
> 
> I have provided more the details in a draft. 
> http://www.ietf.org/internet-drafts/draft-nakhjiri-hokey-hierarchy-04.txt
> 
> Regards,
> 
> Madjid
> 
> -----Original Message-----
> From: Charles Clancy [mailto:clancy@cs.umd.edu] 
> Sent: Saturday, March 31, 2007 11:58 AM
> To: hokey@ietf.org
> Subject: [HOKEY] consensus call: EAP-ER as HOKEY protocol
> 
> HOKEY WG,
> 
> The chairs are making a second consensus call request to adopt EAP-ER as 
> a WG document to satisfy our re-auth and hand-off deliverables.  It 
> would serve as a starting point for development of the HOKEY protocol.
> 
> Note that if accepted, it may be split into two WG documents, separating 
> the EAP-ER-Bootstrap into a second set of messages that could be 
> transported by any service to obtain a USRK or DSUSRK.
> 
> Please respond by Friday, April 13.
> 
> -- 
> t. charles clancy, ph.d.  <>  tcc@umd.edu  <>  www.cs.umd.edu/~clancy
> 
> 
> _______________________________________________
> 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 Tue Apr 10 18:47: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 1HbP7X-0002hm-6F; Tue, 10 Apr 2007 18:47:27 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HbP7W-0002hh-48
	for hokey@ietf.org; Tue, 10 Apr 2007 18:47:26 -0400
Received: from usaga01-in.huawei.com ([206.16.17.211])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbP7U-0003b8-QE
	for hokey@ietf.org; Tue, 10 Apr 2007 18:47:26 -0400
Received: from huawei.com (usaga01-in [172.18.4.6])
	by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTP id <0JGB005WA0N03J@usaga01-in.huawei.com> for
	hokey@ietf.org; Tue, 10 Apr 2007 15:47:24 -0700 (PDT)
Received: from N737011
	(pool-71-112-121-192.sttlwa.dsl-w.verizon.net [71.112.121.192])
	by usaga01-in.huawei.com
	(iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar  3 2004))
	with ESMTPA id <0JGB00HU30MVG5@usaga01-in.huawei.com> for
	hokey@ietf.org; Tue, 10 Apr 2007 15:47:24 -0700 (PDT)
Date: Tue, 10 Apr 2007 15:47:24 -0700
From: Madjid Nakhjiri 
Subject: RE: [HOKEY] consensus call: key distribution security requirement
In-reply-to: <46145077.5020000@cs.umd.edu>
To: 'Charles Clancy' , hokey@ietf.org
Message-id: <008801c77bc2$356d83f0$2f01a8c0@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962
X-Mailer: Microsoft Office Outlook 11
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Thread-index: Acd3GQVKvZZujK4+RtW+w/H1I+dKFwEqLCog
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15
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, 

I am still catching up on my emails. By eliminating B you are introducing
the vulnerability to the lying NAS problem. So I personally never saw adding
B as a peer consent thing, but rather as part of channel binding. This was
part of the channel binding solution I presented in SJ even.

 I don't really see a big problem with peer knowing the authenticator ID, it
can either go as part of the EAP request message or as part of L2 beacon
carrying higher layer network data. 802.21 MIH information server is
supposed to carry all kinds of network data to the mobiles...

R,

Madjid

-----Original Message-----
From: Charles Clancy [mailto:clancy@cs.umd.edu] 
Sent: Wednesday, April 04, 2007 6:27 PM
To: hokey@ietf.org
Subject: Re: [HOKEY] consensus call: key distribution security requirement

All,

I think we need to look at the protocols.  To compare...

3-party protocol (Dan's proposal, slightly simplified assuming AAA 
provides the necessary transport security):

    1) A->B: A, {A, B, Na}Kas
    2) B->S: A, B, {A, B, Na}Kas
    3) S->B: {B, Na}Kas, {A, Kab}Kbs
    4) B->A: {B, Na}Kas

EAP-ER (translated to above notation and assuming AAA transport):

    1) A->B: A, {A, Na}Kas
    2) B->S: A, B, {A, Na}Kas
    3) S->B: {Na}Kas, {Kab}Kbs
    4) B->A: {Na}Kas

EAP-ER+CB (my proposal for adding channel binding to EAP-ER):

    1) A->B: A, {A, Na}Kas
    2) B->S: A, B, {A, Na}Kas
    3) S->B: {B, Na}Kas, {A, Kab}Kbs
    4) B->A: {B, Na}Kas

So, we've added "A" and "B" in messages 3 and 4, but not added "B" in 
message 1.  I feel this satisfies everything *but* peer consent, and 
doesn't require A to know "B" at the beginning.

-- 
t. charles clancy, ph.d.  |  tcc@umd.edu  |  www.cs.umd.edu/~clancy


_______________________________________________
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 Apr 10 18:55: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 1HbPEv-0006jl-Iu; Tue, 10 Apr 2007 18:55:05 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HbPEu-0006ij-CV
	for hokey@ietf.org; Tue, 10 Apr 2007 18:55:04 -0400
Received: from usaga01-in.huawei.com ([206.16.17.211])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbPDO-0004rw-SC
	for hokey@ietf.org; Tue, 10 Apr 2007 18:53:32 -0400
Received: from huawei.com (usaga01-in [172.18.4.6])
	by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTP id <0JGB005L50X63J@usaga01-in.huawei.com> for
	hokey@ietf.org; Tue, 10 Apr 2007 15:53:30 -0700 (PDT)
Received: from N737011
	(pool-71-112-121-192.sttlwa.dsl-w.verizon.net [71.112.121.192])
	by usaga01-in.huawei.com
	(iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar  3 2004))
	with ESMTPA id <0JGB00HCC0X2G5@usaga01-in.huawei.com> for
	hokey@ietf.org; Tue, 10 Apr 2007 15:53:30 -0700 (PDT)
Date: Tue, 10 Apr 2007 15:53:31 -0700
From: Madjid Nakhjiri 
Subject: RE: [HOKEY] consensus call: key distribution security requirement
In-reply-to: <55084.63.239.69.1.1175785977.squirrel@webmail.cs.umd.edu>
To: 'Charles Clancy' ,
	'Yoshihiro Ohba' 
Message-id: <008901c77bc3$10261980$2f01a8c0@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962
X-Mailer: Microsoft Office Outlook 11
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Thread-index: Acd3lSlLb9YRGsBgRL2msjVkSuUp5AELZ92A
X-Spam-Score: 0.0 (/)
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

When B is the identity of the authenticator used in derivation of
per-authenticator master keys (I called it MDMSK for mobility domain MSK)
from HRK, then both peer and HOKEY server need to use the same B in the
derivation, otherwise everything will fall apart. Now whether B is SSID or
something else, it must be recognizable by the HOKEY server.

Madjid

-----Original Message-----
From: Charles Clancy [mailto:clancy@cs.umd.edu] 
Sent: Thursday, April 05, 2007 8:13 AM
To: Yoshihiro Ohba
Cc: hokey@ietf.org
Subject: Re: [HOKEY] consensus call: key distribution security requirement

>> EAP-ER+CB (my proposal for adding channel binding to EAP-ER):
>>
>>    1) A->B: A, {A, Na}Kas
>>    2) B->S: A, B, {A, Na}Kas
>>    3) S->B: {B, Na}Kas, {A, Kab}Kbs
>>    4) B->A: {B, Na}Kas
>>
>> So, we've added "A" and "B" in messages 3 and 4, but not added "B" in
>> message 1.  I feel this satisfies everything *but* peer consent, and
>> doesn't require A to know "B" at the beginning.
>
> If step 3) and step 4) need to happen immediately after step 2), I
> think peer consent requirement is satisfied in your proposal.

The peer has consented that a key should be derived, but did not securely
specify "B" as the recipient of that key.  In message #4, the peer is
informed the recipient was "B".

> On the
> other hand, this does not exempt NAS-ID from being advertised by lower
> layer.

Correct.  However, if the peer doesn't care about the identity of the
network, then he can always accept the key without comparing "B" to
something advertised at L2.

I imagine that in many cases, the identity of "B" is important -- for
example in a WiFi network, where "B" could equal the SSID.  However in a
cellular network, you many not care whose network you're connecting to, so
long as they have the proper roaming relationship with your provider.  In
that case, perhaps checking "B" is less important.

I think this approach is the most flexible.

-- 
t. charles clancy, ph.d.  <>  tcc@umd.edu  <>  www.cs.umd.edu/~clancy


_______________________________________________
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 Apr 10 19:01:44 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HbPLM-0000W9-Ui; Tue, 10 Apr 2007 19:01:44 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HbPLL-0000W4-Do
	for hokey@ietf.org; Tue, 10 Apr 2007 19:01:43 -0400
Received: from usaga01-in.huawei.com ([206.16.17.211])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbPLK-0006UP-6A
	for hokey@ietf.org; Tue, 10 Apr 2007 19:01:43 -0400
Received: from huawei.com (usaga01-in [172.18.4.6])
	by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTP id <0JGB005G01AT3J@usaga01-in.huawei.com> for
	hokey@ietf.org; Tue, 10 Apr 2007 16:01:42 -0700 (PDT)
Received: from N737011
	(pool-71-112-121-192.sttlwa.dsl-w.verizon.net [71.112.121.192])
	by usaga01-in.huawei.com
	(iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar  3 2004))
	with ESMTPA id <0JGB00HZS1AOG5@usaga01-in.huawei.com> for
	hokey@ietf.org; Tue, 10 Apr 2007 16:01:41 -0700 (PDT)
Date: Tue, 10 Apr 2007 16:01:41 -0700
From: Madjid Nakhjiri 
Subject: RE: [HOKEY] consensus call: key distribution security requirement
In-reply-to: 
To: "'Narayanan, Vidya'" ,
	'Yoshihiro Ohba' 
Message-id: <008a01c77bc4$348004c0$2f01a8c0@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962
X-Mailer: Microsoft Office Outlook 11
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Thread-index: Acd7FAVMicbS+2SeT+a5wl321kieYgAADQuAACvqP+A=
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

Madjid>>because, I thought we are worried about the threat of domino effect
for wireless link security (which is between a peer and a specific point of
attachment).

Frankly, I am surprised by the poorness of the example that is given...


> > As an example, if I was guaranteed 1Mbps and that's what I get and 
> > that's what I pay for, the identity of the entity that gave 
> me 1Mbps 
> > may be irrelevant to me.
> 
> But this has nothing to do with security properties we are 
> talking about.

Why not?  

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 Apr 10 19:45: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 1HbQ22-0005S0-3e; Tue, 10 Apr 2007 19:45:50 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HbQ1z-0005P1-LM
	for hokey@ietf.org; Tue, 10 Apr 2007 19:45:47 -0400
Received: from usaga01-in.huawei.com ([206.16.17.211])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbQ1w-00008T-Oo
	for hokey@ietf.org; Tue, 10 Apr 2007 19:45:47 -0400
Received: from huawei.com (usaga01-in [172.18.4.6])
	by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTP id <0JGB005QH3C83J@usaga01-in.huawei.com> for
	hokey@ietf.org; Tue, 10 Apr 2007 16:45:44 -0700 (PDT)
Received: from N737011
	(pool-71-112-121-192.sttlwa.dsl-w.verizon.net [71.112.121.192])
	by usaga01-in.huawei.com
	(iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar  3 2004))
	with ESMTPA id <0JGB00H5I3C4G5@usaga01-in.huawei.com> for
	hokey@ietf.org; Tue, 10 Apr 2007 16:45:44 -0700 (PDT)
Date: Tue, 10 Apr 2007 16:45:45 -0700
From: Madjid Nakhjiri 
In-reply-to: <461AF41F.4040707@cs.umd.edu>
To: 'Charles Clancy' 
Message-id: <009d01c77bca$5c23d190$2f01a8c0@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962
X-Mailer: Microsoft Office Outlook 11
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Thread-index: Acd7Fp754f1DSkWiQmq/S/OGOtVstwAsuCYg
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f0b5a4216bfa030ed8a6f68d1833f8ae
Cc: hokey@ietf.org
Subject: [HOKEY] RE: Using an EAP method for HOKEY??: was: consensus call:
 EAP-ER as HOKEY protocol
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 the quick summary. Only one small nit: MSG1 for HR is actually a
response.

Wrt your comment on not changing or repurposing the existing specs, adding
data to EAP Success won't really change authenticators as I mentioned in my
email to Yoshi. I don't think anybody said that we can do HOKEY without
changing peer or server, we are just trying to minimize impact on
authenticators. Furthermore, as Avi mentioned that is a useful provisioning
feature.

If however we feel that is too much of a change, we may (as Hao suggested)
create a new modified EAP Success code that accommodates the new things we
want. That may be the cleanest way with the least authenticator impact.


R,

Madjid

-----Original Message-----
From: Charles Clancy [mailto:clancy@cs.umd.edu] 
Sent: Monday, April 09, 2007 7:19 PM
To: Madjid Nakhjiri
Cc: hokey@ietf.org
Subject: Re: Using an EAP method for HOKEY??: was: consensus call: EAP-ER as
HOKEY protocol

All the protocols look something like:

  - MSG0: [optional peer<-auth: identity advertisements]
  - MSG1: peer->server: reauth-request
  - MSG2: peer<-server: reauth-response

possible transports:

  - MSG0: id-request, L2 beacon, method, code
  - MSG1: id-response, method, code
  - MSG2: code, success

Proposals:

  - EAP-ER: [L2 beacon], code, code
  - EAP-HR: method, method, success

Major points:

  - MSG0 is required if we do peer authorization, and can also make
    backward compatibility easier
  - All approaches will require either changes or additions to the peer,
    authenticator, and EAP server
  - L2 advertisement of parameters will require L2 support
  - Use of "success" requires redefining the success packet format and
    retransmission characteristics

In general, I think the implementation differences are insignificant. 
Just as id-request/response encoding is just as easy as method-based 
transport from an implementation standpoint, I suspect that method vs 
code transport is equally easy.

Personally I think we should go the direction that's the cleanest, 
adding to standards rather than changing or re-purposing them.  It would 
also be good to avoid changes to L2 (i.e. for MSG0).

-- 
t. charles clancy, ph.d.  <>  tcc@umd.edu  <>  www.cs.umd.edu/~clancy

Madjid Nakhjiri wrote:
> Hi,
> 
> As promised earlier, I am providing an analysis of use of EAP method for
> handover and re-authentication signaling. To me it seems that without
> introducing a new EAP code, one can accomplish the signaling with very
> little change to authenticator state machine, given that the authenticator
> already does receive and transmit AAA attributes along with AAA messages
> encapsulating EAP packets.
> 
> I have called this new method, EAP Handover and re-authentication method
> (EAP-HR), which consists of 3 messages (if you count EAP Success as method
> specific).
> I have shown the 3-party key distribution exchange (KDE) can be carried
over
> the EAP-HR messages easily.
> As you can see in most of cases (handover, re-authentication and even in
> some cases for network setup), a trigger is easily available for the
> authenticator to start with EAP-HR Req, just the way EAP-identity starts
> from the authenticator. So the urgent need for peer-initiated messaging
and
> hence the need to create new EAP code may go away.
> 
> 
> 
> Peer             authenticator             server
> 	EAP-HR REQ
> 	(DID, AID)
>   <-------------
> 	EAP-HR RESP
>       KDE message 1 and 2 (PID, AID and tokens)
> ------------------------------------------------->
> 		EAP/Success
> 		 (KDE message 3 and 4)
> <---------------------------------------------------
> 
> DID: domain ID (used for creating Domain keys)
> AID: authenticator ID advertised by the authenticator 
> (note this can be done as part of lower layer beacon advertisement), so
> carrying data through EAP-HR Request is not 100% necessary the KDE.
> 
> 
> FAQ
> =====
> 
> Roundtrips: 
> ============
> 1.1 when trigger is available at authenticator
> (assuming authenticator-peer trip~20% of server-peer trip).
> 1.5 when trigger needs to arrive from the server.
> 
> 
> Cases where trigger is available at authenticator
> a) in handover, this is available through a handover request from the
peer.
> b) in re-authentication, the authentication/ key status is typically
> available at the authenticator as a result of previous AAA signaling (e.g.
> Session-life-time attribute)
> c) in network setup, the server may send a session-life-time=0 to
> authenticator along with the previous EAP authentication Success, to
> indicate the need to start HOKEY signaling.
> 
> 
> EAP-HR versus EAP identity
> ======================
> I have discussed this with several EAP experts and it seems that using EAP
> Identity request/ response versus using a new EAP method (EAP-HR) are
almost
> identical.
> The issue with EAP Identity is that it does not carry data.
> IMO, modifying EAP Identity to carry data is more straight forward than
> creating EAP-HR.
> 
> 
> 
> EAP Success:
> ==========
> It seems that quite a number of people have already backed up the idea of
> modifying EAP success to carry data: people brought up the fact that 2284
> did allow EAP success carrying data and the only reason 3748 banned EAP
> Success from carrying data was the inadequate method independent way of
> carrying data. It seems to me that keys derived from the hierarchy can be
> used to protect the EAP success and its data and this would allow for
> protected result indication as well. 
> 
> The other reason to allow EAP Success carry data is to provide a natural
> extension to the AAA (authorization, etc) signaling that currently does
not
> reach beyond the authenticator.
> 
> So with that in mind, I hope we don't rehash the previous emails citing
> sentences from 3748 about EAP Success carrying data...
> 
> 3 Party key distribution (KDE)
> =======================
> I have modified the 3 party key distribution slightly to accomodate the
EAP
> method signaling.
> 
>    0  Authenticator to peer: EAP(DAID, DID)
> 
>    1  Peer to Authenticator: EAP((PID, DAID, DID, Np,KNps), [PID, DAID,
>       Np,KNps]Kps)
> 
>    2  Authenticator to Server: AAA(PID, UAID, [PID, UAID]Kas),
>       AAA(EAP((PID, DAID, DID, Np,KNps), [PID, DAID, DID, Np,KNps]Kps))
> 
>    3  Server to Authenticator: AAA({PID,AID,KNpa, KLpa, Kpa}KEas),
>       AAA(EAP(KNpa, KLpa, KNps, [PID, AID, DID, Np+1,KNpa,KLpa,
>       KNps]Kps))
> 
>    4  Authenticator to Peer: EAP(KNpa, KLpa, KNps, [PID, AID, DID, Np+1,
>       KNpa,KLpa, KNps]Kps])
> 
> PID: peer ID.  
>    DID: Domain ID
>    AID: Authenticator ID
>    DAID: Authenticator ID as perceived by the peer (down link ID)
>    UAID: Authenticator ID as perceived by the server (uplink ID)
>    {X}K: X encrypted with key K
>    [X]K: Message Authentication Code over X with key K.
>    X(Y): Y carried with X protocol
>    Kps: A symmetric key shared between peer and Server for signing (IK,
>    provisioned by EAP/HOKEY hierarchy) and identified by KNps.
> 
>    KEps: A symmetric key shared between peer and Server for encryption
>    (CK, provisioning by EAP/HOKEY hierarchy) and identified by KEpsid
> 
>    KEas: A symmetric key shared between authenticator and Server for
>    encryption (provisioned out of band).
> 
>    Kas: A symmetric key between authentication and server for MDCs for
>    signing (provisioned out of band).
> 
> 
>  Kpa: A symmetric key to be shared between peer and authenticator (key
>    to be distributed to authenticator, the MDMSK in this document).  The
>    key is named as KNpa.
> 
>    KLx : Key lifetime for key x
> 
>    KNx: Key name for Key x, e.g.  KENas: key name for KEas
> 
>    Nx : Nonce provided by the party X
> 
> I have provided more the details in a draft. 
> http://www.ietf.org/internet-drafts/draft-nakhjiri-hokey-hierarchy-04.txt
> 
> Regards,
> 
> Madjid
> 
> -----Original Message-----
> From: Charles Clancy [mailto:clancy@cs.umd.edu] 
> Sent: Saturday, March 31, 2007 11:58 AM
> To: hokey@ietf.org
> Subject: [HOKEY] consensus call: EAP-ER as HOKEY protocol
> 
> HOKEY WG,
> 
> The chairs are making a second consensus call request to adopt EAP-ER as 
> a WG document to satisfy our re-auth and hand-off deliverables.  It 
> would serve as a starting point for development of the HOKEY protocol.
> 
> Note that if accepted, it may be split into two WG documents, separating 
> the EAP-ER-Bootstrap into a second set of messages that could be 
> transported by any service to obtain a USRK or DSUSRK.
> 
> Please respond by Friday, April 13.
> 






_______________________________________________
HOKEY mailing list
HOKEY@ietf.org
https://www1.ietf.org/mailman/listinfo/hokey



From hokey-bounces@ietf.org Tue Apr 10 20:02:11 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HbQHr-0005ey-Cs; Tue, 10 Apr 2007 20:02:11 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HbQHq-0005es-0Y
	for hokey@ietf.org; Tue, 10 Apr 2007 20:02:10 -0400
Received: from inet-tsb5.toshiba.co.jp ([202.33.96.24])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbQHi-0005Mc-4k
	for hokey@ietf.org; Tue, 10 Apr 2007 20:02:09 -0400
Received: from tsb-wall.toshiba.co.jp ([133.199.160.134])
	by inet-tsb5.toshiba.co.jp  with ESMTP id l3B01fbv009229;
	Wed, 11 Apr 2007 09:01:41 +0900 (JST)
Received: (from root@localhost) by tsb-wall.toshiba.co.jp  id l3B01fjZ026610;
	Wed, 11 Apr 2007 09:01:41 +0900 (JST)
Received: from ovp1.toshiba.co.jp [133.199.192.124] 
	by tsb-wall.toshiba.co.jp with ESMTP id KAA26609;
	Wed, 11 Apr 2007 09:01:41 +0900
Received: from mx.toshiba.co.jp (localhost [127.0.0.1])
	by ovp1.toshiba.co.jp  with ESMTP id l3B01fXZ019582;
	Wed, 11 Apr 2007 09:01:41 +0900 (JST)
Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id l3B01dK4003684;
	Wed, 11 Apr 2007 09:01:39 +0900 (JST)
Received: from steelhead ([172.30.24.105])
	by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 (built
	Apr 28
	2004)) with ESMTPSA id <0JGB00LUT42OKA60@mail.po.toshiba.co.jp>; Wed,
	11 Apr 2007 09:01:39 +0900 (JST)
Received: from ohba by steelhead with local (Exim 4.63)
	(envelope-from )	id 1HbQHJ-0006bA-Qg; Tue,
	10 Apr 2007 17:01:37 -0700
Date: Tue, 10 Apr 2007 20:01:37 -0400
From: Yoshihiro Ohba 
Subject: Re: [HOKEY] Using an EAP method for HOKEY??: was: consensus call:
	EAP-ER as HOKEY protocol
In-reply-to: <003701c77b9f$439bd0d0$2f01a8c0@china.huawei.com>
To: Madjid Nakhjiri 
Message-id: <20070411000137.GB24740@steelhead>
MIME-version: 1.0
Content-type: text/plain; charset=iso-2022-jp
Content-disposition: inline
References: <20070409230028.GD27511@steelhead>
	<003701c77b9f$439bd0d0$2f01a8c0@china.huawei.com>
User-Agent: Mutt/1.5.13 (2006-08-11)
X-Spam-Score: 0.0 (/)
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: ,
	
Errors-To: hokey-bounces@ietf.org

Madjid,

I was not mentioning server to authenticator part.  I was mentioning
authenticator to peer part.  I believe message 4 (which uses
EAP-Success in your proposal, right?) requires reliable delivery.

Yoshihiro Ohba


On Tue, Apr 10, 2007 at 11:37:15AM -0700, Madjid Nakhjiri wrote:
> Yoshi,
> 
> Please note the terminology, 
> 
> >    3  Server to Authenticator: AAA({PID,AID,KNpa, KLpa, Kpa}KEas),
> >       AAA(EAP(KNpa, KLpa, KNps, [PID, AID, DID, Np+1,KNpa,KLpa,
> >       KNps]Kps))
> 
> the key to be shared by peer and authenticator (Kpa) is carried by AAA
> attributes "AAA(...)" to the authenticator and not by EAP Success. Although
> AAA message carrying these attributes is sent simultaneous as the AAA
> message carrying the EAP success, or possibly the same AAA message carries
> the authenticator keys and the EAP success as different attributes. So the
> reliability rules for AAA messages apply not the reliability rules for EAP
> or EAP success.
> 
> R,
> 
> Madjid
> 
> -----Original Message-----
> From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] 
> Sent: Monday, April 09, 2007 4:00 PM
> To: Madjid Nakhjiri
> Cc: 'Charles Clancy'; hokey@ietf.org
> Subject: Re: [HOKEY] Using an EAP method for HOKEY??: was: consensus call:
> EAP-ER as HOKEY protocol
> 
> Madjid,
> 
> How can key distribution by piggybacking data with EAP-Success work
> when EAP-Success gets lost?  Note that EAP does not retransmit
> EAP-Success.
> 
> Yoshihiro Ohba
> 
> 
> On Mon, Apr 09, 2007 at 03:50:08PM -0700, Madjid Nakhjiri wrote:
> > Hi,
> > 
> > As promised earlier, I am providing an analysis of use of EAP method for
> > handover and re-authentication signaling. To me it seems that without
> > introducing a new EAP code, one can accomplish the signaling with very
> > little change to authenticator state machine, given that the authenticator
> > already does receive and transmit AAA attributes along with AAA messages
> > encapsulating EAP packets.
> > 
> > I have called this new method, EAP Handover and re-authentication method
> > (EAP-HR), which consists of 3 messages (if you count EAP Success as method
> > specific).
> > I have shown the 3-party key distribution exchange (KDE) can be carried
> over
> > the EAP-HR messages easily.
> > As you can see in most of cases (handover, re-authentication and even in
> > some cases for network setup), a trigger is easily available for the
> > authenticator to start with EAP-HR Req, just the way EAP-identity starts
> > from the authenticator. So the urgent need for peer-initiated messaging
> and
> > hence the need to create new EAP code may go away.
> > 
> > 
> > 
> > Peer             authenticator             server
> > 	EAP-HR REQ
> > 	(DID, AID)
> >   <-------------
> > 	EAP-HR RESP
> >       KDE message 1 and 2 (PID, AID and tokens)
> > ------------------------------------------------->
> > 		EAP/Success
> > 		 (KDE message 3 and 4)
> > <---------------------------------------------------
> > 
> > DID: domain ID (used for creating Domain keys)
> > AID: authenticator ID advertised by the authenticator 
> > (note this can be done as part of lower layer beacon advertisement), so
> > carrying data through EAP-HR Request is not 100% necessary the KDE.
> > 
> > 
> > FAQ
> > =====
> > 
> > Roundtrips: 
> > ============
> > 1.1 when trigger is available at authenticator
> > (assuming authenticator-peer trip~20% of server-peer trip).
> > 1.5 when trigger needs to arrive from the server.
> > 
> > 
> > Cases where trigger is available at authenticator
> > a) in handover, this is available through a handover request from the
> peer.
> > b) in re-authentication, the authentication/ key status is typically
> > available at the authenticator as a result of previous AAA signaling (e.g.
> > Session-life-time attribute)
> > c) in network setup, the server may send a session-life-time=0 to
> > authenticator along with the previous EAP authentication Success, to
> > indicate the need to start HOKEY signaling.
> > 
> > 
> > EAP-HR versus EAP identity
> > ======================
> > I have discussed this with several EAP experts and it seems that using EAP
> > Identity request/ response versus using a new EAP method (EAP-HR) are
> almost
> > identical.
> > The issue with EAP Identity is that it does not carry data.
> > IMO, modifying EAP Identity to carry data is more straight forward than
> > creating EAP-HR.
> > 
> > 
> > 
> > EAP Success:
> > ==========
> > It seems that quite a number of people have already backed up the idea of
> > modifying EAP success to carry data: people brought up the fact that 2284
> > did allow EAP success carrying data and the only reason 3748 banned EAP
> > Success from carrying data was the inadequate method independent way of
> > carrying data. It seems to me that keys derived from the hierarchy can be
> > used to protect the EAP success and its data and this would allow for
> > protected result indication as well. 
> > 
> > The other reason to allow EAP Success carry data is to provide a natural
> > extension to the AAA (authorization, etc) signaling that currently does
> not
> > reach beyond the authenticator.
> > 
> > So with that in mind, I hope we don't rehash the previous emails citing
> > sentences from 3748 about EAP Success carrying data...
> > 
> > 3 Party key distribution (KDE)
> > =======================
> > I have modified the 3 party key distribution slightly to accomodate the
> EAP
> > method signaling.
> > 
> >    0  Authenticator to peer: EAP(DAID, DID)
> > 
> >    1  Peer to Authenticator: EAP((PID, DAID, DID, Np,KNps), [PID, DAID,
> >       Np,KNps]Kps)
> > 
> >    2  Authenticator to Server: AAA(PID, UAID, [PID, UAID]Kas),
> >       AAA(EAP((PID, DAID, DID, Np,KNps), [PID, DAID, DID, Np,KNps]Kps))
> > 
> >    3  Server to Authenticator: AAA({PID,AID,KNpa, KLpa, Kpa}KEas),
> >       AAA(EAP(KNpa, KLpa, KNps, [PID, AID, DID, Np+1,KNpa,KLpa,
> >       KNps]Kps))
> > 
> >    4  Authenticator to Peer: EAP(KNpa, KLpa, KNps, [PID, AID, DID, Np+1,
> >       KNpa,KLpa, KNps]Kps])
> > 
> > PID: peer ID.  
> >    DID: Domain ID
> >    AID: Authenticator ID
> >    DAID: Authenticator ID as perceived by the peer (down link ID)
> >    UAID: Authenticator ID as perceived by the server (uplink ID)
> >    {X}K: X encrypted with key K
> >    [X]K: Message Authentication Code over X with key K.
> >    X(Y): Y carried with X protocol
> >    Kps: A symmetric key shared between peer and Server for signing (IK,
> >    provisioned by EAP/HOKEY hierarchy) and identified by KNps.
> > 
> >    KEps: A symmetric key shared between peer and Server for encryption
> >    (CK, provisioning by EAP/HOKEY hierarchy) and identified by KEpsid
> > 
> >    KEas: A symmetric key shared between authenticator and Server for
> >    encryption (provisioned out of band).
> > 
> >    Kas: A symmetric key between authentication and server for MDCs for
> >    signing (provisioned out of band).
> > 
> > 
> >  Kpa: A symmetric key to be shared between peer and authenticator (key
> >    to be distributed to authenticator, the MDMSK in this document).  The
> >    key is named as KNpa.
> > 
> >    KLx : Key lifetime for key x
> > 
> >    KNx: Key name for Key x, e.g.  KENas: key name for KEas
> > 
> >    Nx : Nonce provided by the party X
> > 
> > I have provided more the details in a draft. 
> > http://www.ietf.org/internet-drafts/draft-nakhjiri-hokey-hierarchy-04.txt
> > 
> > Regards,
> > 
> > Madjid
> > 
> > -----Original Message-----
> > From: Charles Clancy [mailto:clancy@cs.umd.edu] 
> > Sent: Saturday, March 31, 2007 11:58 AM
> > To: hokey@ietf.org
> > Subject: [HOKEY] consensus call: EAP-ER as HOKEY protocol
> > 
> > HOKEY WG,
> > 
> > The chairs are making a second consensus call request to adopt EAP-ER as 
> > a WG document to satisfy our re-auth and hand-off deliverables.  It 
> > would serve as a starting point for development of the HOKEY protocol.
> > 
> > Note that if accepted, it may be split into two WG documents, separating 
> > the EAP-ER-Bootstrap into a second set of messages that could be 
> > transported by any service to obtain a USRK or DSUSRK.
> > 
> > Please respond by Friday, April 13.
> > 
> > -- 
> > t. charles clancy, ph.d.  <>  tcc@umd.edu  <>  www.cs.umd.edu/~clancy
> > 
> > 
> > _______________________________________________
> > 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 Tue Apr 10 20:10:20 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HbQPg-000145-Is; Tue, 10 Apr 2007 20:10:16 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HbQPf-00012F-2K
	for hokey@ietf.org; Tue, 10 Apr 2007 20:10:15 -0400
Received: from usaga01-in.huawei.com ([206.16.17.211])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbQPY-0007og-Gs
	for hokey@ietf.org; Tue, 10 Apr 2007 20:10:15 -0400
Received: from huawei.com (usaga01-in [172.18.4.6])
	by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTP id <0JGB005TO4GW3J@usaga01-in.huawei.com> for
	hokey@ietf.org; Tue, 10 Apr 2007 17:10:08 -0700 (PDT)
Received: from N737011
	(pool-71-112-121-192.sttlwa.dsl-w.verizon.net [71.112.121.192])
	by usaga01-in.huawei.com
	(iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar  3 2004))
	with ESMTPA id <0JGB008JT4GRN1@usaga01-in.huawei.com> for
	hokey@ietf.org; Tue, 10 Apr 2007 17:10:08 -0700 (PDT)
Date: Tue, 10 Apr 2007 17:10:09 -0700
From: Madjid Nakhjiri 
Subject: RE: [HOKEY] Using an EAP method for HOKEY??: was: consensus
	call:EAP-ER as HOKEY protocol
In-reply-to: <20070411000137.GB24740@steelhead>
To: 'Yoshihiro Ohba' 
Message-id: <009e01c77bcd$c47b5e40$2f01a8c0@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962
X-Mailer: Microsoft Office Outlook 11
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Thread-index: Acd7zLhdivfV2c1ET2Wpcz3pxpWAWwAAJMig
X-Spam-Score: 0.0 (/)
X-Scan-Signature: fb93e867a11a29ac1dc5018706b412ac
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

Oh, I see, Well, first off, there is no key being distributed to the peer.
The peer and the server derive the MDMSK (per-authenticator key) themselves.
The key distribution is only to the authenticator.

Now as far protecting other data to be carried by EAP Success, today's EAP
Success has some issues that needs fixing, as I mentioned in email to
Charles, either by fixing the current EAP success or by adding a new EAP
success that get both security and reliability protection.

Madjid

-----Original Message-----
From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] 
Sent: Tuesday, April 10, 2007 5:02 PM
To: Madjid Nakhjiri
Cc: hokey@ietf.org
Subject: Re: [HOKEY] Using an EAP method for HOKEY??: was: consensus
call:EAP-ER as HOKEY protocol

Madjid,

I was not mentioning server to authenticator part.  I was mentioning
authenticator to peer part.  I believe message 4 (which uses
EAP-Success in your proposal, right?) requires reliable delivery.

Yoshihiro Ohba


On Tue, Apr 10, 2007 at 11:37:15AM -0700, Madjid Nakhjiri wrote:
> Yoshi,
> 
> Please note the terminology, 
> 
> >    3  Server to Authenticator: AAA({PID,AID,KNpa, KLpa, Kpa}KEas),
> >       AAA(EAP(KNpa, KLpa, KNps, [PID, AID, DID, Np+1,KNpa,KLpa,
> >       KNps]Kps))
> 
> the key to be shared by peer and authenticator (Kpa) is carried by AAA
> attributes "AAA(...)" to the authenticator and not by EAP Success.
Although
> AAA message carrying these attributes is sent simultaneous as the AAA
> message carrying the EAP success, or possibly the same AAA message carries
> the authenticator keys and the EAP success as different attributes. So the
> reliability rules for AAA messages apply not the reliability rules for EAP
> or EAP success.
> 
> R,
> 
> Madjid
> 
> -----Original Message-----
> From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] 
> Sent: Monday, April 09, 2007 4:00 PM
> To: Madjid Nakhjiri
> Cc: 'Charles Clancy'; hokey@ietf.org
> Subject: Re: [HOKEY] Using an EAP method for HOKEY??: was: consensus call:
> EAP-ER as HOKEY protocol
> 
> Madjid,
> 
> How can key distribution by piggybacking data with EAP-Success work
> when EAP-Success gets lost?  Note that EAP does not retransmit
> EAP-Success.
> 
> Yoshihiro Ohba
> 
> 
> On Mon, Apr 09, 2007 at 03:50:08PM -0700, Madjid Nakhjiri wrote:
> > Hi,
> > 
> > As promised earlier, I am providing an analysis of use of EAP method for
> > handover and re-authentication signaling. To me it seems that without
> > introducing a new EAP code, one can accomplish the signaling with very
> > little change to authenticator state machine, given that the
authenticator
> > already does receive and transmit AAA attributes along with AAA messages
> > encapsulating EAP packets.
> > 
> > I have called this new method, EAP Handover and re-authentication method
> > (EAP-HR), which consists of 3 messages (if you count EAP Success as
method
> > specific).
> > I have shown the 3-party key distribution exchange (KDE) can be carried
> over
> > the EAP-HR messages easily.
> > As you can see in most of cases (handover, re-authentication and even in
> > some cases for network setup), a trigger is easily available for the
> > authenticator to start with EAP-HR Req, just the way EAP-identity starts
> > from the authenticator. So the urgent need for peer-initiated messaging
> and
> > hence the need to create new EAP code may go away.
> > 
> > 
> > 
> > Peer             authenticator             server
> > 	EAP-HR REQ
> > 	(DID, AID)
> >   <-------------
> > 	EAP-HR RESP
> >       KDE message 1 and 2 (PID, AID and tokens)
> > ------------------------------------------------->
> > 		EAP/Success
> > 		 (KDE message 3 and 4)
> > <---------------------------------------------------
> > 
> > DID: domain ID (used for creating Domain keys)
> > AID: authenticator ID advertised by the authenticator 
> > (note this can be done as part of lower layer beacon advertisement), so
> > carrying data through EAP-HR Request is not 100% necessary the KDE.
> > 
> > 
> > FAQ
> > =====
> > 
> > Roundtrips: 
> > ============
> > 1.1 when trigger is available at authenticator
> > (assuming authenticator-peer trip~20% of server-peer trip).
> > 1.5 when trigger needs to arrive from the server.
> > 
> > 
> > Cases where trigger is available at authenticator
> > a) in handover, this is available through a handover request from the
> peer.
> > b) in re-authentication, the authentication/ key status is typically
> > available at the authenticator as a result of previous AAA signaling
(e.g.
> > Session-life-time attribute)
> > c) in network setup, the server may send a session-life-time=0 to
> > authenticator along with the previous EAP authentication Success, to
> > indicate the need to start HOKEY signaling.
> > 
> > 
> > EAP-HR versus EAP identity
> > ======================
> > I have discussed this with several EAP experts and it seems that using
EAP
> > Identity request/ response versus using a new EAP method (EAP-HR) are
> almost
> > identical.
> > The issue with EAP Identity is that it does not carry data.
> > IMO, modifying EAP Identity to carry data is more straight forward than
> > creating EAP-HR.
> > 
> > 
> > 
> > EAP Success:
> > ==========
> > It seems that quite a number of people have already backed up the idea
of
> > modifying EAP success to carry data: people brought up the fact that
2284
> > did allow EAP success carrying data and the only reason 3748 banned EAP
> > Success from carrying data was the inadequate method independent way of
> > carrying data. It seems to me that keys derived from the hierarchy can
be
> > used to protect the EAP success and its data and this would allow for
> > protected result indication as well. 
> > 
> > The other reason to allow EAP Success carry data is to provide a natural
> > extension to the AAA (authorization, etc) signaling that currently does
> not
> > reach beyond the authenticator.
> > 
> > So with that in mind, I hope we don't rehash the previous emails citing
> > sentences from 3748 about EAP Success carrying data...
> > 
> > 3 Party key distribution (KDE)
> > =======================
> > I have modified the 3 party key distribution slightly to accomodate the
> EAP
> > method signaling.
> > 
> >    0  Authenticator to peer: EAP(DAID, DID)
> > 
> >    1  Peer to Authenticator: EAP((PID, DAID, DID, Np,KNps), [PID, DAID,
> >       Np,KNps]Kps)
> > 
> >    2  Authenticator to Server: AAA(PID, UAID, [PID, UAID]Kas),
> >       AAA(EAP((PID, DAID, DID, Np,KNps), [PID, DAID, DID, Np,KNps]Kps))
> > 
> >    3  Server to Authenticator: AAA({PID,AID,KNpa, KLpa, Kpa}KEas),
> >       AAA(EAP(KNpa, KLpa, KNps, [PID, AID, DID, Np+1,KNpa,KLpa,
> >       KNps]Kps))
> > 
> >    4  Authenticator to Peer: EAP(KNpa, KLpa, KNps, [PID, AID, DID, Np+1,
> >       KNpa,KLpa, KNps]Kps])
> > 
> > PID: peer ID.  
> >    DID: Domain ID
> >    AID: Authenticator ID
> >    DAID: Authenticator ID as perceived by the peer (down link ID)
> >    UAID: Authenticator ID as perceived by the server (uplink ID)
> >    {X}K: X encrypted with key K
> >    [X]K: Message Authentication Code over X with key K.
> >    X(Y): Y carried with X protocol
> >    Kps: A symmetric key shared between peer and Server for signing (IK,
> >    provisioned by EAP/HOKEY hierarchy) and identified by KNps.
> > 
> >    KEps: A symmetric key shared between peer and Server for encryption
> >    (CK, provisioning by EAP/HOKEY hierarchy) and identified by KEpsid
> > 
> >    KEas: A symmetric key shared between authenticator and Server for
> >    encryption (provisioned out of band).
> > 
> >    Kas: A symmetric key between authentication and server for MDCs for
> >    signing (provisioned out of band).
> > 
> > 
> >  Kpa: A symmetric key to be shared between peer and authenticator (key
> >    to be distributed to authenticator, the MDMSK in this document).  The
> >    key is named as KNpa.
> > 
> >    KLx : Key lifetime for key x
> > 
> >    KNx: Key name for Key x, e.g.  KENas: key name for KEas
> > 
> >    Nx : Nonce provided by the party X
> > 
> > I have provided more the details in a draft. 
> >
http://www.ietf.org/internet-drafts/draft-nakhjiri-hokey-hierarchy-04.txt
> > 
> > Regards,
> > 
> > Madjid
> > 
> > -----Original Message-----
> > From: Charles Clancy [mailto:clancy@cs.umd.edu] 
> > Sent: Saturday, March 31, 2007 11:58 AM
> > To: hokey@ietf.org
> > Subject: [HOKEY] consensus call: EAP-ER as HOKEY protocol
> > 
> > HOKEY WG,
> > 
> > The chairs are making a second consensus call request to adopt EAP-ER as

> > a WG document to satisfy our re-auth and hand-off deliverables.  It 
> > would serve as a starting point for development of the HOKEY protocol.
> > 
> > Note that if accepted, it may be split into two WG documents, separating

> > the EAP-ER-Bootstrap into a second set of messages that could be 
> > transported by any service to obtain a USRK or DSUSRK.
> > 
> > Please respond by Friday, April 13.
> > 
> > -- 
> > t. charles clancy, ph.d.  <>  tcc@umd.edu  <>  www.cs.umd.edu/~clancy
> > 
> > 
> > _______________________________________________
> > 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



_______________________________________________
HOKEY mailing list
HOKEY@ietf.org
https://www1.ietf.org/mailman/listinfo/hokey



From hokey-bounces@ietf.org Tue Apr 10 20:20:50 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HbQZk-0005QQ-L8; Tue, 10 Apr 2007 20:20:40 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HbQZi-0005Ok-Ub
	for hokey@ietf.org; Tue, 10 Apr 2007 20:20:38 -0400
Received: from imx12.toshiba.co.jp ([61.202.160.132])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbQZd-0002aF-0I
	for hokey@ietf.org; Tue, 10 Apr 2007 20:20:38 -0400
Received: from wall11.toshiba.co.jp (wall11 [133.199.90.149])
	by imx12.toshiba.co.jp  with ESMTP id l3B0KD0B025203;
	Wed, 11 Apr 2007 09:20:13 +0900 (JST)
Received: (from root@localhost) by wall11.toshiba.co.jp  id l3B0KCln026492;
	Wed, 11 Apr 2007 09:20:12 +0900 (JST)
Received: from ovp11.toshiba.co.jp [133.199.90.148] 
	by wall11.toshiba.co.jp with ESMTP id KAA26486;
	Wed, 11 Apr 2007 09:20:12 +0900
Received: from mx2.toshiba.co.jp (localhost [127.0.0.1])
	by ovp11.toshiba.co.jp  with ESMTP id l3B0KBBf025102;
	Wed, 11 Apr 2007 09:20:12 +0900 (JST)
Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id l3B0K9jr012416;
	Wed, 11 Apr 2007 09:20:09 +0900 (JST)
Received: from steelhead ([172.30.24.105])
	by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 (built
	Apr 28
	2004)) with ESMTPSA id <0JGB00L974XEKA70@mail.po.toshiba.co.jp>; Wed,
	11 Apr 2007 09:20:09 +0900 (JST)
Received: from ohba by steelhead with local (Exim 4.63)
	(envelope-from )	id 1HbQZ8-0006eg-Qh; Tue,
	10 Apr 2007 17:20:02 -0700
Date: Tue, 10 Apr 2007 20:20:02 -0400
From: Yoshihiro Ohba 
Subject: Re: [HOKEY] Using an EAP method for HOKEY??: was: consensus
	call:EAP-ER as HOKEY protocol
In-reply-to: <009e01c77bcd$c47b5e40$2f01a8c0@china.huawei.com>
To: Madjid Nakhjiri 
Message-id: <20070411002002.GC24740@steelhead>
MIME-version: 1.0
Content-type: text/plain; charset=iso-2022-jp
Content-disposition: inline
References: <20070411000137.GB24740@steelhead>
	<009e01c77bcd$c47b5e40$2f01a8c0@china.huawei.com>
User-Agent: Mutt/1.5.13 (2006-08-11)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a4cdc653ecdd96665f2aa1c1af034c9e
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

Madjid,

The latter option (defining a new Success with acknowledgment) seems
much better than overloading the current EAP Success.

Yoshihiro Ohba


On Tue, Apr 10, 2007 at 05:10:09PM -0700, Madjid Nakhjiri wrote:
> Oh, I see, Well, first off, there is no key being distributed to the peer.
> The peer and the server derive the MDMSK (per-authenticator key) themselves.
> The key distribution is only to the authenticator.
> 
> Now as far protecting other data to be carried by EAP Success, today's EAP
> Success has some issues that needs fixing, as I mentioned in email to
> Charles, either by fixing the current EAP success or by adding a new EAP
> success that get both security and reliability protection.
> 
> Madjid
> 
> -----Original Message-----
> From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] 
> Sent: Tuesday, April 10, 2007 5:02 PM
> To: Madjid Nakhjiri
> Cc: hokey@ietf.org
> Subject: Re: [HOKEY] Using an EAP method for HOKEY??: was: consensus
> call:EAP-ER as HOKEY protocol
> 
> Madjid,
> 
> I was not mentioning server to authenticator part.  I was mentioning
> authenticator to peer part.  I believe message 4 (which uses
> EAP-Success in your proposal, right?) requires reliable delivery.
> 
> Yoshihiro Ohba
> 
> 
> On Tue, Apr 10, 2007 at 11:37:15AM -0700, Madjid Nakhjiri wrote:
> > Yoshi,
> > 
> > Please note the terminology, 
> > 
> > >    3  Server to Authenticator: AAA({PID,AID,KNpa, KLpa, Kpa}KEas),
> > >       AAA(EAP(KNpa, KLpa, KNps, [PID, AID, DID, Np+1,KNpa,KLpa,
> > >       KNps]Kps))
> > 
> > the key to be shared by peer and authenticator (Kpa) is carried by AAA
> > attributes "AAA(...)" to the authenticator and not by EAP Success.
> Although
> > AAA message carrying these attributes is sent simultaneous as the AAA
> > message carrying the EAP success, or possibly the same AAA message carries
> > the authenticator keys and the EAP success as different attributes. So the
> > reliability rules for AAA messages apply not the reliability rules for EAP
> > or EAP success.
> > 
> > R,
> > 
> > Madjid
> > 
> > -----Original Message-----
> > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] 
> > Sent: Monday, April 09, 2007 4:00 PM
> > To: Madjid Nakhjiri
> > Cc: 'Charles Clancy'; hokey@ietf.org
> > Subject: Re: [HOKEY] Using an EAP method for HOKEY??: was: consensus call:
> > EAP-ER as HOKEY protocol
> > 
> > Madjid,
> > 
> > How can key distribution by piggybacking data with EAP-Success work
> > when EAP-Success gets lost?  Note that EAP does not retransmit
> > EAP-Success.
> > 
> > Yoshihiro Ohba
> > 
> > 
> > On Mon, Apr 09, 2007 at 03:50:08PM -0700, Madjid Nakhjiri wrote:
> > > Hi,
> > > 
> > > As promised earlier, I am providing an analysis of use of EAP method for
> > > handover and re-authentication signaling. To me it seems that without
> > > introducing a new EAP code, one can accomplish the signaling with very
> > > little change to authenticator state machine, given that the
> authenticator
> > > already does receive and transmit AAA attributes along with AAA messages
> > > encapsulating EAP packets.
> > > 
> > > I have called this new method, EAP Handover and re-authentication method
> > > (EAP-HR), which consists of 3 messages (if you count EAP Success as
> method
> > > specific).
> > > I have shown the 3-party key distribution exchange (KDE) can be carried
> > over
> > > the EAP-HR messages easily.
> > > As you can see in most of cases (handover, re-authentication and even in
> > > some cases for network setup), a trigger is easily available for the
> > > authenticator to start with EAP-HR Req, just the way EAP-identity starts
> > > from the authenticator. So the urgent need for peer-initiated messaging
> > and
> > > hence the need to create new EAP code may go away.
> > > 
> > > 
> > > 
> > > Peer             authenticator             server
> > > 	EAP-HR REQ
> > > 	(DID, AID)
> > >   <-------------
> > > 	EAP-HR RESP
> > >       KDE message 1 and 2 (PID, AID and tokens)
> > > ------------------------------------------------->
> > > 		EAP/Success
> > > 		 (KDE message 3 and 4)
> > > <---------------------------------------------------
> > > 
> > > DID: domain ID (used for creating Domain keys)
> > > AID: authenticator ID advertised by the authenticator 
> > > (note this can be done as part of lower layer beacon advertisement), so
> > > carrying data through EAP-HR Request is not 100% necessary the KDE.
> > > 
> > > 
> > > FAQ
> > > =====
> > > 
> > > Roundtrips: 
> > > ============
> > > 1.1 when trigger is available at authenticator
> > > (assuming authenticator-peer trip~20% of server-peer trip).
> > > 1.5 when trigger needs to arrive from the server.
> > > 
> > > 
> > > Cases where trigger is available at authenticator
> > > a) in handover, this is available through a handover request from the
> > peer.
> > > b) in re-authentication, the authentication/ key status is typically
> > > available at the authenticator as a result of previous AAA signaling
> (e.g.
> > > Session-life-time attribute)
> > > c) in network setup, the server may send a session-life-time=0 to
> > > authenticator along with the previous EAP authentication Success, to
> > > indicate the need to start HOKEY signaling.
> > > 
> > > 
> > > EAP-HR versus EAP identity
> > > ======================
> > > I have discussed this with several EAP experts and it seems that using
> EAP
> > > Identity request/ response versus using a new EAP method (EAP-HR) are
> > almost
> > > identical.
> > > The issue with EAP Identity is that it does not carry data.
> > > IMO, modifying EAP Identity to carry data is more straight forward than
> > > creating EAP-HR.
> > > 
> > > 
> > > 
> > > EAP Success:
> > > ==========
> > > It seems that quite a number of people have already backed up the idea
> of
> > > modifying EAP success to carry data: people brought up the fact that
> 2284
> > > did allow EAP success carrying data and the only reason 3748 banned EAP
> > > Success from carrying data was the inadequate method independent way of
> > > carrying data. It seems to me that keys derived from the hierarchy can
> be
> > > used to protect the EAP success and its data and this would allow for
> > > protected result indication as well. 
> > > 
> > > The other reason to allow EAP Success carry data is to provide a natural
> > > extension to the AAA (authorization, etc) signaling that currently does
> > not
> > > reach beyond the authenticator.
> > > 
> > > So with that in mind, I hope we don't rehash the previous emails citing
> > > sentences from 3748 about EAP Success carrying data...
> > > 
> > > 3 Party key distribution (KDE)
> > > =======================
> > > I have modified the 3 party key distribution slightly to accomodate the
> > EAP
> > > method signaling.
> > > 
> > >    0  Authenticator to peer: EAP(DAID, DID)
> > > 
> > >    1  Peer to Authenticator: EAP((PID, DAID, DID, Np,KNps), [PID, DAID,
> > >       Np,KNps]Kps)
> > > 
> > >    2  Authenticator to Server: AAA(PID, UAID, [PID, UAID]Kas),
> > >       AAA(EAP((PID, DAID, DID, Np,KNps), [PID, DAID, DID, Np,KNps]Kps))
> > > 
> > >    3  Server to Authenticator: AAA({PID,AID,KNpa, KLpa, Kpa}KEas),
> > >       AAA(EAP(KNpa, KLpa, KNps, [PID, AID, DID, Np+1,KNpa,KLpa,
> > >       KNps]Kps))
> > > 
> > >    4  Authenticator to Peer: EAP(KNpa, KLpa, KNps, [PID, AID, DID, Np+1,
> > >       KNpa,KLpa, KNps]Kps])
> > > 
> > > PID: peer ID.  
> > >    DID: Domain ID
> > >    AID: Authenticator ID
> > >    DAID: Authenticator ID as perceived by the peer (down link ID)
> > >    UAID: Authenticator ID as perceived by the server (uplink ID)
> > >    {X}K: X encrypted with key K
> > >    [X]K: Message Authentication Code over X with key K.
> > >    X(Y): Y carried with X protocol
> > >    Kps: A symmetric key shared between peer and Server for signing (IK,
> > >    provisioned by EAP/HOKEY hierarchy) and identified by KNps.
> > > 
> > >    KEps: A symmetric key shared between peer and Server for encryption
> > >    (CK, provisioning by EAP/HOKEY hierarchy) and identified by KEpsid
> > > 
> > >    KEas: A symmetric key shared between authenticator and Server for
> > >    encryption (provisioned out of band).
> > > 
> > >    Kas: A symmetric key between authentication and server for MDCs for
> > >    signing (provisioned out of band).
> > > 
> > > 
> > >  Kpa: A symmetric key to be shared between peer and authenticator (key
> > >    to be distributed to authenticator, the MDMSK in this document).  The
> > >    key is named as KNpa.
> > > 
> > >    KLx : Key lifetime for key x
> > > 
> > >    KNx: Key name for Key x, e.g.  KENas: key name for KEas
> > > 
> > >    Nx : Nonce provided by the party X
> > > 
> > > I have provided more the details in a draft. 
> > >
> http://www.ietf.org/internet-drafts/draft-nakhjiri-hokey-hierarchy-04.txt
> > > 
> > > Regards,
> > > 
> > > Madjid
> > > 
> > > -----Original Message-----
> > > From: Charles Clancy [mailto:clancy@cs.umd.edu] 
> > > Sent: Saturday, March 31, 2007 11:58 AM
> > > To: hokey@ietf.org
> > > Subject: [HOKEY] consensus call: EAP-ER as HOKEY protocol
> > > 
> > > HOKEY WG,
> > > 
> > > The chairs are making a second consensus call request to adopt EAP-ER as
> 
> > > a WG document to satisfy our re-auth and hand-off deliverables.  It 
> > > would serve as a starting point for development of the HOKEY protocol.
> > > 
> > > Note that if accepted, it may be split into two WG documents, separating
> 
> > > the EAP-ER-Bootstrap into a second set of messages that could be 
> > > transported by any service to obtain a USRK or DSUSRK.
> > > 
> > > Please respond by Friday, April 13.
> > > 
> > > -- 
> > > t. charles clancy, ph.d.  <>  tcc@umd.edu  <>  www.cs.umd.edu/~clancy
> > > 
> > > 
> > > _______________________________________________
> > > 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
> 
> 
> 

_______________________________________________
HOKEY mailing list
HOKEY@ietf.org
https://www1.ietf.org/mailman/listinfo/hokey



From hokey-bounces@ietf.org Tue Apr 10 20:29: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 1HbQi0-0001SR-P4; Tue, 10 Apr 2007 20:29:12 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HbQhz-0001SJ-LT
	for hokey@ietf.org; Tue, 10 Apr 2007 20:29:11 -0400
Received: from usaga01-in.huawei.com ([206.16.17.211])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbQhu-0004XM-Bq
	for hokey@ietf.org; Tue, 10 Apr 2007 20:29:11 -0400
Received: from huawei.com (usaga01-in [172.18.4.6])
	by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTP id <0JGB005935CH3J@usaga01-in.huawei.com> for
	hokey@ietf.org; Tue, 10 Apr 2007 17:29:06 -0700 (PDT)
Received: from N737011
	(pool-71-112-121-192.sttlwa.dsl-w.verizon.net [71.112.121.192])
	by usaga01-in.huawei.com
	(iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar  3 2004))
	with ESMTPA id <0JGB008MU5CDN1@usaga01-in.huawei.com> for
	hokey@ietf.org; Tue, 10 Apr 2007 17:29:05 -0700 (PDT)
Date: Tue, 10 Apr 2007 17:29:04 -0700
From: Madjid Nakhjiri 
Subject: RE: [HOKEY] Using an EAP method for HOKEY??: was: consensuscall:EAP-ER
	as HOKEY protocol
In-reply-to: <20070411002002.GC24740@steelhead>
To: 'Yoshihiro Ohba' 
Message-id: <00ad01c77bd0$6ac86340$2f01a8c0@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962
X-Mailer: Microsoft Office Outlook 11
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Thread-index: Acd7z1UgC3FWWQmMTXuhBBqy0qpJXgAAPegA
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6437e26f1586b9f35812ea5ebeedf4ad
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

Yoshi,

I can relate to that point of view and think that sound like a good
compromise.

R,

Madjid
-----Original Message-----
From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] 
Sent: Tuesday, April 10, 2007 5:20 PM
To: Madjid Nakhjiri
Cc: hokey@ietf.org
Subject: Re: [HOKEY] Using an EAP method for HOKEY??: was:
consensuscall:EAP-ER as HOKEY protocol

Madjid,

The latter option (defining a new Success with acknowledgment) seems
much better than overloading the current EAP Success.

Yoshihiro Ohba


On Tue, Apr 10, 2007 at 05:10:09PM -0700, Madjid Nakhjiri wrote:
> Oh, I see, Well, first off, there is no key being distributed to the peer.
> The peer and the server derive the MDMSK (per-authenticator key)
themselves.
> The key distribution is only to the authenticator.
> 
> Now as far protecting other data to be carried by EAP Success, today's EAP
> Success has some issues that needs fixing, as I mentioned in email to
> Charles, either by fixing the current EAP success or by adding a new EAP
> success that get both security and reliability protection.
> 
> Madjid
> 
> -----Original Message-----
> From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] 
> Sent: Tuesday, April 10, 2007 5:02 PM
> To: Madjid Nakhjiri
> Cc: hokey@ietf.org
> Subject: Re: [HOKEY] Using an EAP method for HOKEY??: was: consensus
> call:EAP-ER as HOKEY protocol
> 
> Madjid,
> 
> I was not mentioning server to authenticator part.  I was mentioning
> authenticator to peer part.  I believe message 4 (which uses
> EAP-Success in your proposal, right?) requires reliable delivery.
> 
> Yoshihiro Ohba
> 
> 
> On Tue, Apr 10, 2007 at 11:37:15AM -0700, Madjid Nakhjiri wrote:
> > Yoshi,
> > 
> > Please note the terminology, 
> > 
> > >    3  Server to Authenticator: AAA({PID,AID,KNpa, KLpa, Kpa}KEas),
> > >       AAA(EAP(KNpa, KLpa, KNps, [PID, AID, DID, Np+1,KNpa,KLpa,
> > >       KNps]Kps))
> > 
> > the key to be shared by peer and authenticator (Kpa) is carried by AAA
> > attributes "AAA(...)" to the authenticator and not by EAP Success.
> Although
> > AAA message carrying these attributes is sent simultaneous as the AAA
> > message carrying the EAP success, or possibly the same AAA message
carries
> > the authenticator keys and the EAP success as different attributes. So
the
> > reliability rules for AAA messages apply not the reliability rules for
EAP
> > or EAP success.
> > 
> > R,
> > 
> > Madjid
> > 
> > -----Original Message-----
> > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] 
> > Sent: Monday, April 09, 2007 4:00 PM
> > To: Madjid Nakhjiri
> > Cc: 'Charles Clancy'; hokey@ietf.org
> > Subject: Re: [HOKEY] Using an EAP method for HOKEY??: was: consensus
call:
> > EAP-ER as HOKEY protocol
> > 
> > Madjid,
> > 
> > How can key distribution by piggybacking data with EAP-Success work
> > when EAP-Success gets lost?  Note that EAP does not retransmit
> > EAP-Success.
> > 
> > Yoshihiro Ohba
> > 
> > 
> > On Mon, Apr 09, 2007 at 03:50:08PM -0700, Madjid Nakhjiri wrote:
> > > Hi,
> > > 
> > > As promised earlier, I am providing an analysis of use of EAP method
for
> > > handover and re-authentication signaling. To me it seems that without
> > > introducing a new EAP code, one can accomplish the signaling with very
> > > little change to authenticator state machine, given that the
> authenticator
> > > already does receive and transmit AAA attributes along with AAA
messages
> > > encapsulating EAP packets.
> > > 
> > > I have called this new method, EAP Handover and re-authentication
method
> > > (EAP-HR), which consists of 3 messages (if you count EAP Success as
> method
> > > specific).
> > > I have shown the 3-party key distribution exchange (KDE) can be
carried
> > over
> > > the EAP-HR messages easily.
> > > As you can see in most of cases (handover, re-authentication and even
in
> > > some cases for network setup), a trigger is easily available for the
> > > authenticator to start with EAP-HR Req, just the way EAP-identity
starts
> > > from the authenticator. So the urgent need for peer-initiated
messaging
> > and
> > > hence the need to create new EAP code may go away.
> > > 
> > > 
> > > 
> > > Peer             authenticator             server
> > > 	EAP-HR REQ
> > > 	(DID, AID)
> > >   <-------------
> > > 	EAP-HR RESP
> > >       KDE message 1 and 2 (PID, AID and tokens)
> > > ------------------------------------------------->
> > > 		EAP/Success
> > > 		 (KDE message 3 and 4)
> > > <---------------------------------------------------
> > > 
> > > DID: domain ID (used for creating Domain keys)
> > > AID: authenticator ID advertised by the authenticator 
> > > (note this can be done as part of lower layer beacon advertisement),
so
> > > carrying data through EAP-HR Request is not 100% necessary the KDE.
> > > 
> > > 
> > > FAQ
> > > =====
> > > 
> > > Roundtrips: 
> > > ============
> > > 1.1 when trigger is available at authenticator
> > > (assuming authenticator-peer trip~20% of server-peer trip).
> > > 1.5 when trigger needs to arrive from the server.
> > > 
> > > 
> > > Cases where trigger is available at authenticator
> > > a) in handover, this is available through a handover request from the
> > peer.
> > > b) in re-authentication, the authentication/ key status is typically
> > > available at the authenticator as a result of previous AAA signaling
> (e.g.
> > > Session-life-time attribute)
> > > c) in network setup, the server may send a session-life-time=0 to
> > > authenticator along with the previous EAP authentication Success, to
> > > indicate the need to start HOKEY signaling.
> > > 
> > > 
> > > EAP-HR versus EAP identity
> > > ======================
> > > I have discussed this with several EAP experts and it seems that using
> EAP
> > > Identity request/ response versus using a new EAP method (EAP-HR) are
> > almost
> > > identical.
> > > The issue with EAP Identity is that it does not carry data.
> > > IMO, modifying EAP Identity to carry data is more straight forward
than
> > > creating EAP-HR.
> > > 
> > > 
> > > 
> > > EAP Success:
> > > ==========
> > > It seems that quite a number of people have already backed up the idea
> of
> > > modifying EAP success to carry data: people brought up the fact that
> 2284
> > > did allow EAP success carrying data and the only reason 3748 banned
EAP
> > > Success from carrying data was the inadequate method independent way
of
> > > carrying data. It seems to me that keys derived from the hierarchy can
> be
> > > used to protect the EAP success and its data and this would allow for
> > > protected result indication as well. 
> > > 
> > > The other reason to allow EAP Success carry data is to provide a
natural
> > > extension to the AAA (authorization, etc) signaling that currently
does
> > not
> > > reach beyond the authenticator.
> > > 
> > > So with that in mind, I hope we don't rehash the previous emails
citing
> > > sentences from 3748 about EAP Success carrying data...
> > > 
> > > 3 Party key distribution (KDE)
> > > =======================
> > > I have modified the 3 party key distribution slightly to accomodate
the
> > EAP
> > > method signaling.
> > > 
> > >    0  Authenticator to peer: EAP(DAID, DID)
> > > 
> > >    1  Peer to Authenticator: EAP((PID, DAID, DID, Np,KNps), [PID,
DAID,
> > >       Np,KNps]Kps)
> > > 
> > >    2  Authenticator to Server: AAA(PID, UAID, [PID, UAID]Kas),
> > >       AAA(EAP((PID, DAID, DID, Np,KNps), [PID, DAID, DID,
Np,KNps]Kps))
> > > 
> > >    3  Server to Authenticator: AAA({PID,AID,KNpa, KLpa, Kpa}KEas),
> > >       AAA(EAP(KNpa, KLpa, KNps, [PID, AID, DID, Np+1,KNpa,KLpa,
> > >       KNps]Kps))
> > > 
> > >    4  Authenticator to Peer: EAP(KNpa, KLpa, KNps, [PID, AID, DID,
Np+1,
> > >       KNpa,KLpa, KNps]Kps])
> > > 
> > > PID: peer ID.  
> > >    DID: Domain ID
> > >    AID: Authenticator ID
> > >    DAID: Authenticator ID as perceived by the peer (down link ID)
> > >    UAID: Authenticator ID as perceived by the server (uplink ID)
> > >    {X}K: X encrypted with key K
> > >    [X]K: Message Authentication Code over X with key K.
> > >    X(Y): Y carried with X protocol
> > >    Kps: A symmetric key shared between peer and Server for signing
(IK,
> > >    provisioned by EAP/HOKEY hierarchy) and identified by KNps.
> > > 
> > >    KEps: A symmetric key shared between peer and Server for encryption
> > >    (CK, provisioning by EAP/HOKEY hierarchy) and identified by KEpsid
> > > 
> > >    KEas: A symmetric key shared between authenticator and Server for
> > >    encryption (provisioned out of band).
> > > 
> > >    Kas: A symmetric key between authentication and server for MDCs for
> > >    signing (provisioned out of band).
> > > 
> > > 
> > >  Kpa: A symmetric key to be shared between peer and authenticator (key
> > >    to be distributed to authenticator, the MDMSK in this document).
The
> > >    key is named as KNpa.
> > > 
> > >    KLx : Key lifetime for key x
> > > 
> > >    KNx: Key name for Key x, e.g.  KENas: key name for KEas
> > > 
> > >    Nx : Nonce provided by the party X
> > > 
> > > I have provided more the details in a draft. 
> > >
> http://www.ietf.org/internet-drafts/draft-nakhjiri-hokey-hierarchy-04.txt
> > > 
> > > Regards,
> > > 
> > > Madjid
> > > 
> > > -----Original Message-----
> > > From: Charles Clancy [mailto:clancy@cs.umd.edu] 
> > > Sent: Saturday, March 31, 2007 11:58 AM
> > > To: hokey@ietf.org
> > > Subject: [HOKEY] consensus call: EAP-ER as HOKEY protocol
> > > 
> > > HOKEY WG,
> > > 
> > > The chairs are making a second consensus call request to adopt EAP-ER
as
> 
> > > a WG document to satisfy our re-auth and hand-off deliverables.  It 
> > > would serve as a starting point for development of the HOKEY protocol.
> > > 
> > > Note that if accepted, it may be split into two WG documents,
separating
> 
> > > the EAP-ER-Bootstrap into a second set of messages that could be 
> > > transported by any service to obtain a USRK or DSUSRK.
> > > 
> > > Please respond by Friday, April 13.
> > > 
> > > -- 
> > > t. charles clancy, ph.d.  <>  tcc@umd.edu  <>  www.cs.umd.edu/~clancy
> > > 
> > > 
> > > _______________________________________________
> > > 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
> 
> 
> 

_______________________________________________
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 Apr 10 22:16: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 1HbSNI-00087u-GP; Tue, 10 Apr 2007 22:15:56 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HbSNH-00087p-9y
	for hokey@ietf.org; Tue, 10 Apr 2007 22:15:55 -0400
Received: from ithilien.qualcomm.com ([129.46.51.59])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbSNF-0000qH-QR
	for hokey@ietf.org; Tue, 10 Apr 2007 22:15:55 -0400
Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149])
	by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id
	l3B2FqPj027338
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL)
	for ; Tue, 10 Apr 2007 19:15:53 -0700
Received: from SANEXCAS02.na.qualcomm.com (sanexcas02.qualcomm.com
	[172.30.36.176])
	by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id
	l3B2Fqdm016676 for ; Tue, 10 Apr 2007 19:15:52 -0700
Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by
	SANEXCAS02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 10 Apr 2007 19:15:51 -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
Subject: RE: [HOKEY] Using an EAP method for HOKEY??: was:
	consensuscall:EAP-ERas HOKEY protocol
Date: Tue, 10 Apr 2007 19:15:49 -0700
Message-ID: 
In-Reply-To: <00ad01c77bd0$6ac86340$2f01a8c0@china.huawei.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [HOKEY] Using an EAP method for HOKEY??: was:
	consensuscall:EAP-ERas HOKEY protocol
Thread-Index: Acd7z1UgC3FWWQmMTXuhBBqy0qpJXgAAPegAAAOF+YA=
References: <20070411002002.GC24740@steelhead>
	<00ad01c77bd0$6ac86340$2f01a8c0@china.huawei.com>
From: "Narayanan, Vidya" 
To: 
X-OriginalArrivalTime: 11 Apr 2007 02:15:51.0747 (UTC)
	FILETIME=[53D0E130:01C77BDF]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f
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'm feeling a bit lazy to re-hash all the relevant discussions yet
another time, so, I'm just going to point to some old discussions on
this topic. The only means by which we can avoid authenticator changes
is using a method-based transport as shown in this email from Charles,
back in December:=20

http://www.opendiameter.org/pipermail/hokeyp/2006-December/000450.html

And, the discussions we had about all the options captured above at the
interim meeting were summarized in the following email:=20

http://www1.ietf.org/mail-archive/web/hokey/current/msg00077.html

We've had a number of other discussions on this list on the very same
topic as well, if people want to read further.=20

Vidya

_______________________________________________
HOKEY mailing list
HOKEY@ietf.org
https://www1.ietf.org/mailman/listinfo/hokey



From hokey-bounces@ietf.org Wed Apr 11 15:33:57 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HbiZh-0000Im-A7; Wed, 11 Apr 2007 15:33:49 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HbiZg-0000EX-2i
	for hokey@ietf.org; Wed, 11 Apr 2007 15:33:48 -0400
Received: from usaga01-in.huawei.com ([206.16.17.211])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbiZe-0005Dr-Ou
	for hokey@ietf.org; Wed, 11 Apr 2007 15:33:48 -0400
Received: from huawei.com (usaga01-in [172.18.4.6])
	by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTP id <0JGC002GBMC6C3@usaga01-in.huawei.com> for
	hokey@ietf.org; Wed, 11 Apr 2007 12:33:42 -0700 (PDT)
Received: from N737011
	(pool-71-112-139-16.sttlwa.dsl-w.verizon.net [71.112.139.16])
	by usaga01-in.huawei.com
	(iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar  3 2004))
	with ESMTPA id <0JGC003SOMC19Y@usaga01-in.huawei.com> for
	hokey@ietf.org; Wed, 11 Apr 2007 12:33:42 -0700 (PDT)
Date: Wed, 11 Apr 2007 12:33:43 -0700
From: Madjid Nakhjiri 
Subject: RE: [HOKEY] Using an EAP method for HOKEY??:
	was:consensuscall:EAP-ERas HOKEY protocol
In-reply-to: 
To: "'Narayanan, Vidya'" , hokey@ietf.org
Message-id: <009501c77c70$5144e740$2f01a8c0@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962
X-Mailer: Microsoft Office Outlook 11
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Thread-index: Acd7z1UgC3FWWQmMTXuhBBqy0qpJXgAAPegAAAOF+YAAJFhjYA==
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa
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

I think we already discussed that we do not need EAP ID request/response
necessary for every exchange, so one 1 RT goes away there.

We can either load EAP ID or do a new method without EAP ID and carry IDs
inside tokens as I have shown.

We are also discussing loading EAP Success, rather than sending an empty
finish followed by a dumb success, so another RT goes away there too.

That analysis is pretty stale at this point. No need to keep resending that
link.

Madjid 

-----Original Message-----
From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] 
Sent: Tuesday, April 10, 2007 7:16 PM
To: hokey@ietf.org
Subject: RE: [HOKEY] Using an EAP method for HOKEY??:
was:consensuscall:EAP-ERas HOKEY protocol


I'm feeling a bit lazy to re-hash all the relevant discussions yet
another time, so, I'm just going to point to some old discussions on
this topic. The only means by which we can avoid authenticator changes
is using a method-based transport as shown in this email from Charles,
back in December: 

http://www.opendiameter.org/pipermail/hokeyp/2006-December/000450.html

And, the discussions we had about all the options captured above at the
interim meeting were summarized in the following email: 

http://www1.ietf.org/mail-archive/web/hokey/current/msg00077.html

We've had a number of other discussions on this list on the very same
topic as well, if people want to read further. 

Vidya

_____________________________________________
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 Apr 11 15:59: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 1Hbiyg-0007jl-Gy; Wed, 11 Apr 2007 15:59:38 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hbiyf-0007jb-B9
	for hokey@ietf.org; Wed, 11 Apr 2007 15:59:37 -0400
Received: from usaga01-in.huawei.com ([206.16.17.211])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbiyZ-0005h6-7L
	for hokey@ietf.org; Wed, 11 Apr 2007 15:59:37 -0400
Received: from huawei.com (usaga01-in [172.18.4.6])
	by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTP id <0JGC0026DNJ6C3@usaga01-in.huawei.com> for
	hokey@ietf.org; Wed, 11 Apr 2007 12:59:30 -0700 (PDT)
Received: from N737011
	(pool-71-112-139-16.sttlwa.dsl-w.verizon.net [71.112.139.16])
	by usaga01-in.huawei.com
	(iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar  3 2004))
	with ESMTPA id <0JGC003NENJ19Y@usaga01-in.huawei.com> for
	hokey@ietf.org; Wed, 11 Apr 2007 12:59:30 -0700 (PDT)
Date: Wed, 11 Apr 2007 12:59:30 -0700
From: Madjid Nakhjiri 
Subject: RE: [HOKEY] key scope versus Context. consensus call: key distribution
	security requirement
In-reply-to: <4614453D.9070503@cs.umd.edu>
To: 'Charles Clancy' 
Message-id: <009601c77c73$eb82ce50$2f01a8c0@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962
X-Mailer: Microsoft Office Outlook 11
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Thread-index: Acd3Ej4zHSD5zCzGQxOaxw6DQhNopgFXkYqw
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede
Cc: 'Bernard Aboba' ,
	'Russ Housley' , 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 Charles,

Apologize for procrastinating on my homework, I was planning on looking at
the PS and see what text changes are needed. But it seems that we first need
a clear and more stringent definition of key scope and key context. Looking
at these, the EAP keying doc and the Housley doc, and having USRK and hokey
PS in mind, I think we should once and for all, nail the terminology down
for the purpose of HOKEY and go forward based on that, so before suggesting
text, I like to add a definition for "scope" and "context" to the main PS
draft:

1) scope: Housley draft does not define this, but EAP keying does:

Key Scope
     The parties to whom a key is available [EAP_keying].

I suggest we adopt this for HOKEY and EMSK hierarchy drafts. However, I am
not sure if the domain for the key would go into the scope definition or in
the context definition.

2) Context: EAP keying does not define this, but Housley does it in a way
that causes confusion for hokey:

"The context includes the following.

            o  The manner in which the keying material is expected to
               be used.

            o  The other parties that are expected to have access to
               the keying material.

            o  The expected lifetime of the keying material.  Lifetime
               of a child key SHOULD NOT be greater than the lifetime of
               its parent in the key hierarchy."

It seems that there is a bit of inconsistency in scope versus context,
especially the second bullet: Before this exercise, I was assuming that
scope was simply the id of the two parties sharing the key, but it seems
that it is ALL parties that can access it.  So I think we should remove the
second bullet and Russ and Bernard should remove that bullet as well (and
instead add the definition of scope explicitly in the Housley draft).

"The manner" in first bullet is vague to me, especially now that we are
defining "usage specific root keys". Is "manner" a usage, such as hokey or
Mobile IP? Is it for a domain? Is it for a crypto purpose, such as signing
or encryption? Is it to be a root for a hierarchy and not used for traffic?
Or is it all the above. For Housley doc this might be ok, but I think for
hokey, we need to be more specific in our requirements on context and the
semantics that goes in it.
So I am suggesting something like the following for "key context" (the main
thing is I am replacing the second bullet)

            o  The usage for which the keying material is generated.
 The usage is defined
in [EMSK-hiearchy], e.g. Mobile IP, handover keying, etc.

            o  The purpose for the keying material, e.g. traffic protection
(signing, encryption), signaling protection, key derivation, etc.


            o  The expected lifetime of the keying material.  Lifetime
               of a child key SHOULD NOT be greater than the lifetime of
               its parent in the key hierarchy."



I can send mods for requirements based on the above later.

R,

Madjid


-----Original Message-----
From: Charles Clancy [mailto:clancy@cs.umd.edu] 
Sent: Wednesday, April 04, 2007 5:39 PM
To: Madjid Nakhjiri
Cc: hokey@ietf.org
Subject: Re: [HOKEY] consensus call: key distribution security requirement

Madjid,

My opinion was that they were all already covered by the problem 
statement in one way or another.

 > 1-Confidentiality --avoiding disclosure of the keying material to
 > passive and active attackers.

Covered by saying we must conform to I-D.housley-aaa-key-mgmt.  I have 
no problem adding that as an explicit thing in section 6 though.

 > 3-Validation of credential source -- the recipient must prove where
 > the credential came from and what context it was delivered for.

Prove to whom?  Regardless, that information should be included in the 
key scope and context -- section 6.1.

 > 4-Validation of authorization -- the scope (intended users) of the
 >        network access credential MUST be distributed as part of the
 >        credential and MUST be protected to the same degree as the
 >        credential itself.

See section 6.1 of the current PS.

 > Some of these requirements are simply reflections of Housley document
 > and to me are met through a channel binding procedure.

Exactly, and CB is already in the PS.

Feel free to send me text if you think section 6.1 should be modified.

-- 
t. charles clancy, ph.d.  |  tcc@umd.edu  |  www.cs.umd.edu/~clancy


_______________________________________________
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 Apr 11 16:17:34 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HbjG2-0007Rl-CY; Wed, 11 Apr 2007 16:17:34 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HbjG1-0007Rg-Cn
	for hokey@ietf.org; Wed, 11 Apr 2007 16:17:33 -0400
Received: from usaga01-in.huawei.com ([206.16.17.211])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbjG0-0001nE-3J
	for hokey@ietf.org; Wed, 11 Apr 2007 16:17:33 -0400
Received: from huawei.com (usaga01-in [172.18.4.6])
	by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTP id <0JGC002LHOB3C3@usaga01-in.huawei.com> for
	hokey@ietf.org; Wed, 11 Apr 2007 13:16:15 -0700 (PDT)
Received: from N737011
	(pool-71-112-139-16.sttlwa.dsl-w.verizon.net [71.112.139.16])
	by usaga01-in.huawei.com
	(iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar  3 2004))
	with ESMTPA id <0JGC003K2OAY9Y@usaga01-in.huawei.com> for
	hokey@ietf.org; Wed, 11 Apr 2007 13:16:15 -0700 (PDT)
Date: Wed, 11 Apr 2007 13:16:15 -0700
From: Madjid Nakhjiri 
Subject: RE: [HOKEY] consensus call: EAP-ER as HOKEY protocol
In-reply-to: <461451F0.5050304@cs.umd.edu>
To: 'Charles Clancy' 
Message-id: <009a01c77c76$42fc13b0$2f01a8c0@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962
X-Mailer: Microsoft Office Outlook 11
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Thread-index: Acd3GcZo+tA2gWx+QT6MWM1ikxA1PQFWuKhA
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

Sure HOKEY is a specific usage, but it is THE usage we have control on in
this group, which means we can go beyond just defining HRK and go further
down the hierarchy to see how handovers are actually managed. If we were
talking about Mobile IP and MIP-USRK, yes, we could not go down the
hierarchy as you said. As far as a generic protocol, say for Mobile IP, it
really depends on the usage architecture, for instance MIP4 has two agents,
only one of which may be on EAP signaling path, what do you do for keying
the other?

Even for HOKEY, as far as getting HRK to HOKEY server using a protocol, I
think this really depends on what architecture and key hierarchy you have in
mind. I can see the HOKEY server to be logical function of the AAA server.
The HOKEY server requests HRK (as a USRK) from EAP server through internal
API based on a trigger, but not using signaling. The HOKEY server could also
generate a domain specific HRK for other domain (HHRK for home, VHRK for
visited domains)

Madjid

-----Original Message-----
From: Charles Clancy [mailto:clancy@cs.umd.edu] 
Sent: Wednesday, April 04, 2007 6:34 PM
To: Madjid Nakhjiri
Cc: hokey@ietf.org
Subject: Re: [HOKEY] consensus call: EAP-ER as HOKEY protocol

Indeed HOKEY is a specific usage.  As a part of that, it needs to define 
a protocol to get a USRK=HRK to the HOKEY server (in EAP-ER this is the 
bootstrap phase).  I was hoping that we could define a generic protocol 
that other services could use too, after defining their own transport 
for the protocol.  This way we could enforce certain security properties.

-- 
t. charles clancy, ph.d.  |  tcc@umd.edu  |  www.cs.umd.edu/~clancy

Madjid Nakhjiri wrote:
> Well, I guess I am sort of fuzzy on the _whole point_ of the separation
> then:) we have an EMSK hierarchy draft that will show/shows USRK and
USDSRK
> derivation, but is not supposed to go into any specific usage, and leaves
> that to other SDOs.
> 
> Then we need to have a spec that deals with HOKEY as a usage and shows HRK
> and its child keys. Per-authenticator keys are part of that. I am not
> talking about non-HOKEY usages, but when it comes to HOKEY, we need to
> specify the whole hierarchy, no?
> 
> Am I missing something?
> 
> Madjid
> 
> 
> -----Original Message-----
> From: Charles Clancy [mailto:clancy@cs.umd.edu] 
> Sent: Monday, April 02, 2007 7:17 PM
> To: Madjid Nakhjiri
> Cc: hokey@ietf.org
> Subject: Re: [HOKEY] consensus call: EAP-ER as HOKEY protocol
> 
> Madjid,
> 
> In response to your second question about the additional document -- the 
> whole point is to separate out the part of HOKEY that would could be 
> reused by another application to obtain a USRK.  The per-authenticator 
> keying has nothing to do with other services or their ability to obtain 
> a USRK, so I don't think it should be included in the second document.
> 



_______________________________________________
HOKEY mailing list
HOKEY@ietf.org
https://www1.ietf.org/mailman/listinfo/hokey



From hokey-bounces@ietf.org Wed Apr 11 16:59: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 1Hbjui-0008Bg-VW; Wed, 11 Apr 2007 16:59:36 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hbjuh-0008Bb-Rg
	for hokey@ietf.org; Wed, 11 Apr 2007 16:59:35 -0400
Received: from usaga01-in.huawei.com ([206.16.17.211])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hbjug-0003fH-Gp
	for hokey@ietf.org; Wed, 11 Apr 2007 16:59:35 -0400
Received: from huawei.com (usaga01-in [172.18.4.6])
	by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTP id <0JGC002VUQB9C3@usaga01-in.huawei.com> for
	hokey@ietf.org; Wed, 11 Apr 2007 13:59:34 -0700 (PDT)
Received: from N737011
	(pool-71-112-139-16.sttlwa.dsl-w.verizon.net [71.112.139.16])
	by usaga01-in.huawei.com
	(iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar  3 2004))
	with ESMTPA id <0JGC00JUCQB21V@usaga01-in.huawei.com> for
	hokey@ietf.org; Wed, 11 Apr 2007 13:59:33 -0700 (PDT)
Date: Wed, 11 Apr 2007 13:59:32 -0700
From: Madjid Nakhjiri 
Subject: RE: [HOKEY] consensus call: key distribution security requirement
In-reply-to: <4614453D.9070503@cs.umd.edu>
To: 'Charles Clancy' 
Message-id: <00a001c77c7c$4fcfb5f0$2f01a8c0@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962
X-Mailer: Microsoft Office Outlook 11
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Thread-index: Acd3Ej4zHSD5zCzGQxOaxw6DQhNopgFZVYsA
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db
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

Here is my homework on PS relating to the 3 requirements I mentioned
earlier.

Section 6.1

Current text: 
"Any key MUST have a well-defined scope and MUST be used in a specific
   context and for the intended use.  This specifically means the
   lifetime and scope of each key MUST be defined clearly so that all
   entities that are authorized to have access to the key have the same
   context during the validity period. "

new text for scope:

"Any key MUST have a well-defined and properly authorized scope. The scope
of a key can be extended to include 3rd parties that receive the key through
distribution (rather than generation). Distribution of the key to such 3rd
parties MUST happen through secure transport, to avoid disclosure of the
keying material to passive and active attackers. When proving the possession
of the distributed keys, such 3rd parties MUST be able to provide proof on
the authorization to use the key and entity making such authorization.
Alternatively, the scope of the key MAY be communicated by the authorizing
party to all parties explicitly. Communication of scope MUST be in a secure
manner. Each party included in the scope definition MUST be known to all
other parties in an unequivocal manner."


Madjid>>The text above, means the scope does not have to be provided from
server to the peer directly, so we are not requiring direct signaling of the
scope, but through a peer-authenticator exchange later on.
Also it says, the party that distributes the key, also authorizes its use.
It is stronger than just transporting the key to authenticator from the
server, but it is weaker than requiring peer consent.
The last sentence covers the channel binding problem.


New text for context:

"Any key MUST have well defined context. The context information MUST be
communicated securely to parties receiving the key through distribution and
MUST be well understood and Must be agreed upon by all parties covered by
key scope definition. This for instance means, all entities that are
authorized to have access to the key have the notion of the key usage and
validity period."

R,

Madjid

-----Original Message-----
From: Charles Clancy [mailto:clancy@cs.umd.edu] 
Sent: Wednesday, April 04, 2007 5:39 PM
To: Madjid Nakhjiri
Cc: hokey@ietf.org
Subject: Re: [HOKEY] consensus call: key distribution security requirement

Madjid,

My opinion was that they were all already covered by the problem 
statement in one way or another.

 > 1-Confidentiality --avoiding disclosure of the keying material to
 > passive and active attackers.

Covered by saying we must conform to I-D.housley-aaa-key-mgmt.  I have 
no problem adding that as an explicit thing in section 6 though.

 > 3-Validation of credential source -- the recipient must prove where
 > the credential came from and what context it was delivered for.

Prove to whom?  Regardless, that information should be included in the 
key scope and context -- section 6.1.

 > 4-Validation of authorization -- the scope (intended users) of the
 >        network access credential MUST be distributed as part of the
 >        credential and MUST be protected to the same degree as the
 >        credential itself.

See section 6.1 of the current PS.

 > Some of these requirements are simply reflections of Housley document
 > and to me are met through a channel binding procedure.

Exactly, and CB is already in the PS.

Feel free to send me text if you think section 6.1 should be modified.

-- 
t. charles clancy, ph.d.  |  tcc@umd.edu  |  www.cs.umd.edu/~clancy


_______________________________________________
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 Apr 11 17:08: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 1Hbk39-00037J-CW; Wed, 11 Apr 2007 17:08:19 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hbk38-00035Q-6I
	for hokey@ietf.org; Wed, 11 Apr 2007 17:08:18 -0400
Received: from usaga01-in.huawei.com ([206.16.17.211])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hbk36-0005Jq-MZ
	for hokey@ietf.org; Wed, 11 Apr 2007 17:08:18 -0400
Received: from huawei.com (usaga01-in [172.18.4.6])
	by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTP id <0JGC002VTQPSC3@usaga01-in.huawei.com> for
	hokey@ietf.org; Wed, 11 Apr 2007 14:08:16 -0700 (PDT)
Received: from N737011
	(pool-71-112-139-16.sttlwa.dsl-w.verizon.net [71.112.139.16])
	by usaga01-in.huawei.com
	(iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar  3 2004))
	with ESMTPA id <0JGC00LSYQPMUZ@usaga01-in.huawei.com> for
	hokey@ietf.org; Wed, 11 Apr 2007 14:08:16 -0700 (PDT)
Date: Wed, 11 Apr 2007 14:08:15 -0700
From: Madjid Nakhjiri 
Subject: RE: [HOKEY] key scope versus Context. consensus call: key distribution
	security requirement
In-reply-to: <0JGC00KZ5Q08B8@szxga03-in.huawei.com>
To: 'Russ Housley' , 'Charles Clancy' 
Message-id: <00a101c77c7d$8652d480$2f01a8c0@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962
X-Mailer: Microsoft Office Outlook 11
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Thread-index: Acd8e2PEyvKsbAyRQbeBJ83BqZvwFQAASAOQ
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 963faf56c3a5b6715f0b71b66181e01a
Cc: 'Bernard Aboba' , 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 Russ,

Ok, yes, I stand corrected. There is no inconsistency. But there is an
overlap as you said. When we get into defining the syntax for scope versus
context for transport and protocol purposes (e.g. we want to possibly
transmit the key context along with the key itself with a AAA message) or
define "usage" for usage specific root key derivation from EMSK, it is
cleaner if there is no overlap in the definitions, so we can say:

Scope is just a bunch of identities, while context is the rest (loosely
speaking).

Thanks for the explanation on "manner". Ok, that is what I understood. So
manner is the cryptographic use of the key (derive keys, wrap keys, protect
stuff and so on).
So it seems "usage" could be another bullet for context (for the purpose of
EMSK draft, possibly not for Housley draft), where "usage" is hokey, Mobile
IP, etc.

R,

Madjid


-----Original Message-----
From: Russ Housley [mailto:housley@vigilsec.com] 
Sent: Wednesday, April 11, 2007 1:53 PM
To: Madjid Nakhjiri; 'Charles Clancy'
Cc: hokey@ietf.org; 'Bernard Aboba'
Subject: RE: [HOKEY] key scope versus Context. consensus call: key
distribution security requirement

Madjid:

See draft-housley-aaa-key-mgmt-09; I belive that key scope is defined 
as the parties to whom the key is available.  Also, a party has 
access to a particular key if it has access to all of the secret 
information needed to derive it.

There is overlap between the concepts of key scope and key 
context.  There is not an inconsistency in my view.

The manner in which a key will be used depends on the protocol 
environment that is being supported.  Will the key be used to derive 
other keys?  Will it be used to encrypt data?  Will it be used to 
encrypt other keys?  Will it be used to integrity protect data (e.g., 
compute a MAC)?  Every party that has access to the key needs to 
answer these questions the same way.

I continue to belive that the key context includes the other parties 
that are expected to perform operations with the key.  Consider an 
encryption key that is used with IPsec ESP.  These are simplex 
keys.  So, one party will perform encryption operations with the key, 
and the other party will perform decryption operation with the 
key.  Both parties need to know about the other, and which operation 
will be performed by each.

Russ


At 03:59 PM 4/11/2007, Madjid Nakhjiri wrote:
>Hi Charles,
>
>Apologize for procrastinating on my homework, I was planning on looking at
>the PS and see what text changes are needed. But it seems that we first
need
>a clear and more stringent definition of key scope and key context. Looking
>at these, the EAP keying doc and the Housley doc, and having USRK and hokey
>PS in mind, I think we should once and for all, nail the terminology down
>for the purpose of HOKEY and go forward based on that, so before suggesting
>text, I like to add a definition for "scope" and "context" to the main PS
>draft:
>
>1) scope: Housley draft does not define this, but EAP keying does:
>
>Key Scope
>      The parties to whom a key is available [EAP_keying].
>
>I suggest we adopt this for HOKEY and EMSK hierarchy drafts. However, I am
>not sure if the domain for the key would go into the scope definition or in
>the context definition.
>
>2) Context: EAP keying does not define this, but Housley does it in a way
>that causes confusion for hokey:
>
>"The context includes the following.
>
>             o  The manner in which the keying material is expected to
>                be used.
>
>             o  The other parties that are expected to have access to
>                the keying material.
>
>             o  The expected lifetime of the keying material.  Lifetime
>                of a child key SHOULD NOT be greater than the lifetime of
>                its parent in the key hierarchy."
>
>It seems that there is a bit of inconsistency in scope versus context,
>especially the second bullet: Before this exercise, I was assuming that
>scope was simply the id of the two parties sharing the key, but it seems
>that it is ALL parties that can access it.  So I think we should remove the
>second bullet and Russ and Bernard should remove that bullet as well (and
>instead add the definition of scope explicitly in the Housley draft).
>
>"The manner" in first bullet is vague to me, especially now that we are
>defining "usage specific root keys". Is "manner" a usage, such as hokey or
>Mobile IP? Is it for a domain? Is it for a crypto purpose, such as signing
>or encryption? Is it to be a root for a hierarchy and not used for traffic?
>Or is it all the above. For Housley doc this might be ok, but I think for
>hokey, we need to be more specific in our requirements on context and the
>semantics that goes in it.
>So I am suggesting something like the following for "key context" (the main
>thing is I am replacing the second bullet)
>
>             o  The usage for which the keying material is generated.
> The usage is
defined
>in [EMSK-hiearchy], e.g. Mobile IP, handover keying, etc.
>
>             o  The purpose for the keying material, e.g. traffic
protection
>(signing, encryption), signaling protection, key derivation, etc.
>
>
>             o  The expected lifetime of the keying material.  Lifetime
>                of a child key SHOULD NOT be greater than the lifetime of
>                its parent in the key hierarchy."
>
>
>
>I can send mods for requirements based on the above later.
>
>R,
>
>Madjid
>
>
>-----Original Message-----
>From: Charles Clancy [mailto:clancy@cs.umd.edu]
>Sent: Wednesday, April 04, 2007 5:39 PM
>To: Madjid Nakhjiri
>Cc: hokey@ietf.org
>Subject: Re: [HOKEY] consensus call: key distribution security requirement
>
>Madjid,
>
>My opinion was that they were all already covered by the problem
>statement in one way or another.
>
>  > 1-Confidentiality --avoiding disclosure of the keying material to
>  > passive and active attackers.
>
>Covered by saying we must conform to I-D.housley-aaa-key-mgmt.  I have
>no problem adding that as an explicit thing in section 6 though.
>
>  > 3-Validation of credential source -- the recipient must prove where
>  > the credential came from and what context it was delivered for.
>
>Prove to whom?  Regardless, that information should be included in the
>key scope and context -- section 6.1.
>
>  > 4-Validation of authorization -- the scope (intended users) of the
>  >        network access credential MUST be distributed as part of the
>  >        credential and MUST be protected to the same degree as the
>  >        credential itself.
>
>See section 6.1 of the current PS.
>
>  > Some of these requirements are simply reflections of Housley document
>  > and to me are met through a channel binding procedure.
>
>Exactly, and CB is already in the PS.
>
>Feel free to send me text if you think section 6.1 should be modified.
>
>--
>t. charles clancy, ph.d.  |  tcc@umd.edu  |  www.cs.umd.edu/~clancy
>
>
>_______________________________________________
>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 Apr 11 17:16:53 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HbkBM-0008Qp-R9; Wed, 11 Apr 2007 17:16:48 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HbkBK-0008Og-MS
	for hokey@ietf.org; Wed, 11 Apr 2007 17:16:46 -0400
Received: from numenor.qualcomm.com ([129.46.51.58])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HbkBG-0005pe-3P
	for hokey@ietf.org; Wed, 11 Apr 2007 17:16:46 -0400
Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149])
	by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id
	l3BLGaN3009692
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 11 Apr 2007 14:16:36 -0700
Received: from [10.50.77.102] (qconnect-10-50-77-102.qualcomm.com
	[10.50.77.102])
	by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id
	l3BLGYSI006212
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Wed, 11 Apr 2007 14:16:35 -0700
Message-ID: <461D5031.2040103@qualcomm.com>
Date: Wed, 11 Apr 2007 14:16:33 -0700
From: Lakshminath Dondeti 
User-Agent: Thunderbird 2.0.0.0 (Windows/20070326)
MIME-Version: 1.0
To: Madjid Nakhjiri 
Subject: Re: [HOKEY] Using an EAP method for
	HOKEY??:	was:consensuscall:EAP-ERas HOKEY protocol
References: <009501c77c70$5144e740$2f01a8c0@china.huawei.com>
In-Reply-To: <009501c77c70$5144e740$2f01a8c0@china.huawei.com>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d
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

Madjid Nakhjiri wrote:
> I think we already discussed that we do not need EAP ID request/response
> necessary for every exchange, so one 1 RT goes away there.

Hmmm, on the Authenticator to AS side, there will still have to be a 
message even if the EAP Request & Response Id exchange on the Peer to 
Authenticator link is optional.  Do you agree?

> 
> We can either load EAP ID or do a new method without EAP ID and carry IDs
> inside tokens as I have shown.

Not sure I understand that.  See above.  You need the EAP Response 
Identity message on the Authenticator to the AS.  If you want the 
Authenticator to send anything meaningful in that message, that means 
either modifications to the Authenticators or having the EAP Request & 
Response Id run between the Peer and the Authenticator.

> 
> We are also discussing loading EAP Success, rather than sending an empty
> finish followed by a dumb success, so another RT goes away there too.

How do you send EAP Success, overloaded, reliably without modifying 
authenticators?

> 
> That analysis is pretty stale at this point. No need to keep resending that
> link.

Err, ok, I will ignore this.

regards,
Lakshminath

> 
> Madjid 
> 
> -----Original Message-----
> From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] 
> Sent: Tuesday, April 10, 2007 7:16 PM
> To: hokey@ietf.org
> Subject: RE: [HOKEY] Using an EAP method for HOKEY??:
> was:consensuscall:EAP-ERas HOKEY protocol
> 
> 
> I'm feeling a bit lazy to re-hash all the relevant discussions yet
> another time, so, I'm just going to point to some old discussions on
> this topic. The only means by which we can avoid authenticator changes
> is using a method-based transport as shown in this email from Charles,
> back in December: 
> 
> http://www.opendiameter.org/pipermail/hokeyp/2006-December/000450.html
> 
> And, the discussions we had about all the options captured above at the
> interim meeting were summarized in the following email: 
> 
> http://www1.ietf.org/mail-archive/web/hokey/current/msg00077.html
> 
> We've had a number of other discussions on this list on the very same
> topic as well, if people want to read further. 
> 
> Vidya
> 
> _____________________________________________
> 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 Wed Apr 11 23:05:34 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hbpcs-0001CZ-5X; Wed, 11 Apr 2007 23:05:34 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HbjoK-0005TY-PE
	for hokey@ietf.org; Wed, 11 Apr 2007 16:53:00 -0400
Received: from woodstock.binhost.com ([66.150.120.2])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HbjoI-0002JN-CL
	for hokey@ietf.org; Wed, 11 Apr 2007 16:53:00 -0400
Received: (qmail 1523 invoked by uid 0); 11 Apr 2007 20:52:47 -0000
Received: from unknown (HELO THINKPADR52.vigilsec.com) (72.66.14.186)
	by woodstock.binhost.com with SMTP; 11 Apr 2007 20:52:47 -0000
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Wed, 11 Apr 2007 16:52:48 -0400
To: Madjid Nakhjiri ,
	'Charles Clancy' 
From: Russ Housley 
Subject: RE: [HOKEY] key scope versus Context. consensus call: key
	distribution security requirement
In-Reply-To: <009601c77c73$eb82ce50$2f01a8c0@china.huawei.com>
References: <4614453D.9070503@cs.umd.edu>
	<009601c77c73$eb82ce50$2f01a8c0@china.huawei.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb
X-Mailman-Approved-At: Wed, 11 Apr 2007 23:05:32 -0400
Cc: 'Bernard Aboba' , 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
Message-Id: 

Madjid:

See draft-housley-aaa-key-mgmt-09; I belive that key scope is defined 
as the parties to whom the key is available.  Also, a party has 
access to a particular key if it has access to all of the secret 
information needed to derive it.

There is overlap between the concepts of key scope and key 
context.  There is not an inconsistency in my view.

The manner in which a key will be used depends on the protocol 
environment that is being supported.  Will the key be used to derive 
other keys?  Will it be used to encrypt data?  Will it be used to 
encrypt other keys?  Will it be used to integrity protect data (e.g., 
compute a MAC)?  Every party that has access to the key needs to 
answer these questions the same way.

I continue to belive that the key context includes the other parties 
that are expected to perform operations with the key.  Consider an 
encryption key that is used with IPsec ESP.  These are simplex 
keys.  So, one party will perform encryption operations with the key, 
and the other party will perform decryption operation with the 
key.  Both parties need to know about the other, and which operation 
will be performed by each.

Russ


At 03:59 PM 4/11/2007, Madjid Nakhjiri wrote:
>Hi Charles,
>
>Apologize for procrastinating on my homework, I was planning on looking at
>the PS and see what text changes are needed. But it seems that we first need
>a clear and more stringent definition of key scope and key context. Looking
>at these, the EAP keying doc and the Housley doc, and having USRK and hokey
>PS in mind, I think we should once and for all, nail the terminology down
>for the purpose of HOKEY and go forward based on that, so before suggesting
>text, I like to add a definition for "scope" and "context" to the main PS
>draft:
>
>1) scope: Housley draft does not define this, but EAP keying does:
>
>Key Scope
>      The parties to whom a key is available [EAP_keying].
>
>I suggest we adopt this for HOKEY and EMSK hierarchy dFrom hokey-bounces@ietf.org Wed Apr 11 23:05:34 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hbpcs-0001CZ-5X; Wed, 11 Apr 2007 23:05:34 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HbjoK-0005TY-PE
	for hokey@ietf.org; Wed, 11 Apr 2007 16:53:00 -0400
Received: from woodstock.binhost.com ([66.150.120.2])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HbjoI-0002JN-CL
	for hokey@ietf.org; Wed, 11 Apr 2007 16:53:00 -0400
Received: (qmail 1523 invoked by uid 0); 11 Apr 2007 20:52:47 -0000
Received: from unknown (HELO THINKPADR52.vigilsec.com) (72.66.14.186)
	by woodstock.binhost.com with SMTP; 11 Apr 2007 20:52:47 -0000
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Wed, 11 Apr 2007 16:52:48 -0400
To: Madjid Nakhjiri ,
	'Charles Clancy' 
From: Russ Housley 
Subject: RE: [HOKEY] key scope versus Context. consensus call: key
	distribution security requirement
In-Reply-To: <009601c77c73$eb82ce50$2f01a8c0@china.huawei.com>
References: <4614453D.9070503@cs.umd.edu>
	<009601c77c73$eb82ce50$2f01a8c0@china.huawei.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb
X-Mailman-Approved-At: Wed, 11 Apr 2007 23:05:32 -0400
Cc: 'Bernard Aboba' , 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
Message-Id: 

Madjid:

See draft-housley-aaa-key-mgmt-09; I belive that key scope is defined 
as the parties to whom the key is available.  Also, a party has 
access to a particular key if it has access to all of the secret 
information needed to derive it.

There is overlap between the concepts of key scope and key 
context.  There is not an inconsistency in my view.

The manner in which a key will be used depends on the protocol 
environment that is being supported.  Will the key be used to derive 
other keys?  Will it be used to encrypt data?  Will it be used to 
encrypt other keys?  Will it be used to integrity protect data (e.g., 
compute a MAC)?  Every party that has access to the key needs to 
answer these questions the same way.

I continue to belive that the key context includes the other parties 
that are expected to perform operations with the key.  Consider an 
encryption key that is used with IPsec ESP.  These are simplex 
keys.  So, one party will perform encryption operations with the key, 
and the other party will perform decryption operation with the 
key.  Both parties need to know about the other, and which operation 
will be performed by each.

Russ


At 03:59 PM 4/11/2007, Madjid Nakhjiri wrote:
>Hi Charles,
>
>Apologize for procrastinating on my homework, I was planning on looking at
>the PS and see what text changes are needed. But it seems that we first need
>a clear and more stringent definition of key scope and key context. Looking
>at these, the EAP keying doc and the Housley doc, and having USRK and hokey
>PS in mind, I think we should once and for all, nail the terminology down
>for the purpose of HOKEY and go forward based on that, so before suggesting
>text, I like to add a definition for "scope" and "context" to the main PS
>draft:
>
>1) scope: Housley draft does not define this, but EAP keying does:
>
>Key Scope
>      The parties to whom a key is available [EAP_keying].
>
>I suggest we adopt this for HOKEY and EMSK hierarchy drafts. However, I am
>not sure if the domain for the key would go into the scope definition or in
>the context definition.
>
>2) Context: EAP keying does not define this, but Housley does it in a way
>that causes confusion for hokey:
>
>"The context includes the following.
>
>             o  The manner in which the keying material is expected to
>                be used.
>
>             o  The other parties that are expected to have access to
>                the keying material.
>
>             o  The expected lifetime of the keying material.  Lifetime
>                of a child key SHOULD NOT be greater than the lifetime of
>                its parent in the key hierarchy."
>
>It seems that there is a bit of inconsistency in scope versus context,
>especially the second bullet: Before this exercise, I was assuming that
>scope was simply the id of the two parties sharing the key, but it seems
>that it is ALL parties that can access it.  So I think we should remove the
>second bullet and Russ and Bernard should remove that bullet as well (and
>instead add the definition of scope explicitly in the Housley draft).
>
>"The manner" in first bullet is vague to me, especially now that we are
>defining "usage specific root keys". Is "manner" a usage, such as hokey or
>Mobile IP? Is it for a domain? Is it for a crypto purpose, such as signing
>or encryption? Is it to be a root for a hierarchy and not used for traffic?
>Or is it all the above. For Housley doc this might be ok, but I think for
>hokey, we need to be more specific in our requirements on context and the
>semantics that goes in it.
>So I am suggesting something like the following for "key context" (the main
>thing is I am replacing the second bullet)
>
>             o  The usage for which the keying material is generated.
> The usage is defined
>in [EMSK-hiearchy], e.g. Mobile IP, handover keying, etc.
>
>             o  The purpose for the keying material, e.g. traffic protection
>(signing, encryption), signaling protection, key derivation, etc.
>
>
>             o  The expected lifetime of the keying material.  Lifetime
>                of a child key SHOULD NOT be greater than the lifetime of
>                its parent in the key hierarchy."
>
>
>
>I can send mods for requirements based on the above later.
>
>R,
>
>Madjid
>
>
>-----Original Message-----
>From: Charles Clancy [mailto:clancy@cs.umd.edu]
>Sent: Wednesday, April 04, 2007 5:39 PM
>To: Madjid Nakhjiri
>Cc: hokey@ietf.org
>Subject: Re: [HOKEY] consensus call: key distribution security requirement
>
>Madjid,
>
>My opinion was that they were all already covered by the problem
>statement in one way or another.
>
>  > 1-Confidentiality --avoiding disclosure of the keying material to
>  > passive and active attackers.
>
>Covered by saying we must conform to I-D.housley-aaa-key-mgmt.  I have
>no problem adding that as an explicit thing in section 6 though.
>
>  > 3-Validation of credential source -- the recipient must prove where
>  > the credential came from and what context it was delivered for.
>
>Prove to whom?  Regardless, that information should be included in the
>key scope and context -- section 6.1.
>
>  > 4-Validation of authorization -- the scope (intended users) of the
>  >        network access credential MUST be distributed as part of the
>  >        credential and MUST be protected to the same degree as the
>  >        credential itself.
>
>See section 6.1 of the current PS.
>
>  > Some of these requirements are simply reflections of Housley document
>  > and to me are met through a channel binding procedure.
>
>Exactly, and CB is already in the PS.
>
>Feel free to send me text if you think section 6.1 should be modified.
>
>--
>t. charles clancy, ph.d.  |  tcc@umd.edu  |  www.cs.umd.edu/~clancy
>
>
>_______________________________________________
>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 Apr 11 23:05:34 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hbpcs-0001Ce-9t; Wed, 11 Apr 2007 23:05:34 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HbkNQ-0004VJ-Hi
	for hokey@ietf.org; Wed, 11 Apr 2007 17:29:17 -0400
Received: from woodstock.binhost.com ([66.150.120.2])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HbkNP-00084b-4K
	for hokey@ietf.org; Wed, 11 Apr 2007 17:29:16 -0400
Received: (qmail 2475 invoked by uid 0); 11 Apr 2007 21:29:07 -0000
Received: from unknown (HELO THINKPADR52.vigilsec.com) (72.66.14.186)
	by woodstock.binhost.com with SMTP; 11 Apr 2007 21:29:07 -0000
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Wed, 11 Apr 2007 17:20:22 -0400
To: Madjid Nakhjiri ,
	'Charles Clancy' 
From: Russ Housley 
Subject: RE: [HOKEY] key scope versus Context. consensus call: key
	distribution security requirement
In-Reply-To: <00a101c77c7d$8652d480$2f01a8c0@china.huawei.com>
References: <0JGC00KZ5Q08B8@szxga03-in.huawei.com>
	<00a101c77c7d$8652d480$2f01a8c0@china.huawei.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 93df555cbdbcdae9621e5b95d44b301e
X-Mailman-Approved-At: Wed, 11 Apr 2007 23:05:32 -0400
Cc: 'Bernard Aboba' , 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
Message-Id: 

If the set of data element together provides the scope and context, 
then you will get no trouble from me.

Russ

At 05:08 PM 4/11/2007, Madjid Nakhjiri wrote:
>Hi Russ,
>
>Ok, yes, I stand corrected. There is no inconsistency. But there is an
>overlap as you said. When we get into defining the syntax for scope versus
>context for transport and protocol purposes (e.g. we want to possibly
>transmit the key context along with the key itself with a AAA message) or
>define "usage" for usage specific root key derivation from EMSK, it is
>cleaner if there is no overlap in the definitions, so we can say:
>
>Scope is just a bunch of identities, while context is the rest (loosely
>speaking).
>
>Thanks for the explanation on "manner". Ok, that is what I understood. So
>manner is the cryptographic use of the key (derive keys, wrap keys, protect
>stuff and so on).
>So it seems "usage" could be another bullet for context (for the purpose of
>EMSK draft, possibly not for Housley draft), where "usage" is hokey, Mobile
>IP, etc.
>
>R,
>
>Madjid
>
>
>-----Original Message-----
>From: Russ Housley [mailto:housley@vigilsec.com]
>Sent: Wednesday, April 11, 2007 1:53 PM
>To: Madjid Nakhjiri; 'Charles Clancy'
>Cc: hokey@ietf.org; 'Bernard Aboba'
>Subject: RE: [HOKEY] key scope versus Context. consensus call: key
>distribution security requirement
>
>Madjid:
>
>See draft-housley-aaa-key-mgmt-09; I belive that key scope is defined
>as the parties to whom the key is available.  Also, a party has
>access to a particular key if it has access to all of the secret
>information needed to derive it.
>
>There is overlap between the concepts of key scope and key
>context.  There is not an inconsistency in my view.
>
>The manner in which a key will be used depends on the protocol
>environment that is being supported.  Will the key be used to derive
>other keys?  Will it be used to encrypt data?  Will it be used to
>encrypt other keys?  Will it be used to integrity protect data (e.g.,
>compute a MAC)?  Every party that has access to the key needs to
>answer these questions the same way.
>
>I continue to belive that the key context includes the other parties
>that are expected to perform operations with the key.  Consider an
>encryption key that is used with IPsec ESP.  These are simplex
>keys.  So, one party will perform encryption operations with the key,
>and the other party will perform decryption operation with the
>key.  Both parties need to know about the other, and which operation
>will be performed by each.
>
>Russ
>
>
>At 03:59 PM 4/11/2007, Madjid Nakhjiri wrote:
> >Hi Charles,
> >
> >Apologize for procrastinating on my homework, I was planning on looking at
> >the PS and see what text changes are needed. But it seems that we first
>need
> >a clear and more stringent definition of key scope and key context. Looking
> >at these, the EAP keying doc and the Housley doc, and having USRK and hokey
> >PS in mind, I think we should once and for all, nail the terminology down
> >for the purpose of HOKEY and go forward based on that, so before suggesting
> >text, I like to add a definition for "scope" and "context" to the main PS
> >draft:
> >
> >1) scope: Housley draft does not define this, but EAP keying does:
> >
> >Key Scope
> >      The parties to whom a key is available [EAP_keying].
> >
> >I suggest we adopt this for HOKEY and EMSK hierarchy drafts. However, I am
> >not sure if the domain for the key would go into the scope definition or in
> >the context definition.
> >
> >2) Context: EAP keying does not define this, but Housley does it in a way
> >that causes confusion for hokey:
> >
> >"The context includes the following.
> >
> >             o  The manner in which the keying material is expected to
> >                be used.
> >
> >             o  The other parties that are expected to have access to
> >                the keying material.
> >
> >             o  The expected lifetime of the keying material.  Lifetime
> >                of a child key SHOULD NOT be greater than the lifetime of
> >                its parent in the key hierarchy."
> >
> >It seems that there is a bit of inconsistency in scope versus context,
> >especially the second bullet: Before this exercise, I was assuming that
> >scope was simply the id of the two parties sharing the key, but it seems
> >that it is ALL parties that can access it.  So I think we should remove the
> >second bullet and Russ and Bernard should remove that bullet as well (and
> >instead add the definition of scope explicitly in the Housley draft).
> >
> >"The manner" in first bullet is vague to me, especially now that we are
> >defining "usage specific root keys". Is "manner" a usage, such as hokey or
> >Mobile IP? Is it for a domain? Is it for a crypto purpose, such as signing
> >or encryption? Is it to be a root for a hierarchy and not used for traffic?
> >Or is it all the above. For Housley doc this might be ok, but I think for
> >hokey, we need to be more specific in our requirements on context and the
> >semantics that goes in it.
> >So I am suggesting something like the following for "key context" (the main
> >thing is I am replacing the second bullet)
> >
> >             o  The usage for which the keying material is generated.
> > The usage is
>defined
> >in [EMSK-hiearchy], e.g. Mobile IP, handover keying, etc.
> >
> >             o  The purpose for the keying material, e.g. traffic
>protection
> >(signing, encryption), signaling protection, key derivation, etc.
> >
> >
> >             o  The expected lifetime of the keying material.  Lifetime
> >                of a child key SHOULD NOT be greater than the lifetime of
> >                its parent in the key hierarchy."
> >
> >
> >
> >I can send mods for requirements based on the above later.
> >
> >R,
> >
> >Madjid
> >
> >
> >-----Original Message-----
> >From: Charles Clancy [mailto:clancy@cs.umd.edu]
> >Sent: Wednesday, April 04, 2007 5:39 PM
> >To: Madjid Nakhjiri
> >Cc: hokey@ietf.org
> >Subject: Re: [HOKEY] consensus call: key distribution security requirement
> >
> >Madjid,
> >
> >My opinion was that they were all already covered by the problem
> >statement in one way or another.
> >
> >  > 1-Confidentiality --avoiding disclosure of the keying material to
> >  > passive and active attackers.
> >
> >Covered by saying we must conform to I-D.housley-aaa-key-mgmt.  I have
> >no problem adding that as an explicit thing in section 6 though.
> >
> >  > 3-Validation of credential source -- the recipient must prove where
> >  > the credential came from and what context it was delivered for.
> >
> >Prove to whom?  Regardless, that information should be included in the
> >key scope and context -- section 6.1.
> >
> >  > 4-Validation of authorization -- the scope (intended users) of the
> >  >        network access credential MUST be distributed as part of the
> >  >        credential and MUST be protected to the same degree as the
> >  >        credential itself.
> >
> >See section 6.1 of the current PS.
> >
> >  > Some of these requirements are simply reflections of Housley document
> >  > and to me are met through a channel binding procedure.
> >
> >Exactly, and CB is already in the PS.
> >
> >Feel free to send me text if you think section 6.1 should be modified.
> >
> >--
> >t. charles clancy, ph.d.  |  tcc@umd.edu  |  www.cs.umd.edu/~clancy
> >
> >
> >_______________________________________________
> >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





rafts. However, I am
>not sure if the domain for the key would go into the scope definition or in
>the context definition.
>
>2) Context: EAP keying does not define this, but Housley does it in a way
>that causes confusion for hokey:
>
>"The context includes the following.
>
>             o  The manner in which the keying material is expected to
>                be used.
>
>             o  The other parties that are expected to have access to
>                the keying material.
>
>             o  The expected lifetime of the keying material.  Lifetime
>                of a child key SHOULD NOT be greater than the lifetime of
>                its parent in the key hierarchy."
>
>It seems that there is a bit of inconsistency in scope versus context,
>especially the second bullet: Before this exercise, I was assuming that
>scope was simply the id of the two parties sharing the key, but it seems
>that it is ALL parties that can access it.  So I think we should remove the
>second bullet and Russ and Bernard should remove that bullet as well (and
>instead add the definition of scope explicitly in the Housley draft).
>
>"The manner" in first bullet is vague to me, especially now that we are
>defining "usage specific root keys". Is "manner" a usage, such as hokey or
>Mobile IP? Is it for a domain? Is it for a crypto purpose, such as signing
>or encryption? Is it to be a root for a hierarchy and not used for traffic?
>Or is it all the above. For Housley doc this might be ok, but I think for
>hokey, we need to be more specific in our requirements on context and the
>semantics that goes in it.
>So I am suggesting something like the following for "key context" (the main
>thing is I am replacing the second bullet)
>
>             o  The usage for which the keying material is generated.
> The usage is defined
>in [EMSK-hiearchy], e.g. Mobile IP, handover keying, etc.
>
>             o  The purpose for the keying material, e.g. traffic protection
>(signing, encryption), signaling protection, key derivation, etc.
>
>
>             o  The expected lifetime of the keying material.  Lifetime
>                of a child key SHOULD NOT be greater than the lifetime of
>                its parent in the key hierarchy."
>
>
>
>I can send mods for requirements based on the above later.
>
>R,
>
>Madjid
>
>
>-----Original Message-----
>From: Charles Clancy [mailto:clancy@cs.umd.edu]
>Sent: Wednesday, April 04, 2007 5:39 PM
>To: Madjid Nakhjiri
>Cc: hokey@ietf.org
>Subject: Re: [HOKEY] consensus call: key distribution security requirement
>
>Madjid,
>
>My opinion was that they were all already covered by the problem
>statement in one way or another.
>
>  > 1-Confidentiality --avoiding disclosure of the keying material to
>  > passive and active attackers.
>
>Covered by saying we must conform to I-D.housley-aaa-key-mgmt.  I have
>no problem adding that as an explicit thing in section 6 though.
>
>  > 3-Validation of credential source -- the recipient must prove where
>  > the credential came from and what context it was delivered for.
>
>Prove to whom?  Regardless, that information should be included in the
>key scope and context -- section 6.1.
>
>  > 4-Validation of authorization -- the scope (intended users) of the
>  >        network access credential MUST be distributed as part of the
>  >        credential and MUST be protected to the same degree as the
>  >        credential itself.
>
>See section 6.1 of the current PS.
>
>  > Some of these requirements are simply reflections of Housley document
>  > and to me are met through a channel binding procedure.
>
>Exactly, and CB is already in the PS.
>
>Feel free to send me text if you think section 6.1 should be modified.
>
>--
>t. charles clancy, ph.d.  |  tcc@umd.edu  |  www.cs.umd.edu/~clancy
>
>
>_______________________________________________
>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 Apr 11 23:05:34 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hbpcs-0001Ce-9t; Wed, 11 Apr 2007 23:05:34 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HbkNQ-0004VJ-Hi
	for hokey@ietf.org; Wed, 11 Apr 2007 17:29:17 -0400
Received: from woodstock.binhost.com ([66.150.120.2])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HbkNP-00084b-4K
	for hokey@ietf.org; Wed, 11 Apr 2007 17:29:16 -0400
Received: (qmail 2475 invoked by uid 0); 11 Apr 2007 21:29:07 -0000
Received: from unknown (HELO THINKPADR52.vigilsec.com) (72.66.14.186)
	by woodstock.binhost.com with SMTP; 11 Apr 2007 21:29:07 -0000
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Wed, 11 Apr 2007 17:20:22 -0400
To: Madjid Nakhjiri ,
	'Charles Clancy' 
From: Russ Housley 
Subject: RE: [HOKEY] key scope versus Context. consensus call: key
	distribution security requirement
In-Reply-To: <00a101c77c7d$8652d480$2f01a8c0@china.huawei.com>
References: <0JGC00KZ5Q08B8@szxga03-in.huawei.com>
	<00a101c77c7d$8652d480$2f01a8c0@china.huawei.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 93df555cbdbcdae9621e5b95d44b301e
X-Mailman-Approved-At: Wed, 11 Apr 2007 23:05:32 -0400
Cc: 'Bernard Aboba' , 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
Message-Id: 

If the set of data element together provides the scope and context, 
then you will get no trouble from me.

Russ

At 05:08 PM 4/11/2007, Madjid Nakhjiri wrote:
>Hi Russ,
>
>Ok, yes, I stand corrected. There is no inconsistency. But there is an
>overlap as you said. When we get into defining the syntax for scope versus
>context for transport and protocol purposes (e.g. we want to possibly
>transmit the key context along with the key itself with a AAA message) or
>define "usage" for usage specific root key derivation from EMSK, it is
>cleaner if there is no overlap in the definitions, so we can say:
>
>Scope is just a bunch of identities, while context is the rest (loosely
>speaking).
>
>Thanks for the explanation on "manner". Ok, that is what I understood. So
>manner is the cryptographic use of the key (derive keys, wrap keys, protect
>stuff and so on).
>So it seems "usage" could be another bullet for context (for the purpose of
>EMSK draft, possibly not for Housley draft), where "usage" is hokey, Mobile
>IP, etc.
>
>R,
>
>Madjid
>
>
>-----Original Message-----
>From: Russ Housley [mailto:housley@vigilsec.com]
>Sent: Wednesday, April 11, 2007 1:53 PM
>To: Madjid Nakhjiri; 'Charles Clancy'
>Cc: hokey@ietf.org; 'Bernard Aboba'
>Subject: RE: [HOKEY] key scope versus Context. consensus call: key
>distribution security requirement
>
>Madjid:
>
>See draft-housley-aaa-key-mgmt-09; I belive that key scope is defined
>as the parties to whom the key is available.  Also, a party has
>access to a particular key if it has access to all of the secret
>information needed to derive it.
>
>There is overlap between the concepts of key scope and key
>context.  There is not an inconsistency in my view.
>
>The manner in which a key will be used depends on the protocol
>environment that is being supported.  Will the key be used to derive
>other keys?  Will it be used to encrypt data?  Will it be used to
>encrypt other keys?  Will it be used to integrity protect data (e.g.,
>compute a MAC)?  Every party that has access to the key needs to
>answer these questions the same way.
>
>I continue to belive that the key context includes the other parties
>that are expected to perform operations with the key.  Consider an
>encryption key that is used with IPsec ESP.  These are simplex
>keys.  So, one party will perform encryption operations with the key,
>and the other party will perform decryption operation with the
>key.  Both parties need to know about the other, and which operation
>will be performed by each.
>
>Russ
>
>
>At 03:59 PM 4/11/2007, Madjid Nakhjiri wrote:
> >Hi Charles,
> >
> >Apologize for procrastinating on my homework, I was planning on looking at
> >the PS and see what text changes are needed. But it seems that we first
>need
> >a clear and more stringent definition of key scope and key context. Looking
> >at these, the EAP keying doc and the Housley doc, and having USRK and hokey
> >PS in mind, I think we should once and for all, nail the terminology down
> >for the purpose of HOKEY and go forward based on that, so before suggesting
> >text, I like to add a definition for "scope" and "context" to the main PS
> >draft:
> >
> >1) scope: Housley draft does not define this, but EAP keying does:
> >
> >Key Scope
> >      The parties to whom a key is available [EAP_keying].
> >
> >I suggest we adopt this for HOKEY and EMSK hierarchy drafts. However, I am
> >not sure if the domain for the key would go into the scope definition or in
> >the context definition.
> >
> >2) Context: EAP keying does not define this, but Housley does it in a way
> >that causes confusion for hokey:
> >
> >"The context includes the following.
> >
> >             o  The manner in which the keying material is expected to
> >                be used.
> >
> >             o  The other parties that are expected to have access to
> >                the keying material.
> >
> >             o  The expected lifetime of the keying material.  Lifetime
> >                of a child key SHOULD NOT be greater than the lifetime of
> >                its parent in the key hierarchy."
> >
> >It seems that there is a bit of inconsistency in scope versus context,
> >especially the second bullet: Before this exercise, I was assuming that
> >scope was simply the id of the two parties sharing the key, but it seems
> >that it is ALL parties that can access it.  So I think we should remove the
> >second bullet and Russ and Bernard should remove that bullet as well (and
> >instead add the definition of scope explicitly in the Housley draft).
> >
> >"The manner" in first bullet is vague to me, especially now that we are
> >defining "usage specific root keys". Is "manner" a usage, such as hokey or
> >Mobile IP? Is it for a domain? Is it for a crypto purpose, such as signing
> >or encryption? Is it to be a root for a hierarchy and not used for traffic?
> >Or is it all the above. For Housley doc this might be ok, but I think for
> >hokey, we need to be more specific in our requirements on context and the
> >semantics that goes in it.
> >So I am suggesting something like the following for "key context" (the main
> >thing is I am replacing the second bullet)
> >
> >             o  The usage for which the keying material is generated.
> > The usage is
>defined
> >in [EMSK-hiearchy], e.g. Mobile IP, handover keying, etc.
> >
> >             o  The purpose for the keying material, e.g. traffic
>protection
> >(signing, encryption), signaling protection, key derivation, etc.
> >
> >
> >             o  The expected lifetime of the keying material.  Lifetime
> >                of a child key SHOULD NOT be greater than the lifetime of
> >                its parent in the key hierarchy."
> >
> >
> >
> >I can send mods for requirements based on the above later.
> >
> >R,
> >
> >Madjid
> >
> >
> >-----Original Message-----
> >From: Charles Clancy [mailto:clancy@cs.umd.edu]
> >Sent: Wednesday, April 04, 2007 5:39 PM
> >To: Madjid Nakhjiri
> >Cc: hokey@ietf.org
> >Subject: Re: [HOKEY] consensus call: key distribution security requirement
> >
> >Madjid,
> >
> >My opinion was that they were all already covered by the problem
> >statement in one way or another.
> >
> >  > 1-Confidentiality --avoiding disclosure of the keying material to
> >  > passive and active attackers.
> >
> >Covered by saying we must conform to I-D.housley-aaa-key-mgmt.  I have
> >no problem adding that as an explicit thing in section 6 though.
> >
> >  > 3-Validation of credential source -- the recipient must prove where
> >  > the credential came from and what context it was delivered for.
> >
> >Prove to whom?  Regardless, that information should be included in the
> >key scope and context -- section 6.1.
> >
> >  > 4-Validation of authorization -- the scope (intended users) of the
> >  >        network access credential MUST be distributed as part of the
> >  >        credential and MUST be protected to the same degree as the
> >  >        credential itself.
> >
> >See section 6.1 of the current PS.
> >
> >  > Some of these requirements are simply reflections of Housley document
> >  > and to me are met through a channel binding procedure.
> >
> >Exactly, and CB is already in the PS.
> >
> >Feel free to send me text if you think section 6.1 should be modified.
> >
> >--
> >t. charles clancy, ph.d.  |  tcc@umd.edu  |  www.cs.umd.edu/~clancy
> >
> >
> >_______________________________________________
> >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 Apr 12 04:06: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 1HbuK2-0001hW-0V; Thu, 12 Apr 2007 04:06:26 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HbuK0-0001hO-NK
	for hokey@ietf.org; Thu, 12 Apr 2007 04:06:24 -0400
Received: from mail.um.es ([155.54.212.109])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbuK0-0007bJ-5e
	for hokey@ietf.org; Thu, 12 Apr 2007 04:06:24 -0400
Received: from localhost (localhost [127.0.0.1])
	by mail.um.es (Postfix) with ESMTP id E5B3223CECC;
	Thu, 12 Apr 2007 10:06:20 +0200 (CEST)
Received: from mail.um.es ([127.0.0.1])
	by localhost (xenon2 [127.0.0.1]) (amavisd-new, port 10024) with LMTP
	id 31558-01-82; Thu, 12 Apr 2007 10:06:18 +0200 (CEST)
Received: from [155.54.205.13] (inf-205-13.um.es [155.54.205.13])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mail.um.es (Postfix) with ESMTP id 1EDC223CF52;
	Thu, 12 Apr 2007 10:06:14 +0200 (CEST)
Message-ID: <461DE873.4070108@dif.um.es>
Date: Thu, 12 Apr 2007 10:06:11 +0200
From: Rafa Marin Lopez 
Organization: University of Murcia
User-Agent: Thunderbird 1.5.0.8 (X11/20061115)
MIME-Version: 1.0
To: Madjid Nakhjiri 
Subject: Re: [HOKEY] nakhjiri-hokey-hierarchy-04 available
References: <007301c77afa$d1d83a50$2f01a8c0@china.huawei.com>
In-Reply-To: <007301c77afa$d1d83a50$2f01a8c0@china.huawei.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at telemat.um.es
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 31247fb3be228bb596db9127becad0bc
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

Madjid Nakhjiri escribi=F3:
> Hi Folks,
>  =20
Hi Madjid,
> Trying to see how the various pieces of the puzzle from EAP signaling t=
o key
> hierarchy and 3 party key distribution fit together, I have updated the=
 key
> hierarchy draft. The draft tries to follow the new guidelines for use o=
f
> EMSK and is experimenting with use of EMSK in deriving the handover roo=
t key
> for use in multiple domains.
>  =20
I have taken a look to the I-D and I'd suggest to separate the EAP=20
method based signalling from the
handover key hierarchy content into a separate I-D. That would really=20
help to clarify things.
You may count on me for this.

As a note, to me, EAP-HR you describe should work as a general transport=20
(and therefore independent of the specific 3-party protocol) for a still=20
under
definition 3-party protocol that should be in another I-D as Charles=20
suggested.

Regarding to the message sent by EAP peer upon receiving the EAP Req/Id,=20
I would like to comment that we are experimenting (with a=20
proof-of-concept testbed) a trade-off solution based on=20
cryptographically generated identities which are built by using keys=20
derived from the EMSK. The identity is encoded in base64 format and=20
included in the EAP response/identity and forwarded. The AAA server can=20
verify that the identity was generated by using a valid key. We have=20
tested this in a linksys access point and we have not found any problem=20
so far. The solution implies little modifications at EAP peer and EAP=20
server state machines (not the transitions itself but the states).=20
Fortunately, the EAP authenticator state machine does not need any=20
modification.
=20
However, the EAP peer must relay in the security association protocol in=20
order to complete the process and to know everything was ok. So a sort=20
of EAP success carrying authenticated data would really help :).


> The draft also discusses the use of 3 party key distribution, the param=
eters
> involved, the AAA attributes and EAP extensions.
>  =20
This might also be included in the separated EAP-HR I-D.

My 0.02 cents.
> The draft can be found at:
>
> http://www.ietf.org/internet-drafts/draft-nakhjiri-hokey-hierarchy-04.t=
xt
>
> comments and discussions are welcome.
>
> R,
>
> Madjid
>
>
>
>
> _______________________________________________
> HOKEY mailing list
> HOKEY@ietf.org
> https://www1.ietf.org/mailman/listinfo/hokey
>
>
>  =20


--=20
------------------------------------------------------
Rafael Marin Lopez
Depto. Ing. de la Info. y las Comunicaciones
Faculty of Computer Science-University of Murcia
30100 Murcia - Spain
Telf: +34968398501    e-mail: rafa@dif.um.es
------------------------------------------------------


_______________________________________________
HOKEY mailing list
HOKEY@ietf.org
https://www1.ietf.org/mailman/listinfo/hokey



From hokey-bounces@ietf.org Thu Apr 12 04:13:12 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HbuQa-0005K6-8i; Thu, 12 Apr 2007 04:13:12 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HbuQY-0005GA-IP
	for hokey@ietf.org; Thu, 12 Apr 2007 04:13:10 -0400
Received: from mail.um.es ([155.54.212.109])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbuQV-0001Cp-L2
	for hokey@ietf.org; Thu, 12 Apr 2007 04:13:10 -0400
Received: from localhost (localhost [127.0.0.1])
	by mail.um.es (Postfix) with ESMTP id 0BAE523CE04;
	Thu, 12 Apr 2007 10:13:07 +0200 (CEST)
Received: from mail.um.es ([127.0.0.1])
	by localhost (xenon2 [127.0.0.1]) (amavisd-new, port 10024) with LMTP
	id 32183-01-47; Thu, 12 Apr 2007 10:13:06 +0200 (CEST)
Received: from [155.54.205.13] (inf-205-13.um.es [155.54.205.13])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mail.um.es (Postfix) with ESMTP id B206F23C5DB;
	Thu, 12 Apr 2007 10:13:05 +0200 (CEST)
Message-ID: <461DEA0F.7080302@dif.um.es>
Date: Thu, 12 Apr 2007 10:13:03 +0200
From: Rafa Marin Lopez 
Organization: University of Murcia
User-Agent: Thunderbird 1.5.0.8 (X11/20061115)
MIME-Version: 1.0
To: Madjid Nakhjiri ,
	'Yoshihiro Ohba' 
Subject: Re: [HOKEY] Using an EAP method for HOKEY??: was:
	consensus	call:EAP-ER as HOKEY protocol
References: <009e01c77bcd$c47b5e40$2f01a8c0@china.huawei.com>
In-Reply-To: <009e01c77bcd$c47b5e40$2f01a8c0@china.huawei.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at telemat.um.es
X-Spam-Score: 0.0 (/)
X-Scan-Signature: fac892abe0c719c7bb99f6e7c710cdae
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 Madjid , Yoshi, all
> Now as far protecting other data to be carried by EAP Success, today's EAP
> Success has some issues that needs fixing, as I mentioned in email to
> Charles, either by fixing the current EAP success or by adding a new EAP
> success that get both security and reliability protection.
>   
I'd rather see a new EAP success (as Yoshi suggests) but carrying some 
authenticated information instead of integrating that security in the 
EAP success itself. In other words, to allow the new EAP success having 
more than 4 bytes should be enough.

Best Regards...

> Madjid
>
> -----Original Message-----
> From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] 
> Sent: Tuesday, April 10, 2007 5:02 PM
> To: Madjid Nakhjiri
> Cc: hokey@ietf.org
> Subject: Re: [HOKEY] Using an EAP method for HOKEY??: was: consensus
> call:EAP-ER as HOKEY protocol
>
> Madjid,
>
> I was not mentioning server to authenticator part.  I was mentioning
> authenticator to peer part.  I believe message 4 (which uses
> EAP-Success in your proposal, right?) requires reliable delivery.
>
> Yoshihiro Ohba
>
>
> On Tue, Apr 10, 2007 at 11:37:15AM -0700, Madjid Nakhjiri wrote:
>   
>> Yoshi,
>>
>> Please note the terminology, 
>>
>>     
>>>    3  Server to Authenticator: AAA({PID,AID,KNpa, KLpa, Kpa}KEas),
>>>       AAA(EAP(KNpa, KLpa, KNps, [PID, AID, DID, Np+1,KNpa,KLpa,
>>>       KNps]Kps))
>>>       
>> the key to be shared by peer and authenticator (Kpa) is carried by AAA
>> attributes "AAA(...)" to the authenticator and not by EAP Success.
>>     
> Although
>   
>> AAA message carrying these attributes is sent simultaneous as the AAA
>> message carrying the EAP success, or possibly the same AAA message carries
>> the authenticator keys and the EAP success as different attributes. So the
>> reliability rules for AAA messages apply not the reliability rules for EAP
>> or EAP success.
>>
>> R,
>>
>> Madjid
>>
>> -----Original Message-----
>> From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] 
>> Sent: Monday, April 09, 2007 4:00 PM
>> To: Madjid Nakhjiri
>> Cc: 'Charles Clancy'; hokey@ietf.org
>> Subject: Re: [HOKEY] Using an EAP method for HOKEY??: was: consensus call:
>> EAP-ER as HOKEY protocol
>>
>> Madjid,
>>
>> How can key distribution by piggybacking data with EAP-Success work
>> when EAP-Success gets lost?  Note that EAP does not retransmit
>> EAP-Success.
>>
>> Yoshihiro Ohba
>>
>>
>> On Mon, Apr 09, 2007 at 03:50:08PM -0700, Madjid Nakhjiri wrote:
>>     
>>> Hi,
>>>
>>> As promised earlier, I am providing an analysis of use of EAP method for
>>> handover and re-authentication signaling. To me it seems that without
>>> introducing a new EAP code, one can accomplish the signaling with very
>>> little change to authenticator state machine, given that the
>>>       
> authenticator
>   
>>> already does receive and transmit AAA attributes along with AAA messages
>>> encapsulating EAP packets.
>>>
>>> I have called this new method, EAP Handover and re-authentication method
>>> (EAP-HR), which consists of 3 messages (if you count EAP Success as
>>>       
> method
>   
>>> specific).
>>> I have shown the 3-party key distribution exchange (KDE) can be carried
>>>       
>> over
>>     
>>> the EAP-HR messages easily.
>>> As you can see in most of cases (handover, re-authentication and even in
>>> some cases for network setup), a trigger is easily available for the
>>> authenticator to start with EAP-HR Req, just the way EAP-identity starts
>>> from the authenticator. So the urgent need for peer-initiated messaging
>>>       
>> and
>>     
>>> hence the need to create new EAP code may go away.
>>>
>>>
>>>
>>> Peer             authenticator             server
>>> 	EAP-HR REQ
>>> 	(DID, AID)
>>>   <-------------
>>> 	EAP-HR RESP
>>>       KDE message 1 and 2 (PID, AID and tokens)
>>> ------------------------------------------------->
>>> 		EAP/Success
>>> 		 (KDE message 3 and 4)
>>> <---------------------------------------------------
>>>
>>> DID: domain ID (used for creating Domain keys)
>>> AID: authenticator ID advertised by the authenticator 
>>> (note this can be done as part of lower layer beacon advertisement), so
>>> carrying data through EAP-HR Request is not 100% necessary the KDE.
>>>
>>>
>>> FAQ
>>> =====
>>>
>>> Roundtrips: 
>>> ============
>>> 1.1 when trigger is available at authenticator
>>> (assuming authenticator-peer trip~20% of server-peer trip).
>>> 1.5 when trigger needs to arrive from the server.
>>>
>>>
>>> Cases where trigger is available at authenticator
>>> a) in handover, this is available through a handover request from the
>>>       
>> peer.
>>     
>>> b) in re-authentication, the authentication/ key status is typically
>>> available at the authenticator as a result of previous AAA signaling
>>>       
> (e.g.
>   
>>> Session-life-time attribute)
>>> c) in network setup, the server may send a session-life-time=0 to
>>> authenticator along with the previous EAP authentication Success, to
>>> indicate the need to start HOKEY signaling.
>>>
>>>
>>> EAP-HR versus EAP identity
>>> ======================
>>> I have discussed this with several EAP experts and it seems that using
>>>       
> EAP
>   
>>> Identity request/ response versus using a new EAP method (EAP-HR) are
>>>       
>> almost
>>     
>>> identical.
>>> The issue with EAP Identity is that it does not carry data.
>>> IMO, modifying EAP Identity to carry data is more straight forward than
>>> creating EAP-HR.
>>>
>>>
>>>
>>> EAP Success:
>>> ==========
>>> It seems that quite a number of people have already backed up the idea
>>>       
> of
>   
>>> modifying EAP success to carry data: people brought up the fact that
>>>       
> 2284
>   
>>> did allow EAP success carrying data and the only reason 3748 banned EAP
>>> Success from carrying data was the inadequate method independent way of
>>> carrying data. It seems to me that keys derived from the hierarchy can
>>>       
> be
>   
>>> used to protect the EAP success and its data and this would allow for
>>> protected result indication as well. 
>>>
>>> The other reason to allow EAP Success carry data is to provide a natural
>>> extension to the AAA (authorization, etc) signaling that currently does
>>>       
>> not
>>     
>>> reach beyond the authenticator.
>>>
>>> So with that in mind, I hope we don't rehash the previous emails citing
>>> sentences from 3748 about EAP Success carrying data...
>>>
>>> 3 Party key distribution (KDE)
>>> =======================
>>> I have modified the 3 party key distribution slightly to accomodate the
>>>       
>> EAP
>>     
>>> method signaling.
>>>
>>>    0  Authenticator to peer: EAP(DAID, DID)
>>>
>>>    1  Peer to Authenticator: EAP((PID, DAID, DID, Np,KNps), [PID, DAID,
>>>       Np,KNps]Kps)
>>>
>>>    2  Authenticator to Server: AAA(PID, UAID, [PID, UAID]Kas),
>>>       AAA(EAP((PID, DAID, DID, Np,KNps), [PID, DAID, DID, Np,KNps]Kps))
>>>
>>>    3  Server to Authenticator: AAA({PID,AID,KNpa, KLpa, Kpa}KEas),
>>>       AAA(EAP(KNpa, KLpa, KNps, [PID, AID, DID, Np+1,KNpa,KLpa,
>>>       KNps]Kps))
>>>
>>>    4  Authenticator to Peer: EAP(KNpa, KLpa, KNps, [PID, AID, DID, Np+1,
>>>       KNpa,KLpa, KNps]Kps])
>>>
>>> PID: peer ID.  
>>>    DID: Domain ID
>>>    AID: Authenticator ID
>>>    DAID: Authenticator ID as perceived by the peer (down link ID)
>>>    UAID: Authenticator ID as perceived by the server (uplink ID)
>>>    {X}K: X encrypted with key K
>>>    [X]K: Message Authentication Code over X with key K.
>>>    X(Y): Y carried with X protocol
>>>    Kps: A symmetric key shared between peer and Server for signing (IK,
>>>    provisioned by EAP/HOKEY hierarchy) and identified by KNps.
>>>
>>>    KEps: A symmetric key shared between peer and Server for encryption
>>>    (CK, provisioning by EAP/HOKEY hierarchy) and identified by KEpsid
>>>
>>>    KEas: A symmetric key shared between authenticator and Server for
>>>    encryption (provisioned out of band).
>>>
>>>    Kas: A symmetric key between authentication and server for MDCs for
>>>    signing (provisioned out of band).
>>>
>>>
>>>  Kpa: A symmetric key to be shared between peer and authenticator (key
>>>    to be distributed to authenticator, the MDMSK in this document).  The
>>>    key is named as KNpa.
>>>
>>>    KLx : Key lifetime for key x
>>>
>>>    KNx: Key name for Key x, e.g.  KENas: key name for KEas
>>>
>>>    Nx : Nonce provided by the party X
>>>
>>> I have provided more the details in a draft. 
>>>
>>>       
> http://www.ietf.org/internet-drafts/draft-nakhjiri-hokey-hierarchy-04.txt
>   
>>> Regards,
>>>
>>> Madjid
>>>
>>> -----Original Message-----
>>> From: Charles Clancy [mailto:clancy@cs.umd.edu] 
>>> Sent: Saturday, March 31, 2007 11:58 AM
>>> To: hokey@ietf.org
>>> Subject: [HOKEY] consensus call: EAP-ER as HOKEY protocol
>>>
>>> HOKEY WG,
>>>
>>> The chairs are making a second consensus call request to adopt EAP-ER as
>>>       
>
>   
>>> a WG document to satisfy our re-auth and hand-off deliverables.  It 
>>> would serve as a starting point for development of the HOKEY protocol.
>>>
>>> Note that if accepted, it may be split into two WG documents, separating
>>>       
>
>   
>>> the EAP-ER-Bootstrap into a second set of messages that could be 
>>> transported by any service to obtain a USRK or DSUSRK.
>>>
>>> Please respond by Friday, April 13.
>>>
>>> -- 
>>> t. charles clancy, ph.d.  <>  tcc@umd.edu  <>  www.cs.umd.edu/~clancy
>>>
>>>
>>> _______________________________________________
>>> 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
>
>
>
> _______________________________________________
> HOKEY mailing list
> HOKEY@ietf.org
> https://www1.ietf.org/mailman/listinfo/hokey
>
>
>   


-- 
------------------------------------------------------
Rafael Marin Lopez
Depto. Ing. de la Info. y las Comunicaciones
Faculty of Computer Science-University of Murcia
30100 Murcia - Spain
Telf: +34968398501    e-mail: rafa@dif.um.es
------------------------------------------------------


_______________________________________________
HOKEY mailing list
HOKEY@ietf.org
https://www1.ietf.org/mailman/listinfo/hokey



From hokey-bounces@ietf.org Thu Apr 12 05:01: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 1HbvB5-0006ds-UE; Thu, 12 Apr 2007 05:01:15 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HbvB4-0006dn-Uh
	for hokey@ietf.org; Thu, 12 Apr 2007 05:01:14 -0400
Received: from numenor.qualcomm.com ([129.46.51.58])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbvB3-0004BN-8d
	for hokey@ietf.org; Thu, 12 Apr 2007 05:01:14 -0400
Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158])
	by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id
	l3C91CZh017974
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL)
	for ; Thu, 12 Apr 2007 02:01:12 -0700
Received: from [10.50.76.46] (qconnect-10-50-76-46.qualcomm.com [10.50.76.46])
	by totoro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id
	l3C91BZJ003435
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT)
	for ; Thu, 12 Apr 2007 02:01:11 -0700 (PDT)
Message-ID: <461DF557.6090601@qualcomm.com>
Date: Thu, 12 Apr 2007 02:01:11 -0700
From: Lakshminath Dondeti 
User-Agent: Thunderbird 2.0.0.0 (Windows/20070326)
MIME-Version: 1.0
To: hokey@ietf.org
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a
Subject: [HOKEY] How does overloading EAP Req&Resp/Id and Success work in
	these cases?
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

Consider the following cases:

In Case 1, EAP Success may be lost in transmission, but EAP works.  The 
Peer would have computed the MSK as part of the EAP Method and the 
Authenticator would have received the MSK.  The Success message will 
make it that far: AAA will make sure of that (e.g., RADIUS message pairing).

How would Type-based re-authentication approaches work in such cases in 
1 RT (or 1.5 RT, counting the EAP Req/Id?)?  More specifically what 
happens when the EAP Success (let's say modified and carrying additional 
data) message gets lost between the Peer and the Authenticator?

************* Case 1 ***************************

Peer                Authenticator                   AS

  <----EAP Req/Id--------

  -----EAP Resp/Id------>   -----AAA(EAP Resp/Id)---->

  <====EAP Method=======>   <====AAA(EAP Method)=====>

               X<--------   <--AAA(EAP Success,MSK)--
               EAP Success

*******************************************************

On Case 2, I am not sure how 3748-compliant it is, but I have had people 
argue with me that it is in fact compliant and I can see how it might 
be.  The NAI might be available through the lower layer and the 
Authenticator, in the interest of saving over the link (over the air 
really, and that too over licensed spectrum, since that's where there is 
a motivation to reduce link usage) bandwidth, sends the AAA message 
containing EAP Response/Identity.

In such cases, the problem is two-fold.  In addition to the Success 
being lost, there may be no provision to even send additional data as 
part of the EAP Response/Identity.  How would Type-based 
re-authentication approaches work in such cases?

************ Case 2 ***************************


Peer                Authenticator                   AS

  <===LowerLayerXchg(NAI)===>

                            -----AAA(EAP Resp/Id)---->

  <====EAP Method=======>   <====AAA(EAP Method)=====>

               X<--------   <--AAA(EAP Success,MSK)---
               EAP Success

****************************************************

There is simply no way to ensure "no changes to authenticator" in 
supporting efficient reauthentication.

thanks,
Lakshminath

_______________________________________________
HOKEY mailing list
HOKEY@ietf.org
https://www1.ietf.org/mailman/listinfo/hokey



From hokey-bounces@ietf.org Thu Apr 12 05:46:32 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hbvsu-0005Kt-Ll; Thu, 12 Apr 2007 05:46:32 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hbvst-0005Kn-PL
	for hokey@ietf.org; Thu, 12 Apr 2007 05:46:31 -0400
Received: from ithilien.qualcomm.com ([129.46.51.59])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hbvst-0007XY-4s
	for hokey@ietf.org; Thu, 12 Apr 2007 05:46:31 -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
	l3C9kQZF007832
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Thu, 12 Apr 2007 02:46:27 -0700
Received: from [10.50.76.46] (qconnect-10-50-76-46.qualcomm.com [10.50.76.46])
	by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id
	l3C9kPSE014810
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Thu, 12 Apr 2007 02:46:26 -0700
Message-ID: <461DFFF1.1090800@qualcomm.com>
Date: Thu, 12 Apr 2007 02:46:25 -0700
From: Lakshminath Dondeti 
User-Agent: Thunderbird 2.0.0.0 (Windows/20070326)
MIME-Version: 1.0
To: Madjid Nakhjiri 
Subject: Re: [HOKEY] Using an EAP method for HOKEY??: was: consensus call:
	EAP-ER as HOKEY protocol
References: <007201c77af9$6cecc490$2f01a8c0@china.huawei.com>
In-Reply-To: <007201c77af9$6cecc490$2f01a8c0@china.huawei.com>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0bb031f3a6fb29f760794ac9bf1997ae
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

Madjid,

Thanks for sharing the details of your proposal, please see inline for 
some notes:

Madjid Nakhjiri wrote:
> Hi,
> 
> As promised earlier, I am providing an analysis of use of EAP method for
> handover and re-authentication signaling. To me it seems that without
> introducing a new EAP code, one can accomplish the signaling with very
> little change to authenticator state machine, given that the authenticator
> already does receive and transmit AAA attributes along with AAA messages
> encapsulating EAP packets.

What is the goal here?  No changes to authenticator?  Very little 
changes to authenticator?

Let's examine what happens when a new code is introduced?  Here are the 
things the authenticator needs to do (I haven't worked on an EAP 
implementation before; my "IETF" implementation and/or interop 
experience is on GDOI, IKEv2 and GKDP).

* Accept EAP messages with Code=5 from the Peer
* if Type != Reauth { drop; return}
* else
* route just as EAP Response Identity is routed (reuse code)

* Accept EAP messages with Code=6 from the Server
* if Type!= Reauth {drop; return}
* else
* send the message to the Peer

I'd say that qualifies as a small change to the authenticator code. 
That kind of upgrade would be of inconsequential complexity; given how 
802.11 APs' Firmware is patched for all sorts of reasons rather 
frequently, it should be a non-issue!

The other thing to note is that such changes are required with your 
proposal too!

> 
> I have called this new method, EAP Handover and re-authentication method
> (EAP-HR), which consists of 3 messages (if you count EAP Success as method
> specific).
> I have shown the 3-party key distribution exchange (KDE) can be carried over
> the EAP-HR messages easily.
> As you can see in most of cases (handover, re-authentication and even in
> some cases for network setup), a trigger is easily available for the
> authenticator to start with EAP-HR Req, just the way EAP-identity starts
> from the authenticator. So the urgent need for peer-initiated messaging and
> hence the need to create new EAP code may go away.
> 

How would the authenticator know to start EAP Request/HR instead of EAP 
Request/Identity?  That is a change to the authenticator, would you 
agree?  Could you explain what the trigger is?

How would it know how to parse and route EAP Response/HR just like EAP 
Response/Identity?  Parsing that message would be as simple/complex as 
parsing something like EAP Initiate/Re-auth (I guess in the latter case 
there is an extra if statement; I'll give you that!).

I have already asked the questions on how to reliably transport EAP 
Success without changes to authenticators (if the answer is to make the 
lower layer reliable, then surely that is a much bigger change!).  Next 
do we know that all authenticator implementations out there would work 
with Success messages larger than 4 Octets?

I will try to look at the message payloads and respond separately (Could 
you please use the notation everyone else has been using and resend that 
part of your message?  The PID, DID, DIDN'T, UAID, DAID, MAID, PAID, 
SAID stuff is confusing!)

regards,
Lakshminath

**Note: No experts were bothered or harmed in crafting this message.  I 
have, however, referred to some relevant RFCs, taken into account HOKEY 
mailing list discussions and meeting notes and offline suggestions from 
various IETF contributors.  Oddly enough, none of the people I spoke to 
had the label "expert" on their badges.

> 
> 
> Peer             authenticator             server
> 	EAP-HR REQ
> 	(DID, AID)
>   <-------------
> 	EAP-HR RESP
>       KDE message 1 and 2 (PID, AID and tokens)
> ------------------------------------------------->
> 		EAP/Success
> 		 (KDE message 3 and 4)
> <---------------------------------------------------
> 
> DID: domain ID (used for creating Domain keys)
> AID: authenticator ID advertised by the authenticator 
> (note this can be done as part of lower layer beacon advertisement), so
> carrying data through EAP-HR Request is not 100% necessary the KDE.
> 
> 
> FAQ
> =====
> 
> Roundtrips: 
> ============
> 1.1 when trigger is available at authenticator
> (assuming authenticator-peer trip~20% of server-peer trip).
> 1.5 when trigger needs to arrive from the server.
> 
> 
> Cases where trigger is available at authenticator
> a) in handover, this is available through a handover request from the peer.
> b) in re-authentication, the authentication/ key status is typically
> available at the authenticator as a result of previous AAA signaling (e.g.
> Session-life-time attribute)
> c) in network setup, the server may send a session-life-time=0 to
> authenticator along with the previous EAP authentication Success, to
> indicate the need to start HOKEY signaling.
> 
> 
> EAP-HR versus EAP identity
> ======================
> I have discussed this with several EAP experts and it seems that using EAP
> Identity request/ response versus using a new EAP method (EAP-HR) are almost
> identical.
> The issue with EAP Identity is that it does not carry data.
> IMO, modifying EAP Identity to carry data is more straight forward than
> creating EAP-HR.
> 
> 
> 
> EAP Success:
> ==========
> It seems that quite a number of people have already backed up the idea of
> modifying EAP success to carry data: people brought up the fact that 2284
> did allow EAP success carrying data and the only reason 3748 banned EAP
> Success from carrying data was the inadequate method independent way of
> carrying data. It seems to me that keys derived from the hierarchy can be
> used to protect the EAP success and its data and this would allow for
> protected result indication as well. 
> 
> The other reason to allow EAP Success carry data is to provide a natural
> extension to the AAA (authorization, etc) signaling that currently does not
> reach beyond the authenticator.
> 
> So with that in mind, I hope we don't rehash the previous emails citing
> sentences from 3748 about EAP Success carrying data...
> 
> 3 Party key distribution (KDE)
> =======================
> I have modified the 3 party key distribution slightly to accomodate the EAP
> method signaling.
> 
>    0  Authenticator to peer: EAP(DAID, DID)
> 
>    1  Peer to Authenticator: EAP((PID, DAID, DID, Np,KNps), [PID, DAID,
>       Np,KNps]Kps)
> 
>    2  Authenticator to Server: AAA(PID, UAID, [PID, UAID]Kas),
>       AAA(EAP((PID, DAID, DID, Np,KNps), [PID, DAID, DID, Np,KNps]Kps))
> 
>    3  Server to Authenticator: AAA({PID,AID,KNpa, KLpa, Kpa}KEas),
>       AAA(EAP(KNpa, KLpa, KNps, [PID, AID, DID, Np+1,KNpa,KLpa,
>       KNps]Kps))
> 
>    4  Authenticator to Peer: EAP(KNpa, KLpa, KNps, [PID, AID, DID, Np+1,
>       KNpa,KLpa, KNps]Kps])
> 
> PID: peer ID.  
>    DID: Domain ID
>    AID: Authenticator ID
>    DAID: Authenticator ID as perceived by the peer (down link ID)
>    UAID: Authenticator ID as perceived by the server (uplink ID)
>    {X}K: X encrypted with key K
>    [X]K: Message Authentication Code over X with key K.
>    X(Y): Y carried with X protocol
>    Kps: A symmetric key shared between peer and Server for signing (IK,
>    provisioned by EAP/HOKEY hierarchy) and identified by KNps.
> 
>    KEps: A symmetric key shared between peer and Server for encryption
>    (CK, provisioning by EAP/HOKEY hierarchy) and identified by KEpsid
> 
>    KEas: A symmetric key shared between authenticator and Server for
>    encryption (provisioned out of band).
> 
>    Kas: A symmetric key between authentication and server for MDCs for
>    signing (provisioned out of band).
> 
> 
>  Kpa: A symmetric key to be shared between peer and authenticator (key
>    to be distributed to authenticator, the MDMSK in this document).  The
>    key is named as KNpa.
> 
>    KLx : Key lifetime for key x
> 
>    KNx: Key name for Key x, e.g.  KENas: key name for KEas
> 
>    Nx : Nonce provided by the party X
> 
> I have provided more the details in a draft. 
> http://www.ietf.org/internet-drafts/draft-nakhjiri-hokey-hierarchy-04.txt
> 
> Regards,
> 
> Madjid
> 
> -----Original Message-----
> From: Charles Clancy [mailto:clancy@cs.umd.edu] 
> Sent: Saturday, March 31, 2007 11:58 AM
> To: hokey@ietf.org
> Subject: [HOKEY] consensus call: EAP-ER as HOKEY protocol
> 
> HOKEY WG,
> 
> The chairs are making a second consensus call request to adopt EAP-ER as 
> a WG document to satisfy our re-auth and hand-off deliverables.  It 
> would serve as a starting point for development of the HOKEY protocol.
> 
> Note that if accepted, it may be split into two WG documents, separating 
> the EAP-ER-Bootstrap into a second set of messages that could be 
> transported by any service to obtain a USRK or DSUSRK.
> 
> Please respond by Friday, April 13.
> 

_______________________________________________
HOKEY mailing list
HOKEY@ietf.org
https://www1.ietf.org/mailman/listinfo/hokey



From hokey-bounces@ietf.org Thu Apr 12 06:21: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 1HbwQf-0005cV-0M; Thu, 12 Apr 2007 06:21:25 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HbwQd-0005X1-61
	for hokey@ietf.org; Thu, 12 Apr 2007 06:21:23 -0400
Received: from numenor.qualcomm.com ([129.46.51.58])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbwQc-0007ji-Qa
	for hokey@ietf.org; Thu, 12 Apr 2007 06:21:23 -0400
Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158])
	by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id
	l3CALL99023158
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL)
	for ; Thu, 12 Apr 2007 03:21:22 -0700
Received: from [10.50.76.46] (qconnect-10-50-76-46.qualcomm.com [10.50.76.46])
	by totoro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id
	l3CALL8b021377
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT)
	for ; Thu, 12 Apr 2007 03:21:21 -0700 (PDT)
Message-ID: <461E0821.3050008@qualcomm.com>
Date: Thu, 12 Apr 2007 03:21:21 -0700
From: Lakshminath Dondeti 
User-Agent: Thunderbird 2.0.0.0 (Windows/20070326)
MIME-Version: 1.0
To: hokey@ietf.org
References: <007301c77afa$d1d83a50$2f01a8c0@china.huawei.com>
	<461DE873.4070108@dif.um.es>
In-Reply-To: <461DE873.4070108@dif.um.es>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352
Subject: [HOKEY] On implementation experiences
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

In the not too distant past, I implemented a protocol called GKDP (it is 
a work item in the IETF now).  It worked great.  I did some private 
demos with it; several people loved the proof of concept and bought into 
the use cases of that protocol.

It was also my own private combination of GDOI and IKEv2; well, that's 
the nice way of saying it.  It was a hack; I took many shortcuts to meet 
deadlines and to make my job simple (there is a nice name for that type 
of thing: quick and dirty prototyping).  Nothing wrong with what I did 
in that context.  The implementation served its purpose very well!  When 
GKDP is standardized, it would be silly to suggest that my hacks should 
be written up and called a protocol.  That would be the simplest way to 
get there, but won't be the correct way.

As long as I am telling implementation stories, here is another: when 
IKEv2 was being standardized, there was another candidate, JFK.  It had 
everything going for it: let's face it, IKE's (#34) successor was JFK 
(#35) in the real world and the acronym fit, what else do we need at the 
IETF?

There was also another aspect to JFK; it supported the responder being 
stateless by including the first message in its entirety in the third 
message.  I was in a hurry to prototype IKEv2 (or JFK, I didn't care, I 
was implementing each draft as it came out) then and implemented that 
version.  Of course, people saw it correctly that JFK was not such a 
good idea.  Not all responders cared to be stateless all the time and 
there are other simpler (message 3 would have been too long and thus 
most probably fragmented and that would not have been a great thing in 
some networks) ways to support stateless responders and we have 4306 (I 
implemented some of that spec too and interoperated with one of the best 
implementations out there now, Tero Kivinen's, when it was in its 
initial stages).

Running code or how fast/easily I or anyone else could implement JFK was 
not what figured in that decision; instead it was whether JFK's long 3rd 
message could have been an issue in most if not all networks over which 
IKE was running.

Implementation input is useful, but it only goes so far.  Some of that 
input, if we are not careful enough can take us toward ugly hacks that 
might work well in some settings but won't work in other compliant systems.

regards,
Lakshminath

_______________________________________________
HOKEY mailing list
HOKEY@ietf.org
https://www1.ietf.org/mailman/listinfo/hokey



From hokey-bounces@ietf.org Thu Apr 12 14:34: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 1Hc47Q-00067z-Mh; Thu, 12 Apr 2007 14:34:04 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hc47P-00066s-Kr
	for hokey@ietf.org; Thu, 12 Apr 2007 14:34:03 -0400
Received: from inet-tsb5.toshiba.co.jp ([202.33.96.24])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hc47O-000676-Nk
	for hokey@ietf.org; Thu, 12 Apr 2007 14:34:03 -0400
Received: from tsb-wall.toshiba.co.jp ([133.199.160.134])
	by inet-tsb5.toshiba.co.jp  with ESMTP id l3CIXwkx025825;
	Fri, 13 Apr 2007 03:33:58 +0900 (JST)
Received: (from root@localhost) by tsb-wall.toshiba.co.jp  id l3CIXxNb029462;
	Fri, 13 Apr 2007 03:33:59 +0900 (JST)
Received: from ovp1.toshiba.co.jp [133.199.192.124] 
	by tsb-wall.toshiba.co.jp with ESMTP id DAA29461;
	Fri, 13 Apr 2007 03:33:58 +0900
Received: from mx2.toshiba.co.jp (localhost [127.0.0.1])
	by ovp1.toshiba.co.jp  with ESMTP id l3CIXwxt022256;
	Fri, 13 Apr 2007 03:33:58 +0900 (JST)
Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id l3CIXwJ9007330;
	Fri, 13 Apr 2007 03:33:58 +0900 (JST)
Received: from steelhead ([172.30.24.105])
	by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 (built
	Apr 28
	2004)) with ESMTPSA id <0JGE00ACVE8HMM80@mail.po.toshiba.co.jp>; Fri,
	13 Apr 2007 03:33:57 +0900 (JST)
Received: from ohba by steelhead with local (Exim 4.63)
	(envelope-from )	id 1Hc47G-00067E-FB; Thu,
	12 Apr 2007 11:33:54 -0700
Date: Thu, 12 Apr 2007 14:33:54 -0400
From: Yoshihiro Ohba 
Subject: Re: [HOKEY] Using an EAP method for HOKEY??: was: consensus call:
	EAP-ER as HOKEY protocol
In-reply-to: <461DFFF1.1090800@qualcomm.com>
To: Lakshminath Dondeti 
Message-id: <20070412183354.GF31369@steelhead>
MIME-version: 1.0
Content-type: text/plain; charset=iso-2022-jp
Content-disposition: inline
References: <007201c77af9$6cecc490$2f01a8c0@china.huawei.com>
	<461DFFF1.1090800@qualcomm.com>
User-Agent: Mutt/1.5.13 (2006-08-11)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: dd7e0c3fd18d19cffdd4de99a114001d
Cc: 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

I am not so much enthusiastic about EAP-ER or EAP-HR (I am more
enthusiastic about general 3-party key distribution protocol), but let
me comment one thing about EAP-HR.

I think that the authenticator that supports EAP-HR can always start
with EAP Request/HR.  If the peer does not support the method, it can
simply NAK and then the authenticator can fall back to legacy
authentication by sending a Request/Identity or other method request.
If the peer does not NAK, EAP-HR signaling will continue.  I think
this provides better backwards compatibility.  But in any case I agree
that the authenticator has to be upgraded to support EAP-HR or EAP-ER.

Yoshihiro Ohba


On Thu, Apr 12, 2007 at 02:46:25AM -0700, Lakshminath Dondeti wrote:
> Madjid,
> 
> Thanks for sharing the details of your proposal, please see inline for 
> some notes:
> 
> Madjid Nakhjiri wrote:
> >Hi,
> >
> >As promised earlier, I am providing an analysis of use of EAP method for
> >handover and re-authentication signaling. To me it seems that without
> >introducing a new EAP code, one can accomplish the signaling with very
> >little change to authenticator state machine, given that the authenticator
> >already does receive and transmit AAA attributes along with AAA messages
> >encapsulating EAP packets.
> 
> What is the goal here?  No changes to authenticator?  Very little 
> changes to authenticator?
> 
> Let's examine what happens when a new code is introduced?  Here are the 
> things the authenticator needs to do (I haven't worked on an EAP 
> implementation before; my "IETF" implementation and/or interop 
> experience is on GDOI, IKEv2 and GKDP).
> 
> * Accept EAP messages with Code=5 from the Peer
> * if Type != Reauth { drop; return}
> * else
> * route just as EAP Response Identity is routed (reuse code)
> 
> * Accept EAP messages with Code=6 from the Server
> * if Type!= Reauth {drop; return}
> * else
> * send the message to the Peer
> 
> I'd say that qualifies as a small change to the authenticator code. 
> That kind of upgrade would be of inconsequential complexity; given how 
> 802.11 APs' Firmware is patched for all sorts of reasons rather 
> frequently, it should be a non-issue!
> 
> The other thing to note is that such changes are required with your 
> proposal too!
> 
> >
> >I have called this new method, EAP Handover and re-authentication method
> >(EAP-HR), which consists of 3 messages (if you count EAP Success as method
> >specific).
> >I have shown the 3-party key distribution exchange (KDE) can be carried 
> >over
> >the EAP-HR messages easily.
> >As you can see in most of cases (handover, re-authentication and even in
> >some cases for network setup), a trigger is easily available for the
> >authenticator to start with EAP-HR Req, just the way EAP-identity starts
> >from the authenticator. So the urgent need for peer-initiated messaging and
> >hence the need to create new EAP code may go away.
> >
> 
> How would the authenticator know to start EAP Request/HR instead of EAP 
> Request/Identity?  That is a change to the authenticator, would you 
> agree?  Could you explain what the trigger is?

> 
> How would it know how to parse and route EAP Response/HR just like EAP 
> Response/Identity?  Parsing that message would be as simple/complex as 
> parsing something like EAP Initiate/Re-auth (I guess in the latter case 
> there is an extra if statement; I'll give you that!).
> 
> I have already asked the questions on how to reliably transport EAP 
> Success without changes to authenticators (if the answer is to make the 
> lower layer reliable, then surely that is a much bigger change!).  Next 
> do we know that all authenticator implementations out there would work 
> with Success messages larger than 4 Octets?
> 
> I will try to look at the message payloads and respond separately (Could 
> you please use the notation everyone else has been using and resend that 
> part of your message?  The PID, DID, DIDN'T, UAID, DAID, MAID, PAID, 
> SAID stuff is confusing!)
> 
> regards,
> Lakshminath
> 
> **Note: No experts were bothered or harmed in crafting this message.  I 
> have, however, referred to some relevant RFCs, taken into account HOKEY 
> mailing list discussions and meeting notes and offline suggestions from 
> various IETF contributors.  Oddly enough, none of the people I spoke to 
> had the label "expert" on their badges.
> 
> >
> >
> >Peer             authenticator             server
> >	EAP-HR REQ
> >	(DID, AID)
> >  <-------------
> >	EAP-HR RESP
> >      KDE message 1 and 2 (PID, AID and tokens)
> >------------------------------------------------->
> >		EAP/Success
> >		 (KDE message 3 and 4)
> ><---------------------------------------------------
> >
> >DID: domain ID (used for creating Domain keys)
> >AID: authenticator ID advertised by the authenticator 
> >(note this can be done as part of lower layer beacon advertisement), so
> >carrying data through EAP-HR Request is not 100% necessary the KDE.
> >
> >
> >FAQ
> >=====
> >
> >Roundtrips: 
> >============
> >1.1 when trigger is available at authenticator
> >(assuming authenticator-peer trip~20% of server-peer trip).
> >1.5 when trigger needs to arrive from the server.
> >
> >
> >Cases where trigger is available at authenticator
> >a) in handover, this is available through a handover request from the peer.
> >b) in re-authentication, the authentication/ key status is typically
> >available at the authenticator as a result of previous AAA signaling (e.g.
> >Session-life-time attribute)
> >c) in network setup, the server may send a session-life-time=0 to
> >authenticator along with the previous EAP authentication Success, to
> >indicate the need to start HOKEY signaling.
> >
> >
> >EAP-HR versus EAP identity
> >======================
> >I have discussed this with several EAP experts and it seems that using EAP
> >Identity request/ response versus using a new EAP method (EAP-HR) are 
> >almost
> >identical.
> >The issue with EAP Identity is that it does not carry data.
> >IMO, modifying EAP Identity to carry data is more straight forward than
> >creating EAP-HR.
> >
> >
> >
> >EAP Success:
> >==========
> >It seems that quite a number of people have already backed up the idea of
> >modifying EAP success to carry data: people brought up the fact that 2284
> >did allow EAP success carrying data and the only reason 3748 banned EAP
> >Success from carrying data was the inadequate method independent way of
> >carrying data. It seems to me that keys derived from the hierarchy can be
> >used to protect the EAP success and its data and this would allow for
> >protected result indication as well. 
> >
> >The other reason to allow EAP Success carry data is to provide a natural
> >extension to the AAA (authorization, etc) signaling that currently does not
> >reach beyond the authenticator.
> >
> >So with that in mind, I hope we don't rehash the previous emails citing
> >sentences from 3748 about EAP Success carrying data...
> >
> >3 Party key distribution (KDE)
> >=======================
> >I have modified the 3 party key distribution slightly to accomodate the EAP
> >method signaling.
> >
> >   0  Authenticator to peer: EAP(DAID, DID)
> >
> >   1  Peer to Authenticator: EAP((PID, DAID, DID, Np,KNps), [PID, DAID,
> >      Np,KNps]Kps)
> >
> >   2  Authenticator to Server: AAA(PID, UAID, [PID, UAID]Kas),
> >      AAA(EAP((PID, DAID, DID, Np,KNps), [PID, DAID, DID, Np,KNps]Kps))
> >
> >   3  Server to Authenticator: AAA({PID,AID,KNpa, KLpa, Kpa}KEas),
> >      AAA(EAP(KNpa, KLpa, KNps, [PID, AID, DID, Np+1,KNpa,KLpa,
> >      KNps]Kps))
> >
> >   4  Authenticator to Peer: EAP(KNpa, KLpa, KNps, [PID, AID, DID, Np+1,
> >      KNpa,KLpa, KNps]Kps])
> >
> >PID: peer ID.  
> >   DID: Domain ID
> >   AID: Authenticator ID
> >   DAID: Authenticator ID as perceived by the peer (down link ID)
> >   UAID: Authenticator ID as perceived by the server (uplink ID)
> >   {X}K: X encrypted with key K
> >   [X]K: Message Authentication Code over X with key K.
> >   X(Y): Y carried with X protocol
> >   Kps: A symmetric key shared between peer and Server for signing (IK,
> >   provisioned by EAP/HOKEY hierarchy) and identified by KNps.
> >
> >   KEps: A symmetric key shared between peer and Server for encryption
> >   (CK, provisioning by EAP/HOKEY hierarchy) and identified by KEpsid
> >
> >   KEas: A symmetric key shared between authenticator and Server for
> >   encryption (provisioned out of band).
> >
> >   Kas: A symmetric key between authentication and server for MDCs for
> >   signing (provisioned out of band).
> >
> >
> > Kpa: A symmetric key to be shared between peer and authenticator (key
> >   to be distributed to authenticator, the MDMSK in this document).  The
> >   key is named as KNpa.
> >
> >   KLx : Key lifetime for key x
> >
> >   KNx: Key name for Key x, e.g.  KENas: key name for KEas
> >
> >   Nx : Nonce provided by the party X
> >
> >I have provided more the details in a draft. 
> >http://www.ietf.org/internet-drafts/draft-nakhjiri-hokey-hierarchy-04.txt
> >
> >Regards,
> >
> >Madjid
> >
> >-----Original Message-----
> >From: Charles Clancy [mailto:clancy@cs.umd.edu] 
> >Sent: Saturday, March 31, 2007 11:58 AM
> >To: hokey@ietf.org
> >Subject: [HOKEY] consensus call: EAP-ER as HOKEY protocol
> >
> >HOKEY WG,
> >
> >The chairs are making a second consensus call request to adopt EAP-ER as 
> >a WG document to satisfy our re-auth and hand-off deliverables.  It 
> >would serve as a starting point for development of the HOKEY protocol.
> >
> >Note that if accepted, it may be split into two WG documents, separating 
> >the EAP-ER-Bootstrap into a second set of messages that could be 
> >transported by any service to obtain a USRK or DSUSRK.
> >
> >Please respond by Friday, April 13.
> >
> 
> _______________________________________________
> 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 Apr 12 15:02: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 1Hc4ZH-0000NJ-4g; Thu, 12 Apr 2007 15:02:51 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hc4ZF-0000ND-W2
	for hokey@ietf.org; Thu, 12 Apr 2007 15:02:49 -0400
Received: from numenor.qualcomm.com ([129.46.51.58])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hc4ZF-0002yG-7F
	for hokey@ietf.org; Thu, 12 Apr 2007 15:02:49 -0400
Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158])
	by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id
	l3CJ2fgO005812
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Thu, 12 Apr 2007 12:02:42 -0700
Received: from SANEXCAS03.na.qualcomm.com (sanexcas03.qualcomm.com
	[172.30.32.65])
	by totoro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l3CJ2UrR019517;
	Thu, 12 Apr 2007 12:02:31 -0700 (PDT)
Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by
	SANEXCAS03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 12 Apr 2007 12:02:30 -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
Subject: RE: [HOKEY] Using an EAP method for HOKEY??: was: consensus
	call:EAP-ER as HOKEY protocol
Date: Thu, 12 Apr 2007 12:02:28 -0700
Message-ID: 
In-Reply-To: <20070412183354.GF31369@steelhead>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [HOKEY] Using an EAP method for HOKEY??: was: consensus
	call:EAP-ER as HOKEY protocol
Thread-Index: Acd9MTgLlBHhgg0iTYKmV/wEQT8IwwAAepUg
References: <007201c77af9$6cecc490$2f01a8c0@china.huawei.com><461DFFF1.1090800@qualcomm.com>
	<20070412183354.GF31369@steelhead>
From: "Narayanan, Vidya" 
To: "Yoshihiro Ohba" ,
	"Dondeti, Lakshminath" 
X-OriginalArrivalTime: 12 Apr 2007 19:02:30.0705 (UTC)
	FILETIME=[1ED03A10:01C77D35]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5ba9b8496764663b12c333825fbf6b3d
Cc: 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

>=20
> I think that the authenticator that supports EAP-HR can=20
> always start with EAP Request/HR.  If the peer does not=20
> support the method, it can simply NAK and then the=20
> authenticator can fall back to legacy authentication by=20
> sending a Request/Identity or other method request.

I don't understand. When a peer shows up, how does the authenticator
know if that peer has already done an initial EAP exchange and has valid
EMSK/DSRK, etc.? To me, the logical thing seems to be that the
authenticator always sends EAP Request/Identity - if the peer has valid
key material, it may send a re-authentication message (EAP
Initiate/Re-auth in the case of EAP-ER); authenticator support for such
re-auth can be known either at the lower layer or if we decide to
include a capability indication in EAP Request/Identity. Peers that
don't support re-auth or peers that are doing an initial access will
simply respond with EAP Response/Identity and will continue the EAP
procedure.=20

> If the peer does not NAK, EAP-HR signaling will continue.  I=20
> think this provides better backwards compatibility.=20

Could you explain why it is better?  Perhaps call flows with
combinations of legacy peers or authenticators might help?=20

> But in=20
> any case I agree that the authenticator has to be upgraded to=20
> support EAP-HR or EAP-ER.
>=20

And I believe the upgrades are equally significant or insignificant,
depending on how you see it. I just don't understand how all the issues
are resolved with the authenticator starting with the re-auth stuff or
re-using EAP Success, etc. That seems to create more backwards
compatibility issues and complicate co-existence of schemes like network
selection and re-authentication, etc.=20

Vidya


> Yoshihiro Ohba
>=20
>=20
> On Thu, Apr 12, 2007 at 02:46:25AM -0700, Lakshminath Dondeti wrote:
> > Madjid,
> >=20
> > Thanks for sharing the details of your proposal, please see=20
> inline for=20
> > some notes:
> >=20
> > Madjid Nakhjiri wrote:
> > >Hi,
> > >
> > >As promised earlier, I am providing an analysis of use of=20
> EAP method=20
> > >for handover and re-authentication signaling. To me it seems that=20
> > >without introducing a new EAP code, one can accomplish the=20
> signaling=20
> > >with very little change to authenticator state machine, given that=20
> > >the authenticator already does receive and transmit AAA attributes=20
> > >along with AAA messages encapsulating EAP packets.
> >=20
> > What is the goal here?  No changes to authenticator?  Very little=20
> > changes to authenticator?
> >=20
> > Let's examine what happens when a new code is introduced?  Here are=20
> > the things the authenticator needs to do (I haven't worked=20
> on an EAP=20
> > implementation before; my "IETF" implementation and/or interop=20
> > experience is on GDOI, IKEv2 and GKDP).
> >=20
> > * Accept EAP messages with Code=3D5 from the Peer
> > * if Type !=3D Reauth { drop; return}
> > * else
> > * route just as EAP Response Identity is routed (reuse code)
> >=20
> > * Accept EAP messages with Code=3D6 from the Server
> > * if Type!=3D Reauth {drop; return}
> > * else
> > * send the message to the Peer
> >=20
> > I'd say that qualifies as a small change to the authenticator code.=20
> > That kind of upgrade would be of inconsequential=20
> complexity; given how
> > 802.11 APs' Firmware is patched for all sorts of reasons rather=20
> > frequently, it should be a non-issue!
> >=20
> > The other thing to note is that such changes are required with your=20
> > proposal too!
> >=20
> > >
> > >I have called this new method, EAP Handover and re-authentication=20
> > >method (EAP-HR), which consists of 3 messages (if you count EAP=20
> > >Success as method specific).
> > >I have shown the 3-party key distribution exchange (KDE) can be=20
> > >carried over the EAP-HR messages easily.
> > >As you can see in most of cases (handover,=20
> re-authentication and even=20
> > >in some cases for network setup), a trigger is easily=20
> available for=20
> > >the authenticator to start with EAP-HR Req, just the way=20
> EAP-identity=20
> > >starts from the authenticator. So the urgent need for=20
> peer-initiated=20
> > >messaging and hence the need to create new EAP code may go away.
> > >
> >=20
> > How would the authenticator know to start EAP Request/HR instead of=20
> > EAP Request/Identity?  That is a change to the authenticator, would=20
> > you agree?  Could you explain what the trigger is?
>=20
> >=20
> > How would it know how to parse and route EAP Response/HR=20
> just like EAP=20
> > Response/Identity?  Parsing that message would be as=20
> simple/complex as=20
> > parsing something like EAP Initiate/Re-auth (I guess in the latter=20
> > case there is an extra if statement; I'll give you that!).
> >=20
> > I have already asked the questions on how to reliably transport EAP=20
> > Success without changes to authenticators (if the answer is to make=20
> > the lower layer reliable, then surely that is a much bigger=20
> change!). =20
> > Next do we know that all authenticator implementations out=20
> there would=20
> > work with Success messages larger than 4 Octets?
> >=20
> > I will try to look at the message payloads and respond separately=20
> > (Could you please use the notation everyone else has been using and=20
> > resend that part of your message?  The PID, DID, DIDN'T,=20
> UAID, DAID,=20
> > MAID, PAID, SAID stuff is confusing!)
> >=20
> > regards,
> > Lakshminath
> >=20
> > **Note: No experts were bothered or harmed in crafting this=20
> message. =20
> > I have, however, referred to some relevant RFCs, taken into account=20
> > HOKEY mailing list discussions and meeting notes and offline=20
> > suggestions from various IETF contributors.  Oddly enough,=20
> none of the=20
> > people I spoke to had the label "expert" on their badges.
> >=20
> > >
> > >
> > >Peer             authenticator             server
> > >	EAP-HR REQ
> > >	(DID, AID)
> > >  <-------------
> > >	EAP-HR RESP
> > >      KDE message 1 and 2 (PID, AID and tokens)
> > >------------------------------------------------->
> > >		EAP/Success
> > >		 (KDE message 3 and 4)
> > ><---------------------------------------------------
> > >
> > >DID: domain ID (used for creating Domain keys)
> > >AID: authenticator ID advertised by the authenticator=20
> (note this can=20
> > >be done as part of lower layer beacon advertisement), so carrying=20
> > >data through EAP-HR Request is not 100% necessary the KDE.
> > >
> > >
> > >FAQ
> > >=3D=3D=3D=3D=3D
> > >
> > >Roundtrips:=20
> > >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > >1.1 when trigger is available at authenticator (assuming=20
> > >authenticator-peer trip~20% of server-peer trip).
> > >1.5 when trigger needs to arrive from the server.
> > >
> > >
> > >Cases where trigger is available at authenticator
> > >a) in handover, this is available through a handover=20
> request from the peer.
> > >b) in re-authentication, the authentication/ key status is=20
> typically=20
> > >available at the authenticator as a result of previous AAA=20
> signaling (e.g.
> > >Session-life-time attribute)
> > >c) in network setup, the server may send a session-life-time=3D0 to =

> > >authenticator along with the previous EAP authentication=20
> Success, to=20
> > >indicate the need to start HOKEY signaling.
> > >
> > >
> > >EAP-HR versus EAP identity
> > >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > >I have discussed this with several EAP experts and it seems that=20
> > >using EAP Identity request/ response versus using a new EAP method=20
> > >(EAP-HR) are almost identical.
> > >The issue with EAP Identity is that it does not carry data.
> > >IMO, modifying EAP Identity to carry data is more straight forward=20
> > >than creating EAP-HR.
> > >
> > >
> > >
> > >EAP Success:
> > >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > >It seems that quite a number of people have already backed up the=20
> > >idea of modifying EAP success to carry data: people brought up the=20
> > >fact that 2284 did allow EAP success carrying data and the only=20
> > >reason 3748 banned EAP Success from carrying data was the=20
> inadequate=20
> > >method independent way of carrying data. It seems to me that keys=20
> > >derived from the hierarchy can be used to protect the EAP=20
> success and=20
> > >its data and this would allow for protected result=20
> indication as well.
> > >
> > >The other reason to allow EAP Success carry data is to provide a=20
> > >natural extension to the AAA (authorization, etc) signaling that=20
> > >currently does not reach beyond the authenticator.
> > >
> > >So with that in mind, I hope we don't rehash the previous emails=20
> > >citing sentences from 3748 about EAP Success carrying data...
> > >
> > >3 Party key distribution (KDE)
> > =
>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > >I have modified the 3 party key distribution slightly to=20
> accomodate=20
> > >the EAP method signaling.
> > >
> > >   0  Authenticator to peer: EAP(DAID, DID)
> > >
> > >   1  Peer to Authenticator: EAP((PID, DAID, DID,=20
> Np,KNps), [PID, DAID,
> > >      Np,KNps]Kps)
> > >
> > >   2  Authenticator to Server: AAA(PID, UAID, [PID, UAID]Kas),
> > >      AAA(EAP((PID, DAID, DID, Np,KNps), [PID, DAID, DID,=20
> > > Np,KNps]Kps))
> > >
> > >   3  Server to Authenticator: AAA({PID,AID,KNpa, KLpa, Kpa}KEas),
> > >      AAA(EAP(KNpa, KLpa, KNps, [PID, AID, DID, Np+1,KNpa,KLpa,
> > >      KNps]Kps))
> > >
> > >   4  Authenticator to Peer: EAP(KNpa, KLpa, KNps, [PID,=20
> AID, DID, Np+1,
> > >      KNpa,KLpa, KNps]Kps])
> > >
> > >PID: peer ID. =20
> > >   DID: Domain ID
> > >   AID: Authenticator ID
> > >   DAID: Authenticator ID as perceived by the peer (down link ID)
> > >   UAID: Authenticator ID as perceived by the server (uplink ID)
> > >   {X}K: X encrypted with key K
> > >   [X]K: Message Authentication Code over X with key K.
> > >   X(Y): Y carried with X protocol
> > >   Kps: A symmetric key shared between peer and Server for=20
> signing (IK,
> > >   provisioned by EAP/HOKEY hierarchy) and identified by KNps.
> > >
> > >   KEps: A symmetric key shared between peer and Server=20
> for encryption
> > >   (CK, provisioning by EAP/HOKEY hierarchy) and=20
> identified by KEpsid
> > >
> > >   KEas: A symmetric key shared between authenticator and=20
> Server for
> > >   encryption (provisioned out of band).
> > >
> > >   Kas: A symmetric key between authentication and server=20
> for MDCs for
> > >   signing (provisioned out of band).
> > >
> > >
> > > Kpa: A symmetric key to be shared between peer and=20
> authenticator (key
> > >   to be distributed to authenticator, the MDMSK in this=20
> document).  The
> > >   key is named as KNpa.
> > >
> > >   KLx : Key lifetime for key x
> > >
> > >   KNx: Key name for Key x, e.g.  KENas: key name for KEas
> > >
> > >   Nx : Nonce provided by the party X
> > >
> > >I have provided more the details in a draft.=20
> >=20
> >http://www.ietf.org/internet-drafts/draft-nakhjiri-hokey-hierarchy-04
> > >.txt
> > >
> > >Regards,
> > >
> > >Madjid
> > >
> > >-----Original Message-----
> > >From: Charles Clancy [mailto:clancy@cs.umd.edu]
> > >Sent: Saturday, March 31, 2007 11:58 AM
> > >To: hokey@ietf.org
> > >Subject: [HOKEY] consensus call: EAP-ER as HOKEY protocol
> > >
> > >HOKEY WG,
> > >
> > >The chairs are making a second consensus call request to=20
> adopt EAP-ER=20
> > >as a WG document to satisfy our re-auth and hand-off=20
> deliverables. =20
> > >It would serve as a starting point for development of the=20
> HOKEY protocol.
> > >
> > >Note that if accepted, it may be split into two WG documents,=20
> > >separating the EAP-ER-Bootstrap into a second set of messages that=20
> > >could be transported by any service to obtain a USRK or DSUSRK.
> > >
> > >Please respond by Friday, April 13.
> > >
> >=20
> > _______________________________________________
> > HOKEY mailing list
> > HOKEY@ietf.org
> > https://www1.ietf.org/mailman/listinfo/hokey
> >=20
>=20
> _______________________________________________
> HOKEY mailing list
> HOKEY@ietf.org
> https://www1.ietf.org/mailman/listinfo/hokey
>=20

_______________________________________________
HOKEY mailing list
HOKEY@ietf.org
https://www1.ietf.org/mailman/listinfo/hokey



From hokey-bounces@ietf.org Thu Apr 12 15:28:10 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hc4xm-0005kv-1r; Thu, 12 Apr 2007 15:28:10 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hc4xl-0005kq-5y
	for hokey@ietf.org; Thu, 12 Apr 2007 15:28:09 -0400
Received: from inet-tsb5.toshiba.co.jp ([202.33.96.24])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hc4xk-0001HM-79
	for hokey@ietf.org; Thu, 12 Apr 2007 15:28:09 -0400
Received: from tsb-wall.toshiba.co.jp ([133.199.160.134])
	by inet-tsb5.toshiba.co.jp  with ESMTP id l3CJS2LM001954;
	Fri, 13 Apr 2007 04:28:02 +0900 (JST)
Received: (from root@localhost) by tsb-wall.toshiba.co.jp  id l3CJS27k010497;
	Fri, 13 Apr 2007 04:28:02 +0900 (JST)
Received: from ovp1.toshiba.co.jp [133.199.192.124] 
	by tsb-wall.toshiba.co.jp with ESMTP id EAA10495;
	Fri, 13 Apr 2007 04:28:02 +0900
Received: from mx2.toshiba.co.jp (localhost [127.0.0.1])
	by ovp1.toshiba.co.jp  with ESMTP id l3CJS1eH018206;
	Fri, 13 Apr 2007 04:28:01 +0900 (JST)
Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id l3CJS1v6005050;
	Fri, 13 Apr 2007 04:28:01 +0900 (JST)
Received: from steelhead ([172.30.24.105])
	by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 (built
	Apr 28
	2004)) with ESMTPSA id <0JGE00ATQGQKMP80@mail.po.toshiba.co.jp>; Fri,
	13 Apr 2007 04:28:01 +0900 (JST)
Received: from ohba by steelhead with local (Exim 4.63)
	(envelope-from )	id 1Hc4xY-0006Gv-PN; Thu,
	12 Apr 2007 12:27:56 -0700
Date: Thu, 12 Apr 2007 15:27:56 -0400
From: Yoshihiro Ohba 
Subject: Re: [HOKEY] Using an EAP method for HOKEY??: was: consensus
	call:EAP-ER as HOKEY protocol
In-reply-to: 
To: "Narayanan, Vidya" 
Message-id: <20070412192756.GG31369@steelhead>
MIME-version: 1.0
Content-type: text/plain; charset=iso-2022-jp
Content-disposition: inline
References: <20070412183354.GF31369@steelhead>
	
User-Agent: Mutt/1.5.13 (2006-08-11)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8eeb555810cda1f2c5989480370dc4ca
Cc: 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

On Thu, Apr 12, 2007 at 12:02:28PM -0700, Narayanan, Vidya wrote:
> > 
> > I think that the authenticator that supports EAP-HR can 
> > always start with EAP Request/HR.  If the peer does not 
> > support the method, it can simply NAK and then the 
> > authenticator can fall back to legacy authentication by 
> > sending a Request/Identity or other method request.
> 
> I don't understand. When a peer shows up, how does the authenticator
> know if that peer has already done an initial EAP exchange and has valid
> EMSK/DSRK, etc.? To me, the logical thing seems to be that the

The authenticator knows that the peer has valid EMSK/DSRK if the peer
returns Request/HR instead of NAK.  
 
> authenticator always sends EAP Request/Identity - if the peer has valid
> key material, it may send a re-authentication message (EAP
> Initiate/Re-auth in the case of EAP-ER); authenticator support for such
> re-auth can be known either at the lower layer or if we decide to
> include a capability indication in EAP Request/Identity. Peers that
> don't support re-auth or peers that are doing an initial access will
> simply respond with EAP Response/Identity and will continue the EAP
> procedure. 
> 
> > If the peer does not NAK, EAP-HR signaling will continue.  I 
> > think this provides better backwards compatibility. 
> 
> Could you explain why it is better?  Perhaps call flows with
> combinations of legacy peers or authenticators might help? 

I would expect EAP-HR proponents to make the call flows, but the
reason is because the NAK-based method negotiation does not require
lower layer advertisement on re-auth support.  I don't buy the idea of
capability indication in EAP Request/Identity or any other proposal
that overloads Identity method because Identity is not a mandatory
method for EAP to start with.

> 
> > But in 
> > any case I agree that the authenticator has to be upgraded to 
> > support EAP-HR or EAP-ER.
> > 
> 
> And I believe the upgrades are equally significant or insignificant,

Agreed.

> depending on how you see it. I just don't understand how all the issues
> are resolved with the authenticator starting with the re-auth stuff or
> re-using EAP Success, etc. That seems to create more backwards
> compatibility issues and complicate co-existence of schemes like network
> selection and re-authentication, etc. 

I don't buy the idea of overloading EAP-Success.  As I indicated in my
other email, if we want to use EAP-HR, a new Success message with
acknowledgment should be used instead.  If the peer and authenticator
have agreed on EAP-ER method, then it is natural to mandate support of
the new Success message with acknowledgment for them.  This is how
backwards compability issue can be addressed in EAP-HR in my view.

Regards,
Yoshihiro Ohba


> 
> Vidya
> 
> 
> > Yoshihiro Ohba
> > 
> > 
> > On Thu, Apr 12, 2007 at 02:46:25AM -0700, Lakshminath Dondeti wrote:
> > > Madjid,
> > > 
> > > Thanks for sharing the details of your proposal, please see 
> > inline for 
> > > some notes:
> > > 
> > > Madjid Nakhjiri wrote:
> > > >Hi,
> > > >
> > > >As promised earlier, I am providing an analysis of use of 
> > EAP method 
> > > >for handover and re-authentication signaling. To me it seems that 
> > > >without introducing a new EAP code, one can accomplish the 
> > signaling 
> > > >with very little change to authenticator state machine, given that 
> > > >the authenticator already does receive and transmit AAA attributes 
> > > >along with AAA messages encapsulating EAP packets.
> > > 
> > > What is the goal here?  No changes to authenticator?  Very little 
> > > changes to authenticator?
> > > 
> > > Let's examine what happens when a new code is introduced?  Here are 
> > > the things the authenticator needs to do (I haven't worked 
> > on an EAP 
> > > implementation before; my "IETF" implementation and/or interop 
> > > experience is on GDOI, IKEv2 and GKDP).
> > > 
> > > * Accept EAP messages with Code=5 from the Peer
> > > * if Type != Reauth { drop; return}
> > > * else
> > > * route just as EAP Response Identity is routed (reuse code)
> > > 
> > > * Accept EAP messages with Code=6 from the Server
> > > * if Type!= Reauth {drop; return}
> > > * else
> > > * send the message to the Peer
> > > 
> > > I'd say that qualifies as a small change to the authenticator code. 
> > > That kind of upgrade would be of inconsequential 
> > complexity; given how
> > > 802.11 APs' Firmware is patched for all sorts of reasons rather 
> > > frequently, it should be a non-issue!
> > > 
> > > The other thing to note is that such changes are required with your 
> > > proposal too!
> > > 
> > > >
> > > >I have called this new method, EAP Handover and re-authentication 
> > > >method (EAP-HR), which consists of 3 messages (if you count EAP 
> > > >Success as method specific).
> > > >I have shown the 3-party key distribution exchange (KDE) can be 
> > > >carried over the EAP-HR messages easily.
> > > >As you can see in most of cases (handover, 
> > re-authentication and even 
> > > >in some cases for network setup), a trigger is easily 
> > available for 
> > > >the authenticator to start with EAP-HR Req, just the way 
> > EAP-identity 
> > > >starts from the authenticator. So the urgent need for 
> > peer-initiated 
> > > >messaging and hence the need to create new EAP code may go away.
> > > >
> > > 
> > > How would the authenticator know to start EAP Request/HR instead of 
> > > EAP Request/Identity?  That is a change to the authenticator, would 
> > > you agree?  Could you explain what the trigger is?
> > 
> > > 
> > > How would it know how to parse and route EAP Response/HR 
> > just like EAP 
> > > Response/Identity?  Parsing that message would be as 
> > simple/complex as 
> > > parsing something like EAP Initiate/Re-auth (I guess in the latter 
> > > case there is an extra if statement; I'll give you that!).
> > > 
> > > I have already asked the questions on how to reliably transport EAP 
> > > Success without changes to authenticators (if the answer is to make 
> > > the lower layer reliable, then surely that is a much bigger 
> > change!).  
> > > Next do we know that all authenticator implementations out 
> > there would 
> > > work with Success messages larger than 4 Octets?
> > > 
> > > I will try to look at the message payloads and respond separately 
> > > (Could you please use the notation everyone else has been using and 
> > > resend that part of your message?  The PID, DID, DIDN'T, 
> > UAID, DAID, 
> > > MAID, PAID, SAID stuff is confusing!)
> > > 
> > > regards,
> > > Lakshminath
> > > 
> > > **Note: No experts were bothered or harmed in crafting this 
> > message.  
> > > I have, however, referred to some relevant RFCs, taken into account 
> > > HOKEY mailing list discussions and meeting notes and offline 
> > > suggestions from various IETF contributors.  Oddly enough, 
> > none of the 
> > > people I spoke to had the label "expert" on their badges.
> > > 
> > > >
> > > >
> > > >Peer             authenticator             server
> > > >	EAP-HR REQ
> > > >	(DID, AID)
> > > >  <-------------
> > > >	EAP-HR RESP
> > > >      KDE message 1 and 2 (PID, AID and tokens)
> > > >------------------------------------------------->
> > > >		EAP/Success
> > > >		 (KDE message 3 and 4)
> > > ><---------------------------------------------------
> > > >
> > > >DID: domain ID (used for creating Domain keys)
> > > >AID: authenticator ID advertised by the authenticator 
> > (note this can 
> > > >be done as part of lower layer beacon advertisement), so carrying 
> > > >data through EAP-HR Request is not 100% necessary the KDE.
> > > >
> > > >
> > > >FAQ
> > > >=====
> > > >
> > > >Roundtrips: 
> > > >============
> > > >1.1 when trigger is available at authenticator (assuming 
> > > >authenticator-peer trip~20% of server-peer trip).
> > > >1.5 when trigger needs to arrive from the server.
> > > >
> > > >
> > > >Cases where trigger is available at authenticator
> > > >a) in handover, this is available through a handover 
> > request from the peer.
> > > >b) in re-authentication, the authentication/ key status is 
> > typically 
> > > >available at the authenticator as a result of previous AAA 
> > signaling (e.g.
> > > >Session-life-time attribute)
> > > >c) in network setup, the server may send a session-life-time=0 to 
> > > >authenticator along with the previous EAP authentication 
> > Success, to 
> > > >indicate the need to start HOKEY signaling.
> > > >
> > > >
> > > >EAP-HR versus EAP identity
> > > >======================
> > > >I have discussed this with several EAP experts and it seems that 
> > > >using EAP Identity request/ response versus using a new EAP method 
> > > >(EAP-HR) are almost identical.
> > > >The issue with EAP Identity is that it does not carry data.
> > > >IMO, modifying EAP Identity to carry data is more straight forward 
> > > >than creating EAP-HR.
> > > >
> > > >
> > > >
> > > >EAP Success:
> > > >==========
> > > >It seems that quite a number of people have already backed up the 
> > > >idea of modifying EAP success to carry data: people brought up the 
> > > >fact that 2284 did allow EAP success carrying data and the only 
> > > >reason 3748 banned EAP Success from carrying data was the 
> > inadequate 
> > > >method independent way of carrying data. It seems to me that keys 
> > > >derived from the hierarchy can be used to protect the EAP 
> > success and 
> > > >its data and this would allow for protected result 
> > indication as well.
> > > >
> > > >The other reason to allow EAP Success carry data is to provide a 
> > > >natural extension to the AAA (authorization, etc) signaling that 
> > > >currently does not reach beyond the authenticator.
> > > >
> > > >So with that in mind, I hope we don't rehash the previous emails 
> > > >citing sentences from 3748 about EAP Success carrying data...
> > > >
> > > >3 Party key distribution (KDE)
> > > >=======================
> > > >I have modified the 3 party key distribution slightly to 
> > accomodate 
> > > >the EAP method signaling.
> > > >
> > > >   0  Authenticator to peer: EAP(DAID, DID)
> > > >
> > > >   1  Peer to Authenticator: EAP((PID, DAID, DID, 
> > Np,KNps), [PID, DAID,
> > > >      Np,KNps]Kps)
> > > >
> > > >   2  Authenticator to Server: AAA(PID, UAID, [PID, UAID]Kas),
> > > >      AAA(EAP((PID, DAID, DID, Np,KNps), [PID, DAID, DID, 
> > > > Np,KNps]Kps))
> > > >
> > > >   3  Server to Authenticator: AAA({PID,AID,KNpa, KLpa, Kpa}KEas),
> > > >      AAA(EAP(KNpa, KLpa, KNps, [PID, AID, DID, Np+1,KNpa,KLpa,
> > > >      KNps]Kps))
> > > >
> > > >   4  Authenticator to Peer: EAP(KNpa, KLpa, KNps, [PID, 
> > AID, DID, Np+1,
> > > >      KNpa,KLpa, KNps]Kps])
> > > >
> > > >PID: peer ID.  
> > > >   DID: Domain ID
> > > >   AID: Authenticator ID
> > > >   DAID: Authenticator ID as perceived by the peer (down link ID)
> > > >   UAID: Authenticator ID as perceived by the server (uplink ID)
> > > >   {X}K: X encrypted with key K
> > > >   [X]K: Message Authentication Code over X with key K.
> > > >   X(Y): Y carried with X protocol
> > > >   Kps: A symmetric key shared between peer and Server for 
> > signing (IK,
> > > >   provisioned by EAP/HOKEY hierarchy) and identified by KNps.
> > > >
> > > >   KEps: A symmetric key shared between peer and Server 
> > for encryption
> > > >   (CK, provisioning by EAP/HOKEY hierarchy) and 
> > identified by KEpsid
> > > >
> > > >   KEas: A symmetric key shared between authenticator and 
> > Server for
> > > >   encryption (provisioned out of band).
> > > >
> > > >   Kas: A symmetric key between authentication and server 
> > for MDCs for
> > > >   signing (provisioned out of band).
> > > >
> > > >
> > > > Kpa: A symmetric key to be shared between peer and 
> > authenticator (key
> > > >   to be distributed to authenticator, the MDMSK in this 
> > document).  The
> > > >   key is named as KNpa.
> > > >
> > > >   KLx : Key lifetime for key x
> > > >
> > > >   KNx: Key name for Key x, e.g.  KENas: key name for KEas
> > > >
> > > >   Nx : Nonce provided by the party X
> > > >
> > > >I have provided more the details in a draft. 
> > > 
> > >http://www.ietf.org/internet-drafts/draft-nakhjiri-hokey-hierarchy-04
> > > >.txt
> > > >
> > > >Regards,
> > > >
> > > >Madjid
> > > >
> > > >-----Original Message-----
> > > >From: Charles Clancy [mailto:clancy@cs.umd.edu]
> > > >Sent: Saturday, March 31, 2007 11:58 AM
> > > >To: hokey@ietf.org
> > > >Subject: [HOKEY] consensus call: EAP-ER as HOKEY protocol
> > > >
> > > >HOKEY WG,
> > > >
> > > >The chairs are making a second consensus call request to 
> > adopt EAP-ER 
> > > >as a WG document to satisfy our re-auth and hand-off 
> > deliverables.  
> > > >It would serve as a starting point for development of the 
> > HOKEY protocol.
> > > >
> > > >Note that if accepted, it may be split into two WG documents, 
> > > >separating the EAP-ER-Bootstrap into a second set of messages that 
> > > >could be transported by any service to obtain a USRK or DSUSRK.
> > > >
> > > >Please respond by Friday, April 13.
> > > >
> > > 
> > > _______________________________________________
> > > 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 Apr 12 15:30: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 1Hc50R-0007gM-88; Thu, 12 Apr 2007 15:30:55 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hc50Q-0007gH-Om
	for hokey@ietf.org; Thu, 12 Apr 2007 15:30:54 -0400
Received: from imx12.toshiba.co.jp ([61.202.160.132])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hc50P-0002nx-2U
	for hokey@ietf.org; Thu, 12 Apr 2007 15:30:54 -0400
Received: from wall11.toshiba.co.jp (wall11 [133.199.90.149])
	by imx12.toshiba.co.jp  with ESMTP id l3CJUn05007565;
	Fri, 13 Apr 2007 04:30:49 +0900 (JST)
Received: (from root@localhost) by wall11.toshiba.co.jp  id l3CJUm4p001628;
	Fri, 13 Apr 2007 04:30:48 +0900 (JST)
Received: from ovp11.toshiba.co.jp [133.199.90.148] 
	by wall11.toshiba.co.jp with ESMTP id EAA01627;
	Fri, 13 Apr 2007 04:30:48 +0900
Received: from mx2.toshiba.co.jp (localhost [127.0.0.1])
	by ovp11.toshiba.co.jp  with ESMTP id l3CJUmJ3018910;
	Fri, 13 Apr 2007 04:30:48 +0900 (JST)
Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id l3CJUlgc005898;
	Fri, 13 Apr 2007 04:30:47 +0900 (JST)
Received: from steelhead ([172.30.24.105])
	by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 (built
	Apr 28
	2004)) with ESMTPSA id <0JGE00A4GGV8MM90@mail.po.toshiba.co.jp>; Fri,
	13 Apr 2007 04:30:47 +0900 (JST)
Received: from ohba by steelhead with local (Exim 4.63)
	(envelope-from )	id 1Hc50H-0006Hc-NG; Thu,
	12 Apr 2007 12:30:45 -0700
Date: Thu, 12 Apr 2007 15:30:45 -0400
From: Yoshihiro Ohba 
Subject: Re: [HOKEY] Using an EAP method for HOKEY??: was: consensus
	call:EAP-ER as HOKEY protocol
In-reply-to: <20070412192756.GG31369@steelhead>
To: Yoshihiro Ohba 
Message-id: <20070412193045.GH31369@steelhead>
MIME-version: 1.0
Content-type: text/plain; charset=iso-2022-jp
Content-disposition: inline
References: <20070412183354.GF31369@steelhead>
	
	<20070412192756.GG31369@steelhead>
User-Agent: Mutt/1.5.13 (2006-08-11)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f
Cc: 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

On Thu, Apr 12, 2007 at 03:27:56PM -0400, Yoshihiro Ohba wrote:
> On Thu, Apr 12, 2007 at 12:02:28PM -0700, Narayanan, Vidya wrote:
> > > 
> > > I think that the authenticator that supports EAP-HR can 
> > > always start with EAP Request/HR.  If the peer does not 
> > > support the method, it can simply NAK and then the 
> > > authenticator can fall back to legacy authentication by 
> > > sending a Request/Identity or other method request.
> > 
> > I don't understand. When a peer shows up, how does the authenticator
> > know if that peer has already done an initial EAP exchange and has valid
> > EMSK/DSRK, etc.? To me, the logical thing seems to be that the
> 
> The authenticator knows that the peer has valid EMSK/DSRK if the peer
> returns Request/HR instead of NAK.  
>  

Correction: Request/HR should read Response/HR.

_______________________________________________
HOKEY mailing list
HOKEY@ietf.org
https://www1.ietf.org/mailman/listinfo/hokey



From hokey-bounces@ietf.org Thu Apr 12 15:46: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 1Hc5F6-0007iD-Dr; Thu, 12 Apr 2007 15:46:04 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hc5F4-0007dw-EZ
	for hokey@ietf.org; Thu, 12 Apr 2007 15:46:02 -0400
Received: from numenor.qualcomm.com ([129.46.51.58])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hc5F3-0005Ez-Ks
	for hokey@ietf.org; Thu, 12 Apr 2007 15:46:02 -0400
Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158])
	by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id
	l3CJjuwx010258
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Thu, 12 Apr 2007 12:45:56 -0700
Received: from sanexcas01.na.qualcomm.com (sanexcas01.qualcomm.com
	[172.30.36.175])
	by totoro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l3CJjtNR005061;
	Thu, 12 Apr 2007 12:45:55 -0700 (PDT)
Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by
	sanexcas01.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 12 Apr 2007 12:45:55 -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
Subject: RE: [HOKEY] Using an EAP method for HOKEY??: was: consensus
	call:EAP-ER as HOKEY protocol
Date: Thu, 12 Apr 2007 12:45:58 -0700
Message-ID: 
In-Reply-To: <20070412192756.GG31369@steelhead>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [HOKEY] Using an EAP method for HOKEY??: was: consensus
	call:EAP-ER as HOKEY protocol
Thread-Index: Acd9OLskEAh0ALH1TmysqRtUAxnkjAAAJ09A
References: <20070412183354.GF31369@steelhead>
	
	<20070412192756.GG31369@steelhead>
From: "Narayanan, Vidya" 
To: "Yoshihiro Ohba" 
X-OriginalArrivalTime: 12 Apr 2007 19:45:55.0115 (UTC)
	FILETIME=[2F29A7B0:01C77D3B]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 746e7c8096e71e3815c27253c4c3edc6
Cc: 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

> > I don't understand. When a peer shows up, how does the=20
> authenticator=20
> > know if that peer has already done an initial EAP exchange and has=20
> > valid EMSK/DSRK, etc.? To me, the logical thing seems to be that the
>=20
> The authenticator knows that the peer has valid EMSK/DSRK if=20
> the peer returns Request/HR instead of NAK. =20
> =20

Isn't it more generic for the authenticator to always send EAP
Request/Identity and let the peer start the re-auth process based on its
current state? I don't understand why having this NAK and then starting
the regular EAP process would be better. To map this to EAP-ER, for
instance, we considered doing a specific "EAP-ER start" type of message
from the authenticator - it's purpose would be pretty much the same as
this EAP Request/HR (triggering the re-auth) - but, that didn't map to
the most generic case and letting the authenticators always send EAP
Request/Identity seemed better.=20

> > authenticator always sends EAP Request/Identity - if the peer has=20
> > valid key material, it may send a re-authentication message (EAP=20
> > Initiate/Re-auth in the case of EAP-ER); authenticator support for=20
> > such re-auth can be known either at the lower layer or if=20
> we decide to=20
> > include a capability indication in EAP Request/Identity. Peers that=20
> > don't support re-auth or peers that are doing an initial=20
> access will=20
> > simply respond with EAP Response/Identity and will continue the EAP=20
> > procedure.
> >=20
> > > If the peer does not NAK, EAP-HR signaling will continue.=20
>  I think=20
> > > this provides better backwards compatibility.
> >=20
> > Could you explain why it is better?  Perhaps call flows with=20
> > combinations of legacy peers or authenticators might help?
>=20
> I would expect EAP-HR proponents to make the call flows, but=20
> the reason is because the NAK-based method negotiation does=20
> not require lower layer advertisement on re-auth support. =20

It is not mandatory to have lower layer support for this. For instance,
a peer capable of re-auth may send a re-auth specific message in
response to EAP Request/Identity. If the authenticator does not support
re-auth, that will be dropped. After a timeout, the peer would then do a
full EAP exchange. For optimized operation, I expect next generation
lower layers to indicate support for re-auth anyway. This would be the
non-optimized case.=20

There is another advantage to having an independent peer initiated
message. In some lower layers, the peer can send that message in
parallel with L2 connection establishment without waiting for anything
to come from the authenticator. If we have to stick to EAP
Request/Response semantics, the authenticators will not accept
unsolicited responses and hence, the message from the authenticator now
becomes mandatory before the peer can send the Response. That is
inefficient and in some systems, the lack of ability to execute
authentication in parallel with L2 connection establishment is a
significant concern.=20

>I=20
> don't buy the idea of capability indication in EAP=20
> Request/Identity or any other proposal that overloads=20
> Identity method because Identity is not a mandatory method=20
> for EAP to start with.
>=20

Good. I'm in agreement there. In terms of including a capability
indication, that would be optional as well - so, if that is really
needed, we can have that discussion. But, in general, I don't like
overloading existing codes - so, I agree with you.=20

> >=20
> > > But in
> > > any case I agree that the authenticator has to be upgraded to=20
> > > support EAP-HR or EAP-ER.
> > >=20
> >=20
> > And I believe the upgrades are equally significant or insignificant,
>=20
> Agreed.
>=20

Good :)

> > depending on how you see it. I just don't understand how all the=20
> > issues are resolved with the authenticator starting with=20
> the re-auth=20
> > stuff or re-using EAP Success, etc. That seems to create more=20
> > backwards compatibility issues and complicate co-existence=20
> of schemes=20
> > like network selection and re-authentication, etc.
>=20
> I don't buy the idea of overloading EAP-Success. =20

Okay. We agree there.=20

>As I=20
> indicated in my other email, if we want to use EAP-HR, a new=20
> Success message with acknowledgment should be used instead. =20
> If the peer and authenticator have agreed on EAP-ER method,=20
> then it is natural to mandate support of the new Success=20
> message with acknowledgment for them.  This is how backwards=20
> compability issue can be addressed in EAP-HR in my view.
>=20

I prefer not having to add more messages when we don't need to. If
re-auth can be peer-initiated with new message codes, the response from
the server has the proper semantics and we don't need any additional
messages. Optionally, the process is tirggered by the authenticator
using EAP Request/Identity with no changes.=20

Regards,
Vidya

> Regards,
> Yoshihiro Ohba
>=20
>=20
> >=20
> > Vidya
> >=20
> >=20
> > > Yoshihiro Ohba
> > >=20
> > >=20
> > > On Thu, Apr 12, 2007 at 02:46:25AM -0700, Lakshminath=20
> Dondeti wrote:
> > > > Madjid,
> > > >=20
> > > > Thanks for sharing the details of your proposal, please see
> > > inline for
> > > > some notes:
> > > >=20
> > > > Madjid Nakhjiri wrote:
> > > > >Hi,
> > > > >
> > > > >As promised earlier, I am providing an analysis of use of
> > > EAP method
> > > > >for handover and re-authentication signaling. To me it=20
> seems that=20
> > > > >without introducing a new EAP code, one can accomplish the
> > > signaling
> > > > >with very little change to authenticator state machine, given=20
> > > > >that the authenticator already does receive and transmit AAA=20
> > > > >attributes along with AAA messages encapsulating EAP packets.
> > > >=20
> > > > What is the goal here?  No changes to authenticator? =20
> Very little=20
> > > > changes to authenticator?
> > > >=20
> > > > Let's examine what happens when a new code is introduced?  Here=20
> > > > are the things the authenticator needs to do (I haven't worked
> > > on an EAP
> > > > implementation before; my "IETF" implementation and/or interop=20
> > > > experience is on GDOI, IKEv2 and GKDP).
> > > >=20
> > > > * Accept EAP messages with Code=3D5 from the Peer
> > > > * if Type !=3D Reauth { drop; return}
> > > > * else
> > > > * route just as EAP Response Identity is routed (reuse code)
> > > >=20
> > > > * Accept EAP messages with Code=3D6 from the Server
> > > > * if Type!=3D Reauth {drop; return}
> > > > * else
> > > > * send the message to the Peer
> > > >=20
> > > > I'd say that qualifies as a small change to the=20
> authenticator code.=20
> > > > That kind of upgrade would be of inconsequential
> > > complexity; given how
> > > > 802.11 APs' Firmware is patched for all sorts of reasons rather=20
> > > > frequently, it should be a non-issue!
> > > >=20
> > > > The other thing to note is that such changes are required with=20
> > > > your proposal too!
> > > >=20
> > > > >
> > > > >I have called this new method, EAP Handover and=20
> re-authentication=20
> > > > >method (EAP-HR), which consists of 3 messages (if you=20
> count EAP=20
> > > > >Success as method specific).
> > > > >I have shown the 3-party key distribution exchange=20
> (KDE) can be=20
> > > > >carried over the EAP-HR messages easily.
> > > > >As you can see in most of cases (handover,
> > > re-authentication and even
> > > > >in some cases for network setup), a trigger is easily
> > > available for
> > > > >the authenticator to start with EAP-HR Req, just the way
> > > EAP-identity
> > > > >starts from the authenticator. So the urgent need for
> > > peer-initiated
> > > > >messaging and hence the need to create new EAP code=20
> may go away.
> > > > >
> > > >=20
> > > > How would the authenticator know to start EAP=20
> Request/HR instead=20
> > > > of EAP Request/Identity?  That is a change to the=20
> authenticator,=20
> > > > would you agree?  Could you explain what the trigger is?
> > >=20
> > > >=20
> > > > How would it know how to parse and route EAP Response/HR
> > > just like EAP
> > > > Response/Identity?  Parsing that message would be as
> > > simple/complex as
> > > > parsing something like EAP Initiate/Re-auth (I guess in=20
> the latter=20
> > > > case there is an extra if statement; I'll give you that!).
> > > >=20
> > > > I have already asked the questions on how to reliably transport=20
> > > > EAP Success without changes to authenticators (if the=20
> answer is to=20
> > > > make the lower layer reliable, then surely that is a much bigger
> > > change!). =20
> > > > Next do we know that all authenticator implementations out
> > > there would
> > > > work with Success messages larger than 4 Octets?
> > > >=20
> > > > I will try to look at the message payloads and respond=20
> separately=20
> > > > (Could you please use the notation everyone else has been using=20
> > > > and resend that part of your message?  The PID, DID, DIDN'T,
> > > UAID, DAID,
> > > > MAID, PAID, SAID stuff is confusing!)
> > > >=20
> > > > regards,
> > > > Lakshminath
> > > >=20
> > > > **Note: No experts were bothered or harmed in crafting this
> > > message. =20
> > > > I have, however, referred to some relevant RFCs, taken into=20
> > > > account HOKEY mailing list discussions and meeting notes and=20
> > > > offline suggestions from various IETF contributors. =20
> Oddly enough,
> > > none of the
> > > > people I spoke to had the label "expert" on their badges.
> > > >=20
> > > > >
> > > > >
> > > > >Peer             authenticator             server
> > > > >	EAP-HR REQ
> > > > >	(DID, AID)
> > > > >  <-------------
> > > > >	EAP-HR RESP
> > > > >      KDE message 1 and 2 (PID, AID and tokens)
> > > > >------------------------------------------------->
> > > > >		EAP/Success
> > > > >		 (KDE message 3 and 4)
> > > > ><---------------------------------------------------
> > > > >
> > > > >DID: domain ID (used for creating Domain keys)
> > > > >AID: authenticator ID advertised by the authenticator
> > > (note this can
> > > > >be done as part of lower layer beacon advertisement),=20
> so carrying=20
> > > > >data through EAP-HR Request is not 100% necessary the KDE.
> > > > >
> > > > >
> > > > >FAQ
> > > > >=3D=3D=3D=3D=3D
> > > > >
> > > > >Roundtrips:=20
> > > > >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > > > >1.1 when trigger is available at authenticator (assuming=20
> > > > >authenticator-peer trip~20% of server-peer trip).
> > > > >1.5 when trigger needs to arrive from the server.
> > > > >
> > > > >
> > > > >Cases where trigger is available at authenticator
> > > > >a) in handover, this is available through a handover
> > > request from the peer.
> > > > >b) in re-authentication, the authentication/ key status is
> > > typically
> > > > >available at the authenticator as a result of previous AAA
> > > signaling (e.g.
> > > > >Session-life-time attribute)
> > > > >c) in network setup, the server may send a=20
> session-life-time=3D0 to=20
> > > > >authenticator along with the previous EAP authentication
> > > Success, to
> > > > >indicate the need to start HOKEY signaling.
> > > > >
> > > > >
> > > > >EAP-HR versus EAP identity
> > > > =
>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > > > >I have discussed this with several EAP experts and it=20
> seems that=20
> > > > >using EAP Identity request/ response versus using a new EAP=20
> > > > >method
> > > > >(EAP-HR) are almost identical.
> > > > >The issue with EAP Identity is that it does not carry data.
> > > > >IMO, modifying EAP Identity to carry data is more straight=20
> > > > >forward than creating EAP-HR.
> > > > >
> > > > >
> > > > >
> > > > >EAP Success:
> > > > >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > > > >It seems that quite a number of people have already=20
> backed up the=20
> > > > >idea of modifying EAP success to carry data: people brought up=20
> > > > >the fact that 2284 did allow EAP success carrying data and the=20
> > > > >only reason 3748 banned EAP Success from carrying data was the
> > > inadequate
> > > > >method independent way of carrying data. It seems to=20
> me that keys=20
> > > > >derived from the hierarchy can be used to protect the EAP
> > > success and
> > > > >its data and this would allow for protected result
> > > indication as well.
> > > > >
> > > > >The other reason to allow EAP Success carry data is to=20
> provide a=20
> > > > >natural extension to the AAA (authorization, etc)=20
> signaling that=20
> > > > >currently does not reach beyond the authenticator.
> > > > >
> > > > >So with that in mind, I hope we don't rehash the=20
> previous emails=20
> > > > >citing sentences from 3748 about EAP Success carrying data...
> > > > >
> > > > >3 Party key distribution (KDE)
> > > > =
>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > > > >I have modified the 3 party key distribution slightly to
> > > accomodate
> > > > >the EAP method signaling.
> > > > >
> > > > >   0  Authenticator to peer: EAP(DAID, DID)
> > > > >
> > > > >   1  Peer to Authenticator: EAP((PID, DAID, DID,
> > > Np,KNps), [PID, DAID,
> > > > >      Np,KNps]Kps)
> > > > >
> > > > >   2  Authenticator to Server: AAA(PID, UAID, [PID, UAID]Kas),
> > > > >      AAA(EAP((PID, DAID, DID, Np,KNps), [PID, DAID, DID,
> > > > > Np,KNps]Kps))
> > > > >
> > > > >   3  Server to Authenticator: AAA({PID,AID,KNpa,=20
> KLpa, Kpa}KEas),
> > > > >      AAA(EAP(KNpa, KLpa, KNps, [PID, AID, DID, Np+1,KNpa,KLpa,
> > > > >      KNps]Kps))
> > > > >
> > > > >   4  Authenticator to Peer: EAP(KNpa, KLpa, KNps, [PID,
> > > AID, DID, Np+1,
> > > > >      KNpa,KLpa, KNps]Kps])
> > > > >
> > > > >PID: peer ID. =20
> > > > >   DID: Domain ID
> > > > >   AID: Authenticator ID
> > > > >   DAID: Authenticator ID as perceived by the peer=20
> (down link ID)
> > > > >   UAID: Authenticator ID as perceived by the server=20
> (uplink ID)
> > > > >   {X}K: X encrypted with key K
> > > > >   [X]K: Message Authentication Code over X with key K.
> > > > >   X(Y): Y carried with X protocol
> > > > >   Kps: A symmetric key shared between peer and Server for
> > > signing (IK,
> > > > >   provisioned by EAP/HOKEY hierarchy) and identified by KNps.
> > > > >
> > > > >   KEps: A symmetric key shared between peer and Server
> > > for encryption
> > > > >   (CK, provisioning by EAP/HOKEY hierarchy) and
> > > identified by KEpsid
> > > > >
> > > > >   KEas: A symmetric key shared between authenticator and
> > > Server for
> > > > >   encryption (provisioned out of band).
> > > > >
> > > > >   Kas: A symmetric key between authentication and server
> > > for MDCs for
> > > > >   signing (provisioned out of band).
> > > > >
> > > > >
> > > > > Kpa: A symmetric key to be shared between peer and
> > > authenticator (key
> > > > >   to be distributed to authenticator, the MDMSK in this
> > > document).  The
> > > > >   key is named as KNpa.
> > > > >
> > > > >   KLx : Key lifetime for key x
> > > > >
> > > > >   KNx: Key name for Key x, e.g.  KENas: key name for KEas
> > > > >
> > > > >   Nx : Nonce provided by the party X
> > > > >
> > > > >I have provided more the details in a draft.=20
> > > >=20
> > >=20
> >http://www.ietf.org/internet-drafts/draft-nakhjiri-hokey-hierarchy-
> > > >04
> > > > >.txt
> > > > >
> > > > >Regards,
> > > > >
> > > > >Madjid
> > > > >
> > > > >-----Original Message-----
> > > > >From: Charles Clancy [mailto:clancy@cs.umd.edu]
> > > > >Sent: Saturday, March 31, 2007 11:58 AM
> > > > >To: hokey@ietf.org
> > > > >Subject: [HOKEY] consensus call: EAP-ER as HOKEY protocol
> > > > >
> > > > >HOKEY WG,
> > > > >
> > > > >The chairs are making a second consensus call request to
> > > adopt EAP-ER
> > > > >as a WG document to satisfy our re-auth and hand-off
> > > deliverables. =20
> > > > >It would serve as a starting point for development of the
> > > HOKEY protocol.
> > > > >
> > > > >Note that if accepted, it may be split into two WG documents,=20
> > > > >separating the EAP-ER-Bootstrap into a second set of messages=20
> > > > >that could be transported by any service to obtain a=20
> USRK or DSUSRK.
> > > > >
> > > > >Please respond by Friday, April 13.
> > > > >
> > > >=20
> > > > _______________________________________________
> > > > HOKEY mailing list
> > > > HOKEY@ietf.org
> > > > https://www1.ietf.org/mailman/listinfo/hokey
> > > >=20
> > >=20
> > > _______________________________________________
> > > HOKEY mailing list
> > > HOKEY@ietf.org
> > > https://www1.ietf.org/mailman/listinfo/hokey
> > >=20
> >=20
> >=20
>=20

_______________________________________________
HOKEY mailing list
HOKEY@ietf.org
https://www1.ietf.org/mailman/listinfo/hokey



From hokey-bounces@ietf.org Thu Apr 12 16:14: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 1Hc5gd-0006b2-1P; Thu, 12 Apr 2007 16:14:31 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hc5gc-0006YY-62
	for hokey@ietf.org; Thu, 12 Apr 2007 16:14:30 -0400
Received: from usaga01-in.huawei.com ([206.16.17.211])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hc5gb-00018J-T7
	for hokey@ietf.org; Thu, 12 Apr 2007 16:14:30 -0400
Received: from huawei.com (usaga01-in [172.18.4.6])
	by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTP id <0JGE00FIXIW5SQ@usaga01-in.huawei.com> for
	hokey@ietf.org; Thu, 12 Apr 2007 13:14:29 -0700 (PDT)
Received: from N737011
	(pool-71-112-139-16.sttlwa.dsl-w.verizon.net [71.112.139.16])
	by usaga01-in.huawei.com
	(iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar  3 2004))
	with ESMTPA id <0JGE00EYQIVZDR@usaga01-in.huawei.com> for
	hokey@ietf.org; Thu, 12 Apr 2007 13:14:29 -0700 (PDT)
Date: Thu, 12 Apr 2007 13:14:29 -0700
From: Madjid Nakhjiri 
Subject: RE: [HOKEY] Using an EAP method for HOKEY??: was: consensus
	call:EAP-ER as HOKEY protocol
In-reply-to: 
To: "'Narayanan, Vidya'" ,
	'Yoshihiro Ohba' 
Message-id: <001601c77d3f$2e3c3da0$2f01a8c0@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962
X-Mailer: Microsoft Office Outlook 11
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Thread-index: Acd9OLskEAh0ALH1TmysqRtUAxnkjAAAJ09AAAEWFTA=
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0
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

EAP does not have an inbuilt method negotiation process, meaning if a party
does not support a method it simply NAKs it.

Plus, authenticator may have other indication about a HOKEY peer, as I have
discussed in my draft. 

1)For boot up, which is the hardest one, for instance the server sending the
initial EAP method success and the AAA authorization attributes, may send
some attributes down indicating this, or simply send a session-life time of
zero to indicate this.

2)for handover and re-auth, could be based on lower layer requests for
associations, etc. Most of lower layers, e.g. 802.11/16 have messaging for
this.

Getting a trigger to an authenticator through a lower layer method is simply
a matter of building the system and not necessarily part of the protocol. 

I don't think it is absolutely necessary to change EAP to include the
triggers. This is very similar to getting a trigger to start Mobile IP,
based on lower layer handover triggers

Many times in IETF we do the actual protocol, whereas the triggers that
start the protocol come from somewhere that may not be discussed in the
protocol. You can argue in the same way how the system starts an EAP access
control, how does the system knows a phone/ laptop just booted up and needs
to access the network? But EAP has been working all along based on lower
layer association requests that trigger it.

Madjid

-----Original Message-----
From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] 
Sent: Thursday, April 12, 2007 12:46 PM
To: Yoshihiro Ohba
Cc: Dondeti, Lakshminath; hokey@ietf.org; Madjid Nakhjiri
Subject: RE: [HOKEY] Using an EAP method for HOKEY??: was: consensus
call:EAP-ER as HOKEY protocol

> > I don't understand. When a peer shows up, how does the 
> authenticator 
> > know if that peer has already done an initial EAP exchange and has 
> > valid EMSK/DSRK, etc.? To me, the logical thing seems to be that the
> 
> The authenticator knows that the peer has valid EMSK/DSRK if 
> the peer returns Request/HR instead of NAK.  
>  

Isn't it more generic for the authenticator to always send EAP
Request/Identity and let the peer start the re-auth process based on its
current state? I don't understand why having this NAK and then starting
the regular EAP process would be better. To map this to EAP-ER, for
instance, we considered doing a specific "EAP-ER start" type of message
from the authenticator - it's purpose would be pretty much the same as
this EAP Request/HR (triggering the re-auth) - but, that didn't map to
the most generic case and letting the authenticators always send EAP
Request/Identity seemed better. 
> 



_______________________________________________
HOKEY mailing list
HOKEY@ietf.org
https://www1.ietf.org/mailman/listinfo/hokey



From hokey-bounces@ietf.org Thu Apr 12 19: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 1Hc907-0008N9-2c; Thu, 12 Apr 2007 19:46:51 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hc905-0008KR-Q6
	for hokey@ietf.org; Thu, 12 Apr 2007 19:46:49 -0400
Received: from usaga01-in.huawei.com ([206.16.17.211])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hc904-0007sa-Im
	for hokey@ietf.org; Thu, 12 Apr 2007 19:46:49 -0400
Received: from huawei.com (usaga01-in [172.18.4.6])
	by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTP id <0JGE00FVPSPZSQ@usaga01-in.huawei.com> for
	hokey@ietf.org; Thu, 12 Apr 2007 16:46:48 -0700 (PDT)
Received: from N737011
	(pool-71-112-139-16.sttlwa.dsl-w.verizon.net [71.112.139.16])
	by usaga01-in.huawei.com
	(iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar  3 2004))
	with ESMTPA id <0JGE003PYSPVGM@usaga01-in.huawei.com> for
	hokey@ietf.org; Thu, 12 Apr 2007 16:46:47 -0700 (PDT)
Date: Thu, 12 Apr 2007 16:46:49 -0700
From: Madjid Nakhjiri 
Subject: RE: [HOKEY] Using an EAP method for HOKEY??:was:consensuscall:EAP-ERas
	HOKEY protocol
In-reply-to: <461D5031.2040103@qualcomm.com>
To: 'Lakshminath Dondeti' 
Message-id: <005e01c77d5c$d6eae510$2f01a8c0@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962
X-Mailer: Microsoft Office Outlook 11
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Thread-index: Acd8frInfsQ9mKJbRuyDnVrZ6X/x7AA3XIvg
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a
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



-----Original Message-----
From: Lakshminath Dondeti [mailto:ldondeti@qualcomm.com] 
Sent: Wednesday, April 11, 2007 2:17 PM
To: Madjid Nakhjiri
Cc: 'Narayanan, Vidya'; hokey@ietf.org
Subject: Re: [HOKEY] Using an EAP method for
HOKEY??:was:consensuscall:EAP-ERas HOKEY protocol

Madjid Nakhjiri wrote:
> I think we already discussed that we do not need EAP ID request/response
> necessary for every exchange, so one 1 RT goes away there.

Hmmm, on the Authenticator to AS side, there will still have to be a 
message even if the EAP Request & Response Id exchange on the Peer to 
Authenticator link is optional.  Do you agree?

Madjid>>Not sure I understand, do you mean AS to Authenticator? If yes, then
I agree, as I said in other emails, if the request has to come all way from
the AS, then you have 1/2 RT, but I was thinking the same way that EAP ID
request comes from Authenticator, we could start the signaling from
authenticator (authenticator-peer trip<<1/2 RT IMO). You could say it is a
hack to have the method started at authenticator and I agree, but EAP ID is
done that way today. The alternative to a new EAP method would be to load
the EAP ID response, but that would mean changing existing ID response. 

 



_______________________________________________
HOKEY mailing list
HOKEY@ietf.org
https://www1.ietf.org/mailman/listinfo/hokey



From hokey-bounces@ietf.org Thu Apr 12 20:05: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 1Hc9Hu-0003zz-47; Thu, 12 Apr 2007 20:05:14 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hc9Hs-0003xv-C2
	for hokey@ietf.org; Thu, 12 Apr 2007 20:05:12 -0400
Received: from usaga01-in.huawei.com ([206.16.17.211])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hc9Hs-0000bw-1B
	for hokey@ietf.org; Thu, 12 Apr 2007 20:05:12 -0400
Received: from huawei.com (usaga01-in [172.18.4.6])
	by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTP id <0JGE00FMNTKNSQ@usaga01-in.huawei.com> for
	hokey@ietf.org; Thu, 12 Apr 2007 17:05:11 -0700 (PDT)
Received: from N737011
	(pool-71-112-139-16.sttlwa.dsl-w.verizon.net [71.112.139.16])
	by usaga01-in.huawei.com
	(iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar  3 2004))
	with ESMTPA id <0JGE003WITKHGM@usaga01-in.huawei.com> for
	hokey@ietf.org; Thu, 12 Apr 2007 17:05:11 -0700 (PDT)
Date: Thu, 12 Apr 2007 17:05:11 -0700
From: Madjid Nakhjiri 
Subject: RE: [HOKEY] nakhjiri-hokey-hierarchy-04 available
In-reply-to: <461DE873.4070108@dif.um.es>
To: 'Rafa Marin Lopez' 
Message-id: <006201c77d5f$67f71680$2f01a8c0@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962
X-Mailer: Microsoft Office Outlook 11
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: quoted-printable
Thread-index: Acd82X7FjHorLy/CToGS4xR676rKNQAg2Zog
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172
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 Rafa,

Thanks for the note.

As far as 3 party KDE, I agree it can be transported differently, I was =
just
trying to show it can be done with an EAP method, that is all. The draft =
I
submitted shows other things that are needed for a complete solutions as
well.
As long as the bundle of specifications the group creates provides a
complete solution, does not leave any holes or create too many
uninteroperable options, it should not matter whether we have one or two
docs, However, please remember that we are defining a 3-party KDE for =
two
specific purpose (delivering MDMSK to an authenticator, or delivering
visited HRK to another domain), so I think we should keep that context =
in
mind and then try to deliver a complete solution for the hokey problem, =
not
a bunch of generic specifications.

Also, thanks a lot for the note on loaded EAP ID implementation, good to
know it does not change authenticator state machine, that is what I was =
sort
of expecting. However, I would think you could replace the =
crypto-generated
ID with protection provided by keys protecting EAP signaling (IK and CK) =
and
that way do not have to have specific crypto for IDs. I showed this in =
the
draft as well. The only thing I was not sure about was whether to =
generate
the CK and IK from HRK or directly from EMSK.


Madjid


-----Original Message-----
From: Rafa Marin Lopez [mailto:rafa@dif.um.es]=20
Sent: Thursday, April 12, 2007 1:06 AM
To: Madjid Nakhjiri
Cc: hokey@ietf.org
Subject: Re: [HOKEY] nakhjiri-hokey-hierarchy-04 available

Madjid Nakhjiri escribi=F3:
> Hi Folks,
>  =20
Hi Madjid,
> Trying to see how the various pieces of the puzzle from EAP signaling =
to
key
> hierarchy and 3 party key distribution fit together, I have updated =
the
key
> hierarchy draft. The draft tries to follow the new guidelines for use =
of
> EMSK and is experimenting with use of EMSK in deriving the handover =
root
key
> for use in multiple domains.
>  =20
I have taken a look to the I-D and I'd suggest to separate the EAP=20
method based signalling from the
handover key hierarchy content into a separate I-D. That would really=20
help to clarify things.
You may count on me for this.

As a note, to me, EAP-HR you describe should work as a general transport =

(and therefore independent of the specific 3-party protocol) for a still =

under
definition 3-party protocol that should be in another I-D as Charles=20
suggested.

Regarding to the message sent by EAP peer upon receiving the EAP Req/Id, =

I would like to comment that we are experimenting (with a=20
proof-of-concept testbed) a trade-off solution based on=20
cryptographically generated identities which are built by using keys=20
derived from the EMSK. The identity is encoded in base64 format and=20
included in the EAP response/identity and forwarded. The AAA server can=20
verify that the identity was generated by using a valid key. We have=20
tested this in a linksys access point and we have not found any problem=20
so far. The solution implies little modifications at EAP peer and EAP=20
server state machines (not the transitions itself but the states).=20
Fortunately, the EAP authenticator state machine does not need any=20
modification.
=20
However, the EAP peer must relay in the security association protocol in =

order to complete the process and to know everything was ok. So a sort=20
of EAP success carrying authenticated data would really help :).


> The draft also discusses the use of 3 party key distribution, the
parameters
> involved, the AAA attributes and EAP extensions.
>  =20
This might also be included in the separated EAP-HR I-D.

My 0.02 cents.
> The draft can be found at:
>
> =
http://www.ietf.org/internet-drafts/draft-nakhjiri-hokey-hierarchy-04.txt=

>
> comments and discussions are welcome.
>
> R,
>
> Madjid
>
>
>
>
> _______________________________________________
> HOKEY mailing list
> HOKEY@ietf.org
> https://www1.ietf.org/mailman/listinfo/hokey
>
>
>  =20


--=20
------------------------------------------------------
Rafael Marin Lopez
Depto. Ing. de la Info. y las Comunicaciones
Faculty of Computer Science-University of Murcia
30100 Murcia - Spain
Telf: +34968398501    e-mail: rafa@dif.um.es
------------------------------------------------------




_______________________________________________
HOKEY mailing list
HOKEY@ietf.org
https://www1.ietf.org/mailman/listinfo/hokey



From hokey-bounces@ietf.org Thu Apr 12 20:11: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 1Hc9OQ-0006o2-DU; Thu, 12 Apr 2007 20:11:58 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hc9OP-0006nd-3s
	for hokey@ietf.org; Thu, 12 Apr 2007 20:11:57 -0400
Received: from usaga01-in.huawei.com ([206.16.17.211])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hc9ON-0004CB-So
	for hokey@ietf.org; Thu, 12 Apr 2007 20:11:57 -0400
Received: from huawei.com (usaga01-in [172.18.4.6])
	by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTP id <0JGE00F7HTVVSQ@usaga01-in.huawei.com> for
	hokey@ietf.org; Thu, 12 Apr 2007 17:11:55 -0700 (PDT)
Received: from N737011
	(pool-71-112-139-16.sttlwa.dsl-w.verizon.net [71.112.139.16])
	by usaga01-in.huawei.com
	(iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar  3 2004))
	with ESMTPA id <0JGE003C6TVRGM@usaga01-in.huawei.com> for
	hokey@ietf.org; Thu, 12 Apr 2007 17:11:55 -0700 (PDT)
Date: Thu, 12 Apr 2007 17:11:56 -0700
From: Madjid Nakhjiri 
Subject: RE: [HOKEY] Using an EAP method for HOKEY??:was:consensuscall:EAP-ERas
	HOKEY protocol
In-reply-to: <461D5031.2040103@qualcomm.com>
To: 'Lakshminath Dondeti' 
Message-id: <006301c77d60$597c4fc0$2f01a8c0@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962
X-Mailer: Microsoft Office Outlook 11
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Thread-index: Acd8frInfsQ9mKJbRuyDnVrZ6X/x7AA4NdCw
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22
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 missed this question.
I agree that we need to fix a few issues for EAP Success, such as adding
protection for it, but EAP community has been crying over lack of protection
for result indication for quite some time, so that would be a welcome
change. I think it can be achieved.

As far as adding EAP Success reliability, it may be tricky (since EAP
success is not acked), but I am not sure at EAP layer it has to do with
authenticator, does it? I am curious, why you say that?


-----Original Message-----
From: Lakshminath Dondeti [mailto:ldondeti@qualcomm.com] 
Sent: Wednesday, April 11, 2007 2:17 PM
To: Madjid Nakhjiri
Cc: 'Narayanan, Vidya'; hokey@ietf.org
Subject: Re: [HOKEY] Using an EAP method for
HOKEY??:was:consensuscall:EAP-ERas HOKEY protocol

> 
> We are also discussing loading EAP Success, rather than sending an empty
> finish followed by a dumb success, so another RT goes away there too.

How do you send EAP Success, overloaded, reliably without modifying 
authenticators?
> 



_______________________________________________
HOKEY mailing list
HOKEY@ietf.org
https://www1.ietf.org/mailman/listinfo/hokey



From hokey-bounces@ietf.org Thu Apr 12 22:08: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 1HcBDJ-00074D-Hu; Thu, 12 Apr 2007 22:08:37 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HcBDH-000743-Rd
	for hokey@ietf.org; Thu, 12 Apr 2007 22:08:35 -0400
Received: from rwcrmhc15.comcast.net ([204.127.192.85])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcBDG-0000oU-G1
	for hokey@ietf.org; Thu, 12 Apr 2007 22:08:35 -0400
Received: from [127.0.0.1] (c-68-49-199-146.hsd1.md.comcast.net[68.49.199.146])
	by comcast.net (rwcrmhc15) with ESMTP
	id <20070413020833m15007fe7se>; Fri, 13 Apr 2007 02:08:33 +0000
Message-ID: <461EE623.202@cs.umd.edu>
Date: Thu, 12 Apr 2007 22:08:35 -0400
From: Charles Clancy 
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: Madjid Nakhjiri 
References: <006301c77d60$597c4fc0$2f01a8c0@china.huawei.com>
In-Reply-To: <006301c77d60$597c4fc0$2f01a8c0@china.huawei.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4
Cc: hokey@ietf.org
Subject: [HOKEY] HOKEY transport compromise? :was: Using an EAP method for
	HOKEY??
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,

One problem I have with using methods instead of codes is protocol 
layering.  Hao mentioned it would be easier to implement a new method 
rather than a new code, and I assume this is because you can simply load 
a new DLL into whatever implementation you're using.  I disagree.  The 
method-based transport we're talking about here doesn't behave like 
normal methods.

It needs to interact with and modify keying material generated by 
*other* methods, stored at the EAP layer.  It needs to modify EAP state 
in ways that methods don't normally modify EAP state.  In Madjid's 
proposal, it may need to have a message generated at the authenticator 
instead of the EAP server.  Consequently, the existing method APIs that 
would make methods easy to implement won't work for a HOKEY method.

So, if what we're doing doesn't behave like a method, I don't think it 
should be transported by a method.

I think a new EAP Success would be reasonable.  Overloading the current 
one is problematic.  I think defining a new EAP ID request/reply would 
also be reasonable.  Overloading the current ones is problematic.

What about using a transport similar to EAP-HR, but defining new codes 
for the messages rather than reusing the current ones?  We could address 
a variety of other EAP problems at the same time, for example by 
defining a TLV structure for data contained in EAP ID request/responses 
and EAP success.

What do others think about this?

--
t. charles clancy, ph.d.  <>  tcc@umd.edu  <>  www.cs.umd.edu/~clancy

Madjid Nakhjiri wrote:
> I missed this question.
> I agree that we need to fix a few issues for EAP Success, such as adding
> protection for it, but EAP community has been crying over lack of protection
> for result indication for quite some time, so that would be a welcome
> change. I think it can be achieved.
> 
> As far as adding EAP Success reliability, it may be tricky (since EAP
> success is not acked), but I am not sure at EAP layer it has to do with
> authenticator, does it? I am curious, why you say that?
> 
> 
> -----Original Message-----
> From: Lakshminath Dondeti [mailto:ldondeti@qualcomm.com] 
> Sent: Wednesday, April 11, 2007 2:17 PM
> To: Madjid Nakhjiri
> Cc: 'Narayanan, Vidya'; hokey@ietf.org
> Subject: Re: [HOKEY] Using an EAP method for
> HOKEY??:was:consensuscall:EAP-ERas HOKEY protocol
> 
>> We are also discussing loading EAP Success, rather than sending an empty
>> finish followed by a dumb success, so another RT goes away there too.
> 
> How do you send EAP Success, overloaded, reliably without modifying 
> authenticators?
> 
> 
> 
> _______________________________________________
> 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 Apr 12 22:14:43 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HcBJD-0003wA-8a; Thu, 12 Apr 2007 22:14:43 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HcBJC-0003w2-BD
	for hokey@ietf.org; Thu, 12 Apr 2007 22:14:42 -0400
Received: from rwcrmhc13.comcast.net ([216.148.227.153])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcBJB-0003G7-1U
	for hokey@ietf.org; Thu, 12 Apr 2007 22:14:42 -0400
Received: from [127.0.0.1] (c-68-49-199-146.hsd1.md.comcast.net[68.49.199.146])
	by comcast.net (rwcrmhc13) with ESMTP
	id <20070413021439m13003b31ve>; Fri, 13 Apr 2007 02:14:40 +0000
Message-ID: <461EE796.4000900@cs.umd.edu>
Date: Thu, 12 Apr 2007 22:14:46 -0400
From: Charles Clancy 
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: Madjid Nakhjiri 
Subject: Re: [HOKEY] consensus call: key distribution security requirement
References: <008801c77bc2$356d83f0$2f01a8c0@china.huawei.com>
In-Reply-To: <008801c77bc2$356d83f0$2f01a8c0@china.huawei.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4
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

MAdjid,

I'm only eliminating B in the initial messages 1/2.  The Lying NAS 
problem is prevented by B being included in messages 3/4.  When the peer 
receives message 4, if the value of "B" differs from the advertised 
value the peer can disconnect.  The side effect is we don't have peer 
authorization, so keying material ends up being sent to "B".  But, 
assuming we have all those freshness guarantees, that keying material is 
useless.

--
t. charles clancy, ph.d.  <>  tcc@umd.edu  <>  www.cs.umd.edu/~clancy

Madjid Nakhjiri wrote:
> Hi Charles, 
> 
> I am still catching up on my emails. By eliminating B you are introducing
> the vulnerability to the lying NAS problem. So I personally never saw adding
> B as a peer consent thing, but rather as part of channel binding. This was
> part of the channel binding solution I presented in SJ even.
> 
>  I don't really see a big problem with peer knowing the authenticator ID, it
> can either go as part of the EAP request message or as part of L2 beacon
> carrying higher layer network data. 802.21 MIH information server is
> supposed to carry all kinds of network data to the mobiles...
> 
> R,
> 
> Madjid
> 
> -----Original Message-----
> From: Charles Clancy [mailto:clancy@cs.umd.edu] 
> Sent: Wednesday, April 04, 2007 6:27 PM
> To: hokey@ietf.org
> Subject: Re: [HOKEY] consensus call: key distribution security requirement
> 
> All,
> 
> I think we need to look at the protocols.  To compare...
> 
> 3-party protocol (Dan's proposal, slightly simplified assuming AAA 
> provides the necessary transport security):
> 
>     1) A->B: A, {A, B, Na}Kas
>     2) B->S: A, B, {A, B, Na}Kas
>     3) S->B: {B, Na}Kas, {A, Kab}Kbs
>     4) B->A: {B, Na}Kas
> 
> EAP-ER (translated to above notation and assuming AAA transport):
> 
>     1) A->B: A, {A, Na}Kas
>     2) B->S: A, B, {A, Na}Kas
>     3) S->B: {Na}Kas, {Kab}Kbs
>     4) B->A: {Na}Kas
> 
> EAP-ER+CB (my proposal for adding channel binding to EAP-ER):
> 
>     1) A->B: A, {A, Na}Kas
>     2) B->S: A, B, {A, Na}Kas
>     3) S->B: {B, Na}Kas, {A, Kab}Kbs
>     4) B->A: {B, Na}Kas
> 
> So, we've added "A" and "B" in messages 3 and 4, but not added "B" in 
> message 1.  I feel this satisfies everything *but* peer consent, and 
> doesn't require A to know "B" at the beginning.
> 


_______________________________________________
HOKEY mailing list
HOKEY@ietf.org
https://www1.ietf.org/mailman/listinfo/hokey



From hokey-bounces@ietf.org Thu Apr 12 22:31:05 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HcBZ3-00056g-3j; Thu, 12 Apr 2007 22:31:05 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HcBZ1-00056a-Ki
	for hokey@ietf.org; Thu, 12 Apr 2007 22:31:03 -0400
Received: from rwcrmhc11.comcast.net ([204.127.192.81])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcBZ1-000896-9c
	for hokey@ietf.org; Thu, 12 Apr 2007 22:31:03 -0400
Received: from [127.0.0.1] (c-68-49-199-146.hsd1.md.comcast.net[68.49.199.146])
	by comcast.net (rwcrmhc11) with ESMTP
	id <20070413023102m11005hge6e>; Fri, 13 Apr 2007 02:31:02 +0000
Message-ID: <461EEB6D.5050704@cs.umd.edu>
Date: Thu, 12 Apr 2007 22:31:09 -0400
From: Charles Clancy 
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: Charles Clancy 
Subject: Re: [HOKEY] HOKEY transport compromise? :was: Using an EAP method
	for	HOKEY??
References: <006301c77d60$597c4fc0$2f01a8c0@china.huawei.com>
	<461EE623.202@cs.umd.edu>
In-Reply-To: <461EE623.202@cs.umd.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248
Cc: 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

Charles Clancy wrote:
> All,
> 
> One problem I have with using methods instead of codes is protocol 
> layering.  Hao mentioned it would be easier to implement a new method 

Sorry, it was actually Michaela that made that comment... though it 
sounds like something Hao would say.  ;-)

> rather than a new code, and I assume this is because you can simply load 
> a new DLL into whatever implementation you're using.  I disagree.  The 
> method-based transport we're talking about here doesn't behave like 
> normal methods.
> 
> It needs to interact with and modify keying material generated by 
> *other* methods, stored at the EAP layer.  It needs to modify EAP state 
> in ways that methods don't normally modify EAP state.  In Madjid's 
> proposal, it may need to have a message generated at the authenticator 
> instead of the EAP server.  Consequently, the existing method APIs that 
> would make methods easy to implement won't work for a HOKEY method.
> 
> So, if what we're doing doesn't behave like a method, I don't think it 
> should be transported by a method.
> 
> I think a new EAP Success would be reasonable.  Overloading the current 
> one is problematic.  I think defining a new EAP ID request/reply would 
> also be reasonable.  Overloading the current ones is problematic.
> 
> What about using a transport similar to EAP-HR, but defining new codes 
> for the messages rather than reusing the current ones?  We could address 
> a variety of other EAP problems at the same time, for example by 
> defining a TLV structure for data contained in EAP ID request/responses 
> and EAP success.
> 
> What do others think about this?
> 
> -- 
> t. charles clancy, ph.d.  <>  tcc@umd.edu  <>  www.cs.umd.edu/~clancy
> 
> Madjid Nakhjiri wrote:
>> I missed this question.
>> I agree that we need to fix a few issues for EAP Success, such as adding
>> protection for it, but EAP community has been crying over lack of 
>> protection
>> for result indication for quite some time, so that would be a welcome
>> change. I think it can be achieved.
>>
>> As far as adding EAP Success reliability, it may be tricky (since EAP
>> success is not acked), but I am not sure at EAP layer it has to do with
>> authenticator, does it? I am curious, why you say that?
>>
>>
>> -----Original Message-----
>> From: Lakshminath Dondeti [mailto:ldondeti@qualcomm.com] Sent: 
>> Wednesday, April 11, 2007 2:17 PM
>> To: Madjid Nakhjiri
>> Cc: 'Narayanan, Vidya'; hokey@ietf.org
>> Subject: Re: [HOKEY] Using an EAP method for
>> HOKEY??:was:consensuscall:EAP-ERas HOKEY protocol
>>
>>> We are also discussing loading EAP Success, rather than sending an empty
>>> finish followed by a dumb success, so another RT goes away there too.
>>
>> How do you send EAP Success, overloaded, reliably without modifying 
>> authenticators?
>>
>>
>>
>> _______________________________________________
>> 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 Apr 12 22:49: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 1HcBqh-00006r-0q; Thu, 12 Apr 2007 22:49:19 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HcBqg-00006m-Li
	for hokey@ietf.org; Thu, 12 Apr 2007 22:49:18 -0400
Received: from numenor.qualcomm.com ([129.46.51.58])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcBqe-0000m8-5t
	for hokey@ietf.org; Thu, 12 Apr 2007 22:49:18 -0400
Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150])
	by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id
	l3D2n5sF019017
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Thu, 12 Apr 2007 19:49:05 -0700
Received: from SANEXCAS02.na.qualcomm.com (sanexcas02.qualcomm.com
	[172.30.36.176])
	by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id
	l3D2n4CT026601; Thu, 12 Apr 2007 19:49:04 -0700
Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by
	SANEXCAS02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 12 Apr 2007 19:49:04 -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
Subject: RE: [HOKEY] HOKEY transport compromise? :was: Using an EAP method
	forHOKEY??
Date: Thu, 12 Apr 2007 19:48:54 -0700
Message-ID: 
In-Reply-To: <461EE623.202@cs.umd.edu>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [HOKEY] HOKEY transport compromise? :was: Using an EAP method
	forHOKEY??
Thread-Index: Acd9cKx8gx/P+om7R0i+1lHfyV844QAA9mXQ
References: <006301c77d60$597c4fc0$2f01a8c0@china.huawei.com>
	<461EE623.202@cs.umd.edu>
From: "Narayanan, Vidya" 
To: "Charles Clancy" ,
	"Madjid Nakhjiri" 
X-OriginalArrivalTime: 13 Apr 2007 02:49:04.0638 (UTC)
	FILETIME=[4C7F69E0:01C77D76]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f
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 Charles,
I don't know what you mean by using a transport similar to EAP-HR with
new codes - isn't the point of EAP-HR to re-use codes? Maybe, I am
really confused at the moment :)=20

In any event, here are some slides comparing the approaches:

http://www.geocities.com/hellovidya/Re-auth_Backwards_Compatibility_Anal
ysis.pdf

The additional messages needed in EAP-HR to accommodate the
Request/Response behavior and Success semantics make it less efficient.
I'm concerned about doing something that is replaced with non-secure
uses anyway in wireless networks where latency wins over any kind of
security. If such messages are needed for security reasons, that's one
thing - in this case, it is only needed because we want to re-use codes
and authenticator retransmission behaviors.=20

Vidya

> -----Original Message-----
> From: Charles Clancy [mailto:clancy@cs.umd.edu]=20
> Sent: Thursday, April 12, 2007 7:09 PM
> To: Madjid Nakhjiri
> Cc: hokey@ietf.org
> Subject: [HOKEY] HOKEY transport compromise? :was: Using an=20
> EAP method forHOKEY??
>=20
> All,
>=20
> One problem I have with using methods instead of codes is=20
> protocol layering.  Hao mentioned it would be easier to=20
> implement a new method rather than a new code, and I assume=20
> this is because you can simply load a new DLL into whatever=20
> implementation you're using.  I disagree.  The method-based=20
> transport we're talking about here doesn't behave like normal methods.
>=20
> It needs to interact with and modify keying material generated by
> *other* methods, stored at the EAP layer.  It needs to modify=20
> EAP state in ways that methods don't normally modify EAP=20
> state.  In Madjid's proposal, it may need to have a message=20
> generated at the authenticator instead of the EAP server. =20
> Consequently, the existing method APIs that would make=20
> methods easy to implement won't work for a HOKEY method.
>=20
> So, if what we're doing doesn't behave like a method, I don't=20
> think it should be transported by a method.
>=20
> I think a new EAP Success would be reasonable.  Overloading=20
> the current one is problematic.  I think defining a new EAP=20
> ID request/reply would also be reasonable.  Overloading the=20
> current ones is problematic.
>=20
> What about using a transport similar to EAP-HR, but defining=20
> new codes for the messages rather than reusing the current=20
> ones?  We could address a variety of other EAP problems at=20
> the same time, for example by defining a TLV structure for=20
> data contained in EAP ID request/responses and EAP success.
>=20
> What do others think about this?
>=20
> --
> t. charles clancy, ph.d.  <>  tcc@umd.edu  <>  www.cs.umd.edu/~clancy
>=20
> Madjid Nakhjiri wrote:
> > I missed this question.
> > I agree that we need to fix a few issues for EAP Success, such as=20
> > adding protection for it, but EAP community has been crying=20
> over lack=20
> > of protection for result indication for quite some time, so=20
> that would=20
> > be a welcome change. I think it can be achieved.
> >=20
> > As far as adding EAP Success reliability, it may be tricky=20
> (since EAP=20
> > success is not acked), but I am not sure at EAP layer it has to do=20
> > with authenticator, does it? I am curious, why you say that?
> >=20
> >=20
> > -----Original Message-----
> > From: Lakshminath Dondeti [mailto:ldondeti@qualcomm.com]
> > Sent: Wednesday, April 11, 2007 2:17 PM
> > To: Madjid Nakhjiri
> > Cc: 'Narayanan, Vidya'; hokey@ietf.org
> > Subject: Re: [HOKEY] Using an EAP method for=20
> > HOKEY??:was:consensuscall:EAP-ERas HOKEY protocol
> >=20
> >> We are also discussing loading EAP Success, rather than sending an=20
> >> empty finish followed by a dumb success, so another RT=20
> goes away there too.
> >=20
> > How do you send EAP Success, overloaded, reliably without modifying=20
> > authenticators?
> >=20
> >=20
> >=20
> > _______________________________________________
> > HOKEY mailing list
> > HOKEY@ietf.org
> > https://www1.ietf.org/mailman/listinfo/hokey
>=20
>=20
> _______________________________________________
> HOKEY mailing list
> HOKEY@ietf.org
> https://www1.ietf.org/mailman/listinfo/hokey
>=20

_______________________________________________
HOKEY mailing list
HOKEY@ietf.org
https://www1.ietf.org/mailman/listinfo/hokey



From hokey-bounces@ietf.org Thu Apr 12 23:00: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 1HcC1v-0005n6-80; Thu, 12 Apr 2007 23:00:55 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HcC1t-0005iu-RW
	for hokey@ietf.org; Thu, 12 Apr 2007 23:00:53 -0400
Received: from ithilien.qualcomm.com ([129.46.51.59])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcC1t-0006EP-D1
	for hokey@ietf.org; Thu, 12 Apr 2007 23:00:53 -0400
Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158])
	by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id
	l3D30gVd006836
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Thu, 12 Apr 2007 20:00:43 -0700
Received: from [10.50.76.59] (qconnect-10-50-76-59.qualcomm.com [10.50.76.59])
	by totoro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id
	l3D30fOb027932
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Thu, 12 Apr 2007 20:00:41 -0700 (PDT)
Message-ID: <461EF258.5020004@qualcomm.com>
Date: Thu, 12 Apr 2007 20:00:40 -0700
From: Lakshminath Dondeti 
User-Agent: Thunderbird 2.0.0.0 (Windows/20070326)
MIME-Version: 1.0
To: Charles Clancy 
References: <006301c77d60$597c4fc0$2f01a8c0@china.huawei.com>
	<461EE623.202@cs.umd.edu>
In-Reply-To: <461EE623.202@cs.umd.edu>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87
Cc: hokey@ietf.org, Madjid Nakhjiri 
Subject: [HOKEY] Re: HOKEY transport compromise? :was: Using an EAP method
	for HOKEY??
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

Charles,

Thanks for your thoughts.  Some notes inline:

Charles Clancy wrote:
> All,
> 
> One problem I have with using methods instead of codes is protocol 
> layering.  Hao mentioned it would be easier to implement a new method 
> rather than a new code, and I assume this is because you can simply load 
> a new DLL into whatever implementation you're using.  I disagree.  The 
> method-based transport we're talking about here doesn't behave like 
> normal methods.
> 
> It needs to interact with and modify keying material generated by 
> *other* methods, stored at the EAP layer.  It needs to modify EAP state 
> in ways that methods don't normally modify EAP state.  In Madjid's 
> proposal, it may need to have a message generated at the authenticator 
> instead of the EAP server.  Consequently, the existing method APIs that 
> would make methods easy to implement won't work for a HOKEY method.
> 
> So, if what we're doing doesn't behave like a method, I don't think it 
> should be transported by a method.

Agreed.

> 
> I think a new EAP Success would be reasonable.  Overloading the current 
> one is problematic.  I think defining a new EAP ID request/reply would 
> also be reasonable.  Overloading the current ones is problematic.

I am curious what this means.  Are we talking about a new EAP Code for a 
message initiated by the Authenticator with similar semantics as 
Request/Response, perhaps something like EAP-Success-New/Initiate 
EAP-Success-New/Finish?

Same question goes for EAP ID thing.  Do you mean EAP 
Request/Identity-New and EAP Response/Identity-New?

> 
> What about using a transport similar to EAP-HR, but defining new codes 
> for the messages rather than reusing the current ones?  We could address 
> a variety of other EAP problems at the same time, for example by 
> defining a TLV structure for data contained in EAP ID request/responses 
> and EAP success.
> 
> What do others think about this?

All interesting ideas, but in my opinion, we will be trying to solve too 
much, and we won't achieve our goals for re-authentication.

Specifically, we will need a EAP Request/Id-new pair and EAP Success-New 
pair of messages for reauthentication, i.e., 2 RTs for reauthentication. 
  Furthermore, for Peer-initiated re-authentication we may need 2.5 RTs 
in all.  Do you agree with that?  If so, aren't we too far away from our 
goals for reauthentication?

thanks,
Lakshminath

> 
> -- 
> t. charles clancy, ph.d.  <>  tcc@umd.edu  <>  www.cs.umd.edu/~clancy
> 
> Madjid Nakhjiri wrote:
>> I missed this question.
>> I agree that we need to fix a few issues for EAP Success, such as adding
>> protection for it, but EAP community has been crying over lack of 
>> protection
>> for result indication for quite some time, so that would be a welcome
>> change. I think it can be achieved.
>>
>> As far as adding EAP Success reliability, it may be tricky (since EAP
>> success is not acked), but I am not sure at EAP layer it has to do with
>> authenticator, does it? I am curious, why you say that?
>>
>>
>> -----Original Message-----
>> From: Lakshminath Dondeti [mailto:ldondeti@qualcomm.com] Sent: 
>> Wednesday, April 11, 2007 2:17 PM
>> To: Madjid Nakhjiri
>> Cc: 'Narayanan, Vidya'; hokey@ietf.org
>> Subject: Re: [HOKEY] Using an EAP method for
>> HOKEY??:was:consensuscall:EAP-ERas HOKEY protocol
>>
>>> We are also discussing loading EAP Success, rather than sending an empty
>>> finish followed by a dumb success, so another RT goes away there too.
>>
>> How do you send EAP Success, overloaded, reliably without modifying 
>> authenticators?
>>
>>
>>
>> _______________________________________________
>> 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 Apr 12 23:28: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 1HcCSC-00072a-Bx; Thu, 12 Apr 2007 23:28:04 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HcCSA-00071t-SW
	for hokey@ietf.org; Thu, 12 Apr 2007 23:28:02 -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 1HcCS9-0006iZ-Dc
	for hokey@ietf.org; Thu, 12 Apr 2007 23:28:02 -0400
Received: from localhost (toshi17.tari.toshiba.com [172.30.24.10])
	by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id
	l3D3MCWS061660; Thu, 12 Apr 2007 23:22:12 -0400 (EDT)
	(envelope-from yohba@tari.toshiba.com)
Date: Thu, 12 Apr 2007 23:22:13 -0400
To: Charles Clancy 
Subject: Re: [HOKEY] HOKEY transport compromise? :was: Using an EAP method for
	HOKEY??
Message-ID: <20070413032213.GA18381@steelhead>
References: <006301c77d60$597c4fc0$2f01a8c0@china.huawei.com>
	<461EE623.202@cs.umd.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-2022-jp
Content-Disposition: inline
In-Reply-To: <461EE623.202@cs.umd.edu>
User-Agent: Mutt/1.5.13 (2006-08-11)
From: Yoshihiro Ohba 
X-Dispatcher: imput version 20050308(IM148)
Lines: 105
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4
Cc: 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

One good thing of using type-based messaging for the first message
exchange is that the peer can simply NAK if it does not support the
new type.  This does not require lower layer changes and I don't think
this adds significant lantency for legacy peer as long as NAK does not
propagated to EAP server.

Regarding a new EAP Success with acknowledgment, if we consider lower
layer impact, we might add legacy EAP-Success after the acknowlegment
of the new Success.  This will work with all existing EAP lower layers
without modifying them at all.


Peer                 Authenticator         Server
----                 -------------         ------
                 <-- Request-HR            
Response/HR-->
                     Response/HR-->
                                       <-- New Success
                 <-- New Success
ACK-->
                 <-- Success
                    

Yet another option is just giving up use of EAP and expect lower
layers to define media-specific transport for a general 3-party key
distribution protocol.

Yoshihiro Ohba


On Thu, Apr 12, 2007 at 10:08:35PM -0400, Charles Clancy wrote:
> All,
> 
> One problem I have with using methods instead of codes is protocol 
> layering.  Hao mentioned it would be easier to implement a new method 
> rather than a new code, and I assume this is because you can simply load 
> a new DLL into whatever implementation you're using.  I disagree.  The 
> method-based transport we're talking about here doesn't behave like 
> normal methods.
> 
> It needs to interact with and modify keying material generated by 
> *other* methods, stored at the EAP layer.  It needs to modify EAP state 
> in ways that methods don't normally modify EAP state.  In Madjid's 
> proposal, it may need to have a message generated at the authenticator 
> instead of the EAP server.  Consequently, the existing method APIs that 
> would make methods easy to implement won't work for a HOKEY method.
> 
> So, if what we're doing doesn't behave like a method, I don't think it 
> should be transported by a method.
> 
> I think a new EAP Success would be reasonable.  Overloading the current 
> one is problematic.  I think defining a new EAP ID request/reply would 
> also be reasonable.  Overloading the current ones is problematic.
> 
> What about using a transport similar to EAP-HR, but defining new codes 
> for the messages rather than reusing the current ones?  We could address 
> a variety of other EAP problems at the same time, for example by 
> defining a TLV structure for data contained in EAP ID request/responses 
> and EAP success.
> 
> What do others think about this?
> 
> --
> t. charles clancy, ph.d.  <>  tcc@umd.edu  <>  www.cs.umd.edu/~clancy
> 
> Madjid Nakhjiri wrote:
> >I missed this question.
> >I agree that we need to fix a few issues for EAP Success, such as adding
> >protection for it, but EAP community has been crying over lack of 
> >protection
> >for result indication for quite some time, so that would be a welcome
> >change. I think it can be achieved.
> >
> >As far as adding EAP Success reliability, it may be tricky (since EAP
> >success is not acked), but I am not sure at EAP layer it has to do with
> >authenticator, does it? I am curious, why you say that?
> >
> >
> >-----Original Message-----
> >From: Lakshminath Dondeti [mailto:ldondeti@qualcomm.com] 
> >Sent: Wednesday, April 11, 2007 2:17 PM
> >To: Madjid Nakhjiri
> >Cc: 'Narayanan, Vidya'; hokey@ietf.org
> >Subject: Re: [HOKEY] Using an EAP method for
> >HOKEY??:was:consensuscall:EAP-ERas HOKEY protocol
> >
> >>We are also discussing loading EAP Success, rather than sending an empty
> >>finish followed by a dumb success, so another RT goes away there too.
> >
> >How do you send EAP Success, overloaded, reliably without modifying 
> >authenticators?
> >
> >
> >
> >_______________________________________________
> >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 Apr 12 23:43:22 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HcCh0-0008HD-Hn; Thu, 12 Apr 2007 23:43:22 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HcCgy-0008H8-Rx
	for hokey@ietf.org; Thu, 12 Apr 2007 23:43:20 -0400
Received: from numenor.qualcomm.com ([129.46.51.58])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcCgx-0004ZF-76
	for hokey@ietf.org; Thu, 12 Apr 2007 23:43:20 -0400
Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158])
	by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id
	l3D3h7K3022733
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Thu, 12 Apr 2007 20:43:08 -0700
Received: from sanexcas01.na.qualcomm.com (sanexcas01.qualcomm.com
	[172.30.36.175])
	by totoro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l3D3h6bt008620;
	Thu, 12 Apr 2007 20:43:06 -0700 (PDT)
Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by
	sanexcas01.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 12 Apr 2007 20:43:06 -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
Subject: RE: [HOKEY] HOKEY transport compromise? :was: Using an EAP method
	forHOKEY??
Date: Thu, 12 Apr 2007 20:43:07 -0700
Message-ID: 
In-Reply-To: <20070413032213.GA18381@steelhead>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [HOKEY] HOKEY transport compromise? :was: Using an EAP method
	forHOKEY??
Thread-Index: Acd9e8eNAdkmkBCxRzK6cq1N0jTzWQAALqMQ
References: <006301c77d60$597c4fc0$2f01a8c0@china.huawei.com><461EE623.202@cs.umd.edu>
	<20070413032213.GA18381@steelhead>
From: "Narayanan, Vidya" 
To: "Yoshihiro Ohba" ,
	"Charles Clancy" 
X-OriginalArrivalTime: 13 Apr 2007 03:43:06.0688 (UTC)
	FILETIME=[D8E8FC00:01C77D7D]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0770535483960d190d4a0d020e7060bd
Cc: 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

Yoshi,
Exactly why would someone use this over just re-doing EAP-AKA or
EAP-GPSK? If we're just designing for the chattiest of EAP methods, we
might as well not do this - the systems that are looking for
optimization already use the most optimized of EAP methods.=20

Some more specific questions inline.=20

> -----Original Message-----
> From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com]=20
> Sent: Thursday, April 12, 2007 8:22 PM
> To: Charles Clancy
> Cc: hokey@ietf.org; Madjid Nakhjiri
> Subject: Re: [HOKEY] HOKEY transport compromise? :was: Using=20
> an EAP method forHOKEY??
>=20
> One good thing of using type-based messaging for the first=20
> message exchange is that the peer can simply NAK if it does=20
> not support the new type.=20

What's good about this? Why are we re-defining authenticator behavior
for the regular EAP exchange as well now? It doesn't co-exist with
network selection or identity hints or such and has nothing to add over
just always sending EAP Request/Identity. I really have a tough time
seeing the usefulness of this.

> This does not require lower layer=20
> changes and I don't think this adds significant lantency for=20
> legacy peer as long as NAK does not propagated to EAP server.
>=20

There is no lower layer change that is "required" in any approach. If
the lower layer supports a capability indication, the operation will be
optimized. Otherwise, a peer will just time out and do a regular EAP
upon accessing via legacy authenticators.=20

Vidya

> Regarding a new EAP Success with acknowledgment, if we=20
> consider lower layer impact, we might add legacy EAP-Success=20
> after the acknowlegment of the new Success.  This will work=20
> with all existing EAP lower layers without modifying them at all.
>=20
>=20
> Peer                 Authenticator         Server
> ----                 -------------         ------
>                  <-- Request-HR           =20
> Response/HR-->
>                      Response/HR-->
>                                        <-- New Success
>                  <-- New Success
> ACK-->
>                  <-- Success
>                    =20
>=20
> Yet another option is just giving up use of EAP and expect=20
> lower layers to define media-specific transport for a general=20
> 3-party key distribution protocol.
>=20
> Yoshihiro Ohba
>=20
>=20
> On Thu, Apr 12, 2007 at 10:08:35PM -0400, Charles Clancy wrote:
> > All,
> >=20
> > One problem I have with using methods instead of codes is protocol=20
> > layering.  Hao mentioned it would be easier to implement a=20
> new method=20
> > rather than a new code, and I assume this is because you can simply=20
> > load a new DLL into whatever implementation you're using. =20
> I disagree. =20
> > The method-based transport we're talking about here doesn't behave=20
> > like normal methods.
> >=20
> > It needs to interact with and modify keying material generated by
> > *other* methods, stored at the EAP layer.  It needs to modify EAP=20
> > state in ways that methods don't normally modify EAP state.  In=20
> > Madjid's proposal, it may need to have a message generated at the=20
> > authenticator instead of the EAP server.  Consequently, the=20
> existing=20
> > method APIs that would make methods easy to implement won't=20
> work for a HOKEY method.
> >=20
> > So, if what we're doing doesn't behave like a method, I=20
> don't think it=20
> > should be transported by a method.
> >=20
> > I think a new EAP Success would be reasonable.  Overloading the=20
> > current one is problematic.  I think defining a new EAP ID=20
> > request/reply would also be reasonable.  Overloading the=20
> current ones is problematic.
> >=20
> > What about using a transport similar to EAP-HR, but=20
> defining new codes=20
> > for the messages rather than reusing the current ones?  We could=20
> > address a variety of other EAP problems at the same time,=20
> for example=20
> > by defining a TLV structure for data contained in EAP ID=20
> > request/responses and EAP success.
> >=20
> > What do others think about this?
> >=20
> > --
> > t. charles clancy, ph.d.  <>  tcc@umd.edu  <> =20
> www.cs.umd.edu/~clancy
> >=20
> > Madjid Nakhjiri wrote:
> > >I missed this question.
> > >I agree that we need to fix a few issues for EAP Success, such as=20
> > >adding protection for it, but EAP community has been=20
> crying over lack=20
> > >of protection for result indication for quite some time, so that=20
> > >would be a welcome change. I think it can be achieved.
> > >
> > >As far as adding EAP Success reliability, it may be tricky=20
> (since EAP=20
> > >success is not acked), but I am not sure at EAP layer it has to do=20
> > >with authenticator, does it? I am curious, why you say that?
> > >
> > >
> > >-----Original Message-----
> > >From: Lakshminath Dondeti [mailto:ldondeti@qualcomm.com]
> > >Sent: Wednesday, April 11, 2007 2:17 PM
> > >To: Madjid Nakhjiri
> > >Cc: 'Narayanan, Vidya'; hokey@ietf.org
> > >Subject: Re: [HOKEY] Using an EAP method for=20
> > >HOKEY??:was:consensuscall:EAP-ERas HOKEY protocol
> > >
> > >>We are also discussing loading EAP Success, rather than=20
> sending an=20
> > >>empty finish followed by a dumb success, so another RT=20
> goes away there too.
> > >
> > >How do you send EAP Success, overloaded, reliably without=20
> modifying=20
> > >authenticators?
> > >
> > >
> > >
> > >_______________________________________________
> > >HOKEY mailing list
> > >HOKEY@ietf.org
> > >https://www1.ietf.org/mailman/listinfo/hokey
> >=20
> >=20
> > _______________________________________________
> > HOKEY mailing list
> > HOKEY@ietf.org
> > https://www1.ietf.org/mailman/listinfo/hokey
> >=20
>=20
> _______________________________________________
> HOKEY mailing list
> HOKEY@ietf.org
> https://www1.ietf.org/mailman/listinfo/hokey
>=20

_______________________________________________
HOKEY mailing list
HOKEY@ietf.org
https://www1.ietf.org/mailman/listinfo/hokey



From hokey-bounces@ietf.org Fri Apr 13 07:56: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 1HcKNs-0003VO-UR; Fri, 13 Apr 2007 07:56:08 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HcKNr-0003VG-Vo
	for hokey@ietf.org; Fri, 13 Apr 2007 07:56:07 -0400
Received: from rwcrmhc14.comcast.net ([204.127.192.84])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcKNm-0004Rz-US
	for hokey@ietf.org; Fri, 13 Apr 2007 07:56:07 -0400
Received: from [127.0.0.1] (c-68-49-199-146.hsd1.md.comcast.net[68.49.199.146])
	by comcast.net (rwcrmhc14) with ESMTP
	id <20070413115601m1400imngbe>; Fri, 13 Apr 2007 11:56:01 +0000
Message-ID: <461F6FD4.8010005@cs.umd.edu>
Date: Fri, 13 Apr 2007 07:56:04 -0400
From: Charles Clancy 
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: Lakshminath Dondeti 
References: <006301c77d60$597c4fc0$2f01a8c0@china.huawei.com>
	<461EE623.202@cs.umd.edu> <461EF258.5020004@qualcomm.com>
In-Reply-To: <461EF258.5020004@qualcomm.com>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c
Cc: hokey@ietf.org, Madjid Nakhjiri 
Subject: [HOKEY] Re: HOKEY transport compromise? :was: Using an EAP method
	for HOKEY??
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

Lakshminath,

I'd see the EAP-Request/Identity-new as an advertisement, containing any 
necessary identity information, and advertising re-auth support.  We 
could make it optional, so the peer wouldn't need to receive it before 
transmitting an EAP-Response/Identity-new, which would contain the 
re-auth request data.  In response, the server would send an 
EAP-Success-new.  So we still have 1.1 RT (since the 
EAP-Request/Identity is being generated by the authenticator, not the 
EAP server).

Picture:

peer                      auth                    server

  [<------- EAP-Req/Id-new -]  (optional)
  -------- EAP-Resp/Id-new(Reauth data) ------------->
  <-------------- EAP-Success-new(Reauth data) -------

I don't think the EAP-Success-new needs to be ACK'd.  If it's not 
received, the peer can retransmit the EAP-Response/Id-new.  This could 
be flexible though, if others wanted to use the EAP-Success-new.  There 
could be a bit in the header that indicated whether or not it should be 
ACK'd.

We basically have the exact same messaging as EAP-ER -- we're just 
renaming some of the messages and defining them a little more generally 
so they could be useful to others in the future.

If we're worried about backward compatibility, the EAP-Request/ID could 
still use the old code, though that's possibly problematic as discussed 
in the past.

--
t. charles clancy, ph.d.  <>  tcc@umd.edu  <>  www.cs.umd.edu/~clancy

Lakshminath Dondeti wrote:
> Charles,
> 
> Thanks for your thoughts.  Some notes inline:
> 
> Charles Clancy wrote:
>> All,
>>
>> One problem I have with using methods instead of codes is protocol 
>> layering.  Hao mentioned it would be easier to implement a new method 
>> rather than a new code, and I assume this is because you can simply 
>> load a new DLL into whatever implementation you're using.  I 
>> disagree.  The method-based transport we're talking about here doesn't 
>> behave like normal methods.
>>
>> It needs to interact with and modify keying material generated by 
>> *other* methods, stored at the EAP layer.  It needs to modify EAP 
>> state in ways that methods don't normally modify EAP state.  In 
>> Madjid's proposal, it may need to have a message generated at the 
>> authenticator instead of the EAP server.  Consequently, the existing 
>> method APIs that would make methods easy to implement won't work for a 
>> HOKEY method.
>>
>> So, if what we're doing doesn't behave like a method, I don't think it 
>> should be transported by a method.
> 
> Agreed.
> 
>>
>> I think a new EAP Success would be reasonable.  Overloading the 
>> current one is problematic.  I think defining a new EAP ID 
>> request/reply would also be reasonable.  Overloading the current ones 
>> is problematic.
> 
> I am curious what this means.  Are we talking about a new EAP Code for a 
> message initiated by the Authenticator with similar semantics as 
> Request/Response, perhaps something like EAP-Success-New/Initiate 
> EAP-Success-New/Finish?
> 
> Same question goes for EAP ID thing.  Do you mean EAP 
> Request/Identity-New and EAP Response/Identity-New?
> 
>>
>> What about using a transport similar to EAP-HR, but defining new codes 
>> for the messages rather than reusing the current ones?  We could 
>> address a variety of other EAP problems at the same time, for example 
>> by defining a TLV structure for data contained in EAP ID 
>> request/responses and EAP success.
>>
>> What do others think about this?
> 
> All interesting ideas, but in my opinion, we will be trying to solve too 
> much, and we won't achieve our goals for re-authentication.
> 
> Specifically, we will need a EAP Request/Id-new pair and EAP Success-New 
> pair of messages for reauthentication, i.e., 2 RTs for reauthentication. 
>  Furthermore, for Peer-initiated re-authentication we may need 2.5 RTs 
> in all.  Do you agree with that?  If so, aren't we too far away from our 
> goals for reauthentication?
> 
> thanks,
> Lakshminath
> 
>>
>> -- 
>> t. charles clancy, ph.d.  <>  tcc@umd.edu  <>  www.cs.umd.edu/~clancy
>>
>> Madjid Nakhjiri wrote:
>>> I missed this question.
>>> I agree that we need to fix a few issues for EAP Success, such as adding
>>> protection for it, but EAP community has been crying over lack of 
>>> protection
>>> for result indication for quite some time, so that would be a welcome
>>> change. I think it can be achieved.
>>>
>>> As far as adding EAP Success reliability, it may be tricky (since EAP
>>> success is not acked), but I am not sure at EAP layer it has to do with
>>> authenticator, does it? I am curious, why you say that?
>>>
>>>
>>> -----Original Message-----
>>> From: Lakshminath Dondeti [mailto:ldondeti@qualcomm.com] Sent: 
>>> Wednesday, April 11, 2007 2:17 PM
>>> To: Madjid Nakhjiri
>>> Cc: 'Narayanan, Vidya'; hokey@ietf.org
>>> Subject: Re: [HOKEY] Using an EAP method for
>>> HOKEY??:was:consensuscall:EAP-ERas HOKEY protocol
>>>
>>>> We are also discussing loading EAP Success, rather than sending an 
>>>> empty
>>>> finish followed by a dumb success, so another RT goes away there too.
>>>
>>> How do you send EAP Success, overloaded, reliably without modifying 
>>> authenticators?
>>>
>>>
>>>
>>> _______________________________________________
>>> 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 Apr 13 09:58: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 1HcMHo-0006EG-Uj; Fri, 13 Apr 2007 09:58:00 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HcMHn-0006E8-H3
	for hokey@ietf.org; Fri, 13 Apr 2007 09:57:59 -0400
Received: from imx12.toshiba.co.jp ([61.202.160.132])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcMHl-0007oX-M9
	for hokey@ietf.org; Fri, 13 Apr 2007 09:57:59 -0400
Received: from wall11.toshiba.co.jp (wall11 [133.199.90.149])
	by imx12.toshiba.co.jp  with ESMTP id l3DDvedG014986;
	Fri, 13 Apr 2007 22:57:40 +0900 (JST)
Received: (from root@localhost) by wall11.toshiba.co.jp  id l3DDvdmL014693;
	Fri, 13 Apr 2007 22:57:39 +0900 (JST)
Received: from ovp11.toshiba.co.jp [133.199.90.148] 
	by wall11.toshiba.co.jp with ESMTP id YAA14692;
	Fri, 13 Apr 2007 22:57:39 +0900
Received: from mx.toshiba.co.jp (localhost [127.0.0.1])
	by ovp11.toshiba.co.jp  with ESMTP id l3DDvdTo005781;
	Fri, 13 Apr 2007 22:57:39 +0900 (JST)
Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id l3DDvcN4002813;
	Fri, 13 Apr 2007 22:57:38 +0900 (JST)
Received: from steelhead ([172.30.24.105])
	by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 (built
	Apr 28
	2004)) with ESMTPSA id <0JGF00F69W3ZNO40@mail.po.toshiba.co.jp>; Fri,
	13 Apr 2007 22:57:38 +0900 (JST)
Received: from ohba by steelhead with local (Exim 4.63)
	(envelope-from )	id 1HcMHQ-0005BV-Ga; Fri,
	13 Apr 2007 06:57:36 -0700
Date: Fri, 13 Apr 2007 09:57:36 -0400
From: Yoshihiro Ohba 
Subject: Re: [HOKEY] HOKEY transport compromise? :was: Using an EAP method
	forHOKEY??
In-reply-to: 
To: "Narayanan, Vidya" 
Message-id: <20070413135736.GA19392@steelhead>
MIME-version: 1.0
Content-type: text/plain; charset=iso-2022-jp
Content-disposition: inline
References: <20070413032213.GA18381@steelhead>
	
User-Agent: Mutt/1.5.13 (2006-08-11)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d890c9ddd0b0a61e8c597ad30c1c2176
Cc: 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

Vidya,

On Thu, Apr 12, 2007 at 08:43:07PM -0700, Narayanan, Vidya wrote:
> Yoshi,
> Exactly why would someone use this over just re-doing EAP-AKA or
> EAP-GPSK? If we're just designing for the chattiest of EAP methods, we
> might as well not do this - the systems that are looking for
> optimization already use the most optimized of EAP methods. 

Any of existing EAP methods does not address 3-party key distribution
issue.  To me it's not just an optimization issue.

> 
> Some more specific questions inline. 
> 
> > -----Original Message-----
> > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] 
> > Sent: Thursday, April 12, 2007 8:22 PM
> > To: Charles Clancy
> > Cc: hokey@ietf.org; Madjid Nakhjiri
> > Subject: Re: [HOKEY] HOKEY transport compromise? :was: Using 
> > an EAP method forHOKEY??
> > 
> > One good thing of using type-based messaging for the first 
> > message exchange is that the peer can simply NAK if it does 
> > not support the new type. 
> 
> What's good about this? Why are we re-defining authenticator behavior
> for the regular EAP exchange as well now? It doesn't co-exist with
> network selection or identity hints or such and has nothing to add over
> just always sending EAP Request/Identity. I really have a tough time
> seeing the usefulness of this.

I could not find a requirement on support for network selection or
identity hints in hokey-reauth-ps.  What is it :)

> 
> > This does not require lower layer 
> > changes and I don't think this adds significant lantency for 
> > legacy peer as long as NAK does not propagated to EAP server.
> > 
> 
> There is no lower layer change that is "required" in any approach. If
> the lower layer supports a capability indication, the operation will be
> optimized. Otherwise, a peer will just time out and do a regular EAP
> upon accessing via legacy authenticators. 

Timeout is a problem, not a solution.

Yoshihiro Ohba


> 
> Vidya
> 
> > Regarding a new EAP Success with acknowledgment, if we 
> > consider lower layer impact, we might add legacy EAP-Success 
> > after the acknowlegment of the new Success.  This will work 
> > with all existing EAP lower layers without modifying them at all.
> > 
> > 
> > Peer                 Authenticator         Server
> > ----                 -------------         ------
> >                  <-- Request-HR            
> > Response/HR-->
> >                      Response/HR-->
> >                                        <-- New Success
> >                  <-- New Success
> > ACK-->
> >                  <-- Success
> >                     
> > 
> > Yet another option is just giving up use of EAP and expect 
> > lower layers to define media-specific transport for a general 
> > 3-party key distribution protocol.
> > 
> > Yoshihiro Ohba
> > 
> > 
> > On Thu, Apr 12, 2007 at 10:08:35PM -0400, Charles Clancy wrote:
> > > All,
> > > 
> > > One problem I have with using methods instead of codes is protocol 
> > > layering.  Hao mentioned it would be easier to implement a 
> > new method 
> > > rather than a new code, and I assume this is because you can simply 
> > > load a new DLL into whatever implementation you're using.  
> > I disagree.  
> > > The method-based transport we're talking about here doesn't behave 
> > > like normal methods.
> > > 
> > > It needs to interact with and modify keying material generated by
> > > *other* methods, stored at the EAP layer.  It needs to modify EAP 
> > > state in ways that methods don't normally modify EAP state.  In 
> > > Madjid's proposal, it may need to have a message generated at the 
> > > authenticator instead of the EAP server.  Consequently, the 
> > existing 
> > > method APIs that would make methods easy to implement won't 
> > work for a HOKEY method.
> > > 
> > > So, if what we're doing doesn't behave like a method, I 
> > don't think it 
> > > should be transported by a method.
> > > 
> > > I think a new EAP Success would be reasonable.  Overloading the 
> > > current one is problematic.  I think defining a new EAP ID 
> > > request/reply would also be reasonable.  Overloading the 
> > current ones is problematic.
> > > 
> > > What about using a transport similar to EAP-HR, but 
> > defining new codes 
> > > for the messages rather than reusing the current ones?  We could 
> > > address a variety of other EAP problems at the same time, 
> > for example 
> > > by defining a TLV structure for data contained in EAP ID 
> > > request/responses and EAP success.
> > > 
> > > What do others think about this?
> > > 
> > > --
> > > t. charles clancy, ph.d.  <>  tcc@umd.edu  <>  
> > www.cs.umd.edu/~clancy
> > > 
> > > Madjid Nakhjiri wrote:
> > > >I missed this question.
> > > >I agree that we need to fix a few issues for EAP Success, such as 
> > > >adding protection for it, but EAP community has been 
> > crying over lack 
> > > >of protection for result indication for quite some time, so that 
> > > >would be a welcome change. I think it can be achieved.
> > > >
> > > >As far as adding EAP Success reliability, it may be tricky 
> > (since EAP 
> > > >success is not acked), but I am not sure at EAP layer it has to do 
> > > >with authenticator, does it? I am curious, why you say that?
> > > >
> > > >
> > > >-----Original Message-----
> > > >From: Lakshminath Dondeti [mailto:ldondeti@qualcomm.com]
> > > >Sent: Wednesday, April 11, 2007 2:17 PM
> > > >To: Madjid Nakhjiri
> > > >Cc: 'Narayanan, Vidya'; hokey@ietf.org
> > > >Subject: Re: [HOKEY] Using an EAP method for 
> > > >HOKEY??:was:consensuscall:EAP-ERas HOKEY protocol
> > > >
> > > >>We are also discussing loading EAP Success, rather than 
> > sending an 
> > > >>empty finish followed by a dumb success, so another RT 
> > goes away there too.
> > > >
> > > >How do you send EAP Success, overloaded, reliably without 
> > modifying 
> > > >authenticators?
> > > >
> > > >
> > > >
> > > >_______________________________________________
> > > >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
> > 
> 
> 

_______________________________________________
HOKEY mailing list
HOKEY@ietf.org
https://www1.ietf.org/mailman/listinfo/hokey



From hokey-bounces@ietf.org Fri Apr 13 10:38:27 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HcMux-0005qQ-5a; Fri, 13 Apr 2007 10:38:27 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HcMuw-0005oV-3J
	for hokey@ietf.org; Fri, 13 Apr 2007 10:38:26 -0400
Received: from mail.um.es ([155.54.212.109])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcMuu-00049V-GG
	for hokey@ietf.org; Fri, 13 Apr 2007 10:38:25 -0400
Received: from localhost (localhost [127.0.0.1])
	by mail.um.es (Postfix) with ESMTP id B785F23CF7E;
	Fri, 13 Apr 2007 16:38:21 +0200 (CEST)
Received: from mail.um.es ([127.0.0.1])
	by localhost (xenon2 [127.0.0.1]) (amavisd-new, port 10024) with LMTP
	id 06463-01-28; Fri, 13 Apr 2007 16:38:21 +0200 (CEST)
Received: from [155.54.205.13] (inf-205-13.um.es [155.54.205.13])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mail.um.es (Postfix) with ESMTP id 80F7C23CF2B;
	Fri, 13 Apr 2007 16:38:21 +0200 (CEST)
Message-ID: <461F95DE.2040909@dif.um.es>
Date: Fri, 13 Apr 2007 16:38:22 +0200
From: Rafa Marin Lopez 
Organization: University of Murcia
User-Agent: Thunderbird 1.5.0.8 (X11/20061115)
MIME-Version: 1.0
To: Yoshihiro Ohba 
Subject: Re: [HOKEY] Using an EAP method for HOKEY??: was: consensus call:
	EAP-ER as HOKEY protocol
References: <007201c77af9$6cecc490$2f01a8c0@china.huawei.com>	<461DFFF1.1090800@qualcomm.com>
	<20070412183354.GF31369@steelhead>
In-Reply-To: <20070412183354.GF31369@steelhead>
Content-Type: text/plain; charset=ISO-2022-JP
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at telemat.um.es
X-Spam-Score: 0.0 (/)
X-Scan-Signature: de4f315c9369b71d7dd5909b42224370
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 Yoshi,
> I am not so much enthusiastic about EAP-ER or EAP-HR (I am more
> enthusiastic about general 3-party key distribution protocol), 
As you know I am in favor about general 3-party key distribution
protocol but i think this is orthogonal to EAP-ER or EAP-HR as long as
both mechanism work as a transport... don't you agree?.

-- 
------------------------------------------------------
Rafael Marin Lopez
Depto. Ing. de la Info. y las Comunicaciones
Faculty of Computer Science-University of Murcia
30100 Murcia - Spain
Telf: +34968398501    e-mail: rafa@dif.um.es
------------------------------------------------------


_______________________________________________
HOKEY mailing list
HOKEY@ietf.org
https://www1.ietf.org/mailman/listinfo/hokey



From hokey-bounces@ietf.org Fri Apr 13 11:29:41 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HcNiX-0006s9-Ke; Fri, 13 Apr 2007 11:29:41 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HcNiV-0006qr-E1
	for hokey@ietf.org; Fri, 13 Apr 2007 11:29:39 -0400
Received: from numenor.qualcomm.com ([129.46.51.58])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcNiT-0006Ul-QN
	for hokey@ietf.org; Fri, 13 Apr 2007 11:29:39 -0400
Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158])
	by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id
	l3DFTQKv004477
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 13 Apr 2007 08:29:26 -0700
Received: from [10.50.76.129] (qconnect-10-50-76-129.qualcomm.com
	[10.50.76.129])
	by totoro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l3DFTPu5006371
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Fri, 13 Apr 2007 08:29:25 -0700 (PDT)
Message-ID: <461FA1D4.5050207@qualcomm.com>
Date: Fri, 13 Apr 2007 08:29:24 -0700
From: Lakshminath Dondeti 
User-Agent: Thunderbird 2.0.0.0 (Windows/20070326)
MIME-Version: 1.0
To: Charles Clancy 
References: <006301c77d60$597c4fc0$2f01a8c0@china.huawei.com>
	<461EE623.202@cs.umd.edu> <461EF258.5020004@qualcomm.com>
	<461F6FD4.8010005@cs.umd.edu>
In-Reply-To: <461F6FD4.8010005@cs.umd.edu>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 202a3ece0492a8c7e7c8672d5214398f
Cc: hokey@ietf.org, Madjid Nakhjiri 
Subject: [HOKEY] Re: HOKEY transport compromise? :was: Using an EAP method
	for HOKEY??
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, I'll preface this message saying that if something like this 
can be done, I am all for it.  All I care about is having a 
peer-initiated 1 RT exchange that can be standardized quickly (to avoid 
being cryptic, my point is that if we mess with 3748 behavior, we'll 
face huge delays after the document gets forwarded to the AD).

EAP Request (Identity or Identity-New) by itself is not optional, so I 
am not sure how peer-initiated aspect works with the proposed approach. 
  3748 says at the moment:

"The Identifier field of the Response MUST match that of the
       currently outstanding Request.  An authenticator receiving a
       Response whose Identifier value does not match that of the
       currently outstanding Request MUST silently discard the Response."

As to sending the old Response to have the Success-new message repeated, 
that is a change to the EAP state machine.  Now this kind of technique 
is not new in the pre-EAP world, so such a change to the EAP state 
machine may be palatable to people (it would make the state machine 
complex).  I actually recall having a heated debate with Vidya on this 
very point some 8-10 months ago :).  To her credit, she was suggesting 
the technique and I said that would require 3748bis.

I guess the behavior is that EAP-Success-New can carry data and it MUST 
be cached for some period and EAP-Response/Id must result in 
retransmission on that message.

I do wonder whether such drastic changes to 3748 are needed, but I am 
tired of this debate.

If all of that can be done, let's do it.  Thanks.

best regards,
Lakshminath

Charles Clancy wrote:
> Lakshminath,
> 
> I'd see the EAP-Request/Identity-new as an advertisement, containing any 
> necessary identity information, and advertising re-auth support.  We 
> could make it optional, so the peer wouldn't need to receive it before 
> transmitting an EAP-Response/Identity-new, which would contain the 
> re-auth request data.  In response, the server would send an 
> EAP-Success-new.  So we still have 1.1 RT (since the 
> EAP-Request/Identity is being generated by the authenticator, not the 
> EAP server).
> 
> Picture:
> 
> peer                      auth                    server
> 
>  [<------- EAP-Req/Id-new -]  (optional)
>  -------- EAP-Resp/Id-new(Reauth data) ------------->
>  <-------------- EAP-Success-new(Reauth data) -------
> 
> I don't think the EAP-Success-new needs to be ACK'd.  If it's not 
> received, the peer can retransmit the EAP-Response/Id-new.  This could 
> be flexible though, if others wanted to use the EAP-Success-new.  There 
> could be a bit in the header that indicated whether or not it should be 
> ACK'd.
> 
> We basically have the exact same messaging as EAP-ER -- we're just 
> renaming some of the messages and defining them a little more generally 
> so they could be useful to others in the future.
> 
> If we're worried about backward compatibility, the EAP-Request/ID could 
> still use the old code, though that's possibly problematic as discussed 
> in the past.
> 
> -- 
> t. charles clancy, ph.d.  <>  tcc@umd.edu  <>  www.cs.umd.edu/~clancy
> 
> Lakshminath Dondeti wrote:
>> Charles,
>>
>> Thanks for your thoughts.  Some notes inline:
>>
>> Charles Clancy wrote:
>>> All,
>>>
>>> One problem I have with using methods instead of codes is protocol 
>>> layering.  Hao mentioned it would be easier to implement a new method 
>>> rather than a new code, and I assume this is because you can simply 
>>> load a new DLL into whatever implementation you're using.  I 
>>> disagree.  The method-based transport we're talking about here 
>>> doesn't behave like normal methods.
>>>
>>> It needs to interact with and modify keying material generated by 
>>> *other* methods, stored at the EAP layer.  It needs to modify EAP 
>>> state in ways that methods don't normally modify EAP state.  In 
>>> Madjid's proposal, it may need to have a message generated at the 
>>> authenticator instead of the EAP server.  Consequently, the existing 
>>> method APIs that would make methods easy to implement won't work for 
>>> a HOKEY method.
>>>
>>> So, if what we're doing doesn't behave like a method, I don't think 
>>> it should be transported by a method.
>>
>> Agreed.
>>
>>>
>>> I think a new EAP Success would be reasonable.  Overloading the 
>>> current one is problematic.  I think defining a new EAP ID 
>>> request/reply would also be reasonable.  Overloading the current ones 
>>> is problematic.
>>
>> I am curious what this means.  Are we talking about a new EAP Code for 
>> a message initiated by the Authenticator with similar semantics as 
>> Request/Response, perhaps something like EAP-Success-New/Initiate 
>> EAP-Success-New/Finish?
>>
>> Same question goes for EAP ID thing.  Do you mean EAP 
>> Request/Identity-New and EAP Response/Identity-New?
>>
>>>
>>> What about using a transport similar to EAP-HR, but defining new 
>>> codes for the messages rather than reusing the current ones?  We 
>>> could address a variety of other EAP problems at the same time, for 
>>> example by defining a TLV structure for data contained in EAP ID 
>>> request/responses and EAP success.
>>>
>>> What do others think about this?
>>
>> All interesting ideas, but in my opinion, we will be trying to solve 
>> too much, and we won't achieve our goals for re-authentication.
>>
>> Specifically, we will need a EAP Request/Id-new pair and EAP 
>> Success-New pair of messages for reauthentication, i.e., 2 RTs for 
>> reauthentication.  Furthermore, for Peer-initiated re-authentication 
>> we may need 2.5 RTs in all.  Do you agree with that?  If so, aren't we 
>> too far away from our goals for reauthentication?
>>
>> thanks,
>> Lakshminath
>>
>>>
>>> -- 
>>> t. charles clancy, ph.d.  <>  tcc@umd.edu  <>  www.cs.umd.edu/~clancy
>>>
>>> Madjid Nakhjiri wrote:
>>>> I missed this question.
>>>> I agree that we need to fix a few issues for EAP Success, such as 
>>>> adding
>>>> protection for it, but EAP community has been crying over lack of 
>>>> protection
>>>> for result indication for quite some time, so that would be a welcome
>>>> change. I think it can be achieved.
>>>>
>>>> As far as adding EAP Success reliability, it may be tricky (since EAP
>>>> success is not acked), but I am not sure at EAP layer it has to do with
>>>> authenticator, does it? I am curious, why you say that?
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Lakshminath Dondeti [mailto:ldondeti@qualcomm.com] Sent: 
>>>> Wednesday, April 11, 2007 2:17 PM
>>>> To: Madjid Nakhjiri
>>>> Cc: 'Narayanan, Vidya'; hokey@ietf.org
>>>> Subject: Re: [HOKEY] Using an EAP method for
>>>> HOKEY??:was:consensuscall:EAP-ERas HOKEY protocol
>>>>
>>>>> We are also discussing loading EAP Success, rather than sending an 
>>>>> empty
>>>>> finish followed by a dumb success, so another RT goes away there too.
>>>>
>>>> How do you send EAP Success, overloaded, reliably without modifying 
>>>> authenticators?
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> 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 Apr 13 11:38: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 1HcNrL-0003uG-Bd; Fri, 13 Apr 2007 11:38:47 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HcNrK-0003u5-V7
	for hokey@ietf.org; Fri, 13 Apr 2007 11:38:46 -0400
Received: from mail.um.es ([155.54.212.109])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcNrK-0001Zm-9j
	for hokey@ietf.org; Fri, 13 Apr 2007 11:38:46 -0400
Received: from localhost (localhost [127.0.0.1])
	by mail.um.es (Postfix) with ESMTP id 9C36E23D1F9;
	Fri, 13 Apr 2007 17:38:45 +0200 (CEST)
Received: from mail.um.es ([127.0.0.1])
	by localhost (xenon2 [127.0.0.1]) (amavisd-new, port 10024) with LMTP
	id 09656-01-78; Fri, 13 Apr 2007 17:38:45 +0200 (CEST)
Received: from [155.54.205.13] (inf-205-13.um.es [155.54.205.13])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mail.um.es (Postfix) with ESMTP id 26DBD23D22B;
	Fri, 13 Apr 2007 17:38:33 +0200 (CEST)
Message-ID: <461FA3FB.3030302@dif.um.es>
Date: Fri, 13 Apr 2007 17:38:35 +0200
From: Rafa Marin Lopez 
Organization: University of Murcia
User-Agent: Thunderbird 1.5.0.8 (X11/20061115)
MIME-Version: 1.0
To: Madjid Nakhjiri 
Subject: Re: [HOKEY] nakhjiri-hokey-hierarchy-04 available
References: <006201c77d5f$67f71680$2f01a8c0@china.huawei.com>
In-Reply-To: <006201c77d5f$67f71680$2f01a8c0@china.huawei.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at telemat.um.es
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de
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 Madjid,
> so I think we should keep that context in
> mind and then try to deliver a complete solution for the hokey problem,=
 not
> a bunch of generic specifications.
>  =20
I am not against that. What I am saying is that the specific 3 party=20
protocol should be independent of the transport (EAP-ER/EAP-HR etc...)
> Also, thanks a lot for the note on loaded EAP ID implementation, good t=
o
> know it does not change authenticator state machine, that is what I was=
 sort
> of expecting.=20
Mmmm... it is normal that EAP authenticator state machine does not=20
change since the solution we have experimented carries a valid identity=20
(but cryptographically generated). So no change at all in EAP=20
Response/Id. I think the overload in EAP Response/Id that your I-D=20
proposes is different right?.

> However, I would think you could replace the crypto-generated
> ID with protection provided by keys protecting EAP signaling (IK and CK=
) and
> that way do not have to have specific crypto for IDs.=20
As I mentioned, personally I am not in favour about using cryptography=20
in the EAP signaling itself. To me it should be only a transport between=20
the peer and server for the 3 party key distribution.

Having said that, the crypto-generated ID included in a normal EAP=20
Response/Id does not require EAP authenticator modification, but what=20
you propose may require it.

> I showed this in the
> draft as well. The only thing I was not sure about was whether to gener=
ate
> the CK and IK from HRK or directly from EMSK.
>
>
> Madjid
>
>
> -----Original Message-----
> From: Rafa Marin Lopez [mailto:rafa@dif.um.es]=20
> Sent: Thursday, April 12, 2007 1:06 AM
> To: Madjid Nakhjiri
> Cc: hokey@ietf.org
> Subject: Re: [HOKEY] nakhjiri-hokey-hierarchy-04 available
>
> Madjid Nakhjiri escribi=F3:
>  =20
>> Hi Folks,
>>  =20
>>    =20
> Hi Madjid,
>  =20
>> Trying to see how the various pieces of the puzzle from EAP signaling =
to
>>    =20
> key
>  =20
>> hierarchy and 3 party key distribution fit together, I have updated th=
e
>>    =20
> key
>  =20
>> hierarchy draft. The draft tries to follow the new guidelines for use =
of
>> EMSK and is experimenting with use of EMSK in deriving the handover ro=
ot
>>    =20
> key
>  =20
>> for use in multiple domains.
>>  =20
>>    =20
> I have taken a look to the I-D and I'd suggest to separate the EAP=20
> method based signalling from the
> handover key hierarchy content into a separate I-D. That would really=20
> help to clarify things.
> You may count on me for this.
>
> As a note, to me, EAP-HR you describe should work as a general transpor=
t=20
> (and therefore independent of the specific 3-party protocol) for a stil=
l=20
> under
> definition 3-party protocol that should be in another I-D as Charles=20
> suggested.
>
> Regarding to the message sent by EAP peer upon receiving the EAP Req/Id=
,=20
> I would like to comment that we are experimenting (with a=20
> proof-of-concept testbed) a trade-off solution based on=20
> cryptographically generated identities which are built by using keys=20
> derived from the EMSK. The identity is encoded in base64 format and=20
> included in the EAP response/identity and forwarded. The AAA server can=
=20
> verify that the identity was generated by using a valid key. We have=20
> tested this in a linksys access point and we have not found any problem=
=20
> so far. The solution implies little modifications at EAP peer and EAP=20
> server state machines (not the transitions itself but the states).=20
> Fortunately, the EAP authenticator state machine does not need any=20
> modification.
> =20
> However, the EAP peer must relay in the security association protocol i=
n=20
> order to complete the process and to know everything was ok. So a sort=20
> of EAP success carrying authenticated data would really help :).
>
> 
>  =20
>> The draft also discusses the use of 3 party key distribution, the
>>    =20
> parameters
>  =20
>> involved, the AAA attributes and EAP extensions.
>>  =20
>>    =20
> This might also be included in the separated EAP-HR I-D.
>
> My 0.02 cents.
>  =20
>> The draft can be found at:
>>
>> http://www.ietf.org/internet-drafts/draft-nakhjiri-hokey-hierarchy-04.=
txt
>>
>> comments and discussions are welcome.
>>
>> R,
>>
>> Madjid
>>
>>
>>
>>
>> _______________________________________________
>> HOKEY mailing list
>> HOKEY@ietf.org
>> https://www1.ietf.org/mailman/listinfo/hokey
>>
>>
>>  =20
>>    =20
>
>
>  =20


--=20
------------------------------------------------------
Rafael Marin Lopez
Depto. Ing. de la Info. y las Comunicaciones
Faculty of Computer Science-University of Murcia
30100 Murcia - Spain
Telf: +34968398501    e-mail: rafa@dif.um.es
------------------------------------------------------


_______________________________________________
HOKEY mailing list
HOKEY@ietf.org
https://www1.ietf.org/mailman/listinfo/hokey



From hokey-bounces@ietf.org Fri Apr 13 11:53:12 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HcO5H-00059N-TE; Fri, 13 Apr 2007 11:53:11 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HcO5H-00056e-1t
	for hokey@ietf.org; Fri, 13 Apr 2007 11:53:11 -0400
Received: from mcfeely.cs.umd.edu ([128.8.128.218])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcO5F-0008Qb-Iu
	for hokey@ietf.org; Fri, 13 Apr 2007 11:53:11 -0400
Received: from mcfeely.cs.umd.edu (localhost [127.0.0.1])
	by mcfeely.cs.umd.edu (8.12.11.20060308/8.12.5) with ESMTP id
	l3DFqqw8005055; Fri, 13 Apr 2007 11:52:52 -0400
Received: (from apache@localhost)
	by mcfeely.cs.umd.edu (8.12.11.20060308/8.12.11/Submit) id
	l3DFqpQB005053; Fri, 13 Apr 2007 11:52:51 -0400
X-Authentication-Warning: mcfeely.cs.umd.edu: apache set sender to
	clancy@cs.umd.edu using -f
Received: from 63.239.69.1 (SquirrelMail authenticated user clancy)
	by webmail.cs.umd.edu with HTTP;
	Fri, 13 Apr 2007 11:52:51 -0400 (EDT)
Message-ID: <40181.63.239.69.1.1176479571.squirrel@webmail.cs.umd.edu>
In-Reply-To: <461FA1D4.5050207@qualcomm.com>
References: <006301c77d60$597c4fc0$2f01a8c0@china.huawei.com>
	<461EE623.202@cs.umd.edu> <461EF258.5020004@qualcomm.com>
	<461F6FD4.8010005@cs.umd.edu> <461FA1D4.5050207@qualcomm.com>
Date: Fri, 13 Apr 2007 11:52:51 -0400 (EDT)
From: "Charles Clancy" 
To: "Lakshminath Dondeti" 
User-Agent: SquirrelMail/1.4.5
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 97c820c82c68af374c4e382a80dc5017
Cc: hokey@ietf.org, Madjid Nakhjiri 
Subject: [HOKEY] Re: HOKEY transport compromise? :was: Using an EAP method
 for HOKEY??
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

To a certain extent, if we're defining new codes, we can dictate their
behavior.  Who's to say an Response/ID-new has to be preceeded by a
Request/ID-new?  Certainly we'll need to do more research.

I think the design constraints are clear, and we have general agreement on
them.  1 RT with an optional .1 RT to advertise identity information for
lower layers that can't advertise information like that, or scenarios
where server-initiation is required.  I don't see the benefits of using
method-based transport, since it won't be any easier to implement than
code-based transport.  Overloading existing EAP codes should be avoided if
possible, unless the benefits to backward compatability are compelling.

-- 
t. charles clancy, ph.d.  <>  tcc@umd.edu  <>  www.cs.umd.edu/~clancy

On Fri, April 13, 2007 11:29 am, Lakshminath Dondeti wrote:
> :).  So, I'll preface this message saying that if something like this
> can be done, I am all for it.  All I care about is having a
> peer-initiated 1 RT exchange that can be standardized quickly (to avoid
> being cryptic, my point is that if we mess with 3748 behavior, we'll
> face huge delays after the document gets forwarded to the AD).
>
> EAP Request (Identity or Identity-New) by itself is not optional, so I
> am not sure how peer-initiated aspect works with the proposed approach.
>   3748 says at the moment:
>
> "The Identifier field of the Response MUST match that of the
>        currently outstanding Request.  An authenticator receiving a
>        Response whose Identifier value does not match that of the
>        currently outstanding Request MUST silently discard the Response."
>
> As to sending the old Response to have the Success-new message repeated,
> that is a change to the EAP state machine.  Now this kind of technique
> is not new in the pre-EAP world, so such a change to the EAP state
> machine may be palatable to people (it would make the state machine
> complex).  I actually recall having a heated debate with Vidya on this
> very point some 8-10 months ago :).  To her credit, she was suggesting
> the technique and I said that would require 3748bis.
>
> I guess the behavior is that EAP-Success-New can carry data and it MUST
> be cached for some period and EAP-Response/Id must result in
> retransmission on that message.
>
> I do wonder whether such drastic changes to 3748 are needed, but I am
> tired of this debate.
>
> If all of that can be done, let's do it.  Thanks.
>
> best regards,
> Lakshminath
>
> Charles Clancy wrote:
>> Lakshminath,
>>
>> I'd see the EAP-Request/Identity-new as an advertisement, containing any
>> necessary identity information, and advertising re-auth support.  We
>> could make it optional, so the peer wouldn't need to receive it before
>> transmitting an EAP-Response/Identity-new, which would contain the
>> re-auth request data.  In response, the server would send an
>> EAP-Success-new.  So we still have 1.1 RT (since the
>> EAP-Request/Identity is being generated by the authenticator, not the
>> EAP server).
>>
>> Picture:
>>
>> peer                      auth                    server
>>
>>  [<------- EAP-Req/Id-new -]  (optional)
>>  -------- EAP-Resp/Id-new(Reauth data) ------------->
>>  <-------------- EAP-Success-new(Reauth data) -------
>>
>> I don't think the EAP-Success-new needs to be ACK'd.  If it's not
>> received, the peer can retransmit the EAP-Response/Id-new.  This could
>> be flexible though, if others wanted to use the EAP-Success-new.  There
>> could be a bit in the header that indicated whether or not it should be
>> ACK'd.
>>
>> We basically have the exact same messaging as EAP-ER -- we're just
>> renaming some of the messages and defining them a little more generally
>> so they could be useful to others in the future.
>>
>> If we're worried about backward compatibility, the EAP-Request/ID could
>> still use the old code, though that's possibly problematic as discussed
>> in the past.
>>
>> --
>> t. charles clancy, ph.d.  <>  tcc@umd.edu  <>  www.cs.umd.edu/~clancy
>>
>> Lakshminath Dondeti wrote:
>>> Charles,
>>>
>>> Thanks for your thoughts.  Some notes inline:
>>>
>>> Charles Clancy wrote:
>>>> All,
>>>>
>>>> One problem I have with using methods instead of codes is protocol
>>>> layering.  Hao mentioned it would be easier to implement a new method
>>>> rather than a new code, and I assume this is because you can simply
>>>> load a new DLL into whatever implementation you're using.  I
>>>> disagree.  The method-based transport we're talking about here
>>>> doesn't behave like normal methods.
>>>>
>>>> It needs to interact with and modify keying material generated by
>>>> *other* methods, stored at the EAP layer.  It needs to modify EAP
>>>> state in ways that methods don't normally modify EAP state.  In
>>>> Madjid's proposal, it may need to have a message generated at the
>>>> authenticator instead of the EAP server.  Consequently, the existing
>>>> method APIs that would make methods easy to implement won't work for
>>>> a HOKEY method.
>>>>
>>>> So, if what we're doing doesn't behave like a method, I don't think
>>>> it should be transported by a method.
>>>
>>> Agreed.
>>>
>>>>
>>>> I think a new EAP Success would be reasonable.  Overloading the
>>>> current one is problematic.  I think defining a new EAP ID
>>>> request/reply would also be reasonable.  Overloading the current ones
>>>> is problematic.
>>>
>>> I am curious what this means.  Are we talking about a new EAP Code for
>>> a message initiated by the Authenticator with similar semantics as
>>> Request/Response, perhaps something like EAP-Success-New/Initiate
>>> EAP-Success-New/Finish?
>>>
>>> Same question goes for EAP ID thing.  Do you mean EAP
>>> Request/Identity-New and EAP Response/Identity-New?
>>>
>>>>
>>>> What about using a transport similar to EAP-HR, but defining new
>>>> codes for the messages rather than reusing the current ones?  We
>>>> could address a variety of other EAP problems at the same time, for
>>>> example by defining a TLV structure for data contained in EAP ID
>>>> request/responses and EAP success.
>>>>
>>>> What do others think about this?
>>>
>>> All interesting ideas, but in my opinion, we will be trying to solve
>>> too much, and we won't achieve our goals for re-authentication.
>>>
>>> Specifically, we will need a EAP Request/Id-new pair and EAP
>>> Success-New pair of messages for reauthentication, i.e., 2 RTs for
>>> reauthentication.  Furthermore, for Peer-initiated re-authentication
>>> we may need 2.5 RTs in all.  Do you agree with that?  If so, aren't we
>>> too far away from our goals for reauthentication?
>>>
>>> thanks,
>>> Lakshminath
>>>
>>>>
>>>> --
>>>> t. charles clancy, ph.d.  <>  tcc@umd.edu  <>  www.cs.umd.edu/~clancy
>>>>
>>>> Madjid Nakhjiri wrote:
>>>>> I missed this question.
>>>>> I agree that we need to fix a few issues for EAP Success, such as
>>>>> adding
>>>>> protection for it, but EAP community has been crying over lack of
>>>>> protection
>>>>> for result indication for quite some time, so that would be a welcome
>>>>> change. I think it can be achieved.
>>>>>
>>>>> As far as adding EAP Success reliability, it may be tricky (since EAP
>>>>> success is not acked), but I am not sure at EAP layer it has to do
>>>>> with
>>>>> authenticator, does it? I am curious, why you say that?
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: Lakshminath Dondeti [mailto:ldondeti@qualcomm.com] Sent:
>>>>> Wednesday, April 11, 2007 2:17 PM
>>>>> To: Madjid Nakhjiri
>>>>> Cc: 'Narayanan, Vidya'; hokey@ietf.org
>>>>> Subject: Re: [HOKEY] Using an EAP method for
>>>>> HOKEY??:was:consensuscall:EAP-ERas HOKEY protocol
>>>>>
>>>>>> We are also discussing loading EAP Success, rather than sending an
>>>>>> empty
>>>>>> finish followed by a dumb success, so another RT goes away there
>>>>>> too.
>>>>>
>>>>> How do you send EAP Success, overloaded, reliably without modifying
>>>>> authenticators?
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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 Apr 13 12:02: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 1HcOEE-00032K-Hq; Fri, 13 Apr 2007 12:02:26 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HcOED-000327-A3
	for hokey@ietf.org; Fri, 13 Apr 2007 12:02:25 -0400
Received: from numenor.qualcomm.com ([129.46.51.58])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcOEB-0004Ux-W2
	for hokey@ietf.org; Fri, 13 Apr 2007 12:02:25 -0400
Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158])
	by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id
	l3DG2DgX007766
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 13 Apr 2007 09:02:13 -0700
Received: from [10.50.76.129] (qconnect-10-50-76-129.qualcomm.com
	[10.50.76.129])
	by totoro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l3DG2230018535
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Fri, 13 Apr 2007 09:02:03 -0700 (PDT)
Message-ID: <461FA97A.2060407@qualcomm.com>
Date: Fri, 13 Apr 2007 09:02:02 -0700
From: Lakshminath Dondeti 
User-Agent: Thunderbird 2.0.0.0 (Windows/20070326)
MIME-Version: 1.0
To: Charles Clancy 
References: <006301c77d60$597c4fc0$2f01a8c0@china.huawei.com>
	<461EE623.202@cs.umd.edu> <461EF258.5020004@qualcomm.com>
	<461F6FD4.8010005@cs.umd.edu> <461FA1D4.5050207@qualcomm.com>
	<40181.63.239.69.1.1176479571.squirrel@webmail.cs.umd.edu>
In-Reply-To: <40181.63.239.69.1.1176479571.squirrel@webmail.cs.umd.edu>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d6b246023072368de71562c0ab503126
Cc: hokey@ietf.org, Madjid Nakhjiri 
Subject: [HOKEY] Re: HOKEY transport compromise? :was: Using an EAP method
 for HOKEY??
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

Charles Clancy wrote:
> To a certain extent, if we're defining new codes, we can dictate their
> behavior.  Who's to say an Response/ID-new has to be preceeded by a
> Request/ID-new?  Certainly we'll need to do more research.

Isn't ID-new a new type?  Perhaps we can define a new code Response-New?

thanks,
Lakshminath

> 
> I think the design constraints are clear, and we have general agreement on
> them.  1 RT with an optional .1 RT to advertise identity information for
> lower layers that can't advertise information like that, or scenarios
> where server-initiation is required.  I don't see the benefits of using
> method-based transport, since it won't be any easier to implement than
> code-based transport.  Overloading existing EAP codes should be avoided if
> possible, unless the benefits to backward compatability are compelling.
> 

_______________________________________________
HOKEY mailing list
HOKEY@ietf.org
https://www1.ietf.org/mailman/listinfo/hokey



From hokey-bounces@ietf.org Fri Apr 13 12:06:18 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HcOHy-0004lA-78; Fri, 13 Apr 2007 12:06:18 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HcOHx-0004eh-1F
	for hokey@ietf.org; Fri, 13 Apr 2007 12:06:17 -0400
Received: from mcfeely.cs.umd.edu ([128.8.128.218])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcOHv-0006eg-R4
	for hokey@ietf.org; Fri, 13 Apr 2007 12:06:17 -0400
Received: from mcfeely.cs.umd.edu (localhost [127.0.0.1])
	by mcfeely.cs.umd.edu (8.12.11.20060308/8.12.5) with ESMTP id
	l3DG6Dx3021264; Fri, 13 Apr 2007 12:06:13 -0400
Received: (from apache@localhost)
	by mcfeely.cs.umd.edu (8.12.11.20060308/8.12.11/Submit) id
	l3DG6DNn021262; Fri, 13 Apr 2007 12:06:13 -0400
X-Authentication-Warning: mcfeely.cs.umd.edu: apache set sender to
	clancy@cs.umd.edu using -f
Received: from 63.239.69.1 (SquirrelMail authenticated user clancy)
	by webmail.cs.umd.edu with HTTP;
	Fri, 13 Apr 2007 12:06:13 -0400 (EDT)
Message-ID: <34519.63.239.69.1.1176480373.squirrel@webmail.cs.umd.edu>
In-Reply-To: <461FA97A.2060407@qualcomm.com>
References: <006301c77d60$597c4fc0$2f01a8c0@china.huawei.com>   
	<461EE623.202@cs.umd.edu> <461EF258.5020004@qualcomm.com>   
	<461F6FD4.8010005@cs.umd.edu> <461FA1D4.5050207@qualcomm.com>
	<40181.63.239.69.1.1176479571.squirrel@webmail.cs.umd.edu>
	<461FA97A.2060407@qualcomm.com>
Date: Fri, 13 Apr 2007 12:06:13 -0400 (EDT)
From: "Charles Clancy" 
To: "Lakshminath Dondeti" 
User-Agent: SquirrelMail/1.4.5
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
X-Spam-Score: 0.6 (/)
X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad
Cc: hokey@ietf.org, Madjid Nakhjiri 
Subject: [HOKEY] Re: HOKEY transport compromise? :was: Using an EAP method
 for HOKEY??
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

On Fri, April 13, 2007 12:02 pm, Lakshminath Dondeti wrote:
> Charles Clancy wrote:
>> To a certain extent, if we're defining new codes, we can dictate their
>> behavior.  Who's to say an Response/ID-new has to be preceeded by a
>> Request/ID-new?  Certainly we'll need to do more research.
>
> Isn't ID-new a new type?  Perhaps we can define a new code Response-New?

Exactly.  That's what I was proposing.

-- 
t. charles clancy, ph.d.  <>  tcc@umd.edu  <>  www.cs.umd.edu/~clancy


_______________________________________________
HOKEY mailing list
HOKEY@ietf.org
https://www1.ietf.org/mailman/listinfo/hokey



From hokey-bounces@ietf.org Fri Apr 13 12: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 1HcOON-0002nc-1H; Fri, 13 Apr 2007 12:12:55 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HcOOM-0002nX-8A
	for hokey@ietf.org; Fri, 13 Apr 2007 12:12:54 -0400
Received: from numenor.qualcomm.com ([129.46.51.58])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcOOK-0003ND-UA
	for hokey@ietf.org; Fri, 13 Apr 2007 12:12:54 -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
	l3DGCfQV009165
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 13 Apr 2007 09:12:42 -0700
Received: from [10.50.76.129] (qconnect-10-50-76-129.qualcomm.com
	[10.50.76.129])
	by hamtaro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id
	l3DGCf4U009972
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Fri, 13 Apr 2007 09:12:41 -0700 (PDT)
Message-ID: <461FABF8.8050705@qualcomm.com>
Date: Fri, 13 Apr 2007 09:12:40 -0700
From: Lakshminath Dondeti 
User-Agent: Thunderbird 2.0.0.0 (Windows/20070326)
MIME-Version: 1.0
To: Charles Clancy 
References: <006301c77d60$597c4fc0$2f01a8c0@china.huawei.com>
	<461EE623.202@cs.umd.edu> <461EF258.5020004@qualcomm.com>
	<461F6FD4.8010005@cs.umd.edu> <461FA1D4.5050207@qualcomm.com>
	<40181.63.239.69.1.1176479571.squirrel@webmail.cs.umd.edu>
	<461FA97A.2060407@qualcomm.com>
	<34519.63.239.69.1.1176480373.squirrel@webmail.cs.umd.edu>
In-Reply-To: <34519.63.239.69.1.1176480373.squirrel@webmail.cs.umd.edu>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c
Cc: hokey@ietf.org, Madjid Nakhjiri 
Subject: [HOKEY] Re: HOKEY transport compromise? :was: Using an EAP method
 for HOKEY??
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 for the clarification Charles.

regards,
Lakshminath

Charles Clancy wrote:
> On Fri, April 13, 2007 12:02 pm, Lakshminath Dondeti wrote:
>> Charles Clancy wrote:
>>> To a certain extent, if we're defining new codes, we can dictate their
>>> behavior.  Who's to say an Response/ID-new has to be preceeded by a
>>> Request/ID-new?  Certainly we'll need to do more research.
>> Isn't ID-new a new type?  Perhaps we can define a new code Response-New?
> 
> Exactly.  That's what I was proposing.
> 

_______________________________________________
HOKEY mailing list
HOKEY@ietf.org
https://www1.ietf.org/mailman/listinfo/hokey



From hokey-bounces@ietf.org Fri Apr 13 12:22:23 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HcOXX-00005n-Hc; Fri, 13 Apr 2007 12:22:23 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HcOXD-0008BX-Nk
	for hokey@ietf.org; Fri, 13 Apr 2007 12:22:04 -0400
Received: from rtp-iport-2.cisco.com ([64.102.122.149])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcOTL-0006Ab-PT
	for hokey@ietf.org; Fri, 13 Apr 2007 12:18:05 -0400
Received: from rtp-dkim-1.cisco.com ([64.102.121.158])
	by rtp-iport-2.cisco.com with ESMTP; 13 Apr 2007 12:18:03 -0400
X-IronPort-AV: i="4.14,408,1170651600"; 
	d="scan'208"; a="118456623:sNHT67769832"
Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13])
	by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l3DGI35b028272; 
	Fri, 13 Apr 2007 12:18:03 -0400
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com
	[64.102.31.102])
	by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l3DGI2lI000505; 
	Fri, 13 Apr 2007 16:18:03 GMT
Received: from xmb-rtp-212.amer.cisco.com ([64.102.31.111]) by
	xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Fri, 13 Apr 2007 12:17:53 -0400
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] Re: HOKEY transport compromise? :was: Using an EAP method
	for HOKEY??
Date: Fri, 13 Apr 2007 12:17:52 -0400
Message-ID: <9958B444368E884DBB215F3FEF36F5B70432717A@xmb-rtp-212.amer.cisco.com>
In-Reply-To: <40181.63.239.69.1.1176479571.squirrel@webmail.cs.umd.edu>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [HOKEY] Re: HOKEY transport compromise? :was: Using an EAP
	method for HOKEY??
Thread-Index: Acd9492ijy0Fcw8QQ+Gx77s8ouvQdwAAPjjQ
References: <006301c77d60$597c4fc0$2f01a8c0@china.huawei.com><461EE623.202@cs.umd.edu>
	<461EF258.5020004@qualcomm.com><461F6FD4.8010005@cs.umd.edu>
	<461FA1D4.5050207@qualcomm.com>
	<40181.63.239.69.1.1176479571.squirrel@webmail.cs.umd.edu>
From: "Hao Zhou \(hzhou\)" 
To: "Charles Clancy" ,
	"Lakshminath Dondeti" 
X-OriginalArrivalTime: 13 Apr 2007 16:17:53.0312 (UTC)
	FILETIME=[49D76A00:01C77DE7]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=10173; t=1176481083;
	x=1177345083; c=relaxed/simple; s=rtpdkim1001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=hzhou@cisco.com;
	z=From:=20=22Hao=20Zhou=20\(hzhou\)=22=20
	|Subject:=20RE=3A=20[HOKEY]=20Re=3A=20HOKEY=20transport=20compromise?=20=
	3Awas=3A=20Using=20an=20EAP=20method=20for=20HOKEY??
	|Sender:=20
	|To:=20=22Charles=20Clancy=22=20,
	=0A=20=20=20=20=20=20
	=20=20=22Lakshminath=20Dondeti=22=20;
	bh=Gw4b69RUXhBlvQqXP9/OIHij29FJ+KBPgGb3vtcKWMs=;
	b=nzs3SvOo5WHucKVfl6CBCsof1PM9z7Mq/UzbDWaybTXzgp8G2JBv/PDw5X1DejQmI+J3lUKd
	7egdqUH5hOfHeT6rPZA9MWNOjtdUpVjqnSi3ebb4vz5yGCjw+X47Emei;
Authentication-Results: rtp-dkim-1; header.From=hzhou@cisco.com; dkim=pass (
	sig from cisco.com/rtpdkim1001 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cdeeb24e6b743a852c396a4af0e53c8f
Cc: 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

Charles:

In general, I agree with you that a more generalized code approach would
be better. I do see one issue with proposed Request ID-new. Unless there
is lower layer capability negotiation that the authentication know the
peer supports the Request/ID-new, sending it to legacy client will be
dropped. That's why I suggest using the existing Request ID.  Somehow
you need capability negotiation that the new codes will be supported.
Unless you are only targeting lower layer that supports that, you will
need some backward compatibility.=20

> -----Original Message-----
> From: Charles Clancy [mailto:clancy@cs.umd.edu]=20
> Sent: Friday, April 13, 2007 11:53 AM
> To: Lakshminath Dondeti
> Cc: hokey@ietf.org; Madjid Nakhjiri
> Subject: [HOKEY] Re: HOKEY transport compromise? :was: Using=20
> an EAP method for HOKEY??
>=20
> To a certain extent, if we're defining new codes, we can=20
> dictate their behavior.  Who's to say an Response/ID-new has=20
> to be preceeded by a Request/ID-new?  Certainly we'll need to=20
> do more research.
>=20
> I think the design constraints are clear, and we have general=20
> agreement on them.  1 RT with an optional .1 RT to advertise=20
> identity information for lower layers that can't advertise=20
> information like that, or scenarios where server-initiation=20
> is required.  I don't see the benefits of using method-based=20
> transport, since it won't be any easier to implement than=20
> code-based transport.  Overloading existing EAP codes should=20
> be avoided if possible, unless the benefits to backward=20
> compatability are compelling.
>=20
> --
> t. charles clancy, ph.d.  <>  tcc@umd.edu  <>  www.cs.umd.edu/~clancy
>=20
> On Fri, April 13, 2007 11:29 am, Lakshminath Dondeti wrote:
> > :).  So, I'll preface this message saying that if something=20
> like this=20
> > can be done, I am all for it.  All I care about is having a=20
> > peer-initiated 1 RT exchange that can be standardized quickly (to=20
> > avoid being cryptic, my point is that if we mess with 3748=20
> behavior,=20
> > we'll face huge delays after the document gets forwarded to the AD).
> >
> > EAP Request (Identity or Identity-New) by itself is not=20
> optional, so I=20
> > am not sure how peer-initiated aspect works with the=20
> proposed approach.
> >   3748 says at the moment:
> >
> > "The Identifier field of the Response MUST match that of the
> >        currently outstanding Request.  An authenticator receiving a
> >        Response whose Identifier value does not match that of the
> >        currently outstanding Request MUST silently discard=20
> the Response."
> >
> > As to sending the old Response to have the Success-new message=20
> > repeated, that is a change to the EAP state machine.  Now=20
> this kind of=20
> > technique is not new in the pre-EAP world, so such a change=20
> to the EAP=20
> > state machine may be palatable to people (it would make the state=20
> > machine complex).  I actually recall having a heated debate=20
> with Vidya=20
> > on this very point some 8-10 months ago :).  To her credit, she was=20
> > suggesting the technique and I said that would require 3748bis.
> >
> > I guess the behavior is that EAP-Success-New can carry data and it=20
> > MUST be cached for some period and EAP-Response/Id must result in=20
> > retransmission on that message.
> >
> > I do wonder whether such drastic changes to 3748 are=20
> needed, but I am=20
> > tired of this debate.
> >
> > If all of that can be done, let's do it.  Thanks.
> >
> > best regards,
> > Lakshminath
> >
> > Charles Clancy wrote:
> >> Lakshminath,
> >>
> >> I'd see the EAP-Request/Identity-new as an advertisement,=20
> containing=20
> >> any necessary identity information, and advertising=20
> re-auth support. =20
> >> We could make it optional, so the peer wouldn't need to receive it=20
> >> before transmitting an EAP-Response/Identity-new, which=20
> would contain=20
> >> the re-auth request data.  In response, the server would send an=20
> >> EAP-Success-new.  So we still have 1.1 RT (since the=20
> >> EAP-Request/Identity is being generated by the=20
> authenticator, not the=20
> >> EAP server).
> >>
> >> Picture:
> >>
> >> peer                      auth                    server
> >>
> >>  [<------- EAP-Req/Id-new -]  (optional)
> >>  -------- EAP-Resp/Id-new(Reauth data) ------------->
> >>  <-------------- EAP-Success-new(Reauth data) -------
> >>
> >> I don't think the EAP-Success-new needs to be ACK'd.  If it's not=20
> >> received, the peer can retransmit the EAP-Response/Id-new.  This=20
> >> could be flexible though, if others wanted to use the=20
> >> EAP-Success-new.  There could be a bit in the header that=20
> indicated=20
> >> whether or not it should be ACK'd.
> >>
> >> We basically have the exact same messaging as EAP-ER -- we're just=20
> >> renaming some of the messages and defining them a little more=20
> >> generally so they could be useful to others in the future.
> >>
> >> If we're worried about backward compatibility, the EAP-Request/ID=20
> >> could still use the old code, though that's possibly=20
> problematic as=20
> >> discussed in the past.
> >>
> >> --
> >> t. charles clancy, ph.d.  <>  tcc@umd.edu  <> =20
> www.cs.umd.edu/~clancy
> >>
> >> Lakshminath Dondeti wrote:
> >>> Charles,
> >>>
> >>> Thanks for your thoughts.  Some notes inline:
> >>>
> >>> Charles Clancy wrote:
> >>>> All,
> >>>>
> >>>> One problem I have with using methods instead of codes=20
> is protocol=20
> >>>> layering.  Hao mentioned it would be easier to implement a new=20
> >>>> method rather than a new code, and I assume this is=20
> because you can=20
> >>>> simply load a new DLL into whatever implementation=20
> you're using.  I=20
> >>>> disagree.  The method-based transport we're talking about here=20
> >>>> doesn't behave like normal methods.
> >>>>
> >>>> It needs to interact with and modify keying material generated by
> >>>> *other* methods, stored at the EAP layer.  It needs to=20
> modify EAP=20
> >>>> state in ways that methods don't normally modify EAP state.  In=20
> >>>> Madjid's proposal, it may need to have a message=20
> generated at the=20
> >>>> authenticator instead of the EAP server.  Consequently, the=20
> >>>> existing method APIs that would make methods easy to implement=20
> >>>> won't work for a HOKEY method.
> >>>>
> >>>> So, if what we're doing doesn't behave like a method, I=20
> don't think=20
> >>>> it should be transported by a method.
> >>>
> >>> Agreed.
> >>>
> >>>>
> >>>> I think a new EAP Success would be reasonable.  Overloading the=20
> >>>> current one is problematic.  I think defining a new EAP ID=20
> >>>> request/reply would also be reasonable.  Overloading the current=20
> >>>> ones is problematic.
> >>>
> >>> I am curious what this means.  Are we talking about a new=20
> EAP Code=20
> >>> for a message initiated by the Authenticator with similar=20
> semantics=20
> >>> as Request/Response, perhaps something like=20
> EAP-Success-New/Initiate=20
> >>> EAP-Success-New/Finish?
> >>>
> >>> Same question goes for EAP ID thing.  Do you mean EAP=20
> >>> Request/Identity-New and EAP Response/Identity-New?
> >>>
> >>>>
> >>>> What about using a transport similar to EAP-HR, but defining new=20
> >>>> codes for the messages rather than reusing the current ones?  We=20
> >>>> could address a variety of other EAP problems at the=20
> same time, for=20
> >>>> example by defining a TLV structure for data contained in EAP ID=20
> >>>> request/responses and EAP success.
> >>>>
> >>>> What do others think about this?
> >>>
> >>> All interesting ideas, but in my opinion, we will be=20
> trying to solve=20
> >>> too much, and we won't achieve our goals for re-authentication.
> >>>
> >>> Specifically, we will need a EAP Request/Id-new pair and EAP=20
> >>> Success-New pair of messages for reauthentication, i.e.,=20
> 2 RTs for=20
> >>> reauthentication.  Furthermore, for Peer-initiated=20
> re-authentication=20
> >>> we may need 2.5 RTs in all.  Do you agree with that?  If=20
> so, aren't=20
> >>> we too far away from our goals for reauthentication?
> >>>
> >>> thanks,
> >>> Lakshminath
> >>>
> >>>>
> >>>> --
> >>>> t. charles clancy, ph.d.  <>  tcc@umd.edu  <> =20
> >>>> www.cs.umd.edu/~clancy
> >>>>
> >>>> Madjid Nakhjiri wrote:
> >>>>> I missed this question.
> >>>>> I agree that we need to fix a few issues for EAP=20
> Success, such as=20
> >>>>> adding protection for it, but EAP community has been=20
> crying over=20
> >>>>> lack of protection for result indication for quite some=20
> time, so=20
> >>>>> that would be a welcome change. I think it can be achieved.
> >>>>>
> >>>>> As far as adding EAP Success reliability, it may be=20
> tricky (since=20
> >>>>> EAP success is not acked), but I am not sure at EAP=20
> layer it has=20
> >>>>> to do with authenticator, does it? I am curious, why=20
> you say that?
> >>>>>
> >>>>>
> >>>>> -----Original Message-----
> >>>>> From: Lakshminath Dondeti [mailto:ldondeti@qualcomm.com] Sent:
> >>>>> Wednesday, April 11, 2007 2:17 PM
> >>>>> To: Madjid Nakhjiri
> >>>>> Cc: 'Narayanan, Vidya'; hokey@ietf.org
> >>>>> Subject: Re: [HOKEY] Using an EAP method for=20
> >>>>> HOKEY??:was:consensuscall:EAP-ERas HOKEY protocol
> >>>>>
> >>>>>> We are also discussing loading EAP Success, rather=20
> than sending=20
> >>>>>> an empty finish followed by a dumb success, so another RT goes=20
> >>>>>> away there too.
> >>>>>
> >>>>> How do you send EAP Success, overloaded, reliably without=20
> >>>>> modifying authenticators?
> >>>>>
> >>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> HOKEY mailing list
> >>>>> HOKEY@ietf.org
> >>>>> https://www1.ietf.org/mailman/listinfo/hokey
> >>>>
> >>>>
> >>
> >>
> >
>=20
>=20
> _______________________________________________
> HOKEY mailing list
> HOKEY@ietf.org
> https://www1.ietf.org/mailman/listinfo/hokey
>=20

_______________________________________________
HOKEY mailing list
HOKEY@ietf.org
https://www1.ietf.org/mailman/listinfo/hokey



From hokey-bounces@ietf.org Mon Apr 16 15:51: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 1HdXES-0001Hn-2g; Mon, 16 Apr 2007 15:51:24 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HdXEN-0001BX-Gp
	for hokey@ietf.org; Mon, 16 Apr 2007 15:51:19 -0400
Received: from usaga01-in.huawei.com ([206.16.17.211])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HdXEG-00049b-9O
	for hokey@ietf.org; Mon, 16 Apr 2007 15:51:19 -0400
Received: from huawei.com (usaga01-in [172.18.4.6])
	by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTP id <0JGL0085PWH78H@usaga01-in.huawei.com> for
	hokey@ietf.org; Mon, 16 Apr 2007 12:51:08 -0700 (PDT)
Received: from N737011
	(pool-71-112-139-16.sttlwa.dsl-w.verizon.net [71.112.139.16])
	by usaga01-in.huawei.com
	(iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar  3 2004))
	with ESMTPA id <0JGL00HTWWH02Y@usaga01-in.huawei.com> for
	hokey@ietf.org; Mon, 16 Apr 2007 12:51:07 -0700 (PDT)
Date: Mon, 16 Apr 2007 12:51:05 -0700
From: Madjid Nakhjiri 
Subject: RE: [HOKEY] HOKEY transport compromise? :was: Using an EAP method
	forHOKEY??
In-reply-to: <461EE623.202@cs.umd.edu>
To: 'Charles Clancy' 
Message-id: <004301c78060$93e54380$2f01a8c0@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962
X-Mailer: Microsoft Office Outlook 11
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Thread-index: Acd9cKpHSwwc1nl7Q6OUNFcG7J7weQC66/8A
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0
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 Charles,

The problem is as I have mentioned before on list or in drafts, EAP was
designed for point to point authentication and is now being stretched for
not only a backend server scenario, but also for key distribution, so we are
kind of using a hammer to tighten a screw.


I proposed EAP-HR request, because I was worried people did not want to see
EAP-ID being loaded with stuff. Note that EAP ID is many times sent from
authenticator today. I understand that something like EAP-HR is not a
conventional method, since it just wants to do work based on a previous
method. But remember that types 1-3 don't behave like methods either:) You
already see EAP-start from the peer to authenticator in SDOs, or EAP-ID
request or Challenge going from authenticator the peer.

So I think, if we are creating new codes, then we should provide something
that is more than a hammer with a sharp edge, hoping it can do some screws
(agreeing with you that we should address some of the other issues as well):

1) We can add peer-initialized messaging, if we need to, or allow the
authenticator (not the server) to send messages to the peer (since this
really a 3 party scenario and we are looking at mobility), this could be in
form of loading ID request, or creating a new ID that also does capability
exchange that allows the parties to communicate that they are running HOKEY
and using EMSK, etc.

2) We need to be able to load and protect EAP-Success (if it is a new code,
I don't have a problem), because today AAA messaging ends at the
authenticator (not at the peer) and there is no protected result indication.
However, to add reliability, you may have to include an ACK to the Success
as well. So I don't know how people are planning to deal with reliability.

Regards,

Madjid
-----Original Message-----
From: Charles Clancy [mailto:clancy@cs.umd.edu] 
Sent: Thursday, April 12, 2007 7:09 PM
To: Madjid Nakhjiri
Cc: hokey@ietf.org
Subject: [HOKEY] HOKEY transport compromise? :was: Using an EAP method
forHOKEY??

All,

One problem I have with using methods instead of codes is protocol 
layering.  Hao mentioned it would be easier to implement a new method 
rather than a new code, and I assume this is because you can simply load 
a new DLL into whatever implementation you're using.  I disagree.  The 
method-based transport we're talking about here doesn't behave like 
normal methods.

It needs to interact with and modify keying material generated by 
*other* methods, stored at the EAP layer.  It needs to modify EAP state 
in ways that methods don't normally modify EAP state.  In Madjid's 
proposal, it may need to have a message generated at the authenticator 
instead of the EAP server.  Consequently, the existing method APIs that 
would make methods easy to implement won't work for a HOKEY method.

So, if what we're doing doesn't behave like a method, I don't think it 
should be transported by a method.

I think a new EAP Success would be reasonable.  Overloading the current 
one is problematic.  I think defining a new EAP ID request/reply would 
also be reasonable.  Overloading the current ones is problematic.

What about using a transport similar to EAP-HR, but defining new codes 
for the messages rather than reusing the current ones?  We could address 
a variety of other EAP problems at the same time, for example by 
defining a TLV structure for data contained in EAP ID request/responses 
and EAP success.

What do others think about this?

--
t. charles clancy, ph.d.  <>  tcc@umd.edu  <>  www.cs.umd.edu/~clancy

Madjid Nakhjiri wrote:
> I missed this question.
> I agree that we need to fix a few issues for EAP Success, such as adding
> protection for it, but EAP community has been crying over lack of
protection
> for result indication for quite some time, so that would be a welcome
> change. I think it can be achieved.
> 
> As far as adding EAP Success reliability, it may be tricky (since EAP
> success is not acked), but I am not sure at EAP layer it has to do with
> authenticator, does it? I am curious, why you say that?
> 
> 
> -----Original Message-----
> From: Lakshminath Dondeti [mailto:ldondeti@qualcomm.com] 
> Sent: Wednesday, April 11, 2007 2:17 PM
> To: Madjid Nakhjiri
> Cc: 'Narayanan, Vidya'; hokey@ietf.org
> Subject: Re: [HOKEY] Using an EAP method for
> HOKEY??:was:consensuscall:EAP-ERas HOKEY protocol
> 
>> We are also discussing loading EAP Success, rather than sending an empty
>> finish followed by a dumb success, so another RT goes away there too.
> 
> How do you send EAP Success, overloaded, reliably without modifying 
> authenticators?
> 
> 
> 
> _______________________________________________
> 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 Mon Apr 16 15:57:39 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HdXKT-0007n4-Vy; Mon, 16 Apr 2007 15:57:38 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HdXKO-0007j0-W0
	for hokey@ietf.org; Mon, 16 Apr 2007 15:57:33 -0400
Received: from usaga01-in.huawei.com ([206.16.17.211])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdXKJ-0007rT-TW
	for hokey@ietf.org; Mon, 16 Apr 2007 15:57:32 -0400
Received: from huawei.com (usaga01-in [172.18.4.6])
	by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTP id <0JGL008ESWRR8H@usaga01-in.huawei.com> for
	hokey@ietf.org; Mon, 16 Apr 2007 12:57:27 -0700 (PDT)
Received: from N737011
	(pool-71-112-139-16.sttlwa.dsl-w.verizon.net [71.112.139.16])
	by usaga01-in.huawei.com
	(iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar  3 2004))
	with ESMTPA id <0JGL003PXWRIL4@usaga01-in.huawei.com> for
	hokey@ietf.org; Mon, 16 Apr 2007 12:57:27 -0700 (PDT)
Date: Mon, 16 Apr 2007 12:57:19 -0700
From: Madjid Nakhjiri 
Subject: RE: [HOKEY] consensus call: key distribution security requirement
In-reply-to: <461EE796.4000900@cs.umd.edu>
To: 'Charles Clancy' 
Message-id: <004401c78061$7640f4e0$2f01a8c0@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962
X-Mailer: Microsoft Office Outlook 11
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Thread-index: Acd9cYKlld+X/gmORhGUwti9MZdF4QC70P2A
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 34d35111647d654d033d58d318c0d21a
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

Ok, I understand, However, if you could load the peer's message (which I am
guessing is the reason, you eliminated it), then you could avoid the server
creating key material for a lying NAS before the peer detecting this. So as
you said the server ends up spending CPU and bandwidth doing all this for
nothing.

Plus, right now, it is really up the peer to detect the issue and the peer
may really not have a way to notify the server, since there is no message
after 4 (EAP Success).

Madjid

-----Original Message-----
From: Charles Clancy [mailto:clancy@cs.umd.edu] 
Sent: Thursday, April 12, 2007 7:15 PM
To: Madjid Nakhjiri
Cc: hokey@ietf.org
Subject: Re: [HOKEY] consensus call: key distribution security requirement

MAdjid,

I'm only eliminating B in the initial messages 1/2.  The Lying NAS 
problem is prevented by B being included in messages 3/4.  When the peer 
receives message 4, if the value of "B" differs from the advertised 
value the peer can disconnect.  The side effect is we don't have peer 
authorization, so keying material ends up being sent to "B".  But, 
assuming we have all those freshness guarantees, that keying material is 
useless.

--
t. charles clancy, ph.d.  <>  tcc@umd.edu  <>  www.cs.umd.edu/~clancy

Madjid Nakhjiri wrote:
> Hi Charles, 
> 
> I am still catching up on my emails. By eliminating B you are introducing
> the vulnerability to the lying NAS problem. So I personally never saw
adding
> B as a peer consent thing, but rather as part of channel binding. This was
> part of the channel binding solution I presented in SJ even.
> 
>  I don't really see a big problem with peer knowing the authenticator ID,
it
> can either go as part of the EAP request message or as part of L2 beacon
> carrying higher layer network data. 802.21 MIH information server is
> supposed to carry all kinds of network data to the mobiles...
> 
> R,
> 
> Madjid
> 
> -----Original Message-----
> From: Charles Clancy [mailto:clancy@cs.umd.edu] 
> Sent: Wednesday, April 04, 2007 6:27 PM
> To: hokey@ietf.org
> Subject: Re: [HOKEY] consensus call: key distribution security requirement
> 
> All,
> 
> I think we need to look at the protocols.  To compare...
> 
> 3-party protocol (Dan's proposal, slightly simplified assuming AAA 
> provides the necessary transport security):
> 
>     1) A->B: A, {A, B, Na}Kas
>     2) B->S: A, B, {A, B, Na}Kas
>     3) S->B: {B, Na}Kas, {A, Kab}Kbs
>     4) B->A: {B, Na}Kas
> 
> EAP-ER (translated to above notation and assuming AAA transport):
> 
>     1) A->B: A, {A, Na}Kas
>     2) B->S: A, B, {A, Na}Kas
>     3) S->B: {Na}Kas, {Kab}Kbs
>     4) B->A: {Na}Kas
> 
> EAP-ER+CB (my proposal for adding channel binding to EAP-ER):
> 
>     1) A->B: A, {A, Na}Kas
>     2) B->S: A, B, {A, Na}Kas
>     3) S->B: {B, Na}Kas, {A, Kab}Kbs
>     4) B->A: {B, Na}Kas
> 
> So, we've added "A" and "B" in messages 3 and 4, but not added "B" in 
> message 1.  I feel this satisfies everything *but* peer consent, and 
> doesn't require A to know "B" at the beginning.
> 


_______________________________________________
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 Apr 16 17:57: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 1HdZC9-0002Ge-IQ; Mon, 16 Apr 2007 17:57:09 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HdZC8-00028Z-Dw
	for hokey@ietf.org; Mon, 16 Apr 2007 17:57:08 -0400
Received: from usaga01-in.huawei.com ([206.16.17.211])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdZC5-0004g4-Vb
	for hokey@ietf.org; Mon, 16 Apr 2007 17:57:08 -0400
Received: from huawei.com (usaga01-in [172.18.4.6])
	by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTP id <0JGM00D7I2B5HA@usaga01-in.huawei.com> for
	hokey@ietf.org; Mon, 16 Apr 2007 14:57:05 -0700 (PDT)
Received: from N737011
	(pool-71-112-139-16.sttlwa.dsl-w.verizon.net [71.112.139.16])
	by usaga01-in.huawei.com
	(iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar  3 2004))
	with ESMTPA id <0JGM00AOB2B0X3@usaga01-in.huawei.com> for
	hokey@ietf.org; Mon, 16 Apr 2007 14:57:05 -0700 (PDT)
Date: Mon, 16 Apr 2007 14:57:04 -0700
From: Madjid Nakhjiri 
Subject: RE: [HOKEY] Re: HOKEY transport compromise? :was: Using an EAP method
	for HOKEY??
In-reply-to: <461F6FD4.8010005@cs.umd.edu>
To: 'Charles Clancy' ,
	'Lakshminath Dondeti' 
Message-id: <005101c78072$2c2c0d20$2f01a8c0@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962
X-Mailer: Microsoft Office Outlook 11
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Thread-index: Acd9wr2DJ4dS0DKEQwyA56zwaMyGwgCrfyBg
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 202a3ece0492a8c7e7c8672d5214398f
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 Charles,

I think we are getting close. I am not sure whether a new EAP-ID code or a
modified EAP-ID with the same code will be easier. It seems that we need to
hear opinions of Ads and implementers/operators.
 
However, I don't want to see the request from authenticator optional,
because the peer would send a response based on no requests and that seems
to be odd, counterintuitive and it seems that it requires state machine
considerations. Have a request and response tied together is a bit cleaner
what EAP-ER suggested. Plus I don't want to see the MSK used at all,
regardless what scenario or network set up stage we are at.

As we seem to agree, 0.1 RT from authenticator to peer should not make a
difference. We only need to add the capability so that both server and
authenticator can send this request if they want to.

Regardless of new code or not, we should use foresight and add identity
exchange, capability exchange and maybe even "left-over" stuff from previous
AAA exchanges (previous EAP success).

Madjid

-----Original Message-----
From: Charles Clancy [mailto:clancy@cs.umd.edu] 
Sent: Friday, April 13, 2007 4:56 AM
To: Lakshminath Dondeti
Cc: hokey@ietf.org; Madjid Nakhjiri
Subject: [HOKEY] Re: HOKEY transport compromise? :was: Using an EAP method
for HOKEY??

Lakshminath,

I'd see the EAP-Request/Identity-new as an advertisement, containing any 
necessary identity information, and advertising re-auth support.  We 
could make it optional, so the peer wouldn't need to receive it before 
transmitting an EAP-Response/Identity-new, which would contain the 
re-auth request data.  In response, the server would send an 
EAP-Success-new.  So we still have 1.1 RT (since the 
EAP-Request/Identity is being generated by the authenticator, not the 
EAP server).

Picture:

peer                      auth                    server

  [<------- EAP-Req/Id-new -]  (optional)
  -------- EAP-Resp/Id-new(Reauth data) ------------->
  <-------------- EAP-Success-new(Reauth data) -------

I don't think the EAP-Success-new needs to be ACK'd.  If it's not 
received, the peer can retransmit the EAP-Response/Id-new.  This could 
be flexible though, if others wanted to use the EAP-Success-new.  There 
could be a bit in the header that indicated whether or not it should be 
ACK'd.

We basically have the exact same messaging as EAP-ER -- we're just 
renaming some of the messages and defining them a little more generally 
so they could be useful to others in the future.

If we're worried about backward compatibility, the EAP-Request/ID could 
still use the old code, though that's possibly problematic as discussed 
in the past.

--
t. charles clancy, ph.d.  <>  tcc@umd.edu  <>  www.cs.umd.edu/~clancy

Lakshminath Dondeti wrote:
> Charles,
> 
> Thanks for your thoughts.  Some notes inline:
> 
> Charles Clancy wrote:
>> All,
>>
>> One problem I have with using methods instead of codes is protocol 
>> layering.  Hao mentioned it would be easier to implement a new method 
>> rather than a new code, and I assume this is because you can simply 
>> load a new DLL into whatever implementation you're using.  I 
>> disagree.  The method-based transport we're talking about here doesn't 
>> behave like normal methods.
>>
>> It needs to interact with and modify keying material generated by 
>> *other* methods, stored at the EAP layer.  It needs to modify EAP 
>> state in ways that methods don't normally modify EAP state.  In 
>> Madjid's proposal, it may need to have a message generated at the 
>> authenticator instead of the EAP server.  Consequently, the existing 
>> method APIs that would make methods easy to implement won't work for a 
>> HOKEY method.
>>
>> So, if what we're doing doesn't behave like a method, I don't think it 
>> should be transported by a method.
> 
> Agreed.
> 
>>
>> I think a new EAP Success would be reasonable.  Overloading the 
>> current one is problematic.  I think defining a new EAP ID 
>> request/reply would also be reasonable.  Overloading the current ones 
>> is problematic.
> 
> I am curious what this means.  Are we talking about a new EAP Code for a 
> message initiated by the Authenticator with similar semantics as 
> Request/Response, perhaps something like EAP-Success-New/Initiate 
> EAP-Success-New/Finish?
> 
> Same question goes for EAP ID thing.  Do you mean EAP 
> Request/Identity-New and EAP Response/Identity-New?
> 
>>
>> What about using a transport similar to EAP-HR, but defining new codes 
>> for the messages rather than reusing the current ones?  We could 
>> address a variety of other EAP problems at the same time, for example 
>> by defining a TLV structure for data contained in EAP ID 
>> request/responses and EAP success.
>>
>> What do others think about this?
> 
> All interesting ideas, but in my opinion, we will be trying to solve too 
> much, and we won't achieve our goals for re-authentication.
> 
> Specifically, we will need a EAP Request/Id-new pair and EAP Success-New 
air of messages for reauthentication, i.e., 2 RTs for reauthentication. 
>  Furthermore, for Peer-initiated re-authentication we may need 2.5 RTs 
> in all.  Do you agree with that?  If so, aren't we too far away from our 
> goals for reauthentication?
> 
> thanks,
> Lakshminath
> 
>>
>> -- 
>> t. charles clancy, ph.d.  <>  tcc@umd.edu  <>  www.cs.umd.edu/~clancy
>>
>> Madjid Nakhjiri wrote:
>>> I missed this question.
>>> I agree that we need to fix a few issues for EAP Success, such as adding
>>> protection for it, but EAP community has been crying over lack of 
>>> protection
>>> for result indication for quite some time, so that would be a welcome
>>> change. I think it can be achieved.
>>>
>>> As far as adding EAP Success reliability, it may be tricky (since EAP
>>> success is not acked), but I am not sure at EAP layer it has to do with
>>> authenticator, does it? I am curious, why you say that?
>>>
>>>
>>> -----Original Message-----
>>> From: Lakshminath Dondeti [mailto:ldondeti@qualcomm.com] Sent: 
>>> Wednesday, April 11, 2007 2:17 PM
>>> To: Madjid Nakhjiri
>>> Cc: 'Narayanan, Vidya'; hokey@ietf.org
>>> Subject: Re: [HOKEY] Using an EAP method for
>>> HOKEY??:was:consensuscall:EAP-ERas HOKEY protocol
>>>
>>>> We are also discussing loading EAP Success, rather than sending an 
>>>> empty
>>>> finish followed by a dumb success, so another RT goes away there too.
>>>
>>> How do you send EAP Success, overloaded, reliably without modifying 
>>> authenticators?
>>>
>>>
>>>
>>> _______________________________________________
>>> 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 Apr 20 11:08:11 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HeuiZ-0005bJ-As; Fri, 20 Apr 2007 11:08:11 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HeuiX-0005YN-M0
	for hokey@ietf.org; Fri, 20 Apr 2007 11:08:09 -0400
Received: from web84101.mail.mud.yahoo.com ([68.142.206.188])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HeuiW-0004Gs-4a
	for hokey@ietf.org; Fri, 20 Apr 2007 11:08:09 -0400
Received: (qmail 40422 invoked by uid 60001); 20 Apr 2007 15:08:07 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com;
	h=X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Message-ID;
	b=y0ZMsUQBm8ahTR/VQH7yOQ1Ks9taFLtPyQFNaia4pLgsDNjQMYLAVHPDAXr7fNJquNrEM9xPRG1cbHwfPKnUSjlwzQChsmKJPvEFRdTCuoX0cYUlbN9y+8LdkjTGEedCXTcJ09bNzd5G6cwA3Xd48gUxiRx1YJEA15YA8ECo5oQ=;
X-YMail-OSG: 3WOecbQVM1n1O_gVvWgrByc2eRFGxwLkJNZprDfsBJYjkHHiqlmHJly0YZBtpNKA.XMXWYEe1lfLFJ_5p9svRk2kCvqZ38lLRAylEEpsKVPoSBiUtrW0wYBp4NyUEA--
Received: from [206.16.17.212] by web84101.mail.mud.yahoo.com via HTTP;
	Fri, 20 Apr 2007 08:08:07 PDT
X-Mailer: YahooMailRC/478 YahooMailWebService/0.7.41.10
Date: Fri, 20 Apr 2007 08:08:07 -0700 (PDT)
From: Behcet Sarikaya 
Subject: Re: [HOKEY] consensus call: EAP-ER as HOKEY protocol
To: hokey@ietf.org
MIME-Version: 1.0
Message-ID: <584803.40010.qm@web84101.mail.mud.yahoo.com>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe
X-BeenThere: hokey@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Behcet Sarikaya 
List-Id: HOKEY WG Mailing List 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============0707329126=="
Errors-To: hokey-bounces@ietf.org

--===============0707329126==
Content-Type: multipart/alternative; boundary="0-1300728965-1177081687=:40010"

--0-1300728965-1177081687=:40010
Content-Type: text/plain; charset=ascii

I would like to support this request. As you know consensus is difficult to reach and once reached, we should make all the effort to keep it.
Yes, there has been newer developments after the call was issued. My idea is ask the draft authors to change the protocol name to HOKEY protocol not EAP-ER or EAP-HR and also to ask them to incorporate some of the nice enhancements proposed after the call then to get this draft published as WG draft.

It might be OK to increase from 1RT to 1.1 or 1.5, however you calculate it.

As for the key hierarchy, I have a concern on trying to standardize complete key hierarchies. Some SDOs already developed their own key hierarchies. 802.11r is I think a good example. Why should we expect the SDO to adopt a compeletly new key hierarchy? Instead, Hokey key hierarchy could complement an existing key hierarchy such as 802.11r by feeding into PMK-R0. Such a key hierarchy has higher possibility of getting adopted in SDOs, IMHO.

Should we ask Joe to revise the key hierarchy draft in this direction, any ways whatever he presented in Prag did not seem to exist in the current draft.

My 2 cents.

Behcet


----- Original Message ----
From: Charles Clancy 
To: hokey@ietf.org
Sent: Saturday, March 31, 2007 1:57:40 PM
Subject: [HOKEY] consensus call: EAP-ER as HOKEY protocol


HOKEY WG,

The chairs are making a second consensus call request to adopt EAP-ER as 
a WG document to satisfy our re-auth and hand-off deliverables.  It 
would serve as a starting point for development of the HOKEY protocol.

Note that if accepted, it may be split into two WG documents, separating 
the EAP-ER-Bootstrap into a second set of messages that could be 
transported by any service to obtain a USRK or DSUSRK.

Please respond by Friday, April 13.

-- 
t. charles clancy, ph.d.  <>  tcc@umd.edu  <>  www.cs.umd.edu/~clancy


_______________________________________________
HOKEY mailing list
HOKEY@ietf.org
https://www1.ietf.org/mailman/listinfo/hokey
--0-1300728965-1177081687=:40010
Content-Type: text/html; charset=ascii


I would like to support this request. As you know consensus is difficult to reach and once reached, we should make all the effort to keep it.


Yes, there has been newer developments after the call was issued. My idea is ask the draft authors to change the protocol name to HOKEY protocol not EAP-ER or EAP-HR and also to ask them to incorporate some of the nice enhancements proposed after the call then to get this draft published as WG draft.


 


It might be OK to increase from 1RT to 1.1 or 1.5, however you calculate it.


 


As for the key hierarchy, I have a concern on trying to standardize complete key hierarchies. Some SDOs already developed their own key hierarchies. 802.11r is I think a good example. Why should we expect the SDO to adopt a compeletly new key hierarchy? Instead, Hokey key hierarchy could complement an existing key hierarchy such as 802.11r by feeding into PMK-R0. Such a key hierarchy has higher possibility of getting adopted in SDOs, IMHO.


 


Should we ask Joe to revise the key hierarchy draft in this direction, any ways whatever he presented in Prag did not seem to exist in the current draft.


 


My 2 cents.


 


Behcet



----- Original Message ----
From: Charles Clancy <clancy@cs.umd.edu>
To: hokey@ietf.org
Sent: Saturday, March 31, 2007 1:57:40 PM
Subject: [HOKEY] consensus call: EAP-ER as HOKEY protocol



HOKEY WG,

The chairs are making a second consensus call request to adopt EAP-ER as 
a WG document to satisfy our re-auth and hand-off deliverables.  It 
would serve as a starting point for development of the HOKEY protocol.

Note that if accepted, it may be split into two WG documents, separating 
the EAP-ER-Bootstrap into a second set of messages that could be 
transported by any service to obtain a USRK or DSUSRK.

Please respond by Friday, April 13.

-- 
t. charles clancy, ph.d.  <>  tcc@umd.edu  <>  www.cs.umd.edu/~clancy


_______________________________________________
HOKEY mailing list
HOKEY@ietf.org
https://www1.ietf.org/mailman/listinfo/hokey




--0-1300728965-1177081687=:40010--


--===============0707329126==
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

--===============0707329126==--




From hokey-bounces@ietf.org Sun Apr 29 18:07: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 1HiHYX-0001FX-Ek; Sun, 29 Apr 2007 18:07:45 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HiHYV-0001FS-EG
	for hokey@ietf.org; Sun, 29 Apr 2007 18:07:43 -0400
Received: from sj-iport-6.cisco.com ([171.71.176.117])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiHYU-0002cs-FE
	for hokey@ietf.org; Sun, 29 Apr 2007 18:07:43 -0400
Received: from sj-dkim-1.cisco.com ([171.71.179.21])
	by sj-iport-6.cisco.com with ESMTP; 29 Apr 2007 15:07:40 -0700
X-IronPort-AV: i="4.14,467,1170662400"; 
	d="txt'?scan'208,217"; a="142144326:sNHT142656048"
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 l3TM7fMB022121; 
	Sun, 29 Apr 2007 15:07:41 -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 l3TM7bMH009747;
	Sun, 29 Apr 2007 22:07:41 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); 
	Sun, 29 Apr 2007 15:07:40 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C78AAA.CDB0C48F"
Date: Sun, 29 Apr 2007 15:07:37 -0700
Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB262503DE52F5@xmb-sjc-215.amer.cisco.com>
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
Thread-Topic: Charles' hokey plan
Thread-Index: AceKqsvvH5TfkXnpTkqZNSAaxJx06g==
From: "Glen Zorn \(gwz\)" 
To: 
X-OriginalArrivalTime: 29 Apr 2007 22:07:40.0869 (UTC)
	FILETIME=[CE027750:01C78AAA]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=25158; t=1177884461;
	x=1178748461; 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:=20Charles'=20hokey=20plan |Sender:=20;
	bh=7yHv/nRy8fRqrG7PgVf6tS0cBhDmCL+7NOILuHN5Gi4=;
	b=jMouu+XUIEuLDIQ0T1TMt/o/WC4KAKKFCgKNS1jeaBoP8kluhB5ZRGVv40E1mpDVMmOVke2p
	YCZYmY7esQ2OFDtr8jzVYK28TPjzocYzDehlsM+WcRuvcOS4isMzWh5NpZZNjXNkPP9PZLTGqN
	38NB0acYLmmr40WIZrnZbbAmI=;
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: 46ad68ada464411807db2a0edd5648ae
Cc: 
Subject: [HOKEY] Charles' hokey plan
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

This is a multi-part message in MIME format.

------_=_NextPart_001_01C78AAA.CDB0C48F
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_002_01C78AAA.CDB0C48F"


------_=_NextPart_002_01C78AAA.CDB0C48F
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

 <>=20
The attached draft represents a distillation of Charles' ideas on a way
forward for the WG.  He has personal business to attend to, so he asked
me to post it on his behalf.  Please send comments to the list.

------_=_NextPart_002_01C78AAA.CDB0C48F
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable






Charles' hokey plan





 =
<<draft-clancy-hokey-plan-00.txt>> 


The attached draft represents a =
distillation of Charles' ideas on a way forward for the WG.  He has =
personal business to attend to, so he asked me to post it on his =
behalf.  Please send comments to the list.




------_=_NextPart_002_01C78AAA.CDB0C48F--

------_=_NextPart_001_01C78AAA.CDB0C48F
Content-Type: text/plain;
	name="draft-clancy-hokey-plan-00.txt"
Content-Transfer-Encoding: base64
Content-Description: draft-clancy-hokey-plan-00.txt
Content-Disposition: attachment;
	filename="draft-clancy-hokey-plan-00.txt"

DQoNCg0KSE9LRVkgV29ya2luZyBHcm91cCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgVC4gQ2xhbmN5DQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBMVFMNCkludGVuZGVkIHN0YXR1czog
SW5mb3JtYXRpb25hbCAgICAgICAgICAgICAgICAgICAgICAgICAgICBBcHJpbCAyOSwgMjAwNw0K
RXhwaXJlczogT2N0b2JlciAzMSwgMjAwNw0KDQoNCiAgICAgICAgICAgICAgICAgSE9LRVkgUmUt
YXV0aGVudGljYXRpb24gUHJvdG9jb2wgUGxhbg0KICAgICAgICAgICAgICAgICAgICAgICBkcmFm
dC1jbGFuY3ktaG9rZXktcGxhbi0wMA0KDQpTdGF0dXMgb2YgdGhpcyBNZW1vDQoNCiAgIEJ5IHN1
Ym1pdHRpbmcgdGhpcyBJbnRlcm5ldC1EcmFmdCwgZWFjaCBhdXRob3IgcmVwcmVzZW50cyB0aGF0
IGFueQ0KICAgYXBwbGljYWJsZSBwYXRlbnQgb3Igb3RoZXIgSVBSIGNsYWltcyBvZiB3aGljaCBo
ZSBvciBzaGUgaXMgYXdhcmUNCiAgIGhhdmUgYmVlbiBvciB3aWxsIGJlIGRpc2Nsb3NlZCwgYW5k
IGFueSBvZiB3aGljaCBoZSBvciBzaGUgYmVjb21lcw0KICAgYXdhcmUgd2lsbCBiZSBkaXNjbG9z
ZWQsIGluIGFjY29yZGFuY2Ugd2l0aCBTZWN0aW9uIDYgb2YgQkNQIDc5Lg0KDQogICBJbnRlcm5l
dC1EcmFmdHMgYXJlIHdvcmtpbmcgZG9jdW1lbnRzIG9mIHRoZSBJbnRlcm5ldCBFbmdpbmVlcmlu
Zw0KICAgVGFzayBGb3JjZSAoSUVURiksIGl0cyBhcmVhcywgYW5kIGl0cyB3b3JraW5nIGdyb3Vw
cy4gIE5vdGUgdGhhdA0KICAgb3RoZXIgZ3JvdXBzIG1heSBhbHNvIGRpc3RyaWJ1dGUgd29ya2lu
ZyBkb2N1bWVudHMgYXMgSW50ZXJuZXQtDQogICBEcmFmdHMuDQoNCiAgIEludGVybmV0LURyYWZ0
cyBhcmUgZHJhZnQgZG9jdW1lbnRzIHZhbGlkIGZvciBhIG1heGltdW0gb2Ygc2l4IG1vbnRocw0K
ICAgYW5kIG1heSBiZSB1cGRhdGVkLCByZXBsYWNlZCwgb3Igb2Jzb2xldGVkIGJ5IG90aGVyIGRv
Y3VtZW50cyBhdCBhbnkNCiAgIHRpbWUuICBJdCBpcyBpbmFwcHJvcHJpYXRlIHRvIHVzZSBJbnRl
cm5ldC1EcmFmdHMgYXMgcmVmZXJlbmNlDQogICBtYXRlcmlhbCBvciB0byBjaXRlIHRoZW0gb3Ro
ZXIgdGhhbiBhcyAid29yayBpbiBwcm9ncmVzcy4iDQoNCiAgIFRoZSBsaXN0IG9mIGN1cnJlbnQg
SW50ZXJuZXQtRHJhZnRzIGNhbiBiZSBhY2Nlc3NlZCBhdA0KICAgaHR0cDovL3d3dy5pZXRmLm9y
Zy9pZXRmLzFpZC1hYnN0cmFjdHMudHh0Lg0KDQogICBUaGUgbGlzdCBvZiBJbnRlcm5ldC1EcmFm
dCBTaGFkb3cgRGlyZWN0b3JpZXMgY2FuIGJlIGFjY2Vzc2VkIGF0DQogICBodHRwOi8vd3d3Lmll
dGYub3JnL3NoYWRvdy5odG1sLg0KDQogICBUaGlzIEludGVybmV0LURyYWZ0IHdpbGwgZXhwaXJl
IG9uIE9jdG9iZXIgMzEsIDIwMDcuDQoNCkNvcHlyaWdodCBOb3RpY2UNCg0KICAgQ29weXJpZ2h0
IChDKSBUaGUgSUVURiBUcnVzdCAoMjAwNykuDQoNCkFic3RyYWN0DQoNCiAgIFRoaXMgZG9jdW1l
bnQgZGVzY3JpYmVzIGEgcGxhbiBmb3J3YXJkIGZvciBpbmNvcnBvcmF0aW5nIHRoZSB3b3JrIG9m
DQogICBhIHZhcmlldHkgb2YgaW5kaXZpZHVhbCBzdWJtaXNzaW9ucyB0byBzYXRpc2Z5IHRoZSBI
T0tFWSB3b3JraW5nDQogICBncm91cCByZS1hdXRoZW50aWNhdGlvbiBwcm9ibGVtIHN0YXRlbWVu
dCBpbnRvIGEgc2luZ2xlIHNldCBvZg0KICAgd29ya2luZy1ncm91cCBkb2N1bWVudHMuDQoNCg0K
DQoNCg0KDQoNCkNsYW5jeSAgICAgICAgICAgICAgICAgIEV4cGlyZXMgT2N0b2JlciAzMSwgMjAw
NyAgICAgICAgICAgICAgICBbUGFnZSAxXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAg
ICAgIEhPS0VZIFBsYW4gICAgICAgICAgICAgICAgICAgICBBcHJpbCAyMDA3DQoNCg0KVGFibGUg
b2YgQ29udGVudHMNCg0KICAgMS4gIEludHJvZHVjdGlvbiAgLiAuIC4gLiAuIC4gLiAuIC4gLiAu
IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAzDQogICAyLiAgVGVybWlub2xvZ3kgLiAuIC4g
LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDMNCiAgIDMuICBF
QVAgS2V5IERlbGl2ZXJ5IFByb3RvY29sIERvY3VtZW50ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g
LiAuIC4gMw0KICAgNC4gIEhPS0VZIFJlLUF1dGggUHJvdG9jb2wgRG9jdW1lbnQgLiAuIC4gLiAu
IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA2DQogICA1LiAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMg
LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDcNCiAgIDYuICBJQU5BIENv
bnNpZGVyYXRpb25zIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g
Nw0KICAgNy4gIFJlZmVyZW5jZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu
IC4gLiAuIC4gLiAuIC4gLiA3DQogICAgIDcuMS4gIE5vcm1hdGl2ZSBSZWZlcmVuY2VzICAuIC4g
LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDcNCiAgICAgNy4yLiAgSW5mb3JtYXRp
dmUgUmVmZXJlbmNlcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNw0KICAg
QXV0aG9yJ3MgQWRkcmVzcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu
IC4gLiAuIC4gLiA3DQogICBJbnRlbGxlY3R1YWwgUHJvcGVydHkgYW5kIENvcHlyaWdodCBTdGF0
ZW1lbnRzICAuIC4gLiAuIC4gLiAuIC4gLiAuIDkNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K
DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpDbGFuY3kg
ICAgICAgICAgICAgICAgICBFeHBpcmVzIE9jdG9iZXIgMzEsIDIwMDcgICAgICAgICAgICAgICAg
W1BhZ2UgMl0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICBIT0tFWSBQbGFuICAg
ICAgICAgICAgICAgICAgICAgQXByaWwgMjAwNw0KDQoNCjEuICBJbnRyb2R1Y3Rpb24NCg0KICAg
T3ZlciB0aGUgcGFzdCBzZXZlcmFsIG1vbnRocywgdGhlcmUgaGF2ZSBiZWVuIHRocmVlIGRvY3Vt
ZW50cywgZWFjaA0KICAgd2l0aCBkaWZmZXJlbnQgcXVhbGl0aWVzIGFuZCBkaWZmZXJlbnQgbGV2
ZWxzIG9mIGNvbXBsZXRlbmVzcywNCiAgIHN1Ym1pdHRlZCBhcyBzb2x1dGlvbnMgZG9jdW1lbnRz
IGZvciBIT0tFWSByZS1hdXRoZW50aWNhdGlvbi4NCg0KICAgRUFQLUVSIFtJLUQudmlkeWEtZWFw
LWVyXSBkZXNjcmliZXMgYSBwcm90b2NvbCBmb3IgZG9pbmcgcmUtDQogICBhdXRoZW50aWNhdGlv
biBpbiBFQVAgYnkgZXh0ZW5kaW5nIEVBUCB3aXRoIGFkZGl0aW9uYWwgUGFja2V0IENvZGVzLg0K
ICAgVGhlc2UgY29kZXMgd291bGQgYWxsb3cgYSBwZWVyLWluaXRpYXRlZCByZS1hdXRoZW50aWNh
dGlvbiByZXF1ZXN0IHRvDQogICBiZSBjb21tdW5pY2F0ZWQgdG8gdGhlIEhPS0VZIHNlcnZlciwg
YW5kIGEgcmVzcG9uc2UgcmV0dXJuZWQuICBJdA0KICAgYWxzbyBkZWZpbmVzIHRoZSBuZWNlc3Nh
cnkga2V5aW5nIGhpZXJhcmNoeSB0byBzdXBwb3J0IHJlLQ0KICAgYXV0aGVudGljYXRpb24uDQoN
CiAgIFRoZSAzLXBhcnR5IGtleWluZyBwcm90b2NvbCBkb2N1bWVudA0KICAgW0ktRC5vaGJhLWhv
a2V5LTNwYXJ0eS1rZXlkaXN0LXBzXSBkZXNjcmliZXMgYm90aCBhZGRpdGlvbmFsIHByb3RvY29s
DQogICByZXF1aXJlbWVudHMgdG8gbW92aXRhdmUgdGhlIHVzZSBvZiBhIDMtcGFydHkga2V5IGRp
c3RyaWJ1dGlvbg0KICAgcHJvdG9jb2wsIGFuZCBhIHJvdWdoIHN0cmF3bWFuIGZvciB3aGF0IHN1
Y2ggYSBwcm90b2NvbCBjb3VsZCBsb29rDQogICBsaWtlLg0KDQogICBFQVAtSFIgW0ktRC5uYWto
amlyaS1ob2tleS1oaWVyYXJjaHldIGRlc2NyaWJlcyBhIHByb3RvY29sIG1vdGl2YXRlZA0KICAg
YnkgdGhlIDMtcGFydHkga2V5aW5nIGRvY3VtZW50IHRoYXQgdXNlcyBtZXRob2QtYmFzZWQgdHJh
bnNwb3J0IHdpdGgNCiAgIGEgbW9kaWZpZWQgRUFQLVN1Y2Nlc3MgcGFja2V0LiAgQWRkaXRpb25h
bGx5LCBhIGtleWluZyBoaWVyYXJjaHkgZm9yDQogICByZS1hdXRoZW50aWNhdGlvbiBpcyBwcmVz
ZW50ZWQuDQoNCiAgIEVhY2ggZG9jdW1lbnQgaGFzIGl0cyBzdHJlbmd0aHMsIGFuZCB0aGlzIGRv
Y3VtZW50IGRlc2NyaWJlcyBhIHBsYW4NCiAgIGZvciBtZXJnaW5nIHRoZW0gaW50byB0d28gd29y
a2luZy1ncm91cCBkb2N1bWVudHMuICBUaGUgZmlyc3QNCiAgIGRvY3VtZW50IHdpbGwgZGVzY3Jp
YmUgRU1TSyBzZXJ2aWNlIGtleSBkZWxpdmVyeSwgYW5kIHRoZSBzZWNvbmQgd2lsbA0KICAgZGVz
Y3JpYmUgdGhlIEhPS0VZIHJlLWF1dGhlbnRpY2F0aW9uIHByb3RvY29sLiAgVGhlIHBsYW4gZXhw
cmVzc2VkIGluDQogICB0aGlzIGRvY3VtZW50IHJlcHJlc2VudHMgYSB2YXJpZXR5IG9mIGNvbXBy
b21pc2VzIG1ha2luZyB1cCB0aGUNCiAgIGNvbnNlbnN1cyBvZiB0aGUgd29ya2luZyBncm91cCwg
YXMgcGVyY2VpdmVkIGJ5IHRoZSBjaGFpcnMuDQoNCg0KMi4gIFRlcm1pbm9sb2d5DQoNCiAgIElu
IHRoaXMgZG9jdW1lbnQsIHNldmVyYWwgd29yZHMgYXJlIHVzZWQgdG8gc2lnbmlmeSB0aGUgcmVx
dWlyZW1lbnRzDQogICBvZiB0aGUgc3BlY2lmaWNhdGlvbi4gIFRoZXNlIHdvcmRzIGFyZSBvZnRl
biBjYXBpdGFsaXplZC4gIFRoZSBrZXkNCiAgIHdvcmRzICJNVVNUIiwgIk1VU1QgTk9UIiwgIlJF
UVVJUkVEIiwgIlNIQUxMIiwgIlNIQUxMIE5PVCIsICJTSE9VTEQiLA0KICAgIlNIT1VMRCBOT1Qi
LCAiUkVDT01NRU5ERUQiLCAiTUFZIiwgYW5kICJPUFRJT05BTCIgaW4gdGhpcyBkb2N1bWVudA0K
ICAgYXJlIHRvIGJlIGludGVycHJldGVkIGFzIGRlc2NyaWJlZCBpbiBbUkZDMjExOV0uDQoNCg0K
My4gIEVBUCBLZXkgRGVsaXZlcnkgUHJvdG9jb2wgRG9jdW1lbnQNCg0KICAgQW55IHNlcnZpY2Ug
dGhhdCBuZWVkcyB0byBvYnRhaW4gYSBVU1JLLCBEU1JLLCBvciBEU1VTUksNCiAgIFtJLUQuaWV0
Zi1ob2tleS1lbXNrLWhpZXJhcmNoeV0gbmVlZHMgdG8gZXhlY3V0ZSBzb21lIHNvcnQgb2YNCiAg
IHByb3RvY29sIGV4Y2hhbmdlIHdpdGggdGhlIEVBUCBzZXJ2ZXIgdG8gb2J0YWluIHRoYXQga2V5
LiAgVGhpcw0KICAgZXhjaGFuZ2UgbWF5IGJlIGV4ZWN1dGVkIGluIGNvbmp1bmN0aW9uIHdpdGgg
c29tZSBvdGhlciBwcm90b2NvbA0KICAgYWN0aW9uLCBvciBwZXJmb3JtZWQgaW5kZXBlbmRlbnRs
eSwgZGVwZW5kaW5nIG9uIGhvdyB0aGUgc2VydmljZQ0KDQoNCg0KQ2xhbmN5ICAgICAgICAgICAg
ICAgICAgRXhwaXJlcyBPY3RvYmVyIDMxLCAyMDA3ICAgICAgICAgICAgICAgIFtQYWdlIDNdDQoM
DQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgSE9LRVkgUGxhbiAgICAgICAgICAgICAg
ICAgICAgIEFwcmlsIDIwMDcNCg0KDQogICBvcGVyYXRlcy4NCg0KICAgVGhlIGdvYWwgb2YgdGhp
cyBkb2N1bWVudCBpcyB0byBkZXNjcmliZSBhIGdlbmVyaWMgcHJvdG9jb2wgdGhhdA0KICAgb3Ro
ZXIgcHJvdG9jb2xzIGNhbiB1c2UgdG8gb2J0YWluIHRoZXNlIHJvb3Qga2V5cy4gIFRoaXMgZG9j
dW1lbnQNCiAgIHdpbGwgbm90LCBob3dldmVyLCBzcGVjaWZ5IGFuIGFjdHVhbCB0cmFuc3BvcnQs
IGFzIGVhY2ggc2VydmljZSBtYXkNCiAgIG5lZWRzIGl0cyBvd24gc3BlY2lhbGl6ZWQgdHJhbnNw
b3J0LiAgQSBnZW5lcmljIEFBQSBrZXlyZXEtYmFzZWQNCiAgIGFwcHJvYWNoIENPVUxEIGJlIGRl
ZmluZWQgaW4gdGhpcyBkb2N1bWVudC4NCg0KICAgVGhlIGZ1bmRhbWVudGFscyBvZiB0aGUga2V5
aW5nIGhpZXJhcmNoeSBuZWNlc3NhcnkgdG8gc3VwcG9ydCBjaGFubmVsDQogICBiaW5kaW5ncywg
YWxvbmcgd2l0aCB0aGUgcHJvdG9jb2wgZXhjaGFuZ2VzLCB3aWxsIGJlIGJhc2VkIG9uIEVBUC1I
Ug0KICAgMy1wYXJ0eSBrZXkgZGVsaXZlcnkgcHJvdG9jb2wgW0ktRC5uYWtoamlyaS1ob2tleS1o
aWVyYXJjaHldLCBhbmQgdGhlDQogICBFQVAtRVItQm9vdHN0cmFwIHByb3RvY29sIFtJLUQudmlk
eWEtZWFwLWVyXS4NCg0KDQogICAgICAgICAgICAgICAgRU1TSw0KICAgICoqKioqKioqKioqKioq
fCoqKioqKioqKioqKioNCiAgICogICArLS0tLS0tLS0tLSstLS0tLS0tLS0tKyAgKg0KICAgKiAg
IHwgICAgICAgICAgfCAgICAgICAgICB8ICAqDQogICAqIFVTUksgICAgICAgRFNSSyAgICAgICAg
IElLICogIEVNU0sgSGllcmFyY2h5ICYNCiAgICogICAgICAgICAgICAgIHwgICAgICAgICAgICA8
LS0gS2V5IERlbGl2ZXJ5DQogICAqICAgKy0tLS0tLS0tLS0rLS0tLS0tLS0tLSsgICogIERvY3Vt
ZW50cw0KICAgKiAgIHwgICAgICAgKioqfCoqKiAgICAgICB8ICAqDQogICAqIERTVVNSSyAgICog
IEhSSyAgKiAgICBEU0lLICoNCiAgICAqKioqKioqKioqICAgIHwgICAgKioqKioqKioqDQogICAq
ICAgKy0tLS0tLS0tLS0rLS0tLS0tLS0tLSsgICoNCiAgICogICB8ICAgICAgICAgIHwgICAgICAg
ICAgfCAgKg0KICAgKiByTVNLICAgICAgIHJNU0sgICAgICAgIHJJSyAqDQogICAqICAgICAgICAg
ICAgICAgICAgICAgICAgICAgPC0tIEhPS0VZIFJlLUF1dGgNCiAgICAqKioqKioqKioqKioqKioq
KioqKioqKioqKioqICAgUHJvdG9jb2wgRG9jdW1lbnQNCg0KICAgICAgICAgICAgICAgRmlndXJl
IDE6IEVBUCBFTVNLIEtleWluZyBIaWVyYXJjaHkgRGl2aXNpb24NCg0KICAgVGhlIHB1cnBvc2Ug
b2YgdGhpcyBkb2N1bWVudCBpcyB0byBkZWZpbmUgdGhlIG5lY2Vzc2FyeSBVU1JLcyBhbmQNCiAg
IERTVVNSS3MgZm9yIGNoYW5uZWwgYmluZGluZyBhdCBlYWNoIGxheWVyIG9mIHRoZSBrZXlpbmcg
aGllcmFyY2h5DQogICAoaS5lLiB0aGUgSUsgYW5kIERTSUspLiAgQWRkaXRpb25hbGx5LCBpdCBz
aGFsbCBkZWZpbmUgcGF5bG9hZHMsIGluDQogICB0aGUgZm9ybSBvZiBvcGFxdWUgYmxvYnMsIHRo
YXQgYSB0cmFuc3BvcnQgcHJvdG9jb2wgU0hPVUxEIGNhcnJ5IGlmDQogICBpdCByZXF1aXJlcyBz
dHJvbmcgc2VjdXJpdHkgb24ga2V5IGRpc3RyaWJ1dGlvbi4NCg0KICAgRm9yIGV4YW1wbGUsIGlm
IEtILVggcmVwcmVzZW50cyB0aGUgaWRlbnRpdHkgb2YgdGhlIGtleSBob2xkZXIgZm9yDQogICBr
ZXkgWCwgYSAzLXBhcnR5IHByb3RvY29sIGZvciBhIHNlcnZpY2UgdGhhdCBzaW1wbHkgdXNlcyBh
IFVTUkssDQogICBpbnNwaXJlZCBieSBbSS1ELm9oYmEtaG9rZXktM3BhcnR5LWtleWRpc3QtcHNd
LCBtaWdodCBsb29rIHNvbWV0aGluZw0KICAgbGlrZSB0aGUgZm9sbG93aW5nLg0KDQogICBGaXJz
dCBsZXQncyBkZWZpbmUgYSBmZXcgZnVuY3Rpb25zOg0KDQogICBvICBTRUMoSywgTSkgPSBNIHx8
IE1JQ19LKE0pDQoNCg0KDQoNCg0KQ2xhbmN5ICAgICAgICAgICAgICAgICAgRXhwaXJlcyBPY3Rv
YmVyIDMxLCAyMDA3ICAgICAgICAgICAgICAgIFtQYWdlIDRdDQoMDQpJbnRlcm5ldC1EcmFmdCAg
ICAgICAgICAgICAgICAgSE9LRVkgUGxhbiAgICAgICAgICAgICAgICAgICAgIEFwcmlsIDIwMDcN
Cg0KDQogICBvICBJRGJpbmQoaWQxLCBpZDIsIGlkMywgTiwgSykgPSBTRUMoSywgaWQxIHx8IGlk
MiB8fCBpZDMgfHwgTikNCiAgIG8gIEtleVRyYW5zcG9ydChLKSA9IEsgb3IgRU5DKEspLCBkZXBl
bmRpbmcgb24gc2VydmljZQ0KDQogICBUaGUgSURiaW5kKC4pIGJsb2IgaXMgYSBiYXNpYyBjaGFu
bmVsIGJpbmRpbmcgYmxvYiB0aGF0IGJpbmRzIHRocmVlDQogICBpZGVudGl0aWVzIHRvZ2V0aGVy
IHdpdGggYSBub25jZSB1c2luZyBhIHNlY3JldCBrZXkuICBVc2luZyB0aGlzDQogICBidWlsZGlu
ZyBibG9jaywgdGhlIHByb3RvY29sIHdvdWxkIGxvb2sgbGlrZToNCg0KICAgMS4gIHBlZXIgLT4g
S0gtVVNSSzogSURiaW5kKHBlZXIsIEVBUCBTZXJ2ZXIsIEtILVVTUkssIE5vbmNlQSwgSUspDQog
ICAyLiAgS0gtVVNSSyAtPiBFQVAgU2VydmVyOiBJRGJpbmQocGVlciwgRUFQIFNlcnZlciwgS0gt
VVNSSywgTm9uY2VBLA0KICAgICAgIElLKQ0KICAgMy4gIEVBUCBTZXJ2ZXIgLT4gS0gtVVNSSzog
SURiaW5kKHBlZXIsIEVBUCBTZXJ2ZXIsIEtILVVTUkssDQogICAgICAgTm9uY2VBKzEsIElLKSwg
S2V5VHJhbnNwb3J0KFVTUkspDQogICA0LiAgS0gtVVNSSyAtPiBwZWVyOiBJRGJpbmQocGVlciwg
RUFQIFNlcnZlciwgS0gtVVNSSywgTm9uY2VBKzEsIElLKQ0KDQogICBUaGlzIHByb3RvY29sIGJp
bmRzIHRoZSB0aHJlZSBpZGVudGl0aWVzIHdpdGggYSBmcmVzaCBub25jZSwgYW5kDQogICByZXR1
cm5zIHRoZSBVU1JLIHRvIHRoZSBzZXJ2aWNlLiAgRm9yIGEgc2VydmljZSB0aGF0IHV0aWxpemVz
IGEgRFNSSywNCiAgIHRoZSBhYm92ZSBleGNoYW5nZSB3b3VsZCBiZSBzaW1pbGFyLCBidXQgaW5j
bHVkZSBhZGRpdGlvbmFsIHBheWxvYWRzLg0KDQogICAxLiAgcGVlciAtPiBLSC1EU1VTUks6IElE
YmluZChwZWVyLCBFQVAgU2VydmVyLCBLSC1EU1JLLCBOb25jZUEsIElLKSwNCiAgICAgICBJRGJp
bmQocGVlciwgS0gtRFNSSywgS0gtRFNVU1JLLCBOb25jZUEsIERTSUspDQogICAyLiAgS0gtRFNV
U1JLIC0+IEtILURTUks6IElEYmluZChwZWVyLCBFQVAgU2VydmVyLCBLSC1EU1JLLCBOb25jZUEs
DQogICAgICAgSUspLCBJRGJpbmQocGVlciwgS0gtRFNSSywgS0gtRFNVU1JLLCBOb25jZUEsIERT
SUspDQogICAzLiAgS0gtRFNSSyAtPiBFQVAgU2VydmVyOiBJRGJpbmQocGVlciwgRUFQIFNlcnZl
ciwgS0gtRFNSSywgTm9uY2VBLA0KICAgICAgIElLKQ0KICAgNC4gIEVBUCBTZXJ2ZXIgLT4gS0gt
RFNSSzogSURiaW5kKHBlZXIsIEVBUCBTZXJ2ZXIsIEtILURTUkssDQogICAgICAgTm9uY2VBKzEs
IElLKSwgS2V5VHJhbnNwb3J0KERTUkspDQogICA1LiAgS0gtRFNSSyAtPiBLSC1EU1VTUks6IElE
YmluZChwZWVyLCBFQVAgU2VydmVyLCBLSC1EU1JLLCBOb25jZUErMSwNCiAgICAgICBJSyksIElE
YmluZChwZWVyLCBLSC1EU1JLLCBLSC1EU1VTUkssIE5vbmNlQSsxLCBEU0lLKSwNCiAgICAgICBL
ZXlUcmFuc3BvcnQoRFNVU1JLKQ0KICAgNi4gIEtILURTVVNSSyAtPiBwZWVyOiBJRGJpbmQocGVl
ciwgRUFQIFNlcnZlciwgS0gtRFNSSywgTm9uY2VBKzEsDQogICAgICAgSUspLCBJRGJpbmQocGVl
ciwgS0gtRFNSSywgS0gtRFNVU1JLLCBOb25jZUErMSwgRFNJSykNCg0KICAgVGhpcyBpcyBzdGls
bCBhIHNpbmdsZSByb3VuZCB0cmlwLCBqdXN0IHJlbGF5ZWQgdGhyb3VnaCBhIHZhcmlldHkgb2YN
CiAgIGludGVybWVkaWF0ZSBub2Rlcy4gIE5vdGUgdGhhdCBpZiBLSC1EU1JLIGFscmVhZHkgaGVs
ZCB0aGUgRFNSSywgdGhlDQogICBwcm90b2NvbCB3b3VsZCBzaW1wbGlmeSB0bzoNCg0KICAgMS4g
IHBlZXIgLT4gS0gtRFNVU1JLOiBJRGJpbmQocGVlciwgRUFQIFNlcnZlciwgS0gtRFNSSywgTm9u
Y2VBLCBJSyksDQogICAgICAgSURiaW5kKHBlZXIsIEtILURTUkssIEtILURTVVNSSywgTm9uY2VB
LCBEU0lLKQ0KICAgMi4gIEtILURTVVNSSyAtPiBLSC1EU1JLOiBJRGJpbmQocGVlciwgRUFQIFNl
cnZlciwgS0gtRFNSSywgTm9uY2VBLA0KICAgICAgIElLKSwgSURiaW5kKHBlZXIsIEtILURTUkss
IEtILURTVVNSSywgTm9uY2VBLCBEU0lLKQ0KICAgMy4gIEtILURTUksgLT4gS0gtRFNVU1JLOiBJ
RGJpbmQocGVlciwgS0gtRFNSSywgS0gtRFNVU1JLLCBOb25jZUErMSwNCiAgICAgICBEU0lLKSwg
S2V5VHJhbnNwb3J0KERTVVNSSykNCiAgIDQuICBLSC1EU1VTUksgLT4gcGVlcjogSURiaW5kKHBl
ZXIsIEtILURTUkssIEtILURTVVNSSywgTm9uY2VBKzEsDQogICAgICAgRFNJSykNCg0KICAgTm90
ZSB0aGF0IHRoZSBwZWVyIGRvZXNuJ3QgbmVlZCB0byBrbm93IGlmIHRoZSBLSC1EU1JLIGFscmVh
ZHkgaG9sZHMNCiAgIHRoZSBEU1JLLiAgVGhlIGluaXRpYWwgbWVzc2FnZSBpcyB0aGUgc2FtZS4N
Cg0KDQoNCg0KQ2xhbmN5ICAgICAgICAgICAgICAgICAgRXhwaXJlcyBPY3RvYmVyIDMxLCAyMDA3
ICAgICAgICAgICAgICAgIFtQYWdlIDVdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAg
ICAgSE9LRVkgUGxhbiAgICAgICAgICAgICAgICAgICAgIEFwcmlsIDIwMDcNCg0KDQogICBJZiBh
IHBhcnRpY3VsYXIgc2VydmljZSBkb2VzIG5vdCBuZWVkIHRoZSBzdHJvbmcgc2VjdXJpdHkgcHJv
cGVydGllcw0KICAgb2YgYSAzLXBhcnR5IGtleSBkaXN0cmlidXRpb24gcHJvdG9jb2wsIHRoZSBr
ZXkgaG9sZGVyIGlkZW50aXRpZXMgaW4NCiAgIHRoZSByZXF1ZXN0IGNhbiBiZSBOVUxMLCBwcm92
aWRlZCB0aGV5IGFyZSBjb3JyZWN0IGluIHRoZSByZXNwb25zZQ0KICAgcGFja2V0cy4gIFRoaXMg
cHJvdmlkZXMgYmFzaWMgY2hhbm5lbCBiaW5kaW5nIHByb3BlcnRpZXMsIGJ1dCBub3QNCiAgIHBl
ZXIgY29uc2VudC4gIEFsc28gYSBzZXJ2aWNlIG1heSBhbHNvIGVsZWN0IHRvIG5vdCB1c2UgdGhp
cyBwcm90b2NvbA0KICAgYXQgYWxsLiAgSXQncyBwcm92aWRlZCBhcyBhIHNldCBvZiBidWlsZGlu
ZyBibG9ja3Mgd2hlcmVieSBkaWZmZXJlbnQNCiAgIHNlcnZpY2VzIGNhbiB1c2UgYSBjb21tb24g
cHJvdG9jb2wgdG8gc2VjdXJlbHkgaW50ZXJhY3Qgd2l0aCBFTVNLcw0KICAgYW5kIERTUktzLg0K
DQogICBUaGUgcG9pbnQgb2YgdGhlIGFib3ZlIHByb3RvY29sIGV4YW1wbGUgd2FzIG5vdCB0byBw
cm92aWRlIGEgY29tcGxldGUNCiAgIGRlc2NyaXB0aW9uLCBidXQgaWxsdXN0cmF0ZSB3aGF0IG5l
ZWRzIHRvIGJlIGRlZmluZWQuICBJbiBwYXJ0aWN1bGFyLA0KICAgZm9ybWFsbHkgZGVmaW5pbmcg
c29tZXRoaW5nIGxpa2UgdGhlIElEYmluZCguKSBhbmQgS2V5VHJhbnNwb3J0KC4pDQogICBwcmlt
aXRpdmVzIGlzIG5lY2Vzc2FyeS4gIFRoZXNlIGJsb2JzIGNhbiB0aGVuIGJlIGNhcnJpZWQgYnkg
YW55DQogICB1bmRlcmx5aW5nIHByb3RvY29sLCBpbmNsdWRpbmcgSE9LRVkuDQoNCiAgIEN1cnJl
bnRseSBvbmx5IEVBUC1FUiBmb3JtYWxseSBzcGVjaWZpZXMgYSBwcm90b2NvbCBmb3IgZGVsaXZl
cmluZw0KICAgdGhlIEhSSyB0byB0aGUgSE9LRVkgc2VydmVyLiAgQ29uc2VxdWVudGx5IHNlY3Rp
b24gNi4yIG9mIHRoZSBFQVAtRVINCiAgIGRvY3VtZW50IFtJLUQudmlkeWEtZWFwLWVyXSB3aWxs
IHNlcnZlIGFzIGEgc3RhcnRpbmcgcG9pbnQgZm9yDQogICBkZXZlbG9wbWVudCBvZiB0aGlzIHBy
b3RvY29sLiAgSXQgc2hhbGwgYmUgZ2VuZXJhbGl6ZWQgdG8gd29yayBmb3IgYW4NCiAgIGFyYml0
cmFyeSBVU1JLIG9yIERTVVNSSywgYW5kIGFsc28gZGVmaW5lIHRoZSBJSyBhbmQgRFNJSyBpbiB0
ZXJtcyBvZg0KICAgdGhlIEtERiBzcGVjaWZpZWQgYnkgW0ktRC5pZXRmLWhva2V5LWVtc2staGll
cmFyY2h5XS4NCg0KDQo0LiAgSE9LRVkgUmUtQXV0aCBQcm90b2NvbCBEb2N1bWVudA0KDQogICBF
QVAtRVIgc2hhbGwgYmUgYWRvcHRlZCBhcyBhIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQgdG8gc2F0
aXNmeSB0aGUNCiAgIEhPS0VZIFJlLUF1dGggUHJvdG9jb2wgcmVxdWlyZW1lbnQsIHN1YmplY3Qg
dG8gYSB2YXJpZXR5IG9mIGNhdmVhdHM6DQoNCiAgIG8gIEl0cyBuYW1lIHNoYWxsIGJlIGNoYW5n
ZWQgdG8gdGhlIEhPS0VZIHByb3RvY29sLg0KICAgbyAgSXQgc2hhbGwgaW5jbHVkZSBzdXBwb3J0
IGZvciBjaGFubmVsIGJpbmRpbmdzIGJ5IGluY2x1ZGluZyB0aGUgTkFTDQogICAgICBJRCBvZiB0
aGUgYXV0aGVudGljYXRvciBhbmQgSUQgb2YgdGhlIEVBUCBzZXJ2ZXIgaW4gdGhlIGludGVncml0
eQ0KICAgICAgcHJvdGVjdGVkIHBvcnRpb25zIG9mIHRoZSBFQVAtRVIgcmVzcG9uc2UgZnJvbSB0
aGUgRUFQIHNlcnZlciB0bw0KICAgICAgdGhlIGF1dGhlbnRpY2F0b3IgYW5kIHBlZXIuICBSZXVz
aW5nIHRoZSBJRGJpbmQoLikgcHJpbWl0aXZlIGluDQogICAgICB0aGUgcHJldmlvdXMgcHJvdG9j
b2wgd291bGQgYmUgZGVzaXJhYmxlLg0KICAgbyAgQSBuZXcsIG9wdGlvbmFsIG1lc3NhZ2Ugc2hh
bGwgYmUgYWRkZWQgdG8gc3VwcG9ydCBhdXRoZW50aWNhdG9yLQ0KICAgICAgaW5pdGlhdGVkIHJl
LWF1dGhlbnRpY2F0aW9uLiAgVGhpcyBtZXNzYWdlIHNoYWxsIGJlIGdlbmVyYWxpemVkDQogICAg
ICBzdWNoIHRoYXQgaXQgaXMgYSAibmV3IiB2ZXJzaW9uIG9mIHRoZSBFQVAtUmVxdWVzdC9JZGVu
dGl0eS4NCiAgIG8gIFRoZSBFQVAtSW5pdGlhdGUvUmVhdXRoIHBhY2tldCBzaGFsbCBiZSBjb252
ZXJ0ZWQgaW50byBhICJuZXciDQogICAgICB2ZXJzaW9uIG9mIHRoZSBFQVAtUmVzcG9uc2UvSWRl
bnRpdHkuDQogICBvICBUaGUgRUFQLUZpbmlzaC9SZWF1dGggcGFja2V0IHNoYWxsIGJlIGNvbnZl
cnRlZCBpbnRvIGEgIm5ldyINCiAgICAgIHZlcnNpb24gb2YgdGhlIEVBUC1TdWNjZXNzLg0KDQog
ICBUaGVzZSAibmV3IiBwYWNrZXQgY29kZXMgc2hhbGwgYmUgZGVzaWduZWQgaW4gYSBnZW5lcmlj
IGZhc2hpb24sIHN1Y2gNCiAgIHRoYXQgdGhleSBjb3VsZCBiZSB1c2VkIGJ5IGZ1dHVyZSBFQVAg
ZXh0ZW5zaW9ucy4gIEZvciBleGFtcGxlLCB0aGUNCiAgIElkZW50aXR5IGNvZGVzIGNvdWxkIG5h
dGl2ZWx5IGluY2x1ZGUgbmV0d29yayBzZWxlY3Rpb24gaW5mb3JtYXRpb24sDQogICByYXRoZXIg
dGhhbiBlbWJlZGRpbmcgdGhlbSBpbnRvIHRoZSBwcm9tcHQgYW5kIGNsaWVudCBOQUkgZmllbGRz
Lg0KICAgVGhlICJuZXciIEVBUC1TdWNjZXNzIGNvdWxkIGluY2x1ZGUgbmF0aXZlIHN1cHBvcnQg
Zm9yIHByb3RlY3RlZA0KICAgcmVzdWx0cyBpbmRpY2F0aW9uLg0KDQoNCg0KQ2xhbmN5ICAgICAg
ICAgICAgICAgICAgRXhwaXJlcyBPY3RvYmVyIDMxLCAyMDA3ICAgICAgICAgICAgICAgIFtQYWdl
IDZdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgSE9LRVkgUGxhbiAgICAgICAg
ICAgICAgICAgICAgIEFwcmlsIDIwMDcNCg0KDQo1LiAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMN
Cg0KICAgVEJELg0KDQoNCjYuICBJQU5BIENvbnNpZGVyYXRpb25zDQoNCiAgIFRoaXMgZG9jdW1l
bnQgZG9lcyBub3QgaW50cm9kdWNlIGFueSBuZXcgSUFOQSBjb25zaWRlcmF0aW9ucy4NCg0KDQo3
LiAgUmVmZXJlbmNlcw0KDQo3LjEuICBOb3JtYXRpdmUgUmVmZXJlbmNlcw0KDQogICBbUkZDMjEx
OV0gIEJyYWRuZXIsIFMuLCAiS2V5IHdvcmRzIGZvciB1c2UgaW4gUkZDcyB0byBJbmRpY2F0ZQ0K
ICAgICAgICAgICAgICBSZXF1aXJlbWVudCBMZXZlbHMiLCBCQ1AgMTQsIFJGQyAyMTE5LCBNYXJj
aCAxOTk3Lg0KDQo3LjIuICBJbmZvcm1hdGl2ZSBSZWZlcmVuY2VzDQoNCiAgIFtJLUQuaWV0Zi1o
b2tleS1lbXNrLWhpZXJhcmNoeV0NCiAgICAgICAgICAgICAgU2Fsb3dleSwgSi4sICJTcGVjaWZp
Y2F0aW9uIGZvciB0aGUgRGVyaXZhdGlvbiBvZiBVc2FnZQ0KICAgICAgICAgICAgICBTcGVjaWZp
YyBSb290IEtleXMgKFVTUkspIGZyb20gYW4gIEV4dGVuZGVkIE1hc3RlciBTZXNzaW9uDQogICAg
ICAgICAgICAgIEtleSAoRU1TSykiLCBkcmFmdC1pZXRmLWhva2V5LWVtc2staGllcmFyY2h5LTAw
ICh3b3JrIGluDQogICAgICAgICAgICAgIHByb2dyZXNzKSwgSmFudWFyeSAyMDA3Lg0KDQogICBb
SS1ELm5ha2hqaXJpLWhva2V5LWhpZXJhcmNoeV0NCiAgICAgICAgICAgICAgTmFraGppcmksIE0u
LCAiS2V5aW5nIGFuZCBzaWduYWxpbmcgZm9yIHdpcmVsZXNzIGFjY2Vzcw0KICAgICAgICAgICAg
ICBhbmQgaGFuZG92ZXIgdXNpbmcgRUFQIChFQVAtSFIpIiwNCiAgICAgICAgICAgICAgZHJhZnQt
bmFraGppcmktaG9rZXktaGllcmFyY2h5LTA0ICh3b3JrIGluIHByb2dyZXNzKSwNCiAgICAgICAg
ICAgICAgQXByaWwgMjAwNy4NCg0KICAgW0ktRC5vaGJhLWhva2V5LTNwYXJ0eS1rZXlkaXN0LXBz
XQ0KICAgICAgICAgICAgICBPaGJhLCBZLiwgIlByb2JsZW0gU3RhdGVtZW50IGFuZCBSZXF1aXJl
bWVudHMgb24gYSAzLVBhcnR5DQogICAgICAgICAgICAgIEtleSBEaXN0cmlidXRpb24gUHJvdG9j
b2wgIGZvciBIYW5kb3ZlciBLZXlpbmciLA0KICAgICAgICAgICAgICBkcmFmdC1vaGJhLWhva2V5
LTNwYXJ0eS1rZXlkaXN0LXBzLTAxICh3b3JrIGluIHByb2dyZXNzKSwNCiAgICAgICAgICAgICAg
TWFyY2ggMjAwNy4NCg0KICAgW0ktRC52aWR5YS1lYXAtZXJdDQogICAgICAgICAgICAgIE5hcmF5
YW5hbiwgVi4gYW5kIEwuIERvbmRldGksICJFQVAgRXh0ZW5zaW9ucyBmb3INCiAgICAgICAgICAg
ICAgRWZmaWNpZW50IFJlLWF1dGhlbnRpY2F0aW9uIiwgZHJhZnQtdmlkeWEtZWFwLWVyLTAyICh3
b3JrDQogICAgICAgICAgICAgIGluIHByb2dyZXNzKSwgSmFudWFyeSAyMDA3Lg0KDQoNCg0KDQoN
Cg0KDQoNCg0KDQpDbGFuY3kgICAgICAgICAgICAgICAgICBFeHBpcmVzIE9jdG9iZXIgMzEsIDIw
MDcgICAgICAgICAgICAgICAgW1BhZ2UgN10NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAg
ICAgICBIT0tFWSBQbGFuICAgICAgICAgICAgICAgICAgICAgQXByaWwgMjAwNw0KDQoNCkF1dGhv
cidzIEFkZHJlc3MNCg0KICAgVC4gQ2hhcmxlcyBDbGFuY3kNCiAgIERvRCBMYWJvcmF0b3J5IGZv
ciBUZWxlY29tbXVuaWNhdGlvbiBTY2llbmNlcw0KICAgODA4MCBHcmVlbm1lYWQgRHJpdmUNCiAg
IENvbGxlZ2UgUGFyaywgTUQNCiAgIFVTQQ0KDQogICBFbWFpbDogY2xhbmN5QExUU25ldC5uZXQN
Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K
DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCkNsYW5jeSAgICAgICAgICAgICAgICAgIEV4cGly
ZXMgT2N0b2JlciAzMSwgMjAwNyAgICAgICAgICAgICAgICBbUGFnZSA4XQ0KDA0KSW50ZXJuZXQt
RHJhZnQgICAgICAgICAgICAgICAgIEhPS0VZIFBsYW4gICAgICAgICAgICAgICAgICAgICBBcHJp
bCAyMDA3DQoNCg0KRnVsbCBDb3B5cmlnaHQgU3RhdGVtZW50DQoNCiAgIENvcHlyaWdodCAoQykg
VGhlIElFVEYgVHJ1c3QgKDIwMDcpLg0KDQogICBUaGlzIGRvY3VtZW50IGlzIHN1YmplY3QgdG8g
dGhlIHJpZ2h0cywgbGljZW5zZXMgYW5kIHJlc3RyaWN0aW9ucw0KICAgY29udGFpbmVkIGluIEJD
UCA3OCwgYW5kIGV4Y2VwdCBhcyBzZXQgZm9ydGggdGhlcmVpbiwgdGhlIGF1dGhvcnMNCiAgIHJl
dGFpbiBhbGwgdGhlaXIgcmlnaHRzLg0KDQogICBUaGlzIGRvY3VtZW50IGFuZCB0aGUgaW5mb3Jt
YXRpb24gY29udGFpbmVkIGhlcmVpbiBhcmUgcHJvdmlkZWQgb24gYW4NCiAgICJBUyBJUyIgYmFz
aXMgYW5kIFRIRSBDT05UUklCVVRPUiwgVEhFIE9SR0FOSVpBVElPTiBIRS9TSEUgUkVQUkVTRU5U
Uw0KICAgT1IgSVMgU1BPTlNPUkVEIEJZIChJRiBBTlkpLCBUSEUgSU5URVJORVQgU09DSUVUWSwg
VEhFIElFVEYgVFJVU1QgQU5EDQogICBUSEUgSU5URVJORVQgRU5HSU5FRVJJTkcgVEFTSyBGT1JD
RSBESVNDTEFJTSBBTEwgV0FSUkFOVElFUywgRVhQUkVTUw0KICAgT1IgSU1QTElFRCwgSU5DTFVE
SU5HIEJVVCBOT1QgTElNSVRFRCBUTyBBTlkgV0FSUkFOVFkgVEhBVCBUSEUgVVNFIE9GDQogICBU
SEUgSU5GT1JNQVRJT04gSEVSRUlOIFdJTEwgTk9UIElORlJJTkdFIEFOWSBSSUdIVFMgT1IgQU5Z
IElNUExJRUQNCiAgIFdBUlJBTlRJRVMgT0YgTUVSQ0hBTlRBQklMSVRZIE9SIEZJVE5FU1MgRk9S
IEEgUEFSVElDVUxBUiBQVVJQT1NFLg0KDQoNCkludGVsbGVjdHVhbCBQcm9wZXJ0eQ0KDQogICBU
aGUgSUVURiB0YWtlcyBubyBwb3NpdGlvbiByZWdhcmRpbmcgdGhlIHZhbGlkaXR5IG9yIHNjb3Bl
IG9mIGFueQ0KICAgSW50ZWxsZWN0dWFsIFByb3BlcnR5IFJpZ2h0cyBvciBvdGhlciByaWdodHMg
dGhhdCBtaWdodCBiZSBjbGFpbWVkIHRvDQogICBwZXJ0YWluIHRvIHRoZSBpbXBsZW1lbnRhdGlv
biBvciB1c2Ugb2YgdGhlIHRlY2hub2xvZ3kgZGVzY3JpYmVkIGluDQogICB0aGlzIGRvY3VtZW50
IG9yIHRoZSBleHRlbnQgdG8gd2hpY2ggYW55IGxpY2Vuc2UgdW5kZXIgc3VjaCByaWdodHMNCiAg
IG1pZ2h0IG9yIG1pZ2h0IG5vdCBiZSBhdmFpbGFibGU7IG5vciBkb2VzIGl0IHJlcHJlc2VudCB0
aGF0IGl0IGhhcw0KICAgbWFkZSBhbnkgaW5kZXBlbmRlbnQgZWZmb3J0IHRvIGlkZW50aWZ5IGFu
eSBzdWNoIHJpZ2h0cy4gIEluZm9ybWF0aW9uDQogICBvbiB0aGUgcHJvY2VkdXJlcyB3aXRoIHJl
c3BlY3QgdG8gcmlnaHRzIGluIFJGQyBkb2N1bWVudHMgY2FuIGJlDQogICBmb3VuZCBpbiBCQ1Ag
NzggYW5kIEJDUCA3OS4NCg0KICAgQ29waWVzIG9mIElQUiBkaXNjbG9zdXJlcyBtYWRlIHRvIHRo
ZSBJRVRGIFNlY3JldGFyaWF0IGFuZCBhbnkNCiAgIGFzc3VyYW5jZXMgb2YgbGljZW5zZXMgdG8g
YmUgbWFkZSBhdmFpbGFibGUsIG9yIHRoZSByZXN1bHQgb2YgYW4NCiAgIGF0dGVtcHQgbWFkZSB0
byBvYnRhaW4gYSBnZW5lcmFsIGxpY2Vuc2Ugb3IgcGVybWlzc2lvbiBmb3IgdGhlIHVzZSBvZg0K
ICAgc3VjaCBwcm9wcmlldGFyeSByaWdodHMgYnkgaW1wbGVtZW50ZXJzIG9yIHVzZXJzIG9mIHRo
aXMNCiAgIHNwZWNpZmljYXRpb24gY2FuIGJlIG9idGFpbmVkIGZyb20gdGhlIElFVEYgb24tbGlu
ZSBJUFIgcmVwb3NpdG9yeSBhdA0KICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pcHIuDQoNCiAgIFRo
ZSBJRVRGIGludml0ZXMgYW55IGludGVyZXN0ZWQgcGFydHkgdG8gYnJpbmcgdG8gaXRzIGF0dGVu
dGlvbiBhbnkNCiAgIGNvcHlyaWdodHMsIHBhdGVudHMgb3IgcGF0ZW50IGFwcGxpY2F0aW9ucywg
b3Igb3RoZXIgcHJvcHJpZXRhcnkNCiAgIHJpZ2h0cyB0aGF0IG1heSBjb3ZlciB0ZWNobm9sb2d5
IHRoYXQgbWF5IGJlIHJlcXVpcmVkIHRvIGltcGxlbWVudA0KICAgdGhpcyBzdGFuZGFyZC4gIFBs
ZWFzZSBhZGRyZXNzIHRoZSBpbmZvcm1hdGlvbiB0byB0aGUgSUVURiBhdA0KICAgaWV0Zi1pcHJA
aWV0Zi5vcmcuDQoNCg0KQWNrbm93bGVkZ21lbnQNCg0KICAgRnVuZGluZyBmb3IgdGhlIFJGQyBF
ZGl0b3IgZnVuY3Rpb24gaXMgcHJvdmlkZWQgYnkgdGhlIElFVEYNCiAgIEFkbWluaXN0cmF0aXZl
IFN1cHBvcnQgQWN0aXZpdHkgKElBU0EpLg0KDQoNCg0KDQoNCkNsYW5jeSAgICAgICAgICAgICAg
ICAgIEV4cGlyZXMgT2N0b2JlciAzMSwgMjAwNyAgICAgICAgICAgICAgICBbUGFnZSA5XQ0KDA0K

------_=_NextPart_001_01C78AAA.CDB0C48F
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_001_01C78AAA.CDB0C48F--