idnits 2.17.1 draft-bew-ipsec-signatures-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 3 instances of too long lines in the document, the longest one being 7 characters in excess of 72. ** The abstract seems to contain references ([ROADMAP], [AH], [RSA], [ESP]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC2409' is mentioned on line 212, but not defined ** Obsolete undefined reference: RFC 2409 (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2402 (ref. 'AH') (Obsoleted by RFC 4302, RFC 4305) ** Obsolete normative reference: RFC 2406 (ref. 'ESP') (Obsoleted by RFC 4303, RFC 4305) -- Possible downref: Non-RFC (?) normative reference: ref. 'ISAKMP-REG' ** Obsolete normative reference: RFC 2401 (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2411 (ref. 'ROADMAP') (Obsoleted by RFC 6071) ** Obsolete normative reference: RFC 3447 (ref. 'RSA') (Obsoleted by RFC 8017) -- Obsolete informational reference (is this intentional?): RFC 3547 (Obsoleted by RFC 6407) Summary: 10 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Brian Weis 3 INTERNET-DRAFT Cisco Systems 4 Document: draft-bew-ipsec-signatures-01.txt August, 2003 5 Expires: February, 2004 7 The Use of RSA Signatures within ESP and AH 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet 15 Engineering Task Force (IETF), its areas, and its working groups. 16 Note that other groups may also distribute working documents as 17 Internet Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Abstract 32 This memo describes the use of the RSA Signature algorithm [RSA] as 33 an authentication algorithm within the revised IPSEC Encapsulating 34 Security Payload [ESP] and the revised IPSEC Authentication Header 35 [AH]. The use of a digital signature algorithm such as RSA provides 36 origin authentication, even when ESP and AH are used to secure group 37 data flows. 39 Further information on the other components necessary for ESP and AH 40 implementations is provided by [ROADMAP]. 42 The Use of RSA Signatures with ESP and AH August, 2003 44 Table of Contents 46 1.0 Introduction......................................................2 47 2.0 Algorithm and Mode................................................3 48 3.0 Performance.......................................................3 49 4.0 Interaction with the ESP Cipher Mechanism.........................4 50 5.0 Security Association Considerations for Group Traffic.............4 51 6.0 Key Management Considerations.....................................4 52 7.0 Security Considerations...........................................5 53 7.1 Eavesdropping...................................................5 54 7.2 Replay..........................................................5 55 7.3 Message Insertion...............................................5 56 7.4 Deletion........................................................5 57 7.5 Modification....................................................6 58 7.6 Man in the middle...............................................6 59 7.7 Denial of Service...............................................6 60 8.0 IANA Considerations...............................................6 61 9.0 Acknowledgements..................................................6 62 10.0 References.......................................................7 63 10.1 Normative References...........................................7 64 10.2 Informative References.........................................7 65 Authors Addresses.....................................................7 67 1.0 Introduction 69 AH and ESP payloads can be used to protect unicast traffic, or group 70 traffic, such as IPv4 and IPv6 multicast traffic. When unicast 71 traffic is protected between a pair of entities, HMAC transforms 72 (such as [HMAC-SHA] and [HMAC-MD5]) are sufficient to prove source 73 authentication. An HMAC is strong enough in that scenario because 74 only one other entity knows the key. However when AH and ESP protect 75 group traffic, this property is no longer valid -- all group members 76 share the single HMAC key and thus can spoof one another. 78 Some multicast applications require true origin authentication, where 79 one group member cannot be spoofed by another group member without 80 detection. The use of asymmetric encryption algorithms, such as RSA, 81 can provide true origin authentication. The sender generates a pair 82 of keys, one of which is never shared (called the "private key") and 83 one of which is distributed to other group members (called the 84 "public key"). 86 When an asymmetric encryption algorithm is used to encrypt the output 87 of a cryptographic hash algorithm, the cipher text is called a 88 "digital signature". A receiver of the digital signature uses the 89 public key to decrypt the hash. 91 This memo describes how RSA digital signatures can be applied as an 92 authentication mechanism to AH and ESP payloads to provide origin 93 authentication. 95 The Use of RSA Signatures with ESP and AH August, 2003 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 98 NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 99 this document are to be interpreted as described in [RFC2119]. 101 2.0 Algorithm and Mode 103 The RSA Public Key Algorithm [RSA] is a widely deployed public key 104 algorithm commonly used for digital signatures. Compared to other 105 public key algorithms, signature verification is relatively quick. 106 This property is useful for groups where receivers may have limited 107 processing capabilities. The RSA Algorithm is commonly supported in 108 hardware, and is no longer encumbered by intellectual property 109 claims. 111 Several schemes for the RSA Algorithm are described in [RSA]. One 112 scheme exists specifically for digital signatures. However, that 113 scheme is not the most efficient for this application. In addition, 114 the signature scheme encodes the hash type into the signature data 115 block, and this is not necessary because the hash algorithm is pre- 116 determined. 118 The RSAES-OAEP raw RSA scheme [RSA, Section 7.1] MUST be used as the 119 encryption scheme. As recommended in [RSA, Section B.1], SHA-1 MUST 120 be used as the signature hash algorithm both as the message to be 121 encrypted by the RSA Algorithm, and as the encoding parameter for the 122 OAEP encoding. The value of parameter string P MUST be the default, 123 which is the hash of an empty string. The mask generation function 124 MUST be MGF1 as defined in [RSA, Section B.2.1]. 126 The size of the RSA modulus used can vary, but MUST be at least 496 127 bits. This restriction is a function of the size of the SHA-1 hash 128 and the number of bits needed for OAEP encapsulation. (For more 129 information, see [RSA, Section 7.1].) 131 3.0 Performance 133 The RSA asymmetric key algorithm is very costly in terms of 134 processing time compared to the HMAC algorithms. However, processing 135 cost is decreasing over time. Faster general-purpose processors are 136 being deployed, faster software implementations are being developed, 137 and hardware acceleration support for the algorithm is becoming more 138 prevalent. However, care should always be taken that RSA signatures 139 are not used for applications that expect to have bandwidth 140 requirements that would be adversely affected. 142 The RSA asymmetric key algorithm is best suited to protect network 143 traffic for network traffic for which: 145 o the sender has a substantial amount of processing power, whereas 146 receivers are not guaranteed to have substantial processing power, 147 and 148 The Use of RSA Signatures with ESP and AH August, 2003 150 o the network traffic is small enough that adding a relatively large 151 authentication tag (in the range of 61 to 256 bytes) does not cause 152 packet fragmentation. 154 Both key pair generation and encryption (or signing) are 155 substantially more expensive operations, but these are isolated to 156 the sender. 158 The size of the RSA modulus can affect the processing required to 159 create and verify RSA digital signatures. Care should be taken to 160 determine what the size of key is needed for the application. 161 Smaller key sizes may be chosen as long as the network traffic 162 protected by the private key flows for less time than it is estimated 163 that an attacker would take to discover the private key. This 164 lifetime is considerably smaller than most public key applications, 165 so a key that is normally considered weak may be satisfactory. (If 166 the RSA public key algorithm were used to encrypt the packet, then 167 the lifetime would be substantially longer.) 169 The addition of a digital signature as an authentication tag adds a 170 significant number of bytes to the packet. This increases the 171 likelihood that the packet encapsulated in AH or ESP may be 172 fragmented. 174 4.0 Interaction with the ESP Cipher Mechanism 176 As of this writing, there are no known issues that preclude the use 177 of the RSA signatures algorithm with any specific cipher algorithm. 179 5.0 Security Association Considerations for Group Traffic 181 When RSA Signatures are used to protect group traffic, they MUST be 182 in accordance with the restrictions set forth in the IPSec 183 Architecture [RFC2401] to ensure that security associations remain 184 unique. That is, one of the following two cases: 186 o Single sender groups where only one source IPv4 or IPV6 187 address is sending packets to the IP multicast destination address. 189 o Multiple sender groups where a single group controller is 190 choosing SPI values for AH and ESP security associations for all 191 group members sending packets to the same IP multicast destination 192 address. 194 6.0 Key Management Considerations 196 The key management mechanism that negotiates the use of RSA 197 Signatures MUST include the length of the RSA modulus during policy 198 negotiation in order to give a device the opportunity to decline. 199 This is especially important for devices with constrained processors 200 that might not be able to handle the verification of signatures using 201 larger key sizes. 203 The Use of RSA Signatures with ESP and AH August, 2003 205 A receiver must have the RSA public key in order to decrypt the 206 packet. When used with a group key management system such as GDOI 207 [RFC3547], the public key SHOULD be to sent as part of the key 208 download policy. If the group has multiple senders, the public key of 209 each sender SHOULD be sent as part of the key download policy. 211 When used with a pair-wise key management system such as IKE 212 [RFC2409] the public key could be passed as an SA attribute. However, 213 given the above performance considerations, the value of using this 214 transform for a pair-wise connection is limited. 216 7.0 Security Considerations 218 This document provides a method of authentication for AH and ESP 219 using digital signatures. This feature provides the following 220 protections: 222 o Message modification integrity. The digital signature allows 223 the receiver of the message to verify that it was exactly the same as 224 when the sender signed it. 226 o Host authentication. The asymmetric nature of the RSA public 227 key algorithm allows the sender to be uniquely verified, even when 228 the message is sent to a group. 230 As suggested by [RFC3552], the following sections describe various 231 attacks that could be deployed against using RSA signatures as a 232 means of authentication. 234 7.1 Eavesdropping 236 This document does not address confidentiality. That function, if 237 desired, must be addressed by an ESP cipher that is used with the 238 RSA Signatures authentication method. The RSA signature itself does 239 not need to be protected in any way. 241 7.2 Replay 243 This document does not address replay attacks. That function, if 244 desired, is addressed through use of AH and ESP sequence numbers as 245 defined in [AH] and [ESP]. 247 7.3 Message Insertion 249 This document directly addresses message insertion attacks. Inserted 250 messages will fail authentication and be dropped by the receiver. 252 7.4 Deletion 254 This document does not address deletion attacks. It is only 255 concerned with validating the legitimacy of messages that are not 256 deleted. 258 The Use of RSA Signatures with ESP and AH August, 2003 260 7.5 Modification 262 This document directly addresses message modification attacks. 263 Modified messages will fail authentication and be dropped by the 264 receiver. 266 7.6 Man in the middle 268 As long as a receiver is given the sender RSA public key in a 269 trusted manner, it will be able to verify that the digital signature 270 is correct. A man in the middle will not be able to spoof the actual 271 sender unless it acquires the RSA private key through some means. 273 RSA modulus sizes must be chosen carefully to ensure that the time it 274 takes a man in the middle to determine the RSA private key through 275 cryptanalysis is longer than the amount of time that packets are 276 signed with that private key. 278 7.7 Denial of Service 280 A receiver of an ESP and AH packet starts by looking up the Security 281 Association in the SADB. If one is found, the ESP or AH sequence 282 number in the packet is verified. If the sequence number falls 283 within the window, the authentication step is performed. 285 An attacker that sends an ESP or AH packet which matches a valid SA 286 on the system and which also has a valid sequence number will cause 287 the receiver to perform the AH or ESP authentication step. Because 288 the process of verifying an RSA digital signature consumes 289 relatively large amounts of processing, this could lead to a denial 290 of service attack on the receiver if many such packets were sent. 292 If the message was sent to an IPv4 or IPv6 multicast group all group 293 members that received the packet would be under attack 294 simultaneously. 296 Further investigation is needed to better estimate the actual 297 effects of this attack, and how it can be mitigated. 299 8.0 IANA Considerations 301 An assigned number is required in the IPSec Authentication Algorithm 302 name space in the ISAKMP registry [ISAKMP-REG]. The mnemonic should 303 be SIG-RSA. 305 A new IPSEC Security Association Attribute is required in the ISAKMP 306 registry to pass the RSA modulus size. The attribute class should be 307 called Authentication Key Length, and it should a Variable type. 309 9.0 Acknowledgements 311 TBD 312 The Use of RSA Signatures with ESP and AH August, 2003 314 10.0 References 316 10.1 Normative References 318 [AH] Kent, S., and R. Atkinson, "IP Authentication Header", RFC 2402, 319 November 1998. 321 [ESP] Kent, S., and R. Atkinson, "IP Encapsulating Security Payload", 322 RFC 2406, November 1998. 324 [ISAKMP-REG] http://www.iana.org/assignments/isakmp-registry 326 [RFC2401] Kent, S., R. Atkinson, "Security Architecture for the 327 Internet Protocol", November 1998 329 [ROADMAP] Thayer, R., Doraswamy, N., and R. Glenn, "IP Security 330 Document Roadmap", RFC 2411, November 1998. 332 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 333 Requirement Level", BCP 14, RFC 2119, March 1997. 335 [RFC3552] E. Rescorla, et. al., Guidelines for Writing RFC Text on 336 Security Considerations, RFC 3552, July 2003. 338 [RSA] Jonsson, J., B. Kaliski, "PKCS #1: RSA Cryptography 339 Specifications Version 2.1", RFC 3447, February 2003. 341 10.2 Informative References 343 [HMAC-MD5] Madson, C., and R. Glenn, "The Use of HMAC-MD5-96 within 344 ESP and AH"", RFC 2403, November, 1998. 346 [HMAC-SHA] Madson, C., and R. Glenn, " The Use of HMAC-SHA-1-96 347 within ESP and AH", RFC 2404, November, 1998. 349 [RFC3547] M. Baugher, B. Weis, T. Hardjono, H. Harney, , The Group 350 Domain of Interpretation, RFC 3547, December 2002. 352 Authors Addresses 354 Brian Weis 355 Cisco Systems 356 170 W. Tasman Drive, 357 San Jose, CA 95134-1706, USA 358 (408) 526-4796 359 bew@cisco.com