< draft-ietf-lisp-crypto-02.txt | draft-ietf-lisp-crypto-03.txt > | |||
---|---|---|---|---|
Internet Engineering Task Force D. Farinacci | Internet Engineering Task Force D. Farinacci | |||
Internet-Draft lispers.net | Internet-Draft lispers.net | |||
Intended status: Experimental B. Weis | Intended status: Experimental B. Weis | |||
Expires: March 11, 2016 cisco Systems | Expires: June 6, 2016 cisco Systems | |||
September 8, 2015 | December 4, 2015 | |||
LISP Data-Plane Confidentiality | LISP Data-Plane Confidentiality | |||
draft-ietf-lisp-crypto-02 | draft-ietf-lisp-crypto-03 | |||
Abstract | Abstract | |||
This document describes a mechanism for encrypting LISP encapsulated | This document describes a mechanism for encrypting LISP encapsulated | |||
traffic. The design describes how key exchange is achieved using | traffic. The design describes how key exchange is achieved using | |||
existing LISP control-plane mechanisms as well as how to secure the | existing LISP control-plane mechanisms as well as how to secure the | |||
LISP data-plane from third-party surveillance attacks. | LISP data-plane from third-party surveillance attacks. | |||
Status of This Memo | Status of This Memo | |||
skipping to change at page 1, line 34 | skipping to change at page 1, line 34 | |||
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 March 11, 2016. | This Internet-Draft will expire on June 6, 2016. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2015 IETF Trust and the persons identified as the | Copyright (c) 2015 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 12 | skipping to change at page 2, line 12 | |||
the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||
described in the Simplified BSD License. | described in the Simplified BSD License. | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | |||
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
3. Diffie-Hellman Key Exchange . . . . . . . . . . . . . . . . . 3 | 3. Diffie-Hellman Key Exchange . . . . . . . . . . . . . . . . . 3 | |||
4. Encoding and Transmitting Key Material . . . . . . . . . . . 4 | 4. Encoding and Transmitting Key Material . . . . . . . . . . . 4 | |||
5. Shared Keys used for the Data-Plane . . . . . . . . . . . . . 7 | 5. Shared Keys used for the Data-Plane . . . . . . . . . . . . . 7 | |||
6. Data-Plane Operation . . . . . . . . . . . . . . . . . . . . 8 | 6. Data-Plane Operation . . . . . . . . . . . . . . . . . . . . 9 | |||
7. Procedures for Encryption and Decryption . . . . . . . . . . 10 | 7. Procedures for Encryption and Decryption . . . . . . . . . . 10 | |||
8. Dynamic Rekeying . . . . . . . . . . . . . . . . . . . . . . 11 | 8. Dynamic Rekeying . . . . . . . . . . . . . . . . . . . . . . 11 | |||
9. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 12 | 9. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 12 | |||
10. Security Considerations . . . . . . . . . . . . . . . . . . . 12 | 10. Security Considerations . . . . . . . . . . . . . . . . . . . 12 | |||
10.1. SAAG Support . . . . . . . . . . . . . . . . . . . . . . 12 | 10.1. SAAG Support . . . . . . . . . . . . . . . . . . . . . . 12 | |||
10.2. LISP-Crypto Security Threats . . . . . . . . . . . . . . 12 | 10.2. LISP-Crypto Security Threats . . . . . . . . . . . . . . 12 | |||
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 | 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 | |||
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 | 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 | |||
12.1. Normative References . . . . . . . . . . . . . . . . . . 13 | 12.1. Normative References . . . . . . . . . . . . . . . . . . 13 | |||
12.2. Informative References . . . . . . . . . . . . . . . . . 14 | 12.2. Informative References . . . . . . . . . . . . . . . . . 14 | |||
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 15 | Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 15 | |||
Appendix B. Document Change Log . . . . . . . . . . . . . . . . 15 | Appendix B. Document Change Log . . . . . . . . . . . . . . . . 15 | |||
B.1. Changes to draft-ietf-lisp-crypto-01.txt . . . . . . . . 15 | B.1. Changes to draft-ietf-lisp-crypto-03.txt . . . . . . . . 15 | |||
B.2. Changes to draft-ietf-lisp-crypto-01.txt . . . . . . . . 15 | B.2. Changes to draft-ietf-lisp-crypto-02.txt . . . . . . . . 16 | |||
B.3. Changes to draft-ietf-lisp-crypto-00.txt . . . . . . . . 15 | B.3. Changes to draft-ietf-lisp-crypto-01.txt . . . . . . . . 16 | |||
B.4. Changes to draft-farinacci-lisp-crypto-01.txt . . . . . . 15 | B.4. Changes to draft-ietf-lisp-crypto-00.txt . . . . . . . . 16 | |||
B.5. Changes to draft-farinacci-lisp-crypto-00.txt . . . . . . 16 | B.5. Changes to draft-farinacci-lisp-crypto-01.txt . . . . . . 16 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 | B.6. Changes to draft-farinacci-lisp-crypto-00.txt . . . . . . 17 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 | ||||
1. Introduction | 1. Introduction | |||
The Locator/ID Separation Protocol [RFC6830] defines a set of | The Locator/ID Separation Protocol [RFC6830] defines a set of | |||
functions for routers to exchange information used to map from non- | functions for routers to exchange information used to map from non- | |||
routable Endpoint Identifiers (EIDs) to routable Routing Locators | routable Endpoint Identifiers (EIDs) to routable Routing Locators | |||
(RLOCs). LISP ITRs and PITRs encapsulate packets to ETRs and RTRs. | (RLOCs). LISP ITRs and PITRs encapsulate packets to ETRs and RTRs. | |||
Packets that arrive at the ITR or PITR are typically not modified. | Packets that arrive at the ITR or PITR are typically not modified. | |||
Which means no protection or privacy of the data is added. If the | Which means no protection or privacy of the data is added. If the | |||
source host encrypts the data stream then the encapsulated packets | source host encrypts the data stream then the encapsulated packets | |||
skipping to change at page 3, line 37 | skipping to change at page 3, line 40 | |||
ITR needs to obtain the RLOC of an ETR, it will get security material | ITR needs to obtain the RLOC of an ETR, it will get security material | |||
to compute a shared secret with the ETR. | to compute a shared secret with the ETR. | |||
The ITR can compute 3 shared-secrets per ETR the ITR is encapsulating | The ITR can compute 3 shared-secrets per ETR the ITR is encapsulating | |||
to. And when the ITR encrypts a packet before encapsulation, it will | to. And when the ITR encrypts a packet before encapsulation, it will | |||
identify the key it used for the crypto calculation so the ETR knows | identify the key it used for the crypto calculation so the ETR knows | |||
which key to use for decrypting the packet after decapsulation. By | which key to use for decrypting the packet after decapsulation. By | |||
using key-ids in the LISP header, we can also get real-time rekeying | using key-ids in the LISP header, we can also get real-time rekeying | |||
functionality. | functionality. | |||
When an ETR (when it is also an ITR) encapsulates packets to this ITR | ||||
(when it is also an ETR), a separate key exchange and shared-secret | ||||
computation is performed. The key management described in this | ||||
documemnt is unidirectional from the ITR (the encapsulator) to the | ||||
ETR (the decapsultor). | ||||
3. Diffie-Hellman Key Exchange | 3. Diffie-Hellman Key Exchange | |||
LISP will use a Diffie-Hellman [RFC2631] key exchange sequence and | LISP will use a Diffie-Hellman [RFC2631] key exchange sequence and | |||
computation for computing a shared secret. The Diffie-Hellman | computation for computing a shared secret. The Diffie-Hellman | |||
parameters will be passed via Cipher Suite code-points in Map-Request | parameters will be passed via Cipher Suite code-points in Map-Request | |||
and Map-Reply messages. | and Map-Reply messages. | |||
Here is a brief description how Diff-Hellman works: | Here is a brief description how Diff-Hellman works: | |||
+----------------------------+---------+----------------------------+ | +----------------------------+---------+----------------------------+ | |||
skipping to change at page 5, line 12 | skipping to change at page 5, line 12 | |||
Map-Reply messages. Diffie-Hellman parameters are encoded in the | Map-Reply messages. Diffie-Hellman parameters are encoded in the | |||
LISP Security Type LCAF [LCAF]. | LISP Security Type LCAF [LCAF]. | |||
0 1 2 3 | 0 1 2 3 | |||
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| AFI = 16387 | Rsvd1 | Flags | | | AFI = 16387 | Rsvd1 | Flags | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Type = 11 | Rsvd2 | 6 + n | | | Type = 11 | Rsvd2 | 6 + n | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Key Count | Rsvd3 |A| Cipher Suite| Rsvd4 |R| | | Key Count | Rsvd3 | Cipher Suite | Rsvd4 |R| | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Key Length | Public Key Material ... | | | Key Length | Public Key Material ... | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| ... Public Key Material | | | ... Public Key Material | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| AFI = x | Locator Address ... | | | AFI = x | Locator Address ... | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
Cipher Suite field contains DH Key Exchange and Cipher/Hash Functions | Cipher Suite field contains DH Key Exchange and Cipher/Hash Functions | |||
The 'Key Count' field encodes the number of {'Key-Length', 'Key- | The 'Key Count' field encodes the number of {'Key-Length', 'Key- | |||
Material'} fields included in the encoded LCAF. The maximum number | Material'} fields included in the encoded LCAF. The maximum number | |||
of keys that can be encoded are 3, each identified by key-id 1, | of keys that can be encoded are 3, each identified by key-id 1, | |||
followed by key-id 2, an finally key-id 3. | followed by key-id 2, an finally key-id 3. | |||
The 'R' bit is not used for this use-case of the Security Type LCAF | The 'R' bit is not used for this use-case of the Security Type LCAF | |||
but is reserved for [LISP-DDT] security. | but is reserved for [LISP-DDT] security. | |||
When the A-bit is set, it indicates that Authentication only is | Cipher Suite 0: | |||
performed according to the Integrity hash function defined in the | Reserved | |||
Cipher Suites. That is an encapsulator will perform an Integrity | ||||
computation over an unencrypted packet and include an ICV value. | ||||
Since the packet contains no ciphertext, there is no IV value | ||||
included in the message. The 7-bit 'Cipher Suite' field defines the | ||||
following code-points: | ||||
Cipher Suite 0: | Cipher Suite 1: | |||
Reserved | Diffie-Hellman Group: 2048-bit MODP [RFC3526] | |||
Encryption: AES with 128-bit keys in CBC mode [AES-CBC] | ||||
Integrity: Integrated with [AES-CBC] AEAD [RFC5116] encryption | ||||
IV length: 16 bytes | ||||
Cipher Suite 1: | Cipher Suite 2: | |||
Diffie-Hellman Group: 1024-bit Modular Exponential (MODP) [RFC2409] | Diffie-Hellman Group: 256-bit Elliptic-Curve 25519 [CURVE25519] | |||
Encryption: AES with 128-bit keys in CBC mode [AES-CBC] | Encryption: AES with 128-bit keys in CBC mode [AES-CBC] | |||
Integrity: HMAC-SHA1-96 [RFC2404] | Integrity: HMAC-SHA1-96 [RFC2404] | |||
IV length: 16 bytes | ||||
Cipher Suite 2: | Cipher Suite 3: | |||
Diffie-Hellman Group: 2048-bit MODP [RFC3526] | Diffie-Hellman Group: 2048-bit MODP [RFC3526] | |||
Encryption: AES with 128-bit keys in CBC mode [AES-CBC] | Encryption: AES with 128-bit keys in GCM mode [AES-GCM] | |||
Integrity: HMAC-SHA1-96 [RFC2404] | Integrity: Integrated with [AES-GCM] AEAD [RFC5116] encryption | |||
IV length: 12 bytes | ||||
Cipher Suite 3: | Cipher Suite 4: | |||
Diffie-Hellman Group: 3072-bit MODP [RFC3526] | Diffie-Hellman Group: 3072-bit MODP [RFC3526] | |||
Encryption: AES with 128-bit keys in CBC mode [AES-CBC] | Encryption: AES with 128-bit keys in GCM mode [AES-GCM] | |||
Integrity: HMAC-SHA1-96 [RFC2404] | Integrity: Integrated with [AES-GCM] AEAD [RFC5116] encryption | |||
IV length: 12 bytes | ||||
Cipher Suite 4: | Cipher Suite 5: | |||
Diffie-Hellman Group: 256-bit Elliptic-Curve 25519 [CURVE25519] | Diffie-Hellman Group: 256-bit Elliptic-Curve 25519 [CURVE25519] | |||
Encryption: AES with 128-bit keys in CBC mode [AES-CBC] | Encryption: AES with 128-bit keys in GCM mode [AES-GCM] | |||
Integrity: HMAC-SHA1-96 [RFC2404] | Integrity: Integrated with [AES-GCM] AEAD [RFC5116] encryption | |||
IV length: 12 bytes | ||||
Cipher Suite 5: | Cipher Suite 6: | |||
Diffie-Hellman Group: 256-bit Elliptic-Curve 25519 [CURVE25519] | Diffie-Hellman Group: 256-bit Elliptic-Curve 25519 [CURVE25519] | |||
Encryption: Chacha20-Poly1305 [CHACHA-POLY] | Encryption/Integrity: Chacha20-Poly1305 [CHACHA-POLY] [RFC7539] | |||
Integrity: HMAC-SHA1-96 [RFC2404] | Integrity: Integrated with Chacha20-Poly1305 AEAD [RFC1116] encryption | |||
IV length: 8 bytes | ||||
The "Public Key Material" field contains the public key generated by | The "Public Key Material" field contains the public key generated by | |||
one of the Cipher Suites defined above. The length of the key in | one of the Cipher Suites defined above. The length of the key in | |||
octets is encoded in the "Key Length" field. | octets is encoded in the "Key Length" field. | |||
When an ITR or PITR send a Map-Request, they will encode their own | When an ITR or PITR send a Map-Request, they will encode their own | |||
RLOC in the Security Type LCAF format within the ITR-RLOCs field. | RLOC in the Security Type LCAF format within the ITR-RLOCs field. | |||
When a ETR or RTR sends a Map-Reply, they will encode their RLOCs in | When a ETR or RTR sends a Map-Reply, they will encode their RLOCs in | |||
Security Type LCAF format within the RLOC-record field of each EID- | Security Type LCAF format within the RLOC-record field of each EID- | |||
record supplied. | record supplied. | |||
skipping to change at page 7, line 16 | skipping to change at page 7, line 28 | |||
5. Shared Keys used for the Data-Plane | 5. Shared Keys used for the Data-Plane | |||
When an ITR or PITR receives a Map-Reply accepting the Cipher Suite | When an ITR or PITR receives a Map-Reply accepting the Cipher Suite | |||
sent in the Map-Request, it is ready to create data plane keys. The | sent in the Map-Request, it is ready to create data plane keys. The | |||
same process is followed by the ETR or RTR returning the Map-Reply. | same process is followed by the ETR or RTR returning the Map-Reply. | |||
The first step is to create a shared secret, using the peer's shared | The first step is to create a shared secret, using the peer's shared | |||
Diffie-Hellman Public Key Material combined with device's own private | Diffie-Hellman Public Key Material combined with device's own private | |||
keying material as described in Section 3. The Diffie-Hellman group | keying material as described in Section 3. The Diffie-Hellman group | |||
used is defined in the Cipher Suite sent in the Map-Request and | used is defined in the cipher suite sent in the Map-Request and | |||
copied into the Map-Reply. | copied into the Map-Reply. | |||
The resulting shared secret is used to compute Encryption and | The resulting shared secret is used to compute an AEAD-key for the | |||
Integrity keys for the algorithms specified in the Cipher Suite. A | algorithms specified in the cipher suite. A Key Derivation Function | |||
Key Derivation Function (KDF) in counter mode as specified by | (KDF) in counter mode as specified by [NIST-SP800-108] is used to | |||
[NIST-SP800-108] is used to generate the data-plane keys. The amount | generate the data-plane keys. The amount of keying material that is | |||
of keying material that is derived depends on the algorithms in the | derived depends on the algorithms in the cipher suite. | |||
cipher suite. | ||||
The inputs to the KDF are as follows: | The inputs to the KDF are as follows: | |||
o KDF function. This is HMAC-SHA-256. | o KDF function. This is HMAC-SHA-256. | |||
o A key for the KDF function. This is the most significant 16 | o A key for the KDF function. This is the computed Diffie-Hellman | |||
octets of the computed Diffie-Hellman shared secret. | shared secret. | |||
o Context that binds the use of the data-plane keys to this session. | o Context that binds the use of the data-plane keys to this session. | |||
The context is made up of the following fields, which are | The context is made up of the following fields, which are | |||
concatenated and provided as the data to be acted upon by the KDF | concatenated and provided as the data to be acted upon by the KDF | |||
function. | function. | |||
Context: | Context: | |||
o A counter, represented as a two-octet value in network-byte order. | o A counter, represented as a two-octet value in network-byte order. | |||
o The null-terminated string "lisp-crypto". | o The null-terminated string "lisp-crypto". | |||
o The ITR's nonce from the the Map-Request the Cipher Suite was | o The ITR's nonce from the the Map-Request the cipher suite was | |||
included in. | included in. | |||
o The number of bits of keying material required (L), represented as | o The number of bits of keying material required (L), represented as | |||
a two-octet value in network byte order. | a two-octet value in network byte order. | |||
The counter value in the context is first set to 1. When the amount | The counter value in the context is first set to 1. When the amount | |||
of keying material exceeds the number of bits returned by the KDF | of keying material exceeds the number of bits returned by the KDF | |||
function, then the KDF function is called again with the same inputs | function, then the KDF function is called again with the same inputs | |||
except that the counter increments for each call. When enough keying | except that the counter increments for each call. When enough keying | |||
material is returned, it is concatenated and used to create keys. | material is returned, it is concatenated and used to create keys. | |||
skipping to change at page 8, line 39 | skipping to change at page 8, line 50 | |||
key-material-2 = HMAC-SHA-256(dh-shared-secret, context) | key-material-2 = HMAC-SHA-256(dh-shared-secret, context) | |||
where: context = 0x0002 || "lisp-crypto" || <itr-nonce> || 0x0200 | where: context = 0x0002 || "lisp-crypto" || <itr-nonce> || 0x0200 | |||
key-material = key-material-1 || key-material-2 | key-material = key-material-1 || key-material-2 | |||
If the key-material is longer than the required number of bits (L), | If the key-material is longer than the required number of bits (L), | |||
then only the most significant L bits are used. | then only the most significant L bits are used. | |||
From the derived key-material, the most significant bits are used for | From the derived key-material, the most significant 256 bits are used | |||
the Encryption key, and least significant bits are used for the | for the AEAD-key by AEAD ciphers. The 256-bit AEAD-key is divided | |||
Integrity key. For example, if the Cipher Suite contains both AES | into a 128-bit encryption key and a 128-bit integrity-check key | |||
with 128-bit keys and HMAC-SHA1-96, the most significant 128 bits | internal to the cipher used by the ITR. | |||
become the ITR's data-plane encryption key, and the next 128-bit | ||||
become the ITR's Integrity key. | ||||
6. Data-Plane Operation | 6. Data-Plane Operation | |||
The LISP encapsulation header [RFC6830] requires changes to encode | The LISP encapsulation header [RFC6830] requires changes to encode | |||
the key-id for the key being used for encryption. | the key-id for the key being used for encryption. | |||
0 1 2 3 | 0 1 2 3 | |||
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
/ | Source Port = xxxx | Dest Port = 4341 | | / | Source Port = xxxx | Dest Port = 4341 | | |||
UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
\ | UDP Length | UDP Checksum | | \ | UDP Length | UDP Checksum | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
L / |N|L|E|V|I|P|K|K| Nonce/Map-Version | \ | L / |N|L|E|V|I|P|K|K| Nonce/Map-Version | \ \ | |||
I +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | I +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AD | |||
S \ | Instance ID/Locator-Status-Bits | | | S \ | Instance ID/Locator-Status-Bits | | / | |||
P +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | P +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | |||
| Initialization Vector (IV) | I | | Initialization Vector (IV) | I | |||
E +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ C | E +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ C | |||
n / | | V | n / | | V | |||
c | | | | c | | | | |||
r | Packet Payload with EID Header ... | | | r | Packet Payload with EID Header ... | | | |||
y | | | | y | | | | |||
p \ | | / | p \ | | / | |||
t +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | t +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Integrity Check Value (ICV) | | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
K-bits indicate when packet is encrypted and which key used | K-bits indicate when packet is encrypted and which key used | |||
When the KK bits are 00, the encapsulated packet is not encrypted. | When the KK bits are 00, the encapsulated packet is not encrypted. | |||
When the value of the KK bits are 1, 2, or 3, it encodes the key-id | When the value of the KK bits are 1, 2, or 3, it encodes the key-id | |||
of the secret keys computed during the Diffie-Hellman Map-Request/ | of the secret keys computed during the Diffie-Hellman Map-Request/ | |||
Map-Reply exchange. When the KK bits are not 0, the payload is | Map-Reply exchange. When the KK bits are not 0, the payload is | |||
prepended with an Initialization Vector (IV) and appended with an | prepended with an Initialization Vector (IV). The length of the IV | |||
Integrity Check Value (ICV). The length of the IV and ICV fields | field is based on the cipher suite used. Since all cipher suites | |||
depend on the Cipher Suite negotiated in the control-plane. | defined in this document do Authenticated Encryption (AEAD), an ICV | |||
field does not need to be present in the packet since it is included | ||||
in the ciphertext. The Additional Data (AD) used for the ICV is | ||||
shown above and includes the LISP header, the IV field and the packet | ||||
payload. | ||||
When an ITR or PITR receives a packet to be encapsulated, they will | When an ITR or PITR receives a packet to be encapsulated, they will | |||
first decide what key to use, encode the key-id into the LISP header, | first decide what key to use, encode the key-id into the LISP header, | |||
and use that key to encrypt all packet data that follows the LISP | and use that key to encrypt all packet data that follows the LISP | |||
header. Therefore, the outer header, UDP header, and LISP header | header. Therefore, the outer header, UDP header, and LISP header | |||
travel as plaintext. | travel as plaintext. | |||
There is an open working group item to discuss if the data | There is an open working group item to discuss if the data | |||
encapsulation header needs change for encryption or any new | encapsulation header needs change for encryption or any new | |||
applications. This draft proposes changes to the existing header so | applications. This draft proposes changes to the existing header so | |||
experimentation can continue without making large changes to the | experimentation can continue without making large changes to the | |||
data-plane at this time. | data-plane at this time. | |||
7. Procedures for Encryption and Decryption | 7. Procedures for Encryption and Decryption | |||
When an ITR, PITR, or RTR encapsulate a packet and have already | When an ITR, PITR, or RTR encapsulate a packet and have already | |||
computed an encryption-key and integrity-key (detailed in section | computed an AEAD-key (detailed in section Section 5) that is | |||
Section 5) that is associated with a destination RLOC, the following | associated with a destination RLOC, the following encryption and | |||
encryption and encapsulation procedures are performed: | encapsulation procedures are performed: | |||
1. The encapsulator creates a random number used as the IV. | 1. The encapsulator creates an IV and prepends the IV value to the | |||
Prepends the IV value to the packet being encapsulated. The IV | packet being encapsulated. For GCM and Chacha cipher suites, the | |||
is incremented for every packet sent to the destination RLOC. | IV is incremented for every packet (beginning with a value of 1 | |||
in the first packet) and sent to the destination RLOC. For CBC | ||||
cipher suites, the IV is a new random number for every packet | ||||
sent to the destination RLOC. For the Chacha cipher suite, the | ||||
IV is an 8-byte random value that is appended to a 4-byte counter | ||||
that is incremented for every packet (beginning with a value of 1 | ||||
in the first packet). | ||||
2. Next encrypt with cipher function AES-CBC using the encryption- | 2. Next encrypt with cipher function AES or Chacha20 using the AEAD- | |||
key over the packet payload. This does not include the IV. The | key over the packet payload following the AEAD specification | |||
IV must be transmitted as plaintext so the decrypter can use it | referenced in the cipher suite definition. This does not include | |||
as input to the decryption cipher. The payload should be padded | the IV. The IV must be transmitted as plaintext so the decrypter | |||
to an integral number of bytes a block cipher may require. | can use it as input to the decryption cipher. The payload should | |||
be padded to an integral number of bytes a block cipher may | ||||
require. The result of the AEAD operation may contain an ICV, | ||||
the size of which is defined by the referenced AEAD | ||||
specification. Note that the AD (i.e. the LISP header exactly as | ||||
will be prepended in the next step and the IV) must be given to | ||||
the AEAD encryption function as the "associated data" argument. | ||||
3. Prepend the LISP header. The key-id field of the LISP header is | 3. Prepend the LISP header. The key-id field of the LISP header is | |||
set to the key-id value that corresponds to key-pair used for the | set to the key-id value that corresponds to key-pair used for the | |||
encryption cipher and for the ICV hash. | encryption cipher. | |||
4. Next compute the ICV value by hashing the packet (which includes | ||||
the LISP header, the IV, and the packet payload) with the HMAC- | ||||
SHA1 function using the integrity-key. The resulting ICV value | ||||
is appended to the packet. The ICV is not ciphertext so a fast | ||||
integrity check can be performed without decryption at the | ||||
receiver. | ||||
5. Lastly, prepend the UDP header and outer IP header onto the | 4. Lastly, prepend the UDP header and outer IP header onto the | |||
encrypted packet and send packet to destination RLOC. | encrypted packet and send packet to destination RLOC. | |||
When an ETR, PETR, or RTR receive an encapsulated packet, the | When an ETR, PETR, or RTR receive an encapsulated packet, the | |||
following decapsulation and decryption procedures are performed: | following decapsulation and decryption procedures are performed: | |||
1. The outer IP header and UDP header are stripped from the start of | 1. The outer IP header, UDP header, LISP header, and IV field are | |||
the packet and the ICV is stripped from the end of the packet. | stripped from the start of the packet. The LISP header and IV | |||
are retained and given to the AEAD decryption operation as the | ||||
2. Next the ICV is computed by running the Integrity function from | "associated data" argument. | |||
the cipher suite using the integrity-key over the packet (which | ||||
includes the LISP header, the IV and packet payload) using the | ||||
integrity-key. If the result does not match the ICV value from | ||||
the packet, the packet was been tampered with, and is dropped, | ||||
and an optional log message may be issued. The integrity-key is | ||||
obtained from a local-cache associated with the key-id value from | ||||
the LISP header. | ||||
3. If the hashed result matches the ICV value from the packet, then | ||||
the LISP header is stripped and decryption occurs over the packet | ||||
payload using the plaintext IV in the packet. | ||||
4. The IV is stripped from the packet. | ||||
5. The packet is decrypted using the encryption-key and the IV from | 2. The packet is decrypted using the AEAD-key and the IV from the | |||
the packet. The encryption-key is obtained from a local-cache | packet. The AEAD-key is obtained from a local-cache associated | |||
associated with the key-id value from the LISP header. The | with the key-id value from the LISP header. The result of the | |||
result of the decryption function is a plaintext packet payload. | decryption function is a plaintext packet payload if the cipher | |||
returned a verified ICV. Otherwise, the packet has been tampered | ||||
with, is dropped, and an optional log message may be issued. If | ||||
the AEAD specification included an ICV, the AEAD decryption | ||||
function will locate the ICV in the ciphertext and compare it to | ||||
a version of the ICV that the AEAD decryption function computes. | ||||
If the computed ICV is different than the ICV located in the | ||||
ciphertext, then it will be considered tampered. | ||||
6. The resulting packet is forwarded to the destination EID. | 3. If the packet was not tampered with, the decrypted packet is | |||
forwarded to the destination EID. | ||||
8. Dynamic Rekeying | 8. Dynamic Rekeying | |||
Since multiple keys can be encoded in both control and data messages, | Since multiple keys can be encoded in both control and data messages, | |||
an ITR can encapsulate and encrypt with a specific key while it is | an ITR can encapsulate and encrypt with a specific key while it is | |||
negotiating other keys with the same ETR. Soon as an ETR or RTR | negotiating other keys with the same ETR. Soon as an ETR or RTR | |||
returns a Map-Reply, it should be prepared to decapsulate and decrypt | returns a Map-Reply, it should be prepared to decapsulate and decrypt | |||
using the new keys computed with the new Diffie-Hellman parameters | using the new keys computed with the new Diffie-Hellman parameters | |||
received in the Map-Request and returned in the Map-Reply. | received in the Map-Request and returned in the Map-Reply. | |||
skipping to change at page 12, line 18 | skipping to change at page 12, line 23 | |||
9. Future Work | 9. Future Work | |||
For performance considerations, newer Elliptic-Curve Diffie-Hellman | For performance considerations, newer Elliptic-Curve Diffie-Hellman | |||
(ECDH) groups can be used as specified in [RFC4492] and [RFC6090] to | (ECDH) groups can be used as specified in [RFC4492] and [RFC6090] to | |||
reduce CPU cycles required to compute shared secret keys. | reduce CPU cycles required to compute shared secret keys. | |||
For better security considerations as well as to be able to build | For better security considerations as well as to be able to build | |||
faster software implementations, newer approaches to ciphers and | faster software implementations, newer approaches to ciphers and | |||
authentication methods will be researched and tested. Some examples | authentication methods will be researched and tested. Some examples | |||
are chacha20 and poly1305 [CHACHA-POLY]. | are Chacha20 and Poly1305 [CHACHA-POLY] [RFC7539]. | |||
10. Security Considerations | 10. Security Considerations | |||
10.1. SAAG Support | 10.1. SAAG Support | |||
The LISP working group has and will continue to seek help from the | The LISP working group has and will continue to seek help from the | |||
SAAG working group for security advice. The SAAG has been involved | SAAG working group for security advice. The SAAG has been involved | |||
early in the design process so they have early input and review. | early in the design process so they have early input and review. | |||
10.2. LISP-Crypto Security Threats | 10.2. LISP-Crypto Security Threats | |||
skipping to change at page 14, line 15 | skipping to change at page 14, line 19 | |||
[RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic | [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic | |||
Curve Cryptography Algorithms", RFC 6090, | Curve Cryptography Algorithms", RFC 6090, | |||
DOI 10.17487/RFC6090, February 2011, | DOI 10.17487/RFC6090, February 2011, | |||
<http://www.rfc-editor.org/info/rfc6090>. | <http://www.rfc-editor.org/info/rfc6090>. | |||
[RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The | [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The | |||
Locator/ID Separation Protocol (LISP)", RFC 6830, | Locator/ID Separation Protocol (LISP)", RFC 6830, | |||
DOI 10.17487/RFC6830, January 2013, | DOI 10.17487/RFC6830, January 2013, | |||
<http://www.rfc-editor.org/info/rfc6830>. | <http://www.rfc-editor.org/info/rfc6830>. | |||
[RFC7539] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF | ||||
Protocols", RFC 7539, DOI 10.17487/RFC7539, May 2015, | ||||
<http://www.rfc-editor.org/info/rfc7539>. | ||||
12.2. Informative References | 12.2. Informative References | |||
[AES-CBC] McGrew, D., Foley, J., and K. Paterson, "Authenticated | [AES-CBC] McGrew, D., Foley, J., and K. Paterson, "Authenticated | |||
Encryption with AES-CBC and HMAC-SHA", draft-mcgrew-aead- | Encryption with AES-CBC and HMAC-SHA", draft-mcgrew-aead- | |||
aes-cbc-hmac-sha2-05.txt (work in progress). | aes-cbc-hmac-sha2-05.txt (work in progress). | |||
[CHACHA-POLY] | [CHACHA-POLY] | |||
Langley, A., "ChaCha20 and Poly1305 based Cipher Suites | Langley, A., "ChaCha20 and Poly1305 based Cipher Suites | |||
for TLS", draft-agl-tls-chacha20poly1305-00 (work in | for TLS", draft-agl-tls-chacha20poly1305-00 (work in | |||
progress). | progress). | |||
skipping to change at page 15, line 7 | skipping to change at page 15, line 17 | |||
"LISP-Secuirty (LISP-SEC)", draft-ietf-lisp-sec-06 (work | "LISP-Secuirty (LISP-SEC)", draft-ietf-lisp-sec-06 (work | |||
in progress). | in progress). | |||
[NIST-SP800-108] | [NIST-SP800-108] | |||
"National Institute of Standards and Technology, | "National Institute of Standards and Technology, | |||
"Recommendation for Key Derivation Using Pseudorandom | "Recommendation for Key Derivation Using Pseudorandom | |||
Functions NIST SP800-108"", NIST SP 800-108, October 2009. | Functions NIST SP800-108"", NIST SP 800-108, October 2009. | |||
Appendix A. Acknowledgments | Appendix A. Acknowledgments | |||
The author would like to thank Dan Harkins, Joel Halpern, Fabio | The authors would like to thank Dan Harkins, Joel Halpern, Fabio | |||
Maino, Ed Lopez, Roger Jorgensen, Watson Ladd, and Ilari Liusvaara | Maino, Ed Lopez, Roger Jorgensen, and Watson Ladd for their interest, | |||
for their interest, suggestions, and discussions about LISP data- | suggestions, and discussions about LISP data-plane security. | |||
plane security. | ||||
The authors would like to give a special thank you to Ilari Liusvaara | ||||
for his extensive commentary and discussion. He has contributed his | ||||
security expertise to make lisp-crypto as secure as the state of the | ||||
art in cryptography. | ||||
In addition, the support and suggestions from the SAAG working group | In addition, the support and suggestions from the SAAG working group | |||
were helpful and appreciative. | were helpful and appreciative. | |||
Appendix B. Document Change Log | Appendix B. Document Change Log | |||
B.1. Changes to draft-ietf-lisp-crypto-01.txt | B.1. Changes to draft-ietf-lisp-crypto-03.txt | |||
o Posted December 2015. | ||||
o Changed cipher suite allocations. We now have 2 AES-CBC cipher | ||||
suites for compatibility, 3 AES-GCM cipher suites that are faster | ||||
ciphers that include AE and a Chacha20-Poly1305 cipher suite which | ||||
is the fastest but not totally proven/accepted.. | ||||
o Remove 1024-bit DH keys for key exchange. | ||||
o Make clear that AES and chacha20 ciphers use AEAD so part of | ||||
encrytion/decryption does authentication. | ||||
o Make it more clear that separate key pairs are used in each | ||||
direction between xTRs. | ||||
o Indicate that the IV length is different per cipher suite. | ||||
o Use a counter based IV for every packet for AEAD ciphers. | ||||
Previously text said to use a random number. But CBC ciphers, use | ||||
a random number. | ||||
o Indicate that key material is sent in network byte order (big | ||||
endian). | ||||
o Remove A-bit from Security Type LCAF. No need to do | ||||
authentication only with the introduction of AEAD ciphers. These | ||||
ciphers can do authentication. So you get ciphertext for free. | ||||
o Remove language that refers to "encryption-key" and "integrity- | ||||
key". Used term "AEAD-key" that is used by the AEAD cipher suites | ||||
that do encryption and authenticaiton internal to the cipher. | ||||
B.2. Changes to draft-ietf-lisp-crypto-02.txt | ||||
o Posted September 2015. | o Posted September 2015. | |||
o Add cipher suite for Elliptic Curve 25519 DH exchange. | o Add cipher suite for Elliptic Curve 25519 DH exchange. | |||
o Add cipher suite for Chacha20/poly1305 ciphers. | o Add cipher suite for Chacha20/Poly1305 ciphers. | |||
B.2. Changes to draft-ietf-lisp-crypto-01.txt | B.3. Changes to draft-ietf-lisp-crypto-01.txt | |||
o Posted May 2015. | o Posted May 2015. | |||
o Create cipher suites and encode them in the Security LCAF. | o Create cipher suites and encode them in the Security LCAF. | |||
o Add IV to beginning of packet header and ICV to end of packet. | o Add IV to beginning of packet header and ICV to end of packet. | |||
o AEAD procedures are now part of encrpytion process. | o AEAD procedures are now part of encrpytion process. | |||
B.3. Changes to draft-ietf-lisp-crypto-00.txt | B.4. Changes to draft-ietf-lisp-crypto-00.txt | |||
o Posted January 2015. | o Posted January 2015. | |||
o Changing draft-farinacci-lisp-crypto-01 to draft-ietf-lisp-crypto- | o Changing draft-farinacci-lisp-crypto-01 to draft-ietf-lisp-crypto- | |||
00. This draft has become a working group document | 00. This draft has become a working group document | |||
o Add text to indicate the working group may work on a new data | o Add text to indicate the working group may work on a new data | |||
encapsulation header format for data-plane encryption. | encapsulation header format for data-plane encryption. | |||
B.4. Changes to draft-farinacci-lisp-crypto-01.txt | B.5. Changes to draft-farinacci-lisp-crypto-01.txt | |||
o Posted July 2014. | o Posted July 2014. | |||
o Add Group-ID to the encoding format of Key Material in a Security | o Add Group-ID to the encoding format of Key Material in a Security | |||
Type LCAF and modify the IANA Considerations so this draft can use | Type LCAF and modify the IANA Considerations so this draft can use | |||
key exchange parameters from the IANA registry. | key exchange parameters from the IANA registry. | |||
o Indicate that the R-bit in the Security Type LCAF is not used by | o Indicate that the R-bit in the Security Type LCAF is not used by | |||
lisp-crypto. | lisp-crypto. | |||
skipping to change at page 16, line 23 | skipping to change at page 17, line 23 | |||
process. | process. | |||
o Add text indicating that when RLOC-probing is used for RLOC | o Add text indicating that when RLOC-probing is used for RLOC | |||
reachability purposes and rekeying is not desired, that the same | reachability purposes and rekeying is not desired, that the same | |||
key exchange parameters should be used so a reallocation of a | key exchange parameters should be used so a reallocation of a | |||
pubic key does not happen at the ETR. | pubic key does not happen at the ETR. | |||
o Add text to indicate that ECDH can be used to reduce CPU | o Add text to indicate that ECDH can be used to reduce CPU | |||
requirements for computing shared secret-keys. | requirements for computing shared secret-keys. | |||
B.5. Changes to draft-farinacci-lisp-crypto-00.txt | B.6. Changes to draft-farinacci-lisp-crypto-00.txt | |||
o Initial draft posted February 2014. | o Initial draft posted February 2014. | |||
Authors' Addresses | Authors' Addresses | |||
Dino Farinacci | Dino Farinacci | |||
lispers.net | lispers.net | |||
San Jose, California 95120 | San Jose, California 95120 | |||
USA | USA | |||
End of changes. 39 change blocks. | ||||
118 lines changed or deleted | 169 lines changed or added | |||
This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |