Re: [Emu] Review of draft-clancy-emu-eap-shared-secret-01

I agree with Lakshminath regarding the point about having actual ciphersuites in a different RFC, so they can be updated. 

  Personally I'm somewhat disappointed that AES-EAX was chosen, even though it's fame is that is simpler than CCM, which is what 802.11i proposes. Not having participated in the discussions on algorithm selection, I am wondering if anybody have given thought to what can be done to help the power and memory-limited mobile, who now has to have *hardware* to please everybody: the EAP for network access, SAP 4-way handshake for link-layer access, MobileIP for mobility, VPN to sooothe operator concerns, etc, to name a few possibilities. Not all of these must be done in hw, of course. What do the implementors have to say about these?

  Michaela

Lakshminath Dondeti <ldondeti@qualcomm.com> wrote:
  >
> EAP-GPSK offers cryptographic flexibility. At the beginning, the
> EAP server selects a set of cryptographic algorithms and key
> sizes, a so called ciphersuite. The current version of EAP-GPSK
> comprises two ciphersuites, but additional ones can be easily
> added.

Do we mean server proposes a suite of algms and the client selects 
one? We probably need to think about the ciphersuite thing a 
bit. Perhaps the IKEv2 like approach of the base protocol nailed 
down in a document and have a "living" RFC that updates ciphersuites 
as necessary.

---------------------------------
Do you Yahoo!?
 Next-gen email? Have it all with the  all-new Yahoo! Mail Beta.