<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 _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
