| Re: Strawman -10/EMSK deletion requirement? | <– Date –> <– Thread –> |
|
From: Rafa Marin Lopez (rafa |
|
| Date: Fri, 10 Mar 2006 08:11:33 -0800 (PST) | |
Hi Jari
will that decision between both cases be specified for application? or would it be better to select one approach (it seems people like second one)?
Regards.
First of all, I think this part of the discussion is largely justI agree on you this. In my mind the AAA server (where EAP server might be co-located) is (or should be) intelligent enough to manage keys from users.
a matter of vague definitions making it hard to make exact
statements. E.g. where is the line between AAA as a
"transport" and as an "application" that has intelligence
to make decisions and grant resources such as keys?
Just to repeat what we have already established, I thinkSo far, between EAP methods and AAA transpor layers (AAA server?? ) we have EAP authenticator layer and EAP layer. An as specified draft-ietf-eap-keying-10.txt both layers cannot cache anything. I think it does not preclude the use of EMSK but it establishes limits to the creation of AMSK. That is, the AMSK should be created just in the moment the EMSK is exported. If EMSK wants to be cached, that part of text should be relaxed, no?
we have consensus that (a) EMSK is generated by EAP
methods and that (b) its not going to be shipped away
to the access devices. In addition, it seems obvious that
the document we are discussing will not define how AMSKs
are used or transported.
So the conclusion is that the EMSK is kept somewhere
between the EAP method and AAA transport layers.
I would note that this means that it is, in an IETF sense,I have seen during discussions and also under my understanding of draft-aboba-eap-keying-extns-00.txt that either 1) AMSK would be tranported from AAA server to some entity or 2) AMSK could be used as a root and cached by the AAA server to derive new keys which would be eventually transported to different entities.
within a box and not transported via protocols. I don't
think it makes a lot of sense to debate too long about
what the internal structure of the box is. I'd be happy
saying that it resides in the EAP server. I would in
addition only say the following about the internal
module structures: The EMSK is not communicated
either to the lower layer or the AAA transport layer.
But AMSKs derived from it can be,
and that any such derivation would have to be defined
in future documents.
will that decision between both cases be specified for application? or would it be better to select one approach (it seems people like second one)?
Regards.
-- ------------------------------------------------------ Rafael Marin Lopez Faculty of Computer Science-University of Murcia 30071 Murcia - Spain Telf: +34968367645 e-mail: rafa [at] dif.um.es ------------------------------------------------------
- RE: Strawman -10/EMSK deletion requirement?, (continued)
- RE: Strawman -10/EMSK deletion requirement? Avi Lior, March 9 2006
- RE: Strawman -10/EMSK deletion requirement? Salowey, Joe, March 9 2006
-
RE: Strawman -10/EMSK deletion requirement? Avi Lior, March 9 2006
-
Re: Strawman -10/EMSK deletion requirement? Jari Arkko, March 10 2006
- Re: Strawman -10/EMSK deletion requirement? Rafa Marin Lopez, March 10 2006
- Re: Strawman -10/EMSK deletion requirement? : EAP peer/authenticator Rafa Marin Lopez, March 10 2006
- Re: Strawman -10/EMSK deletion requirement? Jari Arkko, March 12 2006
- Re: Strawman -10/EMSK deletion requirement? Rafa Marin Lopez, March 13 2006
- Re: Strawman -10/EMSK deletion requirement? Jari Arkko, March 14 2006
-
Re: Strawman -10/EMSK deletion requirement? Jari Arkko, March 10 2006
Results generated by Tiger Technologies using MHonArc.