Re: EAP WG agenda (updated)
From: Mayumi Yanagiya (yanagiya.mayumilab.ntt.co.jp)
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.


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



Results generated by Tiger Technologies using MHonArc.