Hi Hannes,
On Aug 28, 2006, at 11:43 AM, Hannes Tschofenig wrote:
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.
I think that it comes down to unfortunate timing. XCBC was proposed
to NIST but not adopted by them when it got picked up by IKEv2;
afterwards, XCBC got improved into OMAC. I believe that IKEv2 re-
used HMAC as a KDF out of a desire for compatibility with IKEv1.
NIST SP 800-56 Sec. 5.3 mandates a hash-based KDF; NIST has made an
exception for IKE and TLS, allowing their use in FIPS-140 certified
crypto modules, but AFAICT this exception is specific to those
protocols, and would not apply to GPSK. (I would be happy to be
wrong on this point. If it is important, then let's ask the NIST
crypto folks.)
David
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