< draft-ietf-ipsecme-esp-ah-reqts-03.txt   draft-ietf-ipsecme-esp-ah-reqts-04.txt >
Network Working Group D. McGrew Network Working Group D. McGrew
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Obsoletes: 4835 (if approved) W. Feghali Obsoletes: 4835 (if approved) W. Feghali
Intended status: Standards Track Intel Corp. Intended status: Standards Track Intel Corp.
Expires: October 2, 2014 P. Hoffman Expires: October 5, 2014 P. Hoffman
VPN Consortium VPN Consortium
March 31, 2014 April 3, 2014
Cryptographic Algorithm Implementation Requirements and Usage Guidance Cryptographic Algorithm Implementation Requirements and Usage Guidance
for Encapsulating Security Payload (ESP) and Authentication Header (AH) for Encapsulating Security Payload (ESP) and Authentication Header (AH)
draft-ietf-ipsecme-esp-ah-reqts-03 draft-ietf-ipsecme-esp-ah-reqts-04
Abstract Abstract
This Internet Draft is standards track proposal to update to the This Internet Draft is standards track proposal to update to the
Cryptographic Algorithm Implementation Requirements for ESP and AH; Cryptographic Algorithm Implementation Requirements for ESP and AH;
it also adds usage guidance to help in the selection of these it also adds usage guidance to help in the selection of these
algorithms. algorithms.
The Encapsulating Security Payload (ESP) and Authentication Header The Encapsulating Security Payload (ESP) and Authentication Header
(AH) protocols makes use of various cryptographic algorithms to (AH) protocols makes use of various cryptographic algorithms to
skipping to change at page 2, line 4 skipping to change at page 2, line 4
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 2, 2014. This Internet-Draft will expire on October 5, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 36 skipping to change at page 2, line 36
2.1. ESP Authenticated Encryption (Combined Mode Algorithms) . 4 2.1. ESP Authenticated Encryption (Combined Mode Algorithms) . 4
2.2. ESP Encryption Algorithms . . . . . . . . . . . . . . . . 4 2.2. ESP Encryption Algorithms . . . . . . . . . . . . . . . . 4
2.3. ESP Authentication Algorithms . . . . . . . . . . . . . . 4 2.3. ESP Authentication Algorithms . . . . . . . . . . . . . . 4
2.4. AH Authentication Algorithms . . . . . . . . . . . . . . 5 2.4. AH Authentication Algorithms . . . . . . . . . . . . . . 5
2.5. Summary of Changes . . . . . . . . . . . . . . . . . . . 5 2.5. Summary of Changes . . . . . . . . . . . . . . . . . . . 5
3. Usage Guidance . . . . . . . . . . . . . . . . . . . . . . . 5 3. Usage Guidance . . . . . . . . . . . . . . . . . . . . . . . 5
4. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Authenticated Encryption . . . . . . . . . . . . . . . . 6 4.1. Authenticated Encryption . . . . . . . . . . . . . . . . 6
4.2. Encryption Transforms . . . . . . . . . . . . . . . . . . 6 4.2. Encryption Transforms . . . . . . . . . . . . . . . . . . 6
4.3. Authentication Transforms . . . . . . . . . . . . . . . . 7 4.3. Authentication Transforms . . . . . . . . . . . . . . . . 7
5. Algorithm Diversity . . . . . . . . . . . . . . . . . . . . . 7 5. Algorithm Diversity . . . . . . . . . . . . . . . . . . . . . 8
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
9.1. Normative References . . . . . . . . . . . . . . . . . . 9 9.1. Normative References . . . . . . . . . . . . . . . . . . 9
9.2. Informative References . . . . . . . . . . . . . . . . . 9 9.2. Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction 1. Introduction
The Encapsulating Security Payload (ESP) [RFC4303] and the The Encapsulating Security Payload (ESP) [RFC4303] and the
Authentication Header (AH) [RFC4302] are the mechanisms for applying Authentication Header (AH) [RFC4302] are the mechanisms for applying
cryptographic protection to data being sent over an IPsec Security cryptographic protection to data being sent over an IPsec Security
skipping to change at page 5, line 22 skipping to change at page 5, line 22
Algorithms, except that NULL authentication is inapplicable. Algorithms, except that NULL authentication is inapplicable.
2.5. Summary of Changes 2.5. Summary of Changes
Old New Old New
Requirement Requirement Algorithm (notes) Requirement Requirement Algorithm (notes)
---- ----------- ----------------- ---- ----------- -----------------
MAY SHOULD+ AES-GCM with a 16 octet ICV [RFC4106] MAY SHOULD+ AES-GCM with a 16 octet ICV [RFC4106]
MAY SHOULD+ AES-GMAC with AES-128 [RFC4543] MAY SHOULD+ AES-GMAC with AES-128 [RFC4543]
MUST- MAY TripleDES-CBC [RFC2451] MUST- MAY TripleDES-CBC [RFC2451]
SHOULD NOT MUST NOT DES-CBC [RFC2405]
SHOULD+ SHOULD AES-XCBC-MAC-96 [RFC3566] SHOULD+ SHOULD AES-XCBC-MAC-96 [RFC3566]
SHOULD MAY AES-CTR [RFC3686] SHOULD MAY AES-CTR [RFC3686]
3. Usage Guidance 3. Usage Guidance
Since ESP and AH can be used in several different ways, this document Since ESP and AH can be used in several different ways, this document
provides guidance on the best way to utilize these mechanisms. provides guidance on the best way to utilize these mechanisms.
ESP can provide confidentiality, data origin authentication, or the ESP can provide confidentiality, data origin authentication, or the
combination of both of those security services. AH provides only combination of both of those security services. AH provides only
skipping to change at page 6, line 4 skipping to change at page 6, line 7
To provide both confidentiality and authentication, an authenticated To provide both confidentiality and authentication, an authenticated
encryption transform from Section 2.1 SHOULD be used in ESP, in encryption transform from Section 2.1 SHOULD be used in ESP, in
conjunction with NULL authentication. Alternatively, an ESP conjunction with NULL authentication. Alternatively, an ESP
encryption transform and ESP authentication transform MAY be used encryption transform and ESP authentication transform MAY be used
together. It is NOT RECOMMENDED to use ESP with NULL authentication together. It is NOT RECOMMENDED to use ESP with NULL authentication
in conjunction with AH; some configurations of this combination of in conjunction with AH; some configurations of this combination of
services have been shown to be insecure [PD10]. services have been shown to be insecure [PD10].
To provide authentication without confidentiality, an authentication To provide authentication without confidentiality, an authentication
transform MUST be used in either ESP or AH. The IPsec community transform MUST be used in either ESP or AH. The IPsec community
generally perfers ESP wth NULL encryption over AH, but AH is still generally prefers ESP with NULL encryption over AH. AH is still
required in some protocols; further, AH is more appropriate when required in some protocols and operational environments when there
there are security-sensitive options in the IP header. It is not are security-sensitive options in the IP header, such as source
possible to provide effective confidentiality without authentication, routing headers; ESP inherently cannot protect those IP options. It
because the lack of authentication undermines the efficacy of is not possible to provide effective confidentiality without
encryption [B96][V02]. Therefore, an encryption transform MUST NOT authentication, because the lack of authentication undermines the
be used with a NULL authentication transform (unless the encryption trustworthiness of encryption [B96][V02]. Therefore, an encryption
transform is an authenticated encryption transform from Section 2.1). transform MUST NOT be used with a NULL authentication transform
(unless the encryption transform is an authenticated encryption
transform from Section 2.1).
Triple-DES SHOULD NOT be used in any scenario in which multiple Triple-DES SHOULD NOT be used in any scenario in which multiple
gigabytes of data will be encrypted with a single key. As a 64-bit gigabytes of data will be encrypted with a single key. As a 64-bit
block cipher, it leaks information about plaintexts above that block cipher, it leaks information about plaintexts above that
"birthday bound" [M13]. Triple-DES CBC is listed as a MAY implement "birthday bound" [M13]. Triple-DES CBC is listed as a MAY implement
for the sake of backwards compatibility, but its use is discouraged. for the sake of backwards compatibility, but its use is discouraged.
4. Rationale 4. Rationale
This section explains the principles behind the implementation This section explains the principles behind the implementation
 End of changes. 8 change blocks. 
14 lines changed or deleted 17 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/