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

Reply via email to