Subject: [Ipsec] Committing State to an SA

From: David Wierbowski <[email-masked]>
Date: Thu, 16 Aug 2007 22:19:18 -0400

Appendix A of RFC 4306 states:
7) To increase robustness by allowing the responder to not do
   significant processing until it receives a message proving that the
   initiator can receive messages at its claimed IP address, and not
   commit any state to an exchange until the initiator can be
   cryptographically authenticated;

Can somebody explain how the responder can defer committing any state to an
exchange until the initiator is cryptographically authenticated?

The initiator is cryptographically authenticated during the IKE_AUTH
exchange.  RFC 4718 (and draft-hoffman-ikev2bis-01.txt) define the
ResponderSignedOctets as:

   ResponderSignedOctets = RealMessage2 | NonceIData | MACedIDForR
   GenIKEHDR = [ four octets 0 if using port 4500 ] | RealIKEHDR
   RealIKEHDR =  SPIi | SPIr |  . . . | Length
   RealMessage2 = RealIKEHDR | RestOfMessage2
   NonceIPayload = PayloadHeader | NonceIData
   ResponderIDPayload = PayloadHeader | RestOfIDPayload
   RestOfRespIDPayload = IDType | RESERVED | InitIDData
   MACedIDForR = prf(SK_pr, RestOfRespIDPayload)

This implies the responder must save state prior to receiving the IKE_AUTH
exchange.  Specifically it must save some state involving the initiator's
nonce and the IKE_SA_INIT response sent.

Dave Wierbowski

z/OS Comm Server Developer

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

---

From: <[email-masked]>
Date: Fri, 17 Aug 2007 09:15:50 +0300

It should say simply "until it receives a message proving that the
initiator can receive messages at its claimed IP address."; as you
correctly point out, state about IKE_SA_INIT is indeed required to 
verify the IKE_AUTH request.

The text is probably a leftover from very early drafts of IKEv2,
where the contents of message 1 (IKE_SA_INIT request) were 
repeated in message 3 (IKE_AUTH request)...

Best regards,
Pasi

> -----Original Message-----
> From: ext David Wierbowski [mailto:[email-masked]] 
> Sent: 17 August, 2007 05:19
> To: [email-masked]
> Subject: [Ipsec] Committing State to an SA
> 
> Can somebody explain how the responder can defer committing any
> state to an exchange until the initiator is cryptographically
> authenticated?
> 
> This implies the responder must save state prior to receiving the
> IKE_AUTH exchange. Specifically it must save some state involving
> the initiator's nonce and the IKE_SA_INIT response sent.
> 
> Dave Wierbowski 
> 
>

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 17 Aug 2007 12:55:20 +0300

There is to statements there:

>    To increase robustness by allowing the responder to not do
>    initiator can receive messages at its claimed IP address

That means we do not do any Diffie-Hellman or store lots of data at
the responder before we get another message from initiator which
proves that initiator can receive message at its claimed IP address.
I.e. this is the cookie exchange.

>    and not

And this means we do not install any IPSec SAs or other things (i.e
process initial contact or similar notifications) before the initiator
is authenticated (i.e at the IKE_AUTH exchange, after we have verified
the auth payload etc).

This does not say anything that we cannot store anything in the
responder before that, it just say we do not commit any state changes
to tables in use (SAD, allocated ip addresses, clear out old leftover
SAs when using initial contact etc).
-- 
[email-masked]