| Re: EAP WG agenda (updated) | <– Date –> <– Thread –> |
|
From: Mayumi Yanagiya (yanagiya.mayumi |
|
| Date: Tue, 8 Nov 2005 06:14:01 -0500 (EST) | |
Thank you for your reply.
>
>> Hi,
>>
>> I can’t attend this meeting. Could I ask a question about “Keying
>> Extensions” on this list?
>>
>> In that draft, it is specified that only EAP entities can use EAP keys
>> for authentication. But, I think that it will be useful to extend EAP
>> key framework to non-EAP entities such as HA which may use non-EAP
>> authentication method.
>>
>> Are there any problems if we apply EAP key framework to non-EAP entities?
>
>
>
> Its hard to give an answer without talking about the specific keys
> in question. I hope the draft is clear that long-term secrets, MKs,
> TEKs, MSKs, EMSKs are indeed only for specific EAP entities.
> Having said that, I see no reason to prohibit the use of AMSKs
> or even TSKs in a wider context, e.g., the delivery of keys delivered
> from AMSKs for some fast-handoff entity that did not do EAP.
> Of course, such usage would have to be well designed to
> avoid problems and make sense from other points of view,
> but there should not be any fundamental reason to prevent
> this in the EAP keying framework.
I intended to discuss about AMSKs and TSKs usage.
I’m very happy to hear that there is no problem to use AMSK for non-EAP entity. I’ve submitted a draft about this concept in order to reduce pre-setting of authentication information (It has been expired). And, I read that mip6 ML have started discussion about usage of AMSK for mipv6 bootstrapping.
Originally, AMSK was defined in the key framework draft as appendix, wasn’t it? I haven't caught up the reason why the specification of AMSK is separated from main key framework draft.
--Mayumi
>
>> Hi,
>>
>> I can’t attend this meeting. Could I ask a question about “Keying
>> Extensions” on this list?
>>
>> In that draft, it is specified that only EAP entities can use EAP keys
>> for authentication. But, I think that it will be useful to extend EAP
>> key framework to non-EAP entities such as HA which may use non-EAP
>> authentication method.
>>
>> Are there any problems if we apply EAP key framework to non-EAP entities?
>
>
>
> Its hard to give an answer without talking about the specific keys
> in question. I hope the draft is clear that long-term secrets, MKs,
> TEKs, MSKs, EMSKs are indeed only for specific EAP entities.
> Having said that, I see no reason to prohibit the use of AMSKs
> or even TSKs in a wider context, e.g., the delivery of keys delivered
> from AMSKs for some fast-handoff entity that did not do EAP.
> Of course, such usage would have to be well designed to
> avoid problems and make sense from other points of view,
> but there should not be any fundamental reason to prevent
> this in the EAP keying framework.
I intended to discuss about AMSKs and TSKs usage.
I’m very happy to hear that there is no problem to use AMSK for non-EAP entity. I’ve submitted a draft about this concept in order to reduce pre-setting of authentication information (It has been expired). And, I read that mip6 ML have started discussion about usage of AMSK for mipv6 bootstrapping.
> One current issue that is preventing this in practise, however, > is that -08 does not define the AMSKs. My suggestion would be > to define it, which would allow usage of AMSKs (with the good > design) without the need for EAP WG to respin the keying > framework document or add new extensions.
Originally, AMSK was defined in the key framework draft as appendix, wasn’t it? I haven't caught up the reason why the specification of AMSK is separated from main key framework draft.
--Mayumi
> --Jari > > >
-
EAP WG agenda (updated) Jari Arkko, November 4 2005
-
Re: EAP WG agenda (updated) Mayumi Yanagiya, November 6 2005
-
Re: EAP WG agenda (updated) Jari Arkko, November 7 2005
- Re: EAP WG agenda (updated) Mayumi Yanagiya, November 8 2005
-
Re: EAP WG agenda (updated) Jari Arkko, November 7 2005
-
Re: EAP WG agenda (updated) Mayumi Yanagiya, November 6 2005
Results generated by Tiger Technologies using MHonArc.