Internet DRAFT - draft-bew-ipsec-signatures

draft-bew-ipsec-signatures





   Internet Engineering Task Force                                   Brian Weis 
   INTERNET-DRAFT                                                 Cisco Systems 
   Document: draft-bew-ipsec-signatures-01.txt                     August, 2003 
   Expires: February, 2004                                                      
                                                                                
 
                The Use of RSA Signatures within ESP and AH  
 
Status of this Memo 
                                      
   This document is an Internet-Draft and is in full conformance with 
   all provisions of Section 10 of RFC2026. 
    
   Internet-Drafts are working documents of the Internet       
   Engineering Task Force (IETF), its areas, and its working groups.  
   Note that other groups may also distribute working documents as  
   Internet Drafts. 
    
   Internet-Drafts are draft documents valid for a maximum of six months 
   and may be updated, replaced, or obsoleted by other documents at any 
   time.  It is inappropriate to use Internet-Drafts as reference 
   material or to cite them other than as "work in progress." 
    
   The list of current Internet-Drafts can be accessed at 
        http://www.ietf.org/ietf/1id-abstracts.txt 
     
   The list of Internet-Draft Shadow Directories can be accessed at 
        http://www.ietf.org/shadow.html. 
    
Abstract 
    
   This memo describes the use of the RSA Signature algorithm [RSA] as 
   an authentication algorithm within the revised IPSEC Encapsulating 
   Security Payload [ESP] and the revised IPSEC Authentication Header 
   [AH]. The use of a digital signature algorithm such as RSA provides 
   origin authentication, even when ESP and AH are used to secure group 
   data flows. 
    
   Further information on the other components necessary for ESP and AH 
   implementations is provided by [ROADMAP]. 
 
    
    
    
    
    
    
    
    
     
   Weis                 Expires February, 2004                       1 
              The Use of RSA Signatures with ESP and AH  August, 2003 
    
    
Table of Contents 
    
1.0 Introduction......................................................2 
2.0 Algorithm and Mode................................................3 
3.0 Performance.......................................................3 
4.0 Interaction with the ESP Cipher Mechanism.........................4 
5.0 Security Association Considerations for Group Traffic.............4 
6.0 Key Management Considerations.....................................4 
7.0 Security Considerations...........................................5 
  7.1 Eavesdropping...................................................5 
  7.2 Replay..........................................................5 
  7.3 Message Insertion...............................................5 
  7.4 Deletion........................................................5 
  7.5 Modification....................................................6 
  7.6 Man in the middle...............................................6 
  7.7 Denial of Service...............................................6 
8.0 IANA Considerations...............................................6 
9.0 Acknowledgements..................................................6 
10.0 References.......................................................7 
  10.1 Normative References...........................................7 
  10.2 Informative References.........................................7 
Authors Addresses.....................................................7 
 
1.0 Introduction 
    
   AH and ESP payloads can be used to protect unicast traffic, or group 
   traffic, such as IPv4 and IPv6 multicast traffic. When unicast 
   traffic is protected between a pair of entities, HMAC transforms 
   (such as [HMAC-SHA] and [HMAC-MD5]) are sufficient to prove source 
   authentication. An HMAC is strong enough in that scenario because 
   only one other entity knows the key. However when AH and ESP protect 
   group traffic, this property is no longer valid -- all group members 
   share the single HMAC key and thus can spoof one another.  
    
   Some multicast applications require true origin authentication, where 
   one group member cannot be spoofed by another group member without 
   detection. The use of asymmetric encryption algorithms, such as RSA, 
   can provide true origin authentication. The sender generates a pair 
   of keys, one of which is never shared (called the "private key") and 
   one of which is distributed to other group members (called the 
   "public key"). 
    
   When an asymmetric encryption algorithm is used to encrypt the output 
   of a cryptographic hash algorithm, the cipher text is called a 
   "digital signature". A receiver of the digital signature uses the 
   public key to decrypt the hash. 
    
   This memo describes how RSA digital signatures can be applied as an 
   authentication mechanism to AH and ESP payloads to provide origin 
   authentication. 
     
   Weis                 Expires February, 2004                       2 
              The Use of RSA Signatures with ESP and AH  August, 2003 
    
    
    
   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 
   NOT","SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in 
   this document are to be interpreted as described in [RFC2119]. 
                              
2.0 Algorithm and Mode 
    
   The RSA Public Key Algorithm [RSA] is a widely deployed public key 
   algorithm commonly used for digital signatures. Compared to other 
   public key algorithms, signature verification is relatively quick. 
   This property is useful for groups where receivers may have limited 
   processing capabilities. The RSA Algorithm is commonly supported in 
   hardware, and is no longer encumbered by intellectual property 
   claims. 
    
   Several schemes for the RSA Algorithm are described in [RSA]. One 
   scheme exists specifically for digital signatures. However, that 
   scheme is not the most efficient for this application. In addition, 
   the signature scheme encodes the hash type into the signature data 
   block, and this is not necessary because the hash algorithm is pre-
   determined.  
    
   The RSAES-OAEP raw RSA scheme [RSA, Section 7.1] MUST be used as the 
   encryption scheme. As recommended in [RSA, Section B.1], SHA-1 MUST 
   be used as the signature hash algorithm both as the message to be 
   encrypted by the RSA Algorithm, and as the encoding parameter for the 
   OAEP encoding. The value of parameter string P MUST be the default, 
   which is the hash of an empty string. The mask generation function 
   MUST be MGF1 as defined in [RSA, Section B.2.1]. 
    
   The size of the RSA modulus used can vary, but MUST be at least 496 
   bits. This restriction is a function of the size of the SHA-1 hash 
   and the number of bits needed for OAEP encapsulation. (For more 
   information, see [RSA, Section 7.1].) 
    
3.0 Performance 
    
   The RSA asymmetric key algorithm is very costly in terms of 
   processing time compared to the HMAC algorithms. However, processing 
   cost is decreasing over time. Faster general-purpose processors are 
   being deployed, faster software implementations are being developed, 
   and hardware acceleration support for the algorithm is becoming more 
   prevalent. However, care should always be taken that RSA signatures 
   are not used for applications that expect to have bandwidth 
   requirements that would be adversely affected. 
    
   The RSA asymmetric key algorithm is best suited to protect network 
   traffic for network traffic for which: 
    
   o  the sender has a substantial amount of processing power, whereas 
   receivers are not guaranteed to have substantial processing power, 
   and 
    
     
   Weis                 Expires February, 2004                       3 
              The Use of RSA Signatures with ESP and AH  August, 2003 
    
    
   o the network traffic is small enough that adding a relatively large 
   authentication tag (in the range of 61 to 256 bytes) does not cause 
   packet fragmentation. 
    
   Both key pair generation and encryption (or signing) are 
   substantially more expensive operations, but these are isolated to 
   the sender. 
 
   The size of the RSA modulus can affect the processing required to 
   create and verify RSA digital signatures. Care should be taken to 
   determine what the size of key is needed for the application.  
   Smaller key sizes may be chosen as long as the network traffic 
   protected by the private key flows for less time than it is estimated 
   that an attacker would take to discover the private key. This 
   lifetime is considerably smaller than most public key applications, 
   so a key that is normally considered weak may be satisfactory. (If 
   the RSA public key algorithm were used to encrypt the packet, then 
   the lifetime would be substantially longer.) 
 
   The addition of a digital signature as an authentication tag adds a 
   significant number of bytes to the packet. This increases the 
   likelihood that the packet encapsulated in AH or ESP may be 
   fragmented. 
                      
4.0 Interaction with the ESP Cipher Mechanism 
    
   As of this writing, there are no known issues that preclude the use 
   of the RSA signatures algorithm with any specific cipher algorithm. 
    
5.0 Security Association Considerations for Group Traffic 
 
   When RSA Signatures are used to protect group traffic, they MUST be 
   in accordance with the restrictions set forth in the IPSec 
   Architecture [RFC2401] to ensure that security associations remain 
   unique. That is, one of the following two cases: 
    
       o Single sender groups where only one source IPv4 or IPV6 
   address is sending packets to the IP multicast destination address. 
    
       o Multiple sender groups where a single group controller is 
   choosing SPI values for AH and ESP security associations for all 
   group members sending packets to the same IP multicast destination 
   address. 
    
6.0 Key Management Considerations 
    
   The key management mechanism that negotiates the use of RSA 
   Signatures MUST include the length of the RSA modulus during policy 
   negotiation in order to give a device the opportunity to decline. 
   This is especially important for devices with constrained processors 
   that might not be able to handle the verification of signatures using 
   larger key sizes. 
    
     
   Weis                 Expires February, 2004                       4 
              The Use of RSA Signatures with ESP and AH  August, 2003 
    
    
   A receiver must have the RSA public key in order to decrypt the 
   packet. When used with a group key management system such as GDOI 
   [RFC3547], the public key SHOULD be to sent as part of the key 
   download policy. If the group has multiple senders, the public key of 
   each sender SHOULD be sent as part of the key download policy. 
    
   When used with a pair-wise key management system such as IKE 
   [RFC2409] the public key could be passed as an SA attribute. However, 
   given the above performance considerations, the value of using this 
   transform for a pair-wise connection is limited. 
    
7.0 Security Considerations 
    
   This document provides a method of authentication for AH and ESP 
   using digital signatures. This feature provides the following 
   protections: 
    
       o Message modification integrity. The digital signature allows 
   the receiver of the message to verify that it was exactly the same as 
   when the sender signed it. 
    
       o Host authentication. The asymmetric nature of the RSA public 
   key algorithm allows the sender to be uniquely verified, even when 
   the message is sent to a group. 
    
   As suggested by [RFC3552], the following sections describe various 
   attacks that could be deployed against using RSA signatures as a 
   means of authentication. 
    
7.1 Eavesdropping 
 
   This document does not address confidentiality. That function, if 
   desired, must be addressed by an ESP cipher that is used with the 
   RSA Signatures authentication method. The RSA signature itself does 
   not need to be protected in any way. 
    
7.2 Replay 
 
   This document does not address replay attacks. That function, if 
   desired, is addressed through use of AH and ESP sequence numbers as 
   defined in [AH] and [ESP]. 
    
7.3 Message Insertion 
 
   This document directly addresses message insertion attacks. Inserted 
   messages will fail authentication and be dropped by the receiver. 
    
7.4 Deletion 
 
   This document does not address deletion attacks. It is only 
   concerned with validating the legitimacy of messages that are not 
   deleted. 
    
     
   Weis                 Expires February, 2004                       5 
              The Use of RSA Signatures with ESP and AH  August, 2003 
    
    
7.5 Modification 
 
   This document directly addresses message modification attacks. 
   Modified messages will fail authentication and be dropped by the 
   receiver. 
    
7.6 Man in the middle 
 
   As long as a receiver is given the sender RSA public key in a 
   trusted manner, it will be able to verify that the digital signature 
   is correct. A man in the middle will not be able to spoof the actual 
   sender unless it acquires the RSA private key through some means. 
    
   RSA modulus sizes must be chosen carefully to ensure that the time it 
   takes a man in the middle to determine the RSA private key through 
   cryptanalysis is longer than the amount of time that packets are 
   signed with that private key. 
    
7.7 Denial of Service 
 
   A receiver of an ESP and AH packet starts by looking up the Security 
   Association in the SADB. If one is found, the ESP or AH sequence 
   number in the packet is verified. If the sequence number falls 
   within the window, the authentication step is performed. 
    
   An attacker that sends an ESP or AH packet which matches a valid SA 
   on the system and which also has a valid sequence number will cause 
   the receiver to perform the AH or ESP authentication step. Because 
   the process of verifying an RSA digital signature consumes 
   relatively large amounts of processing, this could lead to a denial 
   of service attack on the receiver if many such packets were sent. 
    
   If the message was sent to an IPv4 or IPv6 multicast group all group 
   members that received the packet would be under attack 
   simultaneously. 
    
   Further investigation is needed to better estimate the actual 
   effects of this attack, and how it can be mitigated. 
 
8.0 IANA Considerations 
    
   An assigned number is required in the IPSec Authentication Algorithm 
   name space in the ISAKMP registry [ISAKMP-REG]. The mnemonic should 
   be SIG-RSA. 
    
   A new IPSEC Security Association Attribute is required in the ISAKMP 
   registry to pass the RSA modulus size. The attribute class should be 
   called Authentication Key Length, and it should a Variable type. 
    
9.0 Acknowledgements 
    
   TBD 
    
     
   Weis                 Expires February, 2004                       6 
              The Use of RSA Signatures with ESP and AH  August, 2003 
    
    
10.0 References 
    
10.1 Normative References 
    
   [AH] Kent, S., and R. Atkinson, "IP Authentication Header", RFC 2402, 
   November 1998. 
    
   [ESP] Kent, S., and R. Atkinson, "IP Encapsulating Security Payload", 
   RFC 2406, November 1998. 
 
   [ISAKMP-REG] http://www.iana.org/assignments/isakmp-registry 
    
   [RFC2401] Kent, S., R. Atkinson, "Security Architecture for the 
   Internet Protocol", November 1998  
    
   [ROADMAP] Thayer, R., Doraswamy, N., and R. Glenn, "IP Security 
   Document Roadmap", RFC 2411, November 1998. 
    
   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 
   Requirement Level", BCP 14, RFC 2119, March 1997. 
 
   [RFC3552] E. Rescorla, et. al., Guidelines for Writing RFC Text on 
   Security Considerations, RFC 3552, July 2003. 
 
   [RSA] Jonsson, J., B. Kaliski,  "PKCS #1: RSA Cryptography 
   Specifications Version 2.1", RFC 3447, February 2003. 
    
10.2 Informative References 
    
   [HMAC-MD5] Madson, C., and R. Glenn, "The Use of HMAC-MD5-96 within 
   ESP and AH"", RFC 2403, November, 1998. 
    
   [HMAC-SHA] Madson, C., and R. Glenn, " The Use of HMAC-SHA-1-96 
   within ESP and AH", RFC 2404, November, 1998. 
    
   [RFC3547] M. Baugher, B. Weis, T. Hardjono, H. Harney, , The Group 
   Domain of Interpretation, RFC 3547, December 2002. 
    
    
    
Authors Addresses 
    
   Brian Weis 
   Cisco Systems 
   170 W. Tasman Drive, 
   San Jose, CA 95134-1706, USA 
   (408) 526-4796 
   bew@cisco.com 
     
   Weis                 Expires February, 2004                       7