List Info

Thread: m.getKey() and RFC 4137
m.getKey() and RFC 4137
user name
 2006-03-18 02:15:02 

  


  

    Ryan,

This is valuable input. This unfortunately, is a practical 
limitation. 


 


Re-reading RFC 3748, I guess it really says "it (the EMSK) MUST NOT be transported to, or shared with, 
additional parties, or used to derive any other keys." So, it doesn't say 
anywhere that the EMSK MUST NOT be transported to a lower layer per say. 



 


I guess we cannot really blame RFC 4137 alone ;for what it says 
then ; 


 


We could go down the path that RFC 4137 is an informational RFC and must 
technically not have a bearing on a standards track document - but, 
practical problems supercede that anyway. 


 


It does make the specification a bit sticky with respect to EMSKs now - 
it should be the EAP layer keeping the EMSK (caching if needed) and generating 
the AMSKs out of it. If the EMSK is transported to the AAA layer, it 
doesn't seem to make sense that the AAA layer would be deriving any AMSKs. 



 


We could say that the EMSK is transported along with the MSK to the AAA 
layer in today's implementations, but the EAP layer must maintain a copy of the 
EMSK in order to derive AMSKs from it - but, then, this obviously violates the 
fact that transported keys must be deleted. If we are willing to relax that 
requirement (and add text about the fact that the AAA layer MUST delete the EMSK 
immediately), there may be a way forward. But, I'm not convinced that this 
is the right approach. 


 


Vidya




  

  

  From: Ryan Hurst 
  [mailto:Ryan.Hurstmicrosoft.com] 
Sent: Friday, March 17, 2006 4:32 
  PM
To: eapfrascone.com
Subject: [eap] Re: m.getKey() and 
  RFC 4137


  

  
Vidya - RFC 4137 has been out of last call for nearly 18 
  months and we (Microsoft) have completed a implementation based on it, we 
  already have partners integrating with it.

  
 

  
We are not the only ones, it has also been integrated with 
  other link layers such as IEEE 802.1X-2004, IEEE 802.11i, etc.

  
 

  
I even understand UNH is also going to be building a test 
  sure around 4137 (http://www.iol.unh.edu/).

  
 

  
Simply put proposed changes would ;result 
  in significant changes to these existing standards, that would not only 
  would negate the progress that has been achieved through this working group it 
  would also create confusion in the market and likely cost the industry 
  billions of dollars.

  
If there is in-fact a need for these new 
  capabilities the existing standards are not the place to incorporate 
  them.

  
Ryan M. 
Hurst

  

  
  
   
     
    






 [1]











   
 





about | contact  Other archives ( Real Estate discussion Medical topics )