|
| 1 | +# -*- fill-column: 69; -*- |
| 2 | +# vim: set textwidth=69 |
| 3 | +# Do: title, toc:table-of-contents ::fixed-width-sections |tables |
| 4 | +# Do: ^:sup/sub with curly -:special-strings *:emphasis |
| 5 | +# Don't: prop:no-prop-drawers \n:preserve-linebreaks ':use-smart-quotes |
| 6 | +#+OPTIONS: prop:nil title:t toc:t \n:nil ::t |:t ^:{} -:t *:t ':nil |
| 7 | + |
| 8 | +#+RFC_CATEGORY: info |
| 9 | +#+RFC_NAME: draft-antony-eesp-ikev2-notes |
| 10 | +#+RFC_VERSION: 00 |
| 11 | +#+RFC_IPR: trust200902 |
| 12 | +#+RFC_STREAM: IETF |
| 13 | +#+RFC_XML_VERSION: 3 |
| 14 | +#+RFC_CONSENSUS: true |
| 15 | + |
| 16 | +#+TITLE: Notes on IKEv2 Key Derivation Function |
| 17 | +#+RFC_SHORT_TITLE: KEv2 KDF Notes |
| 18 | +#+AUTHOR: Steffen Klassert |
| 19 | + |
| 20 | +#+AFFILIATION: secunet Security Networks AG |
| 21 | +#+RFC_SHORT_ORG: secunet |
| 22 | +#+RFC_ADD_AUTHOR: ("Antony Antony" " [email protected]" ("secunet" "secunet Security Networks AG")) |
| 23 | +#+RFC_AREA: SEC |
| 24 | +#+RFC_WORKGROUP: IPSECME Working Group |
| 25 | + |
| 26 | +* Introduction |
| 27 | + |
| 28 | +These are notes on EESP IKEv2 and other EESP related information. To keep it in one place for quick access. |
| 29 | + |
| 30 | +* KDF methods |
| 31 | + |
| 32 | +IKEv2 key derivation, [[RFC7296]], is likely ~KDF in Feedback Mode~ specified |
| 33 | +in [[NIST800-108]]. This in iterative method as I see it in Section 2.13 [[RFC7296]] |
| 34 | + |
| 35 | +In the following, | indicates concatenation. prf+ is defined as: |
| 36 | +prf+ (K,S) = T1 | T2 | T3 | T4 | ... |
| 37 | + |
| 38 | +where: |
| 39 | + T1 = prf (K, S | 0x01) |
| 40 | + |
| 41 | + T2 = prf (K, T1 | S | 0x02) |
| 42 | + |
| 43 | + T3 = prf (K, T2 | S | 0x03) |
| 44 | + |
| 45 | + T4 = prf (K, T3 | S | 0x04) |
| 46 | + |
| 47 | + ... |
| 48 | + |
| 49 | +Section 2.14 of [[RFC7296]] |
| 50 | + |
| 51 | +SKEYSEED = prf(Ni | Nr, g^ir) |
| 52 | + |
| 53 | +{SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr} |
| 54 | + = prf+ (SKEYSEED, Ni | Nr | SPIi | SPIr) |
| 55 | + |
| 56 | +(indicating that the quantities SK_d, SK_ai, SK_ar, SK_ei, SK_er, |
| 57 | +SK_pi, and SK_pr are taken in order from the generated bits of the |
| 58 | +prf+). g^ir is the shared secret from the ephemeral Diffie-Hellman |
| 59 | +exchange. g^ir is represented as a string of octets in big endian |
| 60 | +order padded with zeros if necessary to make it the length of the |
| 61 | +modulus. Ni and Nr are the nonces, stripped of any headers. |
| 62 | + |
| 63 | +KEYMAT = prf+(SK_d, Ni | Nr) |
| 64 | + |
| 65 | +Where Ni and Nr are the nonces from the IKE_SA_INIT exchange if this |
| 66 | +request is the first Child SA created or the fresh Ni and Nr from the |
| 67 | +CREATE_CHILD_SA exchange if this is a subsequent creation. |
| 68 | + |
| 69 | +For CREATE_CHILD_SA exchanges including an optional Diffie-Hellman |
| 70 | +exchange, the keying material is defined as: |
| 71 | + |
| 72 | +KEYMAT = prf+(SK_d, g^ir (new) | Ni | Nr) |
| 73 | + |
| 74 | +where g^ir (new) is the shared secret from the ephemeral Diffie- |
| 75 | +Hellman exchange of this CREATE_CHILD_SA exchange (represented as an |
| 76 | +octet string in big endian order padded with zeros in the high-order |
| 77 | +bits if necessary to make it the length of the modulus). |
| 78 | + |
| 79 | +What EESP IKEv2 proposing as ~Heirarchial key derivation~ |
| 80 | +NIST800-108 defines ~Key Hierarchy~ |
| 81 | + |
| 82 | +In Section 5.4 of Key Management for Multicast [[RFC2627]] a Logical Key Hierarchy (LKH) . I din't follow that completly. It is refered in G-IKEv2. |
| 83 | + |
| 84 | +* UDP Encap |
| 85 | + |
| 86 | +Why UDP? |
| 87 | +- For Roadwarrior: IPv4 home gateway. |
| 88 | +- Why Datacenters, without NAT, using UDP? [Tero] This is a failure for a new protocol. |
| 89 | + |
| 90 | +2.1. UDP-Encapsulated ESP Header Format [[RFC3948]] : "the Source Port and Destination Port MUST be the same as that used by IKE traffic " |
| 91 | + |
| 92 | +And [[RFC3947]] for IKE in UDP encapsulation: "The initiator MUST set both UDP source and destination ports to 4500." However, NAT gateways |
| 93 | +in the middle are allowed to change source port number. The receiver must accept any source port. |
| 94 | +And respond to the source port. |
| 95 | + |
| 96 | +* WESP UDP Encap |
| 97 | + |
| 98 | +[[RFC5840]] It use SPI 0x2 . It is 32 bits at the top. SPI 0x2 is reserved. |
| 99 | + |
| 100 | +#+caption: Figure 4: UDP-Encapsulated WESP Header |
| 101 | +#+name: wesp-udp-encap |
| 102 | +#+begin_src |
| 103 | + 0 1 2 3 |
| 104 | + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 |
| 105 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| 106 | + | Src Port (4500) | Dest Port (4500) | |
| 107 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| 108 | + | Length | Checksum | |
| 109 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| 110 | + | Protocol Identifier (value = 0x00000002) | |
| 111 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| 112 | + | Next Header | HdrLen | TrailerLen | Flags | |
| 113 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| 114 | + | Existing ESP Encapsulation | |
| 115 | + ~ ~ |
| 116 | + | | |
| 117 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| 118 | + |
| 119 | +#+end_src |
| 120 | + |
| 121 | +EESP could use that ext 4 bytes, reserve an ESP SPI bellow 255. However, this would lead to waste of 4 bytes every EESP packet. |
| 122 | + |
| 123 | +* Normative References |
| 124 | + |
| 125 | +** RFC2627 |
| 126 | +** RFC3947 |
| 127 | +** RFC3948 |
| 128 | +** RFC5840 |
| 129 | +** RFC7296 |
| 130 | + |
| 131 | +** NIST800-108 |
| 132 | +:PROPERTIES: |
| 133 | +:REF_TARGET: https://www.nist.gov/publications/recommendation-key-derivation-using-pseudorandom-functions-1 |
| 134 | +:REF_TITLE: Recommendation for Key Derivation Using Pseudorandom Functions |
| 135 | +:REF_ORG: NIST |
| 136 | +:END: |
| 137 | + |
| 138 | +* Informative References |
| 139 | + |
| 140 | +** I-D.ietf-ipsecme-g-ikev2 |
0 commit comments