From eapext-bounces@ietf.org Thu Jun 01 19:49:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Flwuz-0001J0-KK; Thu, 01 Jun 2006 19:49:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Flwuy-0001Iv-L4 for eapext@ietf.org; Thu, 01 Jun 2006 19:49:32 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Flwux-0005Bp-98 for eapext@ietf.org; Thu, 01 Jun 2006 19:49:32 -0400 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k51NnUmc031284 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 1 Jun 2006 16:49:30 -0700 Received: from NAEXBR02.na.qualcomm.com (naexbr02.qualcomm.com [10.46.92.109]) by crowley.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k51NnOYc013796 for ; Thu, 1 Jun 2006 16:49:29 -0700 (PDT) Received: from NAEX06.na.qualcomm.com ([129.46.135.160]) by NAEXBR02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Jun 2006 16:48:57 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 1 Jun 2006 16:48:56 -0700 Message-ID: <2EBB8025B6D1BA41B567DB32C1D8DB8490BDB4@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Charter/Motivation discussion Thread-Index: AcaF1fJM+ahU5VhaQX2SrvfBP3o5fg== From: "Narayanan, Vidya" To: X-OriginalArrivalTime: 01 Jun 2006 23:48:58.0012 (UTC) FILETIME=[F31FE5C0:01C685D5] X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Subject: [EAPEXT] Charter/Motivation discussion X-BeenThere: eapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: EAP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eapext-bounces@ietf.org Hi, It appears that we have quite a few folks on the list now. We would like to get people's comments on the charter and get a discussion going to see how many may be interested in this work and what people think are valuable vs not.=20 Please take a look at the charter and motivation and send your thoughts to the list. These can be found at=20 http://www.geocities.com/hellovidya/EAPExt_charter.txt http://www.geocities.com/hellovidya/EAPExt_motivation.txt Thanks, Vidya _______________________________________________ EAPEXT mailing list EAPEXT@ietf.org https://www1.ietf.org/mailman/listinfo/eapext From eapext-bounces@ietf.org Fri Jun 02 17:58:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmHf9-0005nl-Ji; Fri, 02 Jun 2006 17:58:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmHf8-0005ng-7F for eapext@ietf.org; Fri, 02 Jun 2006 17:58:34 -0400 Received: from mga02.intel.com ([134.134.136.20] helo=orsmga101-1.jf.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmHf6-0001mz-MJ for eapext@ietf.org; Fri, 02 Jun 2006 17:58:34 -0400 Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga101-1.jf.intel.com with ESMTP; 02 Jun 2006 14:58:29 -0700 Received: from orsmsx331.jf.intel.com (HELO orsmsx331.amr.corp.intel.com) ([192.168.65.56]) by orsmga001.jf.intel.com with ESMTP; 02 Jun 2006 14:56:27 -0700 X-IronPort-AV: i="4.05,205,1146466800"; d="scan'208"; a="45095102:sNHT17073834155" Received: from orsmsx416.amr.corp.intel.com ([10.22.226.46]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 2 Jun 2006 14:56:27 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 2 Jun 2006 14:56:26 -0700 Message-ID: <102A51607473A4449F0D3E2EF6FFCAD6391263@orsmsx416.amr.corp.intel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: EAP Extensions Work thread-index: AcaF/8GytlC2Jf6rSmOvoB7xGQY4sgASxFVA From: "Walker, Jesse" To: "Narayanan, Vidya" , "Blumenthal, Uri" , "Iyer, Prakash" X-OriginalArrivalTime: 02 Jun 2006 21:56:27.0293 (UTC) FILETIME=[65CBACD0:01C6868F] X-Spam-Score: 0.0 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Cc: eapext@ietf.org Subject: [EAPEXT] RE: EAP Extensions Work X-BeenThere: eapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: EAP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eapext-bounces@ietf.org Vidya, As per your request, here are some comments on the EAPEXT charter: 1. The second paragraph begins: ...for fast EAP re-authentication... Is there a better word than "fast?" When the server is remote, there may be nothing fast about the operation. And is it really re-authentication? In all of the designs I am aware of, the MSK and EMSK are ephemeral state used for authorization, not authentication; this ephemeral state used for authorization is a by-product of authentication. I would be happy with ...for reauthorization... instead. I would make the same kind of change throughout the charter. 2. The second paragraph concludes with: Channel binding ensures that the peer and the server have the same understanding about the network access server (NAS), including its identity, advertised capabilities and services. This has zero utility from a security perspective. The peer has no knowledge that the NAS is valid, but EAP provides it with a security relationship with the server. Similarly, the NAS has no knowledge that the peer is valid, but EAP presumes a security relationship between the NAS and the server. The one and only party in any position to attest to the NAS that the peer is valid is the server. Similarly, the one and only party that is in any position to vouch for the identity of the NAS to the peer is the server. So, this should read: Channel binding will be (re)defined to allow the server to attest to the peer identity to the NAS and to the NAS identity to the peer, plus (pick your favorite attributes here). People are likely to push back and say something like "No, Jesse, you don't understand. The NAS can be in a foreign domain and unknown to the NAS." In response I will say that no security relationship between the NAS and the peer is possible in such a case, because, since the server is explicitly assumed to not know anything about security posture of the NAS, it has absolutely no business distributing a key based on the peer's EMSK to the NAS. Distributing one of the peer's keys to the NAS presupposes a relationship between the NAS and the server that assures the server that the NAS is controlled by a known good guy instead of by Hackers-R-Us, i.e., that exposure of the peer's key to the NAS does not compromise the key. It also presupposes a channel between the NAS and the server that will not expose the key to any other party. People will complain about the word "any," but their complaint does not change the assumption made by EAP. There is an implication here that "defining and scoping channel binding as defined in the EAP keying framework" may not be the correct goal. If channel bindings is defined to support attestation by the server of the peer and the NAS identities to the NAS and the peer, then this is indeed correct. If channel bindings is not defined to support attestation of the NAS and peer identities to the peer and NAS, then it might be better to write "defining or extending channel binding as defined in the EAP keying framework." I think more discussion will be necessary to understand whether the channel bindings concept support the attestation needs, so the charter should not preclude the working group from doing work required to make security work. 3. Bullet 2 of the charter says Specification of EMSK usage. This specification will define the derivation of root keys from the EMSK for specific purposes. Since it is infeasible (and undesirable) to specify every possible usage, what is meant is probably more along the lines of Specification of rules governing EMSK usage. This specification will define guidelines governing the derivation of keys from the EMSK for specific applications. And why is Bullet 3 different from Bullet 2? Maybe I don't understand what Bullet 2 is really about. 4. Bullet 4 of the charter is a complete mystery to me. This Bullet alludes to three applications of the EMSK derivation, but does not provide even a summary motivation as to why these are important applications to consume the other work or why the EAPEXT Working Group is the appropriate home for this work. Yes, you're right; I should read the motivation document, but I think that experience amply shows there is a problem if the motivation for doing work is not immediately obvious from the charter. It is not at all evident why any of these three applications should fall within this group. Hopefully some of this will be helpful to you. Thanks. -- Jesse > -----Original Message----- > From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] > Sent: Thursday, June 01, 2006 9:48 PM > To: Blumenthal, Uri; Walker, Jesse; Iyer, Prakash > Cc: Dondeti, Lakshminath > Subject: EAP Extensions Work >=20 > Jesse, Prakash, Uri, > You may have seen the email that we had sent out on the creation of a > mailing list to discuss next steps on EAP keying (on the IETF mailing > list). We would very much like to get your input on the charter that we > have put together as next steps in this space. We would greatly > appreciate if you could share your thoughts on the list so that we can > have some technical decisions with input from people knowledgeable in > this space. >=20 > You can subsrcibe to the list via > https://www1.ietf.org/mailman/listinfo/eapext. >=20 > The charter and motivation can be found at: >=20 > http://www.geocities.com/hellovidya/EAPExt_charter.txt > http://www.geocities.com/hellovidya/EAPExt_motivation.txt >=20 > Thanks in advance for taking the time to provide any comments. >=20 > Regards, > Vidya _______________________________________________ EAPEXT mailing list EAPEXT@ietf.org https://www1.ietf.org/mailman/listinfo/eapext From eapext-bounces@ietf.org Fri Jun 02 21:31:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmKzP-0001hN-QD; Fri, 02 Jun 2006 21:31:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmKzP-0001cN-4v for eapext@ietf.org; Fri, 02 Jun 2006 21:31:43 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmKRP-0003K1-2d for eapext@ietf.org; Fri, 02 Jun 2006 20:56:35 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FmK8S-0005xV-Dg for eapext@ietf.org; Fri, 02 Jun 2006 20:37:03 -0400 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k530aw7C024662 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 2 Jun 2006 17:36:59 -0700 Received: from NAEXBR04.na.qualcomm.com (naexbr04.qualcomm.com [10.46.141.42]) by magus.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k530awd4011603; Fri, 2 Jun 2006 17:36:58 -0700 (PDT) Received: from NAEX06.na.qualcomm.com ([129.46.135.160]) by NAEXBR04.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Jun 2006 17:36:57 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 2 Jun 2006 17:36:56 -0700 Message-ID: <2EBB8025B6D1BA41B567DB32C1D8DB8490C033@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: EAP Extensions Work Thread-Index: AcaF/8GytlC2Jf6rSmOvoB7xGQY4sgASxFVAABTiXWA= From: "Narayanan, Vidya" To: "Walker, Jesse" , "Blumenthal, Uri" , "Iyer, Prakash" X-OriginalArrivalTime: 03 Jun 2006 00:36:57.0839 (UTC) FILETIME=[D20C5FF0:01C686A5] X-Spam-Score: -2.6 (--) X-Scan-Signature: 4b66a1e94d7d92973ece9e5da449ff80 Cc: eapext@ietf.org Subject: [EAPEXT] RE: EAP Extensions Work X-BeenThere: eapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: EAP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eapext-bounces@ietf.org Hi Jesse, Thank you very much for providing comments. Some comments/questions inline.=20 >=20 > Vidya, >=20 > As per your request, here are some comments on the EAPEXT charter: >=20 > 1. The second paragraph begins: >=20 > ...for fast EAP re-authentication... >=20 > Is there a better word than "fast?" When the server is=20 > remote, there may be nothing fast about the operation.=20 It was meant to be a relative term, really - it is true that server being remote introduces some delay - however, the full EAP exchange is too time consuming - so, in comparison with that, this is a faster process. So, I guess it goes to the definition of "fast" being subjective :) We will clarify what we really mean here. Also, the goal really is to allow this process to even be triggered ahead of time (like pre-authentication).=20 > And is=20 > it really re-authentication? > In all of the designs I am aware of, the MSK and EMSK are=20 > ephemeral state used for authorization, not authentication;=20 > this ephemeral state used for authorization is a by-product=20 > of authentication. I would be happy with >=20 > ...for reauthorization... >=20 > instead. I would make the same kind of change throughout the charter. >=20 Yes and no, actually. When the peer first performs the full EAP exchange, it is authenticated by the server (using the long term credential, for e.g.) and the MSK/EMSK are derived. The MSK provides proof to the authenticator that the peer is *authorized* for network access. In this sceanario itself, what you said is true that the MSK is used for authorization. Now, consider a key derived from the EMSK that the peer later uses to provide proof of possession to the server - that is still authentication. It is just that it doesn't go back to using the long term credential to provide this proof - hence, it avoids having to execute the EAP method again, leading to faster operation. As a result of this subsequent authentication, a key will be handed out to the new authenticator, the key potentially being derived also from the EMSK.=20 Does that make sense?=20 > 2. The second paragraph concludes with: >=20 > Channel binding ensures that the peer and the server have the > same understanding about the network access server (NAS), including > its > identity, advertised capabilities and services. >=20 > This has zero utility from a security perspective. The peer=20 > has no knowledge that the NAS is valid, but EAP provides it=20 > with a security relationship with the server. Similarly, the=20 > NAS has no knowledge that the peer is valid, but EAP presumes=20 > a security relationship between the NAS and the server. The=20 > one and only party in any position to attest to the NAS that=20 > the peer is valid is the server. Similarly, the one and only=20 > party that is in any position to vouch for the identity of=20 > the NAS to the peer is the server. So, this should read: >=20 > Channel binding will be (re)defined to allow the server=20 > to attest to > the peer identity to the NAS and to the NAS identity to=20 > the peer, plus > (pick your favorite attributes here). >=20 I agree with the above. Actually, what you said was exactly what was intended to be said - as a result of that attestation by the server, the peer and the server now have a common understanding of the NAS identity. But, re-wording as you say is fine with me.=20 > People are likely to push back and say something like "No,=20 > Jesse, you don't understand. The NAS can be in a foreign=20 > domain and unknown to the NAS." In response I will say that=20 > no security relationship between the NAS and the peer is=20 > possible in such a case, because, since the server is=20 > explicitly assumed to not know anything about security=20 > posture of the NAS, it has absolutely no business=20 > distributing a key based on the peer's EMSK to the NAS.=20 > Distributing one of the peer's keys to the NAS presupposes a=20 > relationship between the NAS and the server that assures the=20 > server that the NAS is controlled by a known good guy instead=20 > of by Hackers-R-Us, i.e., that exposure of the peer's key to=20 > the NAS does not compromise the key. It also presupposes a=20 > channel between the NAS and the server that will not expose=20 > the key to any other party. People will complain about the=20 > word "any," but their complaint does not change the=20 > assumption made by EAP. >=20 I more or less agree with the above - in the view of EAP, the NAS and the server must have a security relationship. Now, AAA extends that to a hop-by-hop security model, by introducing proxies along the way. That is an accepted model today and is essential for practical deployment. This hop-by-hop model of AAA may have an impact on how channel binding is actually achieved and that requires a lot more discussion. =20 > There is an implication here that "defining and scoping=20 > channel binding as defined in the EAP keying framework" may=20 > not be the correct goal. If channel bindings is defined to=20 > support attestation by the server of the peer and the NAS=20 > identities to the NAS and the peer, then this is indeed=20 > correct. If channel bindings is not defined to support=20 > attestation of the NAS and peer identities to the peer and=20 > NAS, then it might be better to write "defining or extending=20 > channel binding as defined in the EAP keying framework." I=20 > think more discussion will be necessary to understand whether=20 > the channel bindings concept support the attestation needs,=20 > so the charter should not preclude the working group from=20 > doing work required to make security work. >=20 We'll re-word to clarify this. But, I do believe that a lot more discussion needs to happen before we know how to best do channel binding (and whether it even buys anything). The purpose of including channel binding in the charter is strictly to define it; any solutions, if needed, will come after re-chartering. =20 > 3. Bullet 2 of the charter says >=20 > Specification of EMSK usage. This specification will define the > derivation of root keys from the EMSK for specific purposes. >=20 > Since it is infeasible (and undesirable) to specify every=20 > possible usage, what is meant is probably more along the lines of >=20 > Specification of rules governing EMSK usage. This=20 > specification will > define guidelines governing the derivation of keys from=20 > the EMSK for > specific applications. >=20 The specification is actually intended to be a framework for EMSK-derived keys. How about this - "Specification of rules govering EMSK usage. This specification will provide a framework for the derivation of root keys from the EMSK for specific purposes." > And why is Bullet 3 different from Bullet 2? Maybe I don't=20 > understand what Bullet 2 is really about. > Perhaps this will clarify - "An informational document with a template on how to write specifications on the derivation and the distribution of keys from the root keys of the EMSK hierachy." Please note that Bullet 2 refers to the derivation of the first level keys (called root keys) from the EMSK, while Bullet 3 talks about providing guidelines for key derivations thereof. =20 =20 > 4. Bullet 4 of the charter is a complete mystery to me. This=20 > Bullet alludes to three applications of the EMSK derivation,=20 > but does not provide even a summary motivation as to why=20 > these are important applications to consume the other work or=20 > why the EAPEXT Working Group is the appropriate home for this=20 > work. Yes, you're right; I should read the motivation=20 > document, but I think that experience amply shows there is a=20 > problem if the motivation for doing work is not immediately=20 > obvious from the charter. It is not at all evident why any of=20 > these three applications should fall within this group. >=20 Yes, the motivation does discuss the need for this work. To summarize - the EMSK is likely to be used for disparate purposes. Hence, the goal is to derive a root key (called usage specific root key) for each specific purpose from the EMSK. We have identified three usages that need to be currently addressed - fast re-authentication (pending terminology agreement :)), access to one or more home network services and access to one or more visited network services.=20 > Hopefully some of this will be helpful to you. Thanks. >=20 Yes, and thanks again.=20 Regards, Vidya > -- Jesse >=20 > > -----Original Message----- > > From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] > > Sent: Thursday, June 01, 2006 9:48 PM > > To: Blumenthal, Uri; Walker, Jesse; Iyer, Prakash > > Cc: Dondeti, Lakshminath > > Subject: EAP Extensions Work > >=20 > > Jesse, Prakash, Uri, > > You may have seen the email that we had sent out on the=20 > creation of a=20 > > mailing list to discuss next steps on EAP keying (on the=20 > IETF mailing=20 > > list). We would very much like to get your input on the charter that > we > > have put together as next steps in this space. We would greatly=20 > > appreciate if you could share your thoughts on the list so=20 > that we can=20 > > have some technical decisions with input from people=20 > knowledgeable in=20 > > this space. > >=20 > > You can subsrcibe to the list via > > https://www1.ietf.org/mailman/listinfo/eapext. > >=20 > > The charter and motivation can be found at: > >=20 > > http://www.geocities.com/hellovidya/EAPExt_charter.txt > > http://www.geocities.com/hellovidya/EAPExt_motivation.txt > >=20 > > Thanks in advance for taking the time to provide any comments. > >=20 > > Regards, > > Vidya >=20 _______________________________________________ EAPEXT mailing list EAPEXT@ietf.org https://www1.ietf.org/mailman/listinfo/eapext From eapext-bounces@ietf.org Tue Jun 20 17:49:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fso5w-0005ko-4e; Tue, 20 Jun 2006 17:49:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fso5u-0005ke-Os for eapext@ietf.org; Tue, 20 Jun 2006 17:49:10 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fso5r-00058j-DY for eapext@ietf.org; Tue, 20 Jun 2006 17:49:10 -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 k5KLmjBt032274 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 20 Jun 2006 14:48:46 -0700 Received: from NAEXBR02.na.qualcomm.com (naexbr02.qualcomm.com [10.46.92.109]) by neophyte.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5KLfTMx004974; Tue, 20 Jun 2006 14:48:44 -0700 (PDT) Received: from NAEX06.na.qualcomm.com ([129.46.135.160]) by NAEXBR02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Jun 2006 14:48:31 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 20 Jun 2006 14:48:24 -0700 Message-ID: <2EBB8025B6D1BA41B567DB32C1D8DB84A1DD5D@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: EAPExt Problem Statement I-D Thread-Index: AcaUs0Gjq2+IeByDS7WZ8VqkTzP9CA== From: "Narayanan, Vidya" To: X-OriginalArrivalTime: 20 Jun 2006 21:48:31.0713 (UTC) FILETIME=[45C36D10:01C694B3] X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: Sam Hartman , Russ Housley , Bernard Aboba , jari.arkko@piuha.net, smb@cs.columbia.edu Subject: [EAPEXT] EAPExt Problem Statement I-D X-BeenThere: eapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: EAP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eapext-bounces@ietf.org All, We have submitted a problem statement on the proposed EAP extensions work. The draft can be found at http://www.ietf.org/internet-drafts/draft-dondeti-eapext-ps-00.txt.=20 Comments welcome.=20 Thanks, Vidya _______________________________________________ EAPEXT mailing list EAPEXT@ietf.org https://www1.ietf.org/mailman/listinfo/eapext From eapext-bounces@ietf.org Tue Jun 20 17:54:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsoBW-0005YD-7x; Tue, 20 Jun 2006 17:54:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsoBU-0005XF-Fs for eapext@ietf.org; Tue, 20 Jun 2006 17:54:56 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsoBT-0006Ej-3C for eapext@ietf.org; Tue, 20 Jun 2006 17:54:56 -0400 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5KLopUq004887 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 20 Jun 2006 14:50:53 -0700 Received: from NAEXBR03.na.qualcomm.com (naexbr03.qualcomm.com [129.46.134.172]) by crowley.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5KLocLD011562; Tue, 20 Jun 2006 14:50:50 -0700 (PDT) Received: from NAEX06.na.qualcomm.com ([129.46.135.160]) by NAEXBR03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Jun 2006 14:50:12 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 20 Jun 2006 14:50:07 -0700 Message-ID: <2EBB8025B6D1BA41B567DB32C1D8DB84A1DD5F@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D on EAP Extensions for Efficient Re-authentication Thread-Index: AcaUs0Gjq2+IeByDS7WZ8VqkTzP9CAAAAcBw From: "Narayanan, Vidya" To: X-OriginalArrivalTime: 20 Jun 2006 21:50:12.0854 (UTC) FILETIME=[820C5160:01C694B3] X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: Sam Hartman , Russ Housley , Bernard Aboba , jari.arkko@piuha.net, smb@cs.columbia.edu Subject: [EAPEXT] I-D on EAP Extensions for Efficient Re-authentication X-BeenThere: eapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: EAP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eapext-bounces@ietf.org All, A draft on EAP Extensions for Efficient Re-authentication can be found at http://www.ietf.org/internet-drafts/draft-vidya-eap-er-00.txt.=20 Please review and provide any comments you have.=20 Thanks, Vidya _______________________________________________ EAPEXT mailing list EAPEXT@ietf.org https://www1.ietf.org/mailman/listinfo/eapext