Subject: [Ipsec] RE:

From: Magnus Alström <[email-masked]>
Date: Mon, 3 Jan 2005 10:32:24 +0100 (CET)

Hi Tero,

Thanks for the comments. I guessed that the sign operation should be a hash+sign operation, but the question is still how the hashing should be performed. There is a prf function negotiated, but no hash algorithm. Should I take the data and create a hmac? Or should I take whatever algorithm I prefer and encode the digest to a der-encoded digest-info before I sign?  

regards Magnus

----- Original Message -----

Datum: Thu, 30 Dec 2004 11:47:43 +0200

Från: Tero Kivinen <[email-masked]>

Till:  Magnus Alström <[email-masked]>

Cc:  [email-masked]

Ämne: [Ipsec] IKEv2

Magnus Alström writes:

> 1.3 The CREATE_CHILD_SA Exchange

> In the CHILD_SA created as part of the initial exchange, a second KE

> payload and nonce MUST NOT be sent. The result is that the CHILD_SA

> will always use the same DH group (or none). Should you not be

> allowed to use different groups? 

No. There is no point of using different group there. In quite many

cases this CHILD_SA will also be the only SA created. Having only one

group there and only one DH calculation simplifies the protocol and

reduces calculation overhead.

> 2.15. Authentication of the IKE_SA (2.15)

> According to the draft should the authentication data be created by

> appending: <message>, <nonce_x> and <prf(SK_px,id_x)>. As a result

> will the complete data to be signed be quite large, of course

> depending on the original message. How are that signature supposed

> to be created?

Signing includes the normal phase of the calculating hash over the

data before actually signing it. The old IKEv1 method of signing the

already calculated digest caused some problems, as there is hardware

implementation and APIs which only allow hash+sign, and do not offer

any raw signing operations. So IKEv2 uses normal hash+sign operation. 

> 2.23 NAT Traversal 

> You are supposed to send the NAT_DETECTION payloads in the first

> IKE_SA_INIT exchange and are also supposed to add the payloads

> before CERT_REQ payload. The CERT_REQ payload is part of the

> IKE_SA_INIT exchange for responder and the following IKE_AUTH

> exchange for initiator.

The location of the NAT_DETECTION payload is after the Ni and Nr

payloads (and if there is CERTREQ in the responder IKE_SA_INIT then it

is between Nr and CERTREQ). There is no CERTREQ in the initiator

IKE_SA_INIT packet, so the location is after Ni.

I.e:

       Initiator                          Responder

      -----------                        -----------

       HDR, SAi1, KEi, Ni,

	    N(NAT_DETECTION_DESTINATION_IP),

	    N(NAT_DETECTION_SOURCE_IP), 

	    [N(NAT_DETECTION_SOURCE_IP) ...] -->

                            <--    HDR, SAr1, KEr, Nr,

					N(NAT_DETECTION_DESTINATION_IP),

					N(NAT_DETECTION_SOURCE_IP), 

					[N(NAT_DETECTION_SOURCE_IP) ...],

					[CERTREQ]

I.e. there is exactly one NAT_DETECTION_DESTINATION_IP payload, and

then one or more NAT_DETECTION_SOURCE_IP notifications. The draft does

not specify the order of the destination and source IP payloads, but I

used the same order that is used in the rfc3947 (IKEv1 NAT-T). 

> The NAT_DETECTION payloads should include the SPIs, but the

> initiator will not know the responder spi until the first message is

> received. When are the NAT_DETECTION payloads supposed to be

> transmitted?

The initiator will use responder SPIr of 0 when sending its own

notifications (i.e the exactly same SPI it puts in the IKE_SA_INIT

packet where it is sending this notification. The responder will use

the same when checking the values sent by the initiator, but it will

then use both SPIs when sending its own reply packet. I agree this is

not perhaps very clear from the draft, and reason for this is that

there is fewer round trips in the IKEv1 than what was in the main mode

of the IKEv1 (where the payloads appeared in the 3rd and 4th packet

(2nd round trip)).

On the other hand we do not want to complicate the protocol

description by defining the NAT_DETECTION_* payloads differently

depending whether they are sent by the initiator or responder (i.e.

say that skip SPIr in the initiators NAT_DETECTION_* payloads, now we

include SPIr, but use value of 0). 

> 3.6 Certificate payload

> Why is it a MUST requirement to send and receive first two Hash and

> URL formats. To add http lookup in a minimal implementation seems to

> be quite unneccessary. 

This is trying to enforce that even minimal implementations can work

even when you cannot send large enough UDP packets which could hold

certificates. 

-- 

[email-masked]

_______________________________________________
Ipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipsec