idnits 2.17.1 draft-ietf-ipsec-skip-pfs-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 10 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 11 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 146: '...tor. This identity MAY be encrypted in...' RFC 2119 keyword, line 188: '...he version field MUST be 1 for this ve...' RFC 2119 keyword, line 198: '...o initiator) these fields MUST be zero...' RFC 2119 keyword, line 208: '...A responder MAY choose a different val...' RFC 2119 keyword, line 222: '...utation. A responder MUST use the same...' (4 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 293 has weird spacing: '... Header proto...' == Line 311 has weird spacing: '... Header proto...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 20, 1995) is 10651 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Normative reference to a draft: ref. '1' == Outdated reference: A later version (-01) exists of draft-ietf-ipsec-cdp-00 -- Possible downref: Normative reference to a draft: ref. '2' Summary: 11 errors (**), 0 flaws (~~), 6 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 - 1 - 3 IPSEC Working Group Ashar Aziz 4 INTERNET-DRAFT Sun Microsystems, Inc. 6 Expires in six months February 20, 1995 8 SKIP extension for Perfect Forward Secrecy (PFS) 9 11 Status of this Memo 13 This document is a submission to the IETF Internet Protocol Security 14 (IPSEC) Working Group. Comments are solicited and should be addressed to 15 to the working group mailing list (ipsec@ans.net) or to the authors. 17 This document is an Internet-Draft. Internet Drafts are working 18 documents of the Internet Engineering Task Force (IETF), its areas, and 19 its working Groups. Note that other groups may also distribute working 20 documents as Internet Drafts. 22 Internet-Drafts draft documents are valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference material 25 or to cite them other than as "work in progress." 27 To learn the current status of any Internet-Draft, please check the 28 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 29 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 30 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 31 ftp.isi.edu (US West Coast). 33 Distribution of this memo is unlimited. 35 Abstract 37 This document describes an optional extension specifying how to use an 38 ephemeral Diffie-Hellman exchange in conjunction with the SKIP protocol 39 in order to provide perfect forward secrecy for situations where forward 40 secrecy is necessary. 42 1. Introduction 44 This document describes how an ephemeral Diffie-Hellman key exchange can 45 be used in conjunction with the SKIP key distributions protocol [1] to 46 provide Perfect Forward Secrecy (PFS) for situations where PFS is 47 required. 49 The certificate discovery protocol [2] is used to exchange ephemeral 50 Diffie-Hellman values by defining a new certificate type for ephemeral 51 DH certificates. This ephemeral certificate is then used to compute an 52 ephemeral master key, which is used in place of the master keys Kijn 53 used in the base SKIP protocol. 55 In addition a new type of Master Key-ID (MKID) type is defined here, to 56 indicate the use of ephemeral master keys. In addition to perfect 57 forward secrecy, principal anonymity is also supported in the context of 58 the ephemeral certificate exchange. 60 No new protocol family is introduced in order to provide PFS with SKIP. 61 Rather, existing mechanisms such as the certificate discovery protocol, 62 and the extensible MKID types are used to optionally provide PFS over 63 the base SKIP protocol. 65 Using an ephemeral Diffie-Hellman exchange introduces greater bilateral 66 state and overhead than is present in the base SKIP protocol. When using 67 ephemeral certificates, certain features of the base SKIP protocol that 68 rely on statelessness (e.g. quick failover of intermediate nodes) become 69 unavailable. 71 Optional use of both the stateless and stateful modes of operation (with 72 the associated lack and presence of PFS) is specified in the context of 73 the SKIP protocol to provide greater flexibility than is possible with 74 protocols that provide only one or the other modes of operation. 76 2. Cryptographic Description of Ephemeral Certificate Exchange 78 Cryptographic Notation used for describing Ephemeral Certificates: 80 Note: All exponentiations (e.g. g^x) are mod p. The mod p reduction is 81 assumed, and is omitted for the sake of brevity. 83 g^x: Ephemeral Diffie-Hellman public value of initiator (I) 84 g^y: Ephemeral Diffie-Hellman public value of responder (J) 85 g^i: Certified long-term Diffie-Hellman value of initiator 86 g^j: Certified long-term Diffie-Hellman value of responder 87 Cert_I: Long-Lived Certificate of initiator, containing value g^i 88 Cert_J: Long-Lived Certificate of responder, containing value g^j 89 {Message}K: Message authenticated with a Message Authentication Code 90 (MAC) computed using key K 91 [Message]K: Message encrypted using key K 92 EMKID_J_I: Ephemeral Master Key-ID used in packets from J to I 93 EMKID_I_J: Ephemeral Master Key-ID used in packets from I to J 95 The ephemeral certificate exchange is described using the 96 notation above as follows: 98 I->J: { g^x, g, p, [Cert_I]g^xj, EMKID_J_I}Kij 99 J->I: { g^y, g, p, [Cert_J]g^xj, EMKID_J_I, EMKID_I_J}Kij 101 The ephemeral master key (denoted as EKijn) is computed as 103 EKijn = MD5(Kij | g^xy | n | 01) | MD5( Kij | g^xy | n | 00) 105 where n is the counter from the SKIP header. This master key 106 computation is very similar to the master key computation 107 specified in the base SKIP protocol, with the exception of 108 the inclusion of the ephemeral Diffie-Hellman shared 109 secret g^xy in the master key hash computation. As in 110 the base SKIP protocol, "00" and "01" refer to one byte 111 values containing the values 0 and 1 respectively, 112 and "|" refers to concatenation. 114 The values EMKID_I_J and EMKID_J_I refer to the ephemeral 115 Master Key-ID to be used in SKIP packets sent from I to J 116 and J to I, respectively. I picks the ephemeral MKID to 117 be used in packets sent from J to I, and J picks the 118 ephemeral MKID to be used in packets sent from I to J. 119 In either case, both ephemeral MKIDs identify the same 120 EKijn computed as specified in Section 2 above. 121 This Ekijn is used to encrypt the packet key Kp 122 present in the SKIP header. 124 The encryption of each principal's certificate using g^xj is optional. 125 It is used to provide anonymity of the parties involved in the 126 ephemeral exchange. In case anonymity is not desired or necessary 127 (e.g. node to node communications) the encryption using g^xj may 128 be omitted. 130 3. Ephemeral Certificate Format 132 An ephemeral certificate contains essentially an ephemeral randomly 133 generated Diffie-Hellman public value, authenticated using the long- 134 lived certified Diffie-Hellman values used by the base SKIP protocol. 135 The certificate is authenticated using Kij from the base SKIP protocol 136 as a key to compute a MAC over the certificate contents. 138 Each principal involved in an ephemeral certificate exchange computes an 139 ephemeral master key by combining ephemeral Diffie-Hellman shared secret 140 values with the long-lived Diffie-Hellman shared secret values as 141 specified above. This ephemeral master key is then used to encrypt the 142 traffic keys Kp communicated in the SKIP header. 144 In addition to the ephemeral Diffie-Hellman public values, an ephemeral 145 certificate contains the identity and certified Diffie-Hellman public 146 values of the exchange initiator. This identity MAY be encrypted in 147 order to provide anonymity. 149 The following is the format of an ephemeral certificate: 151 Ephemeral Diffie-Hellman Certificate Format: 153 0 1 2 3 154 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 | Ver | Rsvd | Protocol | Port | Cert MAC Alg | 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 | Validity Interval (Seconds) | 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 | DH Public Value Length | DH Public Value (g^x or g^y) ~ 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 162 ~ ~ 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 | Generator Length | Generator (g) ~ 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 166 ~ ~ 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 | Modulus Length | Modulus (p) ~ 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 170 ~ ~ 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 | Ephemeral Master Key-ID EMKID_I_J | 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 | Ephemeral Master Key-ID EMKID_J_I | 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 | Cert Enc. Alg | Cert Type | Encrypted Cert. Length | 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 | Encrypted Long-Lived Certificate ~ 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 180 ~ ~ 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 | Ephemeral Certificate MAC ~ 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 ~ ~ 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 The version field specifies the version number of the ephemeral 188 certificate. The version field MUST be 1 for this version of the 189 certificate format. 191 The protocol and port # together identify the responder for which the 192 certificate exchange is intended. An example of a responder could be a 193 telnet or ftp process, in which case the protocol field would specify 194 TCP, and the port # would identify the corresponding listener port for 195 the telnet or ftp daemon process. If the protocol field is zero, then 196 the node, as opposed to a process on the node, is the principal with 197 which the ephemeral certificate exchange takes place. In the certificate 198 sent from J to I (responder to initiator) these fields MUST be zero 199 filled. 201 "Cert MAC Alg" identifies the MAC algorithm which is used to compute a 202 MAC over the certificate contents. The scope of the MAC computation is 203 the entire certificate, with the MAC field treated as zero filled for 204 the purposes of the MAC computation. 206 The "Validity Interval" specifies how long the ephemeral master key 207 derived from this exchange should be used for. This value is in seconds. 208 A responder MAY choose a different value for this field than the 209 initiator, in which case the actual validity interval for this master 210 key is the minimum of the two values in the exchange. At the end of the 211 validity interval, the ephemeral master key and the all associated 212 secret information is destroyed by both the responder and the initiator. 213 A new exchange may be initiated either subsequent or prior to the expiry 214 of the ephemeral master key, in case there is still encrypted traffic 215 that needs to be sent in PFS mode. 217 DH Public Value Length specifies the length of the DH public value 218 field. DH Public Value contains the ephemeral DH public value (g^x or 219 g^y), specified as a string of octets with the most significant octet 220 first. Similarly, Generator Length, Generator and Modulus Length, 221 Modulus specify the lengths and values of the Generator (g) and the 222 Modulus (p) used for the DH computation. A responder MUST use the same 223 values for the generator and modulus as the initiator. 225 The field EMKID_I_J specifies what the ephemeral MKID should be for 226 packets sent from I to J. Since J picks the value of this field, this 227 field MUST be zero filled in the ephemeral certificate sent from I to J. 228 The value of this field is specified in the ephemeral certificate sent 229 from J to I. 231 The field EMKID_J_I specifies what the ephemeral MKID field contains for 232 packets sent from J to I. I picks the value of this field, and J MUST 233 fill in the same value in this field as was present in the ephemeral 234 certificate that J received from I. 236 Each of EMKID_I_J and EMKID_J_I is used only as the Destination MKID in 237 a SKIP header. When used in ephemeral master key mode, the Source MKID 238 MUST be absent, and indicated by a zero filled Source NSID field in the 239 SKIP header. 241 The combination of an ephemeral Destination MKID and the destination IP 242 address uniquely identififes an ephemeral master key. 244 "Cert Enc. Alg" specifies the encryption algorithm used to encrypt I and 245 J's long-lived certificate. This is the same DH certificate as used in 246 the base SKIP protocol. The type of this certificate is indicated using 247 the "Cert Type" field. This value MUST NOT refer to an ephemeral 248 certificate type. 250 The certificate is encrypted using the low-order key-size bits of g^xj 251 as the encryption key. If the encryption algorithm requires per message 252 variables (e.g. an IV) then this is derived using the high order 253 variable size bits of g^xj. Since only I and J can properly compute 254 g^xj, the encryption of I and J's certificate provides principal 255 anonymity for situations where anonymity is desired. The anonymity 256 protection provided is secure against both active and passive forms of 257 attack. 259 If the "Cert Enc. Alg" field is zero, then the long-lived certificate is 260 in the clear. In this case the field "Encrypted Long-Lived Certificate" 261 contains the long-lived DH certificate in the clear. 263 When J receives an encrypted long-lived certificate, it first computes 264 g^xj in order to decrypt the long-lived DH certificate. Having obtained 265 (and verified) the long-lived certificate (which contains the value g^i) 266 J computes g^ij, and thereby Kij which it uses to verify the MAC field 267 "Certificate MAC" of the ephemeral certificate. If the MAC field is 268 incorrect, the ephemeral certificate MUST be discarded. If the MAC field 269 is correct, J computes EKijn as specified above and responds with its 270 own ephemeral certificate, containing g^y. 272 When I receives an ephemeral certificate, it uses the value EMKID_J_I to 273 locate the request for which this is the corresponding response. A non- 274 zero EMKID_I_J field indicates that this a response to an ephemeral 275 certificate request initiated by I, as opposed to a new certificate 276 exchange initiated by J. 277 .P 279 4. Informational 281 The following shows an example of how the ephemeral certificate exchange 282 is used in conjunction with the SKIP header. 284 Assume that the value EMKID_J_I is 1001, and the value EMKID_I_J is 2007 285 after a succesfull ephemeral certificate exchange. EKijn is computed as 286 described in Section 2 above. 288 SKIP Header in packet sent from I to J 290 0 1 2 3 291 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 | Clear IP Header protocol = SKIP... (typically 20-bytes) 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | Ver | Rsvd.| Src NSID=0 | Dst NSID=EMKID|NEXT HEADER | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | Counter n | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | Kij alg. | Crypt alg | MAC Alg. | Comp Alg | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | Kp encrypted in EKijn... (typically 8-16 bytes) 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 | Destination MKID (contains the value 2007) 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 SKIP Header in packet from J to I 308 0 1 2 3 309 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 | Clear IP Header protocol = SKIP... (typically 20-bytes) 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 | Ver | Rsvd.| Src NSID=0 | Dst NSID=EMKID|NEXT HEADER | 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 | Counter n | 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 | Kij alg. | Crypt alg. | MAC Alg. | Comp Alg | 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 | Kp encrypted in EKijn... (typically 8-16 bytes) 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 | Destination MKID (contains the value 1001) 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 5. Certificate Type and Name Space Assignments 326 5.1 Certificate Type Assignment 328 The ephemeral Diffie-Hellman certificate type as defined in this 329 document is pending assignment by IANA. 331 5.2 NSID Assignment 333 The NSID for ephemeral MKIDs EMKID is pending assignment by IANA. 335 6. Generalization for Key-Agreement techniques other than classic DH 337 Although the ephemeral certificate exchange scheme specified above uses 338 the constructions of classic Diffie-Hellman (exponentiation over finite 339 fields) the scheme is fully generalizable to other key-agreement 340 techniques, such as Elliptic Curve (EC) variants of Diffie-Hellman. In 341 order to use these other DH variants, a new ephemeral certificate type 342 may be defined that contains parameters specific to these other DH 343 variant schemes. 345 7. Security Considerations 347 The topic of this memo is security. 349 References 351 [1] Aziz, A., Markson, T., Prafullchandra, H., "Simple Key Management 352 for Intern et Protocols", (I-D draft-ietf-ipsec-skip-06.txt), Work 353 In Progress 355 [2] Aziz, A., Markson, T., Prafullchandra, H., "Certificate Discovery 356 Protocol", (I-D draft-ietf-ipsec-cdp-00.txt), Work In Progress 357 Author Information: 359 Ashar Aziz 360 Sun Microsystems, Inc. 361 MS PAL1-550, 362 2550 Garcia Ave. 363 Mountain View, CA 94043 365 e-mail: ashar.aziz@Eng.Sun.COM