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 <[EMAIL PROTECTED]> wrote:
Lakshminath Dondeti <[EMAIL PROTECTED]> 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.
_______________________________________________ Emu mailing list [email protected] https://www1.ietf.org/mailman/listinfo/emu
