One document matched: draft-ietf-msec-ipsec-signatures-02.txt
Differences from draft-ietf-msec-ipsec-signatures-01.txt
Internet Engineering Task Force Brian Weis
INTERNET-DRAFT Cisco Systems
Document: draft-ietf-msec-ipsec-signatures-02.txt October, 2004
Expires: April, 2005
The Use of RSA Signatures within ESP and AH
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
RFC 3668.
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
[RSA] as an authentication algorithm within the revised IP
Encapsulating Security Payload [ESP] and the revised IP
Authentication Header [AH]. The use of a digital signature algorithm,
such as RSA, provides data origin authentication in applications when
a secret key method (e.g., HMAC) is not sufficient. One example is
the use of ESP and AH to authenticate the sender of an IP multicast
packet.
Further information on the other components necessary for ESP and AH
implementations is provided by [ROADMAP].
Weis Expires April, 2005 1
The Use of RSA Signatures with ESP and AH October, 2004
Table of Contents
1.0 Introduction......................................................2
2.0 Algorithm and Mode................................................3
3.0 Performance.......................................................4
4.0 Interaction with the ESP Cipher Mechanism.........................4
5.0 Key Management Considerations.....................................5
6.0 Security Considerations...........................................5
6.1 Eavesdropping...................................................5
6.2 Replay..........................................................6
6.3 Message Insertion...............................................6
6.4 Deletion........................................................6
6.5 Modification....................................................6
6.6 Man in the middle...............................................6
6.7 Denial of Service...............................................6
7.0 IANA Considerations...............................................7
8.0 Acknowledgements..................................................7
9.0 References........................................................7
9.1 Normative References............................................7
9.2 Informative References..........................................8
Authors Address.......................................................8
Full Copyright Statement..............................................8
1.0 Introduction
AH and ESP 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] and [HMAC-MD5]) are sufficient to prove data origin
authentication. An HMAC is sufficient protection in that scenario
because only one other entity knows the key, and proof-of-possession
of the key in the HMAC construct authenticates the sender. However
when AH and ESP authenticate group traffic, this property is no
longer valid. This is because all group members share the single HMAC
key and the identity of the sender is not uniquely established.
Some group applications require true data origin authentication,
where one group member cannot successfully impersonate another group
member. The use of asymmetric encryption algorithms, such as RSA, to
create a digital signature can provide true data origin
authentication.
With asymmetric encryption 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 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, which is then compared to a hash generated by
Weis Expires April, 2005 2
The Use of RSA Signatures with ESP and AH October, 2004
the receiver. If the hashes match, then the receiver has confidence
in the claimed origin of the packet.
This memo describes how RSA digital signatures can be applied as an
authentication mechanism to AH and ESP payloads 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, and is not encumbered by any known
intellectual property claims.
Several schemes for the RSA algorithm are described in [RSA]. Two
schemes (RSASSA-PKCS1-v1.5 and RSASSA-PSS) combine the generation of
a hash from a message, and the signing of that hash. However, this
combination of cryptographic operations is not always appropriate for
IPsec, where a variety of hardware and software modules may be used.
In addition, one signature method (RSASSA-PPKCS1-v1.5) encodes the
hash type into the signature data block, and this encoding is not
necessary because the hash algorithm is pre-determined in IPsec.
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 distribution mechanism of the RSA public key and its replacement
interval are a local policy matter. The use of an ephemeral key pair
with a lifetime of the AH or ESP 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.
The size of the RSA modulus 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].) Note that when an ephemeral RSA key pair is
used, a relatively short key size may be acceptable because it only
need be valid for the lifetime of the IPsec SA.
Weis Expires April, 2005 3
The Use of RSA Signatures with ESP and AH October, 2004
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 which:
o The sender has a substantial amount of processing power, whereas
receivers are not guaranteed to have substantial 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 encryption (or signing) are substantially
more expensive operations the decryption (or signature verification),
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 modulus is 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 normally considered weak 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 AH or ESP may be
fragmented.
4.0 Interaction with the ESP Cipher Mechanism
There are no known issues that preclude the use of the RSA
signatures algorithm with any specific cipher algorithm.
Weis Expires April, 2005 4
The Use of RSA Signatures with ESP and AH October, 2004
5.0 Key Management Considerations
Key management mechanisms negotiating the use of RSA Signatures MUST
include the length of the RSA modulus during policy negotiation. 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.
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 pair-
wise SAs is NOT RECOMMENDED. In the case of pair-wise 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 pair-wise connection is
limited..
6.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.
Non-repudiation is not claimed as a property of this transform. Note
that although the sender can be uniquely verified through the use of
the public key, the transform itself does not provide any method of
certifying that the identity of the sender is associated with the RSA
key pair. Such a certification would be necessary in order to claim
non-repudiation, and is outside the scope of this document.
A number of attacks are suggested by [RFC3552]. The following
sections describe the risks those attacks present when RSA signatures
are used for AH and ESP packet authentication.
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
Weis Expires April, 2005 5
The Use of RSA Signatures with ESP and AH October, 2004
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 AH and ESP sequence numbers as
defined in [AH] and [ESP].
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
receiver to perform the AH or ESP 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.
Weis Expires April, 2005 6
The Use of RSA Signatures with ESP and AH October, 2004
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
an ESP or AH payload in an AH payload 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".
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.
8.0 Acknowledgements
Scott Fluhrer and David McGrew provided advice regarding applicable
key sizes.
9.0 References
9.1 Normative References
[AH] Kent, S., "IP Authentication Header", draft-ietf-ipsec-
rfc2402bis-07.txt, March 2004.
[ESP] Kent, S., "IP Encapsulating Security Payload (ESP)", draft-
ietf-ipsec-esp-v3-08.txt, March 2004.
[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.
[ROADMAP] Thayer, R., Doraswamy, N., and R. Glenn, "IP Security
Document Roadmap", RFC 2411, November 1998.
Weis Expires April, 2005 7
The Use of RSA Signatures with ESP and AH October, 2004
[RSA] Jonsson, J., B. Kaliski, "Public-Key Cryptography Standard
(PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC 3447,
February 2003.
9.2 Informative References
[GDOI] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The Group
Domain of Interpretation", RFC 3547, December 2002.
[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.
[IKEV2] C. Kaufman, "Internet Key Exchange (IKEv2) Protocol", draft-
ietf-ipsec-ikev2-15.txt, August 13, 2004.
Authors 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 (2004). 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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Weis Expires April, 2005 8 | PAFTECH AB 2003-2026 | 2026-04-23 17:19:41 |