eap Mailing List: RE: Re: m.getKey() and RFC 4137

[Narayanan, Vidya (vidyan]

> > Vidya said:
> > 
> > "I wonder if we are restricted in defining the behavior of the EMSK 
> > based on a spec that did not consider EMSKs to begin with? 
> It may be 
> > that we would conclude it is okay to pass the EMSK to the 
> AAA layer - 
> > but, should we be constrained by 4137 though?"
> > 
> > RFC 4137 treats keying material as a *structure* not a single 
> > variable, so that all the keying material and parameters 
> are passed to 
> > the lower layer at the same time.  This would not have been 
> necessary 
> > if the document only meant to deal with the MSK. Since RFC 4137 
> > references the key frame work document as well as RFC 3748, 
> it cannot 
> > be claimed that it was unaware of the key management 
> document, which 
> > until -09 included passing of the EMSK to the lower layer.
> > 
> [Joe] Awareness and having a good understanding of it are two 
> different things.  I think we have made much progress in 
> understanding in discussions since RFC 3748 (which reserves 
> the EMSK for future use) and RFC 4137 (which doesn't mention 
> the EMSK at all). 

Well, for that matter, RFC 4137 doesn't mention the MSK either :) 

> Basing a decision on what is loosely 
> captured in RFC 4137 would be short sighted.  I don't think 
> these documents should be interpreted as encourage or 
> discourage passing the EMSK to various places. 
> 

I agree with this though. If 4137 captured a snapshot that has been
revisited and evolved further, it doesn't seem reasonable to use that as
a baseline. What are the implications on existing implementations
because of this? Do we have a sense of that? 

Vidya