Subject: RE: [Hokeyp] [Emu] Re: MSK but no EMSK

Date: Fri, 17 Nov 2006 15:15:46 -0500

> Subject: Re: [Hokeyp] [Emu] Re: MSK but no EMSK
> 
> I happen to agree with Vidya on this.
> 
> It is not optional for new EAP methods to produce EMSK. 
> Whether EMSK gets used or not is totally besides the point.  
> (If we can conceive that EMSK would serve a need in some 
> distant future - we have to enforce its generation now. And 
> it is required by RFC 3748 :-)
> 
> What to do with the existing _old_ methods that aren't 
> compliant - I leave it for the group to decide.
> 
> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Narayanan, Vidya
> Sent: Thursday, November 16, 2006 9:35 PM
> To: Bernard Aboba; [email-masked]; [email-masked]
> Subject: Re: [Hokeyp] [Emu] Re: MSK but no EMSK
> 
> > 
> > It's worth keeping in mind that there are very few existing RFC 
> > 3748-compliant EAP implementations.  So most existing EAP method 
> > implementations do not generate an EMSK, and most existing EAP 
> > implementations would not do anything with the EMSK if it 
> were to be 
> > generated.
> > 
> 
> Well, the question is this - is the requirement to 
> interoperate with existing standards or existing 
> implementations? Given that we have a spec that says what it 
> does, it seems to make sense to interoperate with that. If we 
> are going by existing implementations, there is probably more 
> than one flavor and then there is the question of when the 
> MSK is directly delivered to the authenticator and when it 
> isn't and how the peer knows that. 
> 
> In this case, I tend to agree with Charles that it is better 
> to have to fix non-compliant implementations than try to 
> design around them. Also, if we choose to ignore the standard 
> and use the implementations that don't produce an EMSK as a 
> data point, the standard doesn't seem to be serving a purpose 
> then - perhaps, we should then consider revising
> RFC3748 to reflect what we want to use as a starting point 
> for requirements? 
> 
> Vidya
> _______________________________________________
> Hokeyp mailing list
> [email-masked]
> http://www.opendiameter.org/mailman/listinfo/hokeyp
> _______________________________________________
> Hokeyp mailing list
> [email-masked]
> http://www.opendiameter.org/mailman/listinfo/hokeyp
> 

_______________________________________________
Hokeyp mailing list
[email-masked]
http://www.opendiameter.org/mailman/listinfo/hokeyp

_______________________________________________
Emu mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/emu

---

From: "Blumenthal, Uri" <[email-masked]>
Date: Fri, 17 Nov 2006 09:22:04 -0500

>The discussion focuses on the problem EMSK is optional or mandatory.

I don't think this is a problem - GENERATION of EMSK is compulsoty as
spelled out in RFC 3578.

The problem is non-compliance. Some, er, people seem to think "the
standard says do A, but since I don't use A at the moment - I won't
bother."

>RFC3578 defined EMSK is mandatory, 

And that should be the end of discussion.

>                     but it is not used at all. 

First - do you know all the applications that use key-generating EAP
methods? But really - who cares? 

>If EMSK must be used, it is mandatory. if no, I think, 
>it may be better that it is optional.

VERY strongly disagree. Mandatory is what is explicitly specified as
mandatory, period. Otherwise many would implement just those pieces and
features of the standard that his particular product needs today.

(I'm proud of my restraint - not even once using a term "B*S*" :-)