[Ipsec] RE: Question / Remark on PRF/MAC in IKEv2 draft-spec (repeat)

I don't know why your message was blocked from the ipsec list. Hopefully my reply will make it and I've included your note below.

In answer to your questions:

1) Yes, the label PRF_AES128_CBC in IKEv2 is inconsistent with the label used for the same PRF function in RFC3664 where it is called AES-XCBC-PRF-128. Part of this is because the IKEv2 document always puts the algorithm type as the first element of the name (in this case PRF). But it seems potentially confusing (to say the least) to have the IKEv2 spec say CBC while RFC3664 says XCBC since these imply different algorithms.

I believe the intent was to use the XCBC algorithm and that the IKEv2 spec is in error. I propose changing the IKEv2 spec during AUTH48 to specify PRF_AES128_XCBC to reduce possible confusion. The IKEv2 already refers to RFC3664 for the definition of the algorithm.

2) The current spec says that when using shared keys the AUTH payload is computed using the negotiated PRF algorithm. One could argue that it would be cryptographically preferable to do the outer computation with the negotiated MAC algorithm rather than the negotiated PRF algorithm, but I don't believe there are any weaknesses introduced by using the PRF so I don't believe it should be changed at this late date given that there are working implementations that such a change would break.

Paul... can you confirm that PRF is what the implementations in the bakeoff used?

	--Charlie

________________________________________
From: ventzislav.nikov@philips.com [mailto:ventzislav.nikov@philips.com] 
Sent: Thursday, March 10, 2005 2:01 AM
To: ipsec@lists.tislabs.com; Charlie Kaufman
Subject: Question / Remark on PRF/MAC in IKEv2 draft-spec (repeat)

Hello, 

I send again the mail from 28.02.05 sent to ipsec@ietf.org which is still waiting for the approval ?!? 
--------------- 
Your mail to 'Ipsec' with the subject

   Question / Remark on PRF/MAC in IKEv2 draft-spec

Is being held until the list moderator can review it for approval. 
----------------- 

1)
In the draft-ietf-ipsec-ikev2-xx the PRF (pseudo random function) is specified to has tag: 
PRF_AES128_CBC (referring to RFC3664), but in RFC 3664 it is 
"The AES-XCBC-PRF-128 Algorithm for the IKE". 
So it is not CBC but XCBC right?

2) 
In Section 2.15 "Authentication of the IKE_SA" the AUTH field is explained. 
First the document states that the signature or MAC is computed over a <text> with a <key>. 
In case the key is symmetric (e.g. derived from EAP-SIM subprotocol into IKEv2) the document states that 
AUTH = prf(prf(<key>,"Key Pad for IKEv2"), <text>) i.e. 
deciphered it is NewKey = prf(<key>,"Key Pad for IKEv2") and then AUTH = prf(NewKey, <text>). 
But what I expected instead is AUTH = MAC(NewKey, <text>). 

Note that there is subtle difference between PRF and MAC as cryptographic functions from one side and 
from other side (practical) even the algorithms are the same (e.g. HMAC-MD5, HMAC-SHA1, AES-XCBC) 
MAC is always truncated to 96 bits! 

So, could you confirm that AUTH is computed using MAC instead of PRF? 

Regards 
Ventzislav Nikov

_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec