Hi David,
thanks for your feedback.
If I read through it I get the impression that the IKEv2 selected
algorithms (as defined in RFC 4307) would not be allowed to go forward.
I wonder whether we put the bar a bit high here.
One might even get the impression that nobody read RFC 4307 before it
was published.
Ciao
Hannes
David McGrew schrieb:
Hi Hannes,
a few comments inline:
-----Original Message-----
From: Hannes Tschofenig [mailto:[EMAIL PROTECTED]
Sent: Tuesday, August 22, 2006 2:20 AM
To: M. Vanderveen
Cc: [email protected]
Subject: Re: [Emu] EAP-GPSK: Ciphersuites
Hi
let us for a moment assume that RFC 4307 makes some
reasonable algorithm choices (we are talking about IKEv2
here). If we take the text and apply it to EAP-GPSK then we
would produce something like:
Conservative Choice:
-----------------------
(Integrity)
AUTH_HMAC_SHA1_96 2 [RFC2404] MUST
(Encryption)
ENCR_3DES 3 [RFC2451] MUST-
I agree with Joe that AES is preferable to 3DES, barring some strong
legacy considerations.
(Key Derivation)
PRF_HMAC_SHA1 2 [RFC2104] MUST
If it is a goal to conform to FIPS-140-2, that goal will probably drive
the key derivation function choice in the direction of
http://www.ietf.org/internet-drafts/draft-dang-nistkdf-01.txt. (I
like HMAC as a KDF, but I am not confident that it is going to be
approved for that purpose within FIPS-140-2.)
(Note that there is no MUST for encryption algorithms specified in RFC
4307.)
Choice for the Future:
-----------------------
(Encryption)
ENCR_AES_CBC 12 [AES-CBC] SHOULD+
(Integrity)
AUTH_AES_XCBC_96 5 [AES-MAC] SHOULD+
OMAC is a better choice than XCBC, since it is FIPS-140 approved, and
has some minor advantages (it's a refinement of XCBC that is
unfortunately not backwards compatible with it).
(Key Derivation)
PRF_AES128_CBC 4 [AESPRF] SHOULD+
Same KDF considerations as above.
David
Does this sound like a terrible bad idea?
Ciao
Hannes
M. Vanderveen schrieb:
Both are pretty popular. Why not list them both? As for
which one to be
mandatory to implement, someone should to a search through
other systems
(e.g. IEEE, IPSec) and see which one is most popular.
*/Hannes Tschofenig <[EMAIL PROTECTED]>/* wrote:
Hi all,
the current version of the document
http://tools.ietf.org/wg/emu/draft-clancy-emu-eap-shared-secret-01.txt
still supports AES-EAX:
+-----------+----+-------------+---------------+--------------------+
| CSuite/ | KS | Encryption | Integrity | Key Derivation |
| Specifier | | | | Function |
+-----------+----+-------------+---------------+--------------------+
| 0x000001 | 16 | AES-EAX-128 | AES-CMAC-128 | GKDF-128 |
+-----------+----+-------------+---------------+--------------------+
At the IETF#66 EMU meeting AES CCM was suggested.
Later, it got the impression that AES-CBC was more
appreciated. Should
we update the draft with AES-CBC?
Ciao
Hannes
_______________________________________________
Emu mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/emu
--------------------------------------------------------------
----------
Do you Yahoo!?
Get on board. You're invited
<http://us.rd.yahoo.com/evt=40791/*http://advision.webevents.y
ahoo.com/handraisers>
to try the new Yahoo! Mail Beta.
_______________________________________________
Emu mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/emu
_______________________________________________
Emu mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/emu
