One document matched: draft-ietf-msec-ipsec-signatures-05.txt
Differences from draft-ietf-msec-ipsec-signatures-04.txt
Internet Engineering Task Force Brian Weis
INTERNET-DRAFT Cisco Systems
Document: draft-ietf-msec-ipsec-signatures-05.txt May, 2005
Expires: November, 2005
The Use of RSA/SHA-1 Signatures within ESP and AH
Status of this Memo
By submitting this Internet-Draft, each author represents that
any applicable patent or other IPR claims of which he or she is
aware have been or will be disclosed, and any of which he or she
becomes aware will be disclosed, in accordance with Section 6 of
BCP 79.
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 Digital Signature algorithm as
an authentication algorithm within the revised IP Encapsulating
Security Payload (ESP) as described in RFC XXXX and the revised IP
Authentication Header (AH) as described in RFC YYYY. The use of a
digital signature algorithm, such as RSA, provides data origin
authentication in applications when a secret key method (e.g., HMAC)
does not provide this property. One example is the use of ESP and AH
to authenticate the sender of an IP multicast packet.
-- Note to RFC Editor: Please replace RFC XXXX with the RFC
-- number that is assigned to draft-ietf-ipsec-esp-v3 and
-- replace RFC YYYY with the RFC number assigned to
-- draft-ietf-ipsec-rfc2402bis. Please also modify normative
-- references [ESP] and [AH] that point to these drafts with
-- their respective RFC numbers. Lastly, informative references
-- [IKEV2] and [AES-GCM] should be changed to their assigned
-- RFC numbers, assuming they are published before this
-- document.
Weis Expires November, 2005 [Page 1]
The Use of RSA Signatures with ESP and AH May, 2005
Table of Contents
1.0 Introduction.......................................................2
2.0 Algorithm and Mode.................................................3
2.1 Key size discussion..............................................4
3.0 Performance........................................................4
4.0 Interaction with the ESP Cipher Mechanism..........................5
5.0 Key Management Considerations......................................5
6.0 Security Considerations............................................6
6.1 Eavesdropping....................................................7
6.2 Replay...........................................................7
6.3 Message Insertion................................................7
6.4 Deletion.........................................................7
6.5 Modification.....................................................7
6.6 Man in the middle................................................7
6.7 Denial of Service................................................7
7.0 IANA Considerations................................................8
8.0 Acknowledgements...................................................8
9.0 References.........................................................9
9.1 Normative References.............................................9
9.2 Informative References...........................................9
Author's Address......................................................10
Full Copyright Statement..............................................10
Intellectual Property.................................................10
1.0 Introduction
Encapsulating Security Payload (ESP) [ESP] and Authentication Header
(AH) [AH] headers can be used to protect both unicast traffic and
group (e.g., IPv4 and IPv6 multicast) traffic. When unicast traffic
is protected between a pair of entities, HMAC transforms (such as
[HMAC-SHA]) are sufficient to prove data origin authentication. An
HMAC is sufficient protection in that scenario because only the two
entities involved in the communication have access to the key, and
proof-of-possession of the key in the HMAC construct authenticates
the sender. However when ESP and AH authenticate group traffic, this
property no longer holds because all group members share the single
HMAC key. In the group case the identity of the sender is not
uniquely established, since any of the key holders has the ability to
form the HMAC transform. Although the HMAC transform establishes a
group-level security property, data origin authentication is not
achieved.
Some group applications require true data origin authentication,
where one group member cannot successfully impersonate another group
member. The use of asymmetric digital signature algorithms, such as
RSA, can provide true data origin authentication.
Weis Expires November, 2005 [Page 2]
The Use of RSA Signatures with ESP and AH May, 2005
With asymmetric algorithms, 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
the private key is used to sign the output of a cryptographic hash
algorithm, the result is called a "digital signature". A receiver of
the digital signature uses the public key, the signature value, and
an independently computed hash to determine whether or not the
claimed origin of the packet is correct.
This memo describes how RSA digital signatures can be applied as an
ESP and AH authentication mechanism to provide data origin
authentication.
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
efficient. This property is useful for groups where receivers may
have limited processing capabilities. The RSA algorithm is commonly
supported in hardware.
Two digital signatures encoding methods are supported in [RSA].
RSASSA-PKCS1-v1_5 MUST be supported by a conforming implementation.
RSASSA-PSS is generally believed to be more secure, but at the time
of this writing is not ubiquitous. Furthermore, the RSASSA-PSS method
of appending a salt (as opposed to prepended a salt) does not offer
extra protection against collisions. RSASSA-PSS SHOULD be used
whenever it is available. SHA-1 MUST be used as the signature hash
algorithm used by the RSA digital signature algorithm. No ICV Padding
bits are necessary.
The distribution mechanism of the RSA public key and its replacement
interval are a group policy matter. The use of an ephemeral key pair
with a lifetime of the ESP or AH SA is RECOMMENDED. This recommended
policy reduces the exposure of the RSA private key to the lifetime of
the data being signed by the private key. Also, this obviates the
need to revoke or transmit the validity period of the key pair.
Digital signature generation is performed as described in [RSA,
Section 8.1.1] (RSASSA-PSS) and [RSA, Section 8.2.1](RSASSA-PKCS1-
v1_5). The authenticated portion of the AH or ESP packet is given to
the signature generation function, along with the signer's RSA
private key. Summarizing, the signature generation process computes a
SHA-1 hash of the authenticated packet bytes, signs the SHA-1 hash
using the private key, and encodes the result with the specified RSA
encoding type. This process results in an authenticator value that is
equal to the size of the RSA modulus.
Weis Expires November, 2005 [Page 3]
The Use of RSA Signatures with ESP and AH May, 2005
Digital signature verification is performed as described in [RSA,
Section 8.1.2] (RSASSA-PSS) and [RSA, Section 8.2.2](RSASSA-PKCS1-
v1_5). Upon receipt, the authenticator value is given to the
verification function along with the authenticated portion of the AH
or ESP packet and the public key. In summary, the verification
function computes a SHA-1 hash of the authenticated packet bytes,
decrypts the SHA-1 hash in the authenticator value, and validates
that the appropriate encoding was applied and was correct. The two
SHA-1 hashes are compared, and if they are identical the validation
is successful.
2.1 Key size discussion
The choice of RSA modulus size must be made carefully. If too small
of a modulus size is chosen, an attacker may be able to reconstruct
the private key used to sign packets before the key is no longer used
by the sender to sign packets. This order of events may result in the
data origin authentication property being compromised. However,
choosing a modulus size larger than necessary will result in an
unnecessarily high cost of CPU cycles for the sender and all
receivers of the packet.
A conforming implementation MUST support a modulus size of 1024 bits.
Recent guidance [TWIRL, RSA-TR] on key sizes make estimates as to the
amount of effort an attacker would need to expend in order to
reconstruct an RSA private key. Table 1 summarizes the maximum length
of time that selected modulus sizes should be used. Note that these
recommendations are based on factors such as the cost of processing
and memory, as well as cryptographic analysis methods, which were
current at the time these documents were published. As those factors
change, choices of key lifetimes should take them into account.
Number of Recommended Maximum
Modulus Bits Lifetime
------------ -------------------
768 1 week
1024 1 year
Table 1. RSA Key Use Lifetime Recommendations
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.
Weis Expires November, 2005 [Page 4]
The Use of RSA Signatures with ESP and AH May, 2005
Care should be taken that RSA signatures are not used for
applications when potential receivers are known to lack sufficient
processing power to verify the signature. It is also important to use
this scheme judiciously when any receiver may be battery powered.
The RSA asymmetric key algorithm is best suited to protect network
traffic for which:
o The sender has a substantial amount of processing power, and
o The network traffic is small enough that adding a relatively large
authentication tag (in the range of 62 to 256 bytes) does not
cause packet fragmentation.
RSA key pair generation and signing are substantially more expensive
operations than signature verification, but these are isolated to the
sender.
The size of the RSA modulus affects the processing required to create
and verify RSA digital signatures. Care should be taken to determine
the size of modulus needed for the application. Smaller modulus
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 that store the signed data
for a period of time. But since the digital signature is used only
for sender verification purposes, a modulus that is considered weak
in another context may be satisfactory.
The size of the RSA public exponent can affect the processing
required to verify RSA digital signatures. Low-exponent RSA
signatures may result in a lower verification processing cost. At the
time of this writing, no attacks are known against low-exponent RSA
signatures that would allow an attacker to create a valid signature
using the RSAES-OAEP raw RSA scheme.
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 ESP or AH may be
fragmented.
4.0 Interaction with the ESP Cipher Mechanism
The RSA signatures algorithm cannot be used with an ESP Combined Mode
algorithm that includes an explicit ICV. The Combined Mode algorithm
will add the ESP ICV field, which does not allow use of a separate
authentication algorithm to add the ESP ICV field. One example of
such an algorithm is the ESP Galois/Counter Mode algorithm [AES-GCM].
5.0 Key Management Considerations
Weis Expires November, 2005 [Page 5]
The Use of RSA Signatures with ESP and AH May, 2005
Key management mechanisms negotiating the use of RSA Signatures MUST
include the length of the RSA modulus during policy negotiation using
the Authentication Key Length SA Attribute. This gives a device the
opportunity to decline use of the algorithm. This is especially
important for devices with constrained processors that might not be
able to verify signatures using larger key sizes.
Key management mechanisms negotiating the use of RSA Signatures also
MUST include the encoding method during policy negotiation using the
Signature Encoding Algorithm SA Attribute.
A receiver must have the RSA public key in order to verify integrity
of the packet. When used with a group key management system (e.g.,
RFC 3547 [GDOI]), the public key SHOULD be 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.
Use of this transform to obtain data origin authentication for
pairwise SAs is NOT RECOMMENDED. In the case of pairwise SAs (such as
negotiated by the Internet Key Exchange [IKEv2]), data origin
authentication can be achieved with an HMAC transform. Because the
performance impact of an RSA signature is typically greater than an
HMAC, the value of using this transform for a pairwise connection is
limited.
6.0 Security Considerations
This document provides a method of authentication for ESP and AH
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.
Non-repudiation is not claimed as a property of this transform. At
times, the property of non-repudiation may be applied to digital
signatures on application level objects (e.g., electronic mail).
However, this document describes a means of authenticating network
level objects (i.e., IP packets), which are ephemeral and not
directly correlated to any application. Non-repudiation is not
applicable to network level objects (i.e., IP packets).
A number of attacks are suggested by [RFC3552]. The following
sections describe the risks those attacks present when RSA signatures
are used for ESP and AH packet authentication.
Weis Expires November, 2005 [Page 6]
The Use of RSA Signatures with ESP and AH May, 2005
6.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 from an eavesdropper.
6.2 Replay
This document does not address replay attacks. That function, if
desired, is addressed through use of ESP and AH sequence numbers as
defined in [ESP] and [AH].
6.3 Message Insertion
This document directly addresses message insertion attacks. Inserted
messages will fail authentication and be dropped by the receiver.
6.4 Deletion
This document does not address deletion attacks. It is only concerned
with validating the legitimacy of messages that are not deleted.
6.5 Modification
This document directly addresses message modification attacks.
Modified messages will fail authentication and be dropped by the
receiver.
6.6 Man in the middle
As long as a receiver is given the sender RSA public key in a trusted
manner (e.g., by a key management protocol), 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.
The RSA modulus size must be chosen carefully to ensure that the time
a man in the middle needs to determine the RSA private key through
cryptanalysis is longer than the amount of time that packets are
signed with that private key.
6.7 Denial of Service
According to IPsec processing rules, a receiver of an ESP and AH
packet begins by looking up the Security Association in the SADB. If
one is found, the ESP or AH sequence number in the packet is
verified. No further processing will be applied to packets with an
invalid sequence number.
An attacker that sends an ESP or AH packet matching a valid SA on the
system and also having a valid sequence number will cause the
Weis Expires November, 2005 [Page 7]
The Use of RSA Signatures with ESP and AH May, 2005
receiver to perform the ESP or AH authentication step. Because the
process of verifying an RSA digital signature consumes relatively
large amounts of processing, many such packets could lead to a denial
of service attack on the receiver.
If the message was sent to an IPv4 or IPv6 multicast group all group
members that received the packet would be under attack
simultaneously.
This attack can be mitigated against most attackers by encapsulating
ESP or AH using an RSA Signature for authentication within ESP or AH
using an HMAC transform for authentication. In this case, the HMAC
transform would be validated first, and as long as the attacker does
not possess the HMAC key no digital signatures would be evaluated on
the attacker packets. However, if the attacker does possess the HMAC
key (e.g., they are a legitimate member of the group using the SA)
then the DoS attack cannot be mitigated.
7.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".
An assigned number is also required in the "IPSEC AH Transform
Identifiers" name space in the ISAKMP registry. Its mnemonic should
be "AH-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.
A second "IPSEC Security Association Attribute" is required in the
ISAKMP registry to pass the RSA signature encoding type. The
attribute class should be called "Signature Encoding Algorithm", and
it should be a Basic type. The following rules apply to define the
values of the attribute:
Name Value
---- -----
Reserved 0
RSASSA-PKCS1-v1_5 1
RSASSA-PSS 2
Values 3-61439 are reserved to IANA. New values MUST be added due to
a Standards Action as defined in [RFC2434]. Values 61440-65535 are
for private use and may be allocated by implementations for their own
purposes.
8.0 Acknowledgements
Weis Expires November, 2005 [Page 8]
The Use of RSA Signatures with ESP and AH May, 2005
Scott Fluhrer and David McGrew provided advice regarding applicable
key sizes. Scott Fluhrer also provided advice regarding key
lifetimes.
9.0 References
9.1 Normative References
[AH] Kent, S., "IP Authentication Header", draft-ietf-ipsec-
rfc2402bis-10.txt, December 2004.
[ESP] Kent, S., "IP Encapsulating Security Payload (ESP)", draft-
ietf-ipsec-esp-v3-09.txt, September2004.
[ISAKMP-REG] http://www.iana.org/assignments/isakmp-registry
[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, "Public-Key Cryptography Standard
(PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC 3447,
February 2003.
[SHA] FIPS PUB 180-2: Specifications for the Secure Hash Standard,
August 2002.
http://csrc.nist.gov/publications/fips/fips180-2/fips180-2.pdf.
9.2 Informative References
[AES-GCM] Viega, J., and D. McGrew, "The Use of Galois/Counter Mode
(GCM) in IPsec ESP", draft-ietf-ipsec-ciph-aes-gcm-00.txt, April 27,
2004.
[GDOI] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The Group
Domain of Interpretation", RFC 3547, December 2002.
[HMAC-SHA] Madson, C., and R. Glenn, "The Use of HMAC-SHA-1-96 within
ESP and AH", RFC 2404, November 1998.
[IKEV2] C. Kaufman, "Internet Key Exchange (IKEv2) Protocol", draft-
ietf-ipsec-ikev2-17.txt, September 23, 2004.
[RSA-TR] B. Kaliski, "TWIRL and RSA Key Size", RSA Laboratories
Technical Note, http://www.rsasecurity.com/rsalabs/node.asp?id=2004,
May 6, 2003.
[TWIRL] Shamir, A., and E. Tromer, "Factoring Large Numbers with the
TwIRL Device", Draft, February 9, 2003.
Weis Expires November, 2005 [Page 9]
The Use of RSA Signatures with ESP and AH May, 2005
Author's Address
Brian Weis
Cisco Systems
170 W. Tasman Drive,
San Jose, CA 95134-1706, USA
(408) 526-4796
bew@cisco.com
Full Copyright Statement
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology
described in this document or the extent to which any license
under such rights might or might not be available; nor does it
represent that it has made any independent effort to identify any
such rights. Information on the procedures with respect to rights
in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention
any copyrights, patents or patent applications, or other
proprietary rights that may cover technology that may be required
to implement this standard. Please address the information to the
IETF at ietf-ipr@ietf.org.
Acknowledgement
Weis Expires November, 2005 [Page 10]
The Use of RSA Signatures with ESP and AH May, 2005
Funding for the RFC Editor function is currently provided by the
Internet Society.
Weis Expires November, 2005 [Page 11]
| PAFTECH AB 2003-2026 | 2026-04-23 06:04:28 |