Hi Michaela,
M. Vanderveen wrote:
I agree with Lakshminath regarding the point about having actual
ciphersuites in a different RFC, so they can be updated.
I don't agree. Why would this be useful? You then have to read two
documents to implement the EAP method. It would be the same as putting
the packet format in another document.
New ciphersuites can be added later. They would be in a separate document.
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?
There was a discussion about this issue during today's meeting. There
was indeed tendency to avoid EAX usage and focus on CCM instead.
Ciao
Hannes
Michaela
*/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.
<http://us.rd.yahoo.com/evt=42241/*http://advision.webevents.yahoo.com/handraisers>
------------------------------------------------------------------------
_______________________________________________
Emu mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/emu
_______________________________________________
Emu mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/emu
