Subject: [IPsec] Issue (resumption): clarify what state comes from where

From: <[email-masked]>
Date: Tue, 17 Mar 2009 12:26:53 +0100

<not wearing any hats>

When a session is resumed, both peers need to somehow get all the
information they need for the new IKE_SA. Some of this comes from the
ticket (on gateway side); some from local storage (on client side --
also gateway if using ticket-by reference); and some is fresh from the
IKE exchanges.

I think the draft needs some more clarification about where each piece
comes from on each side.

Much of this might actually be obvious to the authors, but e.g. as I
noted in my 2008-11-18 email, the draft never actually says that in
addition to storing the opaque ticket, the client also stores keys
(and lot of other stuff) from its IKE_SA (and this was causing some
confusion in IETF73)... and thus the text in Section 4.7 (saying that
both peers take e.g. the SA value from the ticket) is not really
correct (gateway does that, but not client, since the client can't
parse the ticket).

Also, when I started sketching a table summarizing this, I noticed
that there are some pieces of information where the answer (where it
comes from) is not totally clear. Here's my current sketch; parts that
I found a bit unclear are marked with "???":

+-----------------------------------------------------------------+
| Information            | Client          | Gateway              |
|------------------------+-----------------+----------------------|
| IDi                    | local state     | ticket/local state   |
|------------------------+-----------------+----------------------|
| IDr                    | local state     | ???                  |
|------------------------+-----------------+----------------------|
| Certificates (note 1)  | local state     | ticket/local state   |
|------------------------+-----------------+----------------------|
| local IP address/port  |                 | from                 |
| peer IP address/port   | client selects  | IKE_SESSION_RESUME   |
| (note 2)               |                 | exchange             |
|------------------------+----------------------------------------|
| NAT_DETECTION status   | not resumed (NAT_DETECTION_* payloads  |
|                        | included in IKE_SESSION_RESUME)        |
|------------------------+----------------------------------------|
| SPIs                   | fresh from IKE_SESSION_RESUME exchange |
|------------------------+----------------------------------------|
| Which peer is the      | the one who initiates the              |
| "original initiator"?  | IKE_SESSION_RESUME exchange            |
|------------------------+----------------------------------------|
| IKE_SA sequence        | start from 0 (for IKE_SESSION_RESUME   |
| numbers                | request/response)                      |
|------------------------+----------------------------------------|
| IKE_SA algorithms      | local state     | ticket/local state   |
| (SAr)                  |                 |                      |
|------------------------+----------------------------------------|
| IKE_SA keys (SK_*)     | See Section 4.7                        |
|------------------------+----------------------------------------|
| IKE_SA window size     | reset to 1                             |
|------------------------+----------------------------------------|
| CHILD_SAs (ESP/AH)     | not resumed (new CHILD_SAs created     |
|                        | from scratch)                          |
|------------------------+----------------------------------------|
|                        | not resumed (IKE_SESSION_RESUME        |
| Internal IP address    | exchange can assign same or            |
|                        | different address) (note 3)            |
|------------------------+----------------------------------------|
| Other CP information   | not resumed                            |
|------------------------+----------------------------------------|
| Peer Vendor IDs        | ???                                    |
|------------------------+----------------------------------------|
| Peer supports MOBIKE?  | ???                                    |
| [RFC4555]              |                                        |
|------------------------+----------------------------------------|
| MOBIKE additional      | ???                                    |
| addresses [RFC4555]    |                                        |
|------------------------+----------------------------------------|
| Time until             |                                        |
| reauthentication       | ???                                    |
| [RFC4478]              |                                        |
+-----------------------------------------------------------------+
| Peer supports          |                                        |
| redirects? [draft-..]  | ???                                    |
+-----------------------------------------------------------------+

Note 1: Certificates don't need to be stored if the peer never uses
them for anything after the IKE_SA is up (but would be needed if
exposed to applications via IPsec APIs).

Note 2: If the certificate has an iPAddress SubjectAltName, and the
implementation requires it to match the peer source IP address, this
check needs to be performed also on session resumption (and the
required information saved locally or in the ticket).

Note 3: The client can request the address it was using earlier,
and if possible, the gateway should honor the request.

Note 4: IKEv2 features that affect only the IKE_AUTH exchange
(including HTTP_CERT_LOOKUP_SUPPORTED, multiple authentication
exchanges [RFC4739], ECDSA authentication [RFC4754], and OCSP
[RFC4806]) don't usually need any state in the IKE_SA (after the
IKE_AUTH exchanges are done), so resumption doesn't affect them.

Note 5: Since information about CHILD_SAs and configuration payloads
is not resumed, IKEv2 features related to CHILD_SA negotiation (such
as IPCOMP_SUPPORTED, ESP_TFC_PADDING_NOT_SUPPORTED, and
ROHC-over-IPsec [draft-ietf-rohc-ikev2-extensions-hcoipsec-08]) and
configuration aren't usually affected by session resumption.

Note 6: New IKEv2 features that are not covered by notes 4 and 5
should specify how the interact with session resumption.

Best regards,
Pasi