idnits 2.17.1 draft-ietf-msec-ipsec-signatures-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 516. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 529. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 536. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 542. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([IKEV2], [AES-GCM], [AH], [ESP]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == 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: 'IKEv2' is mentioned on line 295, but not defined == Missing Reference: 'RFC2434' is mentioned on line 431, but not defined ** Obsolete undefined reference: RFC 2434 (Obsoleted by RFC 5226) == Unused Reference: 'SHA' is defined on line 465, but no explicit reference was found in the text == Outdated reference: A later version (-11) exists of draft-ietf-ipsec-rfc2402bis-10 == Outdated reference: A later version (-10) exists of draft-ietf-ipsec-esp-v3-09 -- Possible downref: Non-RFC (?) normative reference: ref. 'ISAKMP-REG' ** Obsolete normative reference: RFC 3447 (ref. 'RSA') (Obsoleted by RFC 8017) -- Possible downref: Non-RFC (?) normative reference: ref. 'SHA' -- Obsolete informational reference (is this intentional?): RFC 3547 (ref. 'GDOI') (Obsoleted by RFC 6407) Summary: 6 errors (**), 0 flaws (~~), 8 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Brian Weis 2 INTERNET-DRAFT Cisco Systems 3 Document: draft-ietf-msec-ipsec-signatures-06.txt June, 2005 4 Expires: December, 2005 6 The Use of RSA/SHA-1 Signatures within ESP and AH 8 Status of this Memo 10 By submitting this Internet-Draft, each author represents that 11 any applicable patent or other IPR claims of which he or she is 12 aware have been or will be disclosed, and any of which he or she 13 becomes aware will be disclosed, in accordance with Section 6 of 14 BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Abstract 34 This memo describes the use of the RSA Digital Signature algorithm as 35 an authentication algorithm within the revised IP Encapsulating 36 Security Payload (ESP) as described in RFC XXXX and the revised IP 37 Authentication Header (AH) as described in RFC YYYY. The use of a 38 digital signature algorithm, such as RSA, provides data origin 39 authentication in applications when a secret key method (e.g., HMAC) 40 does not provide this property. One example is the use of ESP and AH 41 to authenticate the sender of an IP multicast packet. 43 -- Note to RFC Editor: Please replace RFC XXXX with the RFC 44 -- number that is assigned to draft-ietf-ipsec-esp-v3 and 45 -- replace RFC YYYY with the RFC number assigned to 46 -- draft-ietf-ipsec-rfc2402bis. Please also modify normative 47 -- references [ESP] and [AH] that point to these drafts with 48 -- their respective RFC numbers. Lastly, informative references 49 -- [IKEV2] and [AES-GCM] should be changed to their assigned 50 -- RFC numbers, assuming they are published before this 51 -- document. 53 The Use of RSA/SHA-1 Signatures with ESP and AH June, 2005 55 Table of Contents 57 1.0 Introduction.......................................................2 58 2.0 Algorithm and Mode.................................................3 59 2.1 Key size discussion..............................................4 60 3.0 Performance........................................................5 61 4.0 Interaction with the ESP Cipher Mechanism..........................6 62 5.0 Key Management Considerations......................................6 63 6.0 Security Considerations............................................6 64 6.1 Eavesdropping....................................................7 65 6.2 Replay...........................................................7 66 6.3 Message Insertion................................................7 67 6.4 Deletion.........................................................7 68 6.5 Modification.....................................................7 69 6.6 Man in the middle................................................7 70 6.7 Denial of Service................................................8 71 7.0 IANA Considerations................................................8 72 8.0 Acknowledgements...................................................9 73 9.0 References.........................................................9 74 9.1 Normative References.............................................9 75 9.2 Informative References..........................................10 76 Author's Address......................................................10 77 Full Copyright Statement..............................................10 78 Intellectual Property.................................................11 80 1.0 Introduction 82 Encapsulating Security Payload (ESP) [ESP] and Authentication Header 83 (AH) [AH] headers can be used to protect both unicast traffic and 84 group (e.g., IPv4 and IPv6 multicast) traffic. When unicast traffic 85 is protected between a pair of entities, HMAC transforms (such as 86 [HMAC-SHA]) are sufficient to prove data origin authentication. An 87 HMAC is sufficient protection in that scenario because only the two 88 entities involved in the communication have access to the key, and 89 proof-of-possession of the key in the HMAC construct authenticates 90 the sender. However when ESP and AH authenticate group traffic, this 91 property no longer holds because all group members share the single 92 HMAC key. In the group case the identity of the sender is not 93 uniquely established, since any of the key holders has the ability to 94 form the HMAC transform. Although the HMAC transform establishes a 95 group-level security property, data origin authentication is not 96 achieved. 98 Some group applications require true data origin authentication, 99 where one group member cannot successfully impersonate another group 100 member. The use of asymmetric digital signature algorithms, such as 101 RSA, can provide true data origin authentication. 103 The Use of RSA/SHA-1 Signatures with ESP and AH June, 2005 105 With asymmetric algorithms, the sender generates a pair of keys, one 106 of which is never shared (called the "private key") and one of which 107 is distributed to other group members (called the "public key"). When 108 the private key is used to sign the output of a cryptographic hash 109 algorithm, the result is called a "digital signature". A receiver of 110 the digital signature uses the public key, the signature value, and 111 an independently computed hash to determine whether or not the 112 claimed origin of the packet is correct. 114 This memo describes how RSA digital signatures can be applied as an 115 ESP and AH authentication mechanism to provide data origin 116 authentication. 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 119 NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 120 this document are to be interpreted as described in [RFC2119]. 122 2.0 Algorithm and Mode 124 The RSA Public Key Algorithm [RSA] is a widely deployed public key 125 algorithm commonly used for digital signatures. Compared to other 126 public key algorithms, signature verification is relatively 127 efficient. This property is useful for groups where receivers may 128 have limited processing capabilities. The RSA algorithm is commonly 129 supported in hardware. 131 Two digital signatures encoding methods are supported in [RSA]. 132 RSASSA-PKCS1-v1_5 MUST be supported by a conforming implementation. 133 RSASSA-PSS is generally believed to be more secure, but at the time 134 of this writing is not ubiquitous. RSASSA-PSS SHOULD be used whenever 135 it is available. SHA-1 MUST be used as the signature hash algorithm 136 used by the RSA digital signature algorithm. 138 When specified for ESP, the ICV is equal in size to the RSA modulus, 139 unless the RSA modulus is not a multiple of 8 bits. In this case, the 140 ICV MUST be prepended with between 1 and 7 bits set to zero such that 141 the ICV is a multiple of 8 bits. This specification matches the 142 output S [RSA, Section 8.1.1] (RSASSA-PSS) and [RSA, Section 143 8.2.1](RSASSA-PKCS1-v1_5) when the RSA modulus is not a multiple of 8 144 bits. No implicit ESP ICV Padding bits are necessary. 146 When specified for AH, the ICV is equal in size of the RSA modulus, 147 unless the RSA modulus is not a multiple of 32 bits (IPv4) or 64 bits 148 (IPv6) [AH, Section 2.6]. In this case, explicit ICV Padding bits are 149 necessary to create a suitably sized ICV [AH, Section 3.3.3.2.1]. 151 The distribution mechanism of the RSA public key and its replacement 152 interval are a group policy matter. The use of an ephemeral key pair 153 with a lifetime of the ESP or AH SA is RECOMMENDED. This recommended 154 policy reduces the exposure of the RSA private key to the lifetime of 155 the data being signed by the private key. Also, this obviates the 156 need to revoke or transmit the validity period of the key pair. 158 The Use of RSA/SHA-1 Signatures with ESP and AH June, 2005 160 Digital signature generation is performed as described in [RSA, 161 Section 8.1.1] (RSASSA-PSS) and [RSA, Section 8.2.1](RSASSA-PKCS1- 162 v1_5). The authenticated portion of the AH or ESP packet ([AH, 163 Section 3.3.3], [ESP, Section 3.3.2]) is used as the message M, which 164 is passed to the signature generation function. The signer's RSA 165 private key is passed as K. Summarizing, the signature generation 166 process computes a SHA-1 hash of the authenticated packet bytes, 167 signs the SHA-1 hash using the private key, and encodes the result 168 with the specified RSA encoding type. This process results in a value 169 S, which is known as the ICV in AH and ESP. 171 Digital signature verification is performed as described in [RSA, 172 Section 8.1.2] (RSASSA-PSS) and [RSA, Section 8.2.2](RSASSA-PKCS1- 173 v1_5). Upon receipt, the ICV is passed to the verification function 174 as S. The authenticated portion of the AH or ESP packet is used as 175 the message M, and the RSA public key is passed as (n, e). In 176 summary, the verification function computes a SHA-1 hash of the 177 authenticated packet bytes, decrypts the SHA-1 hash in the ICV, and 178 validates that the appropriate encoding was applied and was correct. 179 The two SHA-1 hashes are compared, and if they are identical the 180 validation is successful. 182 2.1 Key size discussion 184 The choice of RSA modulus size must be made carefully. If too small 185 of a modulus size is chosen, an attacker may be able to reconstruct 186 the private key used to sign packets before the key is no longer used 187 by the sender to sign packets. This order of events may result in the 188 data origin authentication property being compromised. However, 189 choosing a modulus size larger than necessary will result in an 190 unnecessarily high cost of CPU cycles for the sender and all 191 receivers of the packet. 193 A conforming implementation MUST support a modulus size of 1024 bits. 195 Recent guidance [TWIRL, RSA-TR] on key sizes make estimates as to the 196 amount of effort an attacker would need to expend in order to 197 reconstruct an RSA private key. Table 1 summarizes the maximum length 198 of time that selected modulus sizes should be used. Note that these 199 recommendations are based on factors such as the cost of processing 200 and memory, as well as cryptographic analysis methods, which were 201 current at the time these documents were published. As those factors 202 change, choices of key lifetimes should take them into account. 204 The Use of RSA/SHA-1 Signatures with ESP and AH June, 2005 206 Number of Recommended Maximum 207 Modulus Bits Lifetime 208 ------------ ------------------- 209 768 1 week 210 1024 1 year 212 Table 1. RSA Key Use Lifetime Recommendations 214 3.0 Performance 216 The RSA asymmetric key algorithm is very costly in terms of 217 processing time compared to the HMAC algorithms. However, processing 218 cost is decreasing over time. Faster general-purpose processors are 219 being deployed, faster software implementations are being developed, 220 and hardware acceleration support for the algorithm is becoming more 221 prevalent. 223 Care should be taken that RSA signatures are not used for 224 applications when potential receivers are known to lack sufficient 225 processing power to verify the signature. It is also important to use 226 this scheme judiciously when any receiver may be battery powered. 228 The RSA asymmetric key algorithm is best suited to protect network 229 traffic for which: 231 o The sender has a substantial amount of processing power, and 233 o The network traffic is small enough that adding a relatively large 234 authentication tag (in the range of 62 to 256 bytes) does not 235 cause packet fragmentation. 237 RSA key pair generation and signing are substantially more expensive 238 operations than signature verification, but these are isolated to the 239 sender. 241 The size of the RSA modulus affects the processing required to create 242 and verify RSA digital signatures. Care should be taken to determine 243 the size of modulus needed for the application. Smaller modulus 244 sizes may be chosen as long as the network traffic protected by the 245 private key flows for less time than it is estimated that an attacker 246 would take to discover the private key. This lifetime is considerably 247 smaller than most public key applications that store the signed data 248 for a period of time. But since the digital signature is used only 249 for sender verification purposes, a modulus that is considered weak 250 in another context may be satisfactory. 252 The size of the RSA public exponent can affect the processing 253 required to verify RSA digital signatures. Low-exponent RSA 254 signatures may result in a lower verification processing cost. At the 255 time of this writing, no attacks are known against low-exponent RSA 256 The Use of RSA/SHA-1 Signatures with ESP and AH June, 2005 258 signatures that would allow an attacker to create a valid signature 259 using the RSAES-OAEP raw RSA scheme. 261 The addition of a digital signature as an authentication tag adds a 262 significant number of bytes to the packet. This increases the 263 likelihood that the packet encapsulated in ESP or AH may be 264 fragmented. 266 4.0 Interaction with the ESP Cipher Mechanism 268 The RSA signatures algorithm cannot be used with an ESP Combined Mode 269 algorithm that includes an explicit ICV. The Combined Mode algorithm 270 will add the ESP ICV field, which does not allow use of a separate 271 authentication algorithm to add the ESP ICV field. One example of 272 such an algorithm is the ESP Galois/Counter Mode algorithm [AES-GCM]. 274 5.0 Key Management Considerations 276 Key management mechanisms negotiating the use of RSA Signatures MUST 277 include the length of the RSA modulus during policy negotiation using 278 the Authentication Key Length SA Attribute. This gives a device the 279 opportunity to decline use of the algorithm. This is especially 280 important for devices with constrained processors that might not be 281 able to verify signatures using larger key sizes. 283 Key management mechanisms negotiating the use of RSA Signatures also 284 MUST include the encoding method during policy negotiation using the 285 Signature Encoding Algorithm SA Attribute. 287 A receiver must have the RSA public key in order to verify integrity 288 of the packet. When used with a group key management system (e.g., 289 RFC 3547 [GDOI]), the public key SHOULD be sent as part of the key 290 download policy. If the group has multiple senders, the public key of 291 each sender SHOULD be sent as part of the key download policy. 293 Use of this transform to obtain data origin authentication for 294 pairwise SAs is NOT RECOMMENDED. In the case of pairwise SAs (such as 295 negotiated by the Internet Key Exchange [IKEv2]), data origin 296 authentication can be achieved with an HMAC transform. Because the 297 performance impact of an RSA signature is typically greater than an 298 HMAC, the value of using this transform for a pairwise connection is 299 limited. 301 6.0 Security Considerations 303 This document provides a method of authentication for ESP and AH 304 using digital signatures. This feature provides the following 305 protections: 307 o Message modification integrity. The digital signature allows the 308 receiver of the message to verify that it was exactly the same as 309 when the sender signed it. 311 The Use of RSA/SHA-1 Signatures with ESP and AH June, 2005 313 o Host authentication. The asymmetric nature of the RSA public key 314 algorithm allows the sender to be uniquely verified, even when the 315 message is sent to a group. 317 Non-repudiation is not claimed as a property of this transform. At 318 times, the property of non-repudiation may be applied to digital 319 signatures on application level objects (e.g., electronic mail). 320 However, this document describes a means of authenticating network 321 level objects (i.e., IP packets), which are ephemeral and not 322 directly correlated to any application. Non-repudiation is not 323 applicable to network level objects (i.e., IP packets). 325 A number of attacks are suggested by [RFC3552]. The following 326 sections describe the risks those attacks present when RSA signatures 327 are used for ESP and AH packet authentication. 329 6.1 Eavesdropping 331 This document does not address confidentiality. That function, if 332 desired, must be addressed by an ESP cipher that is used with the RSA 333 Signatures authentication method. The RSA signature itself does not 334 need to be protected from an eavesdropper. 336 6.2 Replay 338 This document does not address replay attacks. That function, if 339 desired, is addressed through use of ESP and AH sequence numbers as 340 defined in [ESP] and [AH]. 342 6.3 Message Insertion 344 This document directly addresses message insertion attacks. Inserted 345 messages will fail authentication and be dropped by the receiver. 347 6.4 Deletion 349 This document does not address deletion attacks. It is only concerned 350 with validating the legitimacy of messages that are not deleted. 352 6.5 Modification 354 This document directly addresses message modification attacks. 355 Modified messages will fail authentication and be dropped by the 356 receiver. 358 6.6 Man in the middle 360 As long as a receiver is given the sender RSA public key in a trusted 361 manner (e.g., by a key management protocol), it will be able to 362 verify that the digital signature is correct. A man in the middle 363 The Use of RSA/SHA-1 Signatures with ESP and AH June, 2005 365 will not be able to spoof the actual sender unless it acquires the 366 RSA private key through some means. 368 The RSA modulus size must be chosen carefully to ensure that the time 369 a man in the middle needs to determine the RSA private key through 370 cryptanalysis is longer than the amount of time that packets are 371 signed with that private key. 373 6.7 Denial of Service 375 According to IPsec processing rules, a receiver of an ESP and AH 376 packet begins by looking up the Security Association in the SADB. If 377 one is found, the ESP or AH sequence number in the packet is 378 verified. No further processing will be applied to packets with an 379 invalid sequence number. 381 An attacker that sends an ESP or AH packet matching a valid SA on the 382 system and also having a valid sequence number will cause the 383 receiver to perform the ESP or AH authentication step. Because the 384 process of verifying an RSA digital signature consumes relatively 385 large amounts of processing, many such packets could lead to a denial 386 of service attack on the receiver. 388 If the message was sent to an IPv4 or IPv6 multicast group all group 389 members that received the packet would be under attack 390 simultaneously. 392 This attack can be mitigated against most attackers by encapsulating 393 ESP or AH using an RSA Signature for authentication within ESP or AH 394 using an HMAC transform for authentication. In this case, the HMAC 395 transform would be validated first, and as long as the attacker does 396 not possess the HMAC key no digital signatures would be evaluated on 397 the attacker packets. However, if the attacker does possess the HMAC 398 key (e.g., they are a legitimate member of the group using the SA) 399 then the DoS attack cannot be mitigated. 401 7.0 IANA Considerations 403 An assigned number is required in the "IPSec Authentication 404 Algorithm" name space in the ISAKMP registry [ISAKMP-REG]. The 405 mnemonic should be "SIG-RSA". 407 An assigned number is also required in the "IPSEC AH Transform 408 Identifiers" name space in the ISAKMP registry. Its mnemonic should 409 be "AH-RSA". 411 A new "IPSEC Security Association Attribute" is required in the 412 ISAKMP registry to pass the RSA modulus size. The attribute class 413 should be called "Authentication Key Length", and it should a 414 Variable type. 416 The Use of RSA/SHA-1 Signatures with ESP and AH June, 2005 418 A second "IPSEC Security Association Attribute" is required in the 419 ISAKMP registry to pass the RSA signature encoding type. The 420 attribute class should be called "Signature Encoding Algorithm", and 421 it should be a Basic type. The following rules apply to define the 422 values of the attribute: 424 Name Value 425 ---- ----- 426 Reserved 0 427 RSASSA-PKCS1-v1_5 1 428 RSASSA-PSS 2 430 Values 3-61439 are reserved to IANA. New values MUST be added due to 431 a Standards Action as defined in [RFC2434]. Values 61440-65535 are 432 for private use and may be allocated by implementations for their own 433 purposes. 435 8.0 Acknowledgements 437 Scott Fluhrer and David McGrew provided advice regarding applicable 438 key sizes. Scott Fluhrer also provided advice regarding key 439 lifetimes. Ian Jackson, Steve Kent, and Ran Canetti provided many 440 helpful comments. Sam Hartman, Russ Housley, and Lakshminth Dondeti 441 provided valuable guidance in the development of this document. 443 9.0 References 445 9.1 Normative References 447 [AH] Kent, S., "IP Authentication Header", draft-ietf-ipsec- 448 rfc2402bis-10.txt, December 2004. 450 [ESP] Kent, S., "IP Encapsulating Security Payload (ESP)", draft- 451 ietf-ipsec-esp-v3-09.txt, September2004. 453 [ISAKMP-REG] http://www.iana.org/assignments/isakmp-registry 455 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 456 Requirement Level", BCP 14, RFC 2119, March 1997. 458 [RFC3552] E. Rescorla, et. al., "Guidelines for Writing RFC Text on 459 Security Considerations", RFC 3552, July 2003. 461 [RSA] Jonsson, J., B. Kaliski, "Public-Key Cryptography Standard 462 (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC 3447, 463 February 2003. 465 [SHA] FIPS PUB 180-2: Specifications for the Secure Hash Standard, 466 August 2002. 467 http://csrc.nist.gov/publications/fips/fips180-2/fips180-2.pdf. 469 The Use of RSA/SHA-1 Signatures with ESP and AH June, 2005 471 9.2 Informative References 473 [AES-GCM] Viega, J., and D. McGrew, "The Use of Galois/Counter Mode 474 (GCM) in IPsec ESP", draft-ietf-ipsec-ciph-aes-gcm-00.txt, April 27, 475 2004. 477 [GDOI] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The Group 478 Domain of Interpretation", RFC 3547, December 2002. 480 [HMAC-SHA] Madson, C., and R. Glenn, "The Use of HMAC-SHA-1-96 within 481 ESP and AH", RFC 2404, November 1998. 483 [IKEV2] C. Kaufman, "Internet Key Exchange (IKEv2) Protocol", draft- 484 ietf-ipsec-ikev2-17.txt, September 23, 2004. 486 [RSA-TR] B. Kaliski, "TWIRL and RSA Key Size", RSA Laboratories 487 Technical Note, http://www.rsasecurity.com/rsalabs/node.asp?id=2004, 488 May 6, 2003. 490 [TWIRL] Shamir, A., and E. Tromer, "Factoring Large Numbers with the 491 TwIRL Device", Draft, February 9, 2003. 493 Author's Address 495 Brian Weis 496 Cisco Systems 497 170 W. Tasman Drive, 498 San Jose, CA 95134-1706, USA 499 (408) 526-4796 500 bew@cisco.com 502 Full Copyright Statement 504 Copyright (C) The Internet Society (2005). 506 This document is subject to the rights, licenses and restrictions 507 contained in BCP 78, and except as set forth therein, the authors 508 retain all their rights. 510 This document and the information contained herein are provided on an 511 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 512 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 513 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 514 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 515 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 516 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 518 The Use of RSA/SHA-1 Signatures with ESP and AH June, 2005 520 Intellectual Property 522 The IETF takes no position regarding the validity or scope of any 523 Intellectual Property Rights or other rights that might be claimed 524 to pertain to the implementation or use of the technology 525 described in this document or the extent to which any license 526 under such rights might or might not be available; nor does it 527 represent that it has made any independent effort to identify any 528 such rights. Information on the procedures with respect to rights 529 in RFC documents can be found in BCP 78 and BCP 79. 531 Copies of IPR disclosures made to the IETF Secretariat and any 532 assurances of licenses to be made available, or the result of an 533 attempt made to obtain a general license or permission for the use 534 of such proprietary rights by implementers or users of this 535 specification can be obtained from the IETF on-line IPR repository 536 at http://www.ietf.org/ipr. 538 The IETF invites any interested party to bring to its attention 539 any copyrights, patents or patent applications, or other 540 proprietary rights that may cover technology that may be required 541 to implement this standard. Please address the information to the 542 IETF at ietf-ipr@ietf.org. 544 Acknowledgement 546 Funding for the RFC Editor function is currently provided by the 547 Internet Society.