draft-ietf-manet-rfc6622-bis-04.txt   draft-ietf-manet-rfc6622-bis-05.txt 
Mobile Ad hoc Networking (MANET) U. Herberg Mobile Ad hoc Networking (MANET) U. Herberg
Internet-Draft Fujitsu Laboratories of America Internet-Draft Fujitsu Laboratories of America
Obsoletes: 6622 (if approved) T. Clausen Obsoletes: 6622 (if approved) T. Clausen
Intended status: Standards Track LIX, Ecole Polytechnique Intended status: Standards Track LIX, Ecole Polytechnique
Expires: January 31, 2014 C. Dearlove Expires: March 14, 2014 C. Dearlove
BAE Systems ATC BAE Systems ATC
July 30, 2013 September 10, 2013
Integrity Check Value and Timestamp TLV Definitions Integrity Check Value and Timestamp TLV Definitions
for Mobile Ad Hoc Networks (MANETs) for Mobile Ad Hoc Networks (MANETs)
draft-ietf-manet-rfc6622-bis-04 draft-ietf-manet-rfc6622-bis-05
Abstract Abstract
This document revises, extends and replaces RFC 6622. It describes This document revises, extends and replaces RFC 6622. It describes
general and flexible TLVs for representing cryptographic Integrity general and flexible TLVs for representing cryptographic Integrity
Check Values (ICVs) and timestamps, using the generalized Mobile Ad Check Values (ICVs) and timestamps, using the generalized Mobile Ad
Hoc Network (MANET) packet/message format defined in RFC 5444. It Hoc Network (MANET) packet/message format defined in RFC 5444. It
defines two Packet TLVs, two Message TLVs, and two Address Block TLVs defines two Packet TLVs, two Message TLVs, and two Address Block TLVs
for affixing ICVs and timestamps to a packet, a message, and one or for affixing ICVs and timestamps to a packet, a message, and one or
more addresses, respectively. more addresses, respectively.
skipping to change at page 1, line 40 skipping to change at page 1, line 40
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 January 31, 2014. This Internet-Draft will expire on March 14, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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 3, line 28 skipping to change at page 3, line 28
9. Message TLVs . . . . . . . . . . . . . . . . . . . . . . . . . 10 9. Message TLVs . . . . . . . . . . . . . . . . . . . . . . . . . 10
9.1. ICV Message TLV . . . . . . . . . . . . . . . . . . . . . 11 9.1. ICV Message TLV . . . . . . . . . . . . . . . . . . . . . 11
9.2. TIMESTAMP Message TLV . . . . . . . . . . . . . . . . . . 11 9.2. TIMESTAMP Message TLV . . . . . . . . . . . . . . . . . . 11
10. Address Block TLVs . . . . . . . . . . . . . . . . . . . . . . 11 10. Address Block TLVs . . . . . . . . . . . . . . . . . . . . . . 11
10.1. ICV Address Block TLV . . . . . . . . . . . . . . . . . . 11 10.1. ICV Address Block TLV . . . . . . . . . . . . . . . . . . 11
10.2. TIMESTAMP Address Block TLV . . . . . . . . . . . . . . . 12 10.2. TIMESTAMP Address Block TLV . . . . . . . . . . . . . . . 12
11. ICV: Basic . . . . . . . . . . . . . . . . . . . . . . . . . . 12 11. ICV: Basic . . . . . . . . . . . . . . . . . . . . . . . . . . 12
12. ICV: Hash Function and Cryptographic Function . . . . . . . . 12 12. ICV: Hash Function and Cryptographic Function . . . . . . . . 12
12.1. General ICV TLV Structure . . . . . . . . . . . . . . . . 13 12.1. General ICV TLV Structure . . . . . . . . . . . . . . . . 13
12.1.1. Rationale . . . . . . . . . . . . . . . . . . . . . . 14 12.1.1. Rationale . . . . . . . . . . . . . . . . . . . . . . 14
12.2. Considerations for Calculating the ICV . . . . . . . . . 14 12.2. Considerations for Calculating the ICV . . . . . . . . . 15
12.2.1. ICV Packet TLV . . . . . . . . . . . . . . . . . . . 15 12.2.1. ICV Packet TLV . . . . . . . . . . . . . . . . . . . 15
12.2.2. ICV Message TLV . . . . . . . . . . . . . . . . . . . 15 12.2.2. ICV Message TLV . . . . . . . . . . . . . . . . . . . 15
12.2.3. ICV Address Block TLV . . . . . . . . . . . . . . . . 16 12.2.3. ICV Address Block TLV . . . . . . . . . . . . . . . . 16
12.3. Example of a Message Including an ICV . . . . . . . . . . 16 12.3. Example of a Message Including an ICV . . . . . . . . . . 16
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
13.1. Expert Review: Evaluation Guidelines . . . . . . . . . . 18 13.1. Expert Review: Evaluation Guidelines . . . . . . . . . . 18
13.2. Packet TLV Types . . . . . . . . . . . . . . . . . . . . 18 13.2. Packet TLV Types . . . . . . . . . . . . . . . . . . . . 18
13.3. Message TLV Types . . . . . . . . . . . . . . . . . . . . 18 13.3. Message TLV Types . . . . . . . . . . . . . . . . . . . . 18
13.4. Address Block TLV Types . . . . . . . . . . . . . . . . . 19 13.4. Address Block TLV Types . . . . . . . . . . . . . . . . . 19
13.5. ICV Packet TLV Type Extensions . . . . . . . . . . . . . 19 13.5. ICV Packet TLV Type Extensions . . . . . . . . . . . . . 19
skipping to change at page 4, line 12 skipping to change at page 4, line 12
16.1. Normative References . . . . . . . . . . . . . . . . . . 26 16.1. Normative References . . . . . . . . . . . . . . . . . . 26
16.2. Informative References . . . . . . . . . . . . . . . . . 28 16.2. Informative References . . . . . . . . . . . . . . . . . 28
1. Introduction 1. Introduction
[RFC Editor note: Please replace "xxxx" throughout this document with [RFC Editor note: Please replace "xxxx" throughout this document with
the RFC number assigned to this document, and remove this note.] the RFC number assigned to this document, and remove this note.]
This document specifies a syntactical representation of security- This document specifies a syntactical representation of security-
related information for use with [RFC5444] addresses, messages, and related information for use with [RFC5444] addresses, messages, and
packets, and also sets up IANA registrations of TLV types and type packets, and also specifies IANA registrations of TLV types and type
extension registries for these TLV types. This specification does extension registries for these TLV types. This specification does
not represent a stand-alone protocol, but is intended for use by not represent a stand-alone protocol, but is intended for use by
MANET routing protocols, or security extensions thereof. MANET routing protocols, or security extensions thereof.
Specifically, this document, which revises, extends, and replaces Specifically, this document, which revises, extends, and replaces
[RFC6622], specifies: [RFC6622], specifies:
o Two kinds of TLV: one for carrying Integrity Check Values (ICVs) o Two kinds of TLV: one for carrying Integrity Check Values (ICVs)
and one for timestamps in packets, messages, and address blocks as and one for timestamps in packets, messages, and address blocks as
defined by [RFC5444]. defined by [RFC5444].
o A generic framework for use of these TLVs, accounting for specific o A generic framework for use of these TLVs, accounting for specific
features of Packet, Message and Address Block TLVs. features of Packet, Message and Address Block TLVs.
o IANA registrations for TLVs, and registries for TLV Type o IANA registrations for TLVs, and registries for TLV Type
Extensions, replacing those from [RFC6622]. Extensions, replacing those from [RFC6622].
This document sets up IANA registries for recording code points for This document specifies IANA registries for recording code points for
ICV TLVs and TIMESTAMP TLVs, as well as timestamps, hash-functions, ICV TLVs and TIMESTAMP TLVs, as well as timestamps, hash-functions,
and cryptographic functions. and cryptographic functions.
Moreover, in Section 12, this document defines the following: Moreover, in Section 12, this document defines the following:
o A method for generating ICVs using a combination of a o A method for generating ICVs using a combination of a
cryptographic function and a hash function, and for including such cryptographic function and a hash function, and for including such
ICVs in the value field of a TLV. ICVs in the value field of a TLV.
1.1. Differences from RFC6622 1.1. Differences from RFC6622
This document obsoletes [RFC6622], replacing that document as the This document obsoletes [RFC6622], replacing that document as the
specification of two TLV types, TIMESTAMP and ICV, for packets, specification of two TLV types, TIMESTAMP and ICV, for packets,
messages and address blocks. For the ICV TLV as well as repeating messages and address blocks. For the ICV type, this document
the specification of two type extensions, 0 and 1, it also specifies specifies a new type extension, 2 (see Section 12), in addition to
a new type extension, 2, in Section 12 of this document. including the original type extensions (0 and 1) from [RFC6622].
The TLV value of an ICV TLV with type extension 2 has the same The TLV value of an ICV TLV with type extension 2 has the same
internal structure as an ICV TLV with type extension 1, but is internal structure as an ICV TLV with type extension 1, but is
calculated also over the source address of the IP datagram carrying calculated also over the source address of the IP datagram carrying
the packet, message, or Address Block. The rationale for adding this the packet, message, or Address Block. The rationale for adding this
type extension is that some MANET protocols, such as [RFC6130], use type extension is that some MANET protocols, such as [RFC6130], use
the IP source address of the IP datagram carrying the packet, message the IP source address of the IP datagram carrying the packet, message
or Address Block, e.g., to identify links with neighbor routers. If or Address Block, e.g., to identify links with neighbor routers. If
this address is not otherwise contained in the packet, message, or this address is not otherwise contained in the packet, message, or
Address Block payload (which is permitted, e.g., in [RFC6130]), then Address Block payload (which is permitted, e.g., in [RFC6130]), then
skipping to change at page 7, line 30 skipping to change at page 7, line 30
specification of such MANET routing protocol security extensions. specification of such MANET routing protocol security extensions.
This document addresses the last of the points above, by specifying a This document addresses the last of the points above, by specifying a
common exchange format for cryptographic ICVs and timestamps, making common exchange format for cryptographic ICVs and timestamps, making
reservations from within the Packet TLV, Message TLV, and Address reservations from within the Packet TLV, Message TLV, and Address
Block TLV registries of [RFC5444], to be used by (and shared among) Block TLV registries of [RFC5444], to be used by (and shared among)
MANET routing protocol security extensions. MANET routing protocol security extensions.
For the specific decomposition of an ICV using a cryptographic For the specific decomposition of an ICV using a cryptographic
function and a hash function (specified in Section 12), this document function and a hash function (specified in Section 12), this document
sets up two IANA registries (see Section 13) for code points for hash specifies two IANA registries (see Section 13) for code points for
functions and cryptographic functions. hash functions and cryptographic functions.
With respect to [RFC5444], this document is: With respect to [RFC5444], this document is:
o Intended to be used in the non-normative, but intended, mode of o Intended to be used in the non-normative, but intended, mode of
use described in Appendix B of [RFC5444]. use described in Appendix B of [RFC5444].
o A specific example of the Security Considerations section of o A specific example of the Security Considerations section of
[RFC5444] (the authentication part). [RFC5444] (the authentication part).
5. Overview and Functioning 5. Overview and Functioning
This document specifies a syntactical representation of security- This document specifies a syntactical representation of security-
related information for use with [RFC5444] addresses, messages, and related information for use with [RFC5444] addresses, messages, and
packets, and also sets up IANA registrations (see Section 13) of TLV packets, and also specifies IANA registrations (see Section 13) of
types and type extension registries for these TLV types. TLV types and type extension registries for these TLV types.
Moreover, this document provides guidelines for how MANET routing Moreover, this document provides guidelines for how MANET routing
protocols, and MANET routing protocol extensions using this protocols, and MANET routing protocol extensions using this
specification, should treat ICV and Timestamp TLVs, and mutable specification, should treat ICV and Timestamp TLVs, and mutable
fields in messages. This specification does not represent a stand- fields in messages. This specification does not represent a stand-
alone protocol. MANET routing protocols, and MANET routing protocol alone protocol. MANET routing protocols, and MANET routing protocol
extensions using this specification, MUST provide instructions as to extensions using this specification, MUST provide instructions as to
how to handle packets, messages, and addresses with security how to handle packets, messages, and addresses with security
information, associated as specified in this document. information, associated as specified in this document.
This document sets up TLV type assignments (see Section 13) from the This document specifies TLV type assignments (see Section 13) from
registries defined for Packet, Message, and Address Block TLVs in the registries defined for Packet, Message, and Address Block TLVs in
[RFC5444]. When a TLV type is assigned from one of these registries, [RFC5444]. When a TLV type is assigned from one of these registries,
a registry for type extensions for that TLV type is created by IANA. a registry for type extensions for that TLV type is created by IANA.
This document sets up these type extension registries, in order to This document specifies these type extension registries, in order to
specify internal structure (and accompanying processing) of the specify internal structure (and accompanying processing) of the
<value> field of a TLV. <value> field of a TLV.
For example, and as reported in this document, an ICV TLV with type For example, and as reported in this document, an ICV TLV with type
extension = 0 specifies that the <value> field has no pre-defined extension = 0 specifies that the <value> field has no pre-defined
internal structure, but is simply a sequence of octets. An ICV TLV internal structure, but is simply a sequence of octets. An ICV TLV
with type extension = 1 specifies that the <value> field has a pre- with type extension = 1 specifies that the <value> field has a pre-
defined internal structure and defines its interpretation. An ICV defined internal structure and defines its interpretation. An ICV
TLV with type extension = 2 (added in this document) is the same as TLV with type extension = 2 (added in this document) is the same as
an ICV TLV with type extension = 1, except that the integrity an ICV TLV with type extension = 1, except that the integrity
skipping to change at page 14, line 4 skipping to change at page 14, line 4
The version of this TLV, specified in this section, assumes that, The version of this TLV, specified in this section, assumes that,
unless otherwise specified, calculating the ICV can be decomposed unless otherwise specified, calculating the ICV can be decomposed
into: into:
ICV-value = cryptographic-function(hash-function(content)) ICV-value = cryptographic-function(hash-function(content))
In some cases a different combination of cryptographic function and In some cases a different combination of cryptographic function and
hash function may be specified. This is the case for the HMAC hash function may be specified. This is the case for the HMAC
function, which is specified as defined in Section 13.12, using the function, which is specified as defined in Section 13.12, using the
hash function twice. hash function twice. Using cryptographic-function "none" is provided
for symmetry and possible future use, but it SHOULD NOT be used with
any currently specified hash-function.
The difference between the two type extensions is that in addition to The difference between the two type extensions is that in addition to
the information covered by the ICV using type extension 1 (which is the information covered by the ICV using type extension 1 (which is
detailed in the following sections), the ICV using type extension 2 detailed in the following sections), the ICV using type extension 2
also MUST cover the source address of the IP datagram carrying the also MUST cover the source address of the IP datagram carrying the
corresponding packet, message, or Address Block. corresponding packet, message, or Address Block.
The <ICV-data> field MAY be truncated after being calculated, this is The <ICV-data> field MAY be truncated after being calculated, this is
indicated by its length, calculated as described above. The indicated by its length, calculated as described above. The
truncation SHOULD be as specified for the relevant cryptographic truncation SHOULD be as specified for the relevant cryptographic
function (and, if appropriate, hash function). function (and, if appropriate, hash function). When using
truncation, it is RECOMMENDED to follow the guidelines for minimal
ICV length set out in [NIST-SP-800-107]. In particular, the <ICV-
data> field HMAC SHOULD NOT be truncated below 4 octets.
The hash function and the cryptographic function correspond to the The hash function and the cryptographic function correspond to the
entries in two IANA registries, which are described in Section 13. entries in two IANA registries, which are described in Section 13.
12.1.1. Rationale 12.1.1. Rationale
The rationale for separating the hash function and the cryptographic The rationale for separating the hash function and the cryptographic
function into two octets instead of having all combinations in a function into two octets instead of having all combinations in a
single octet -- possibly as a TLV type extension -- is that adding single octet -- possibly as a TLV type extension -- is that adding
further hash functions or cryptographic functions in the future may further hash functions or cryptographic functions in the future may
skipping to change at page 25, line 40 skipping to change at page 25, line 40
| Value | Algorithm | Description | Reference | | Value | Algorithm | Description | Reference |
+---------+-----------+---------------------------------+-----------+ +---------+-----------+---------------------------------+-----------+
| 0 | none | The "identity function": The | RFC xxxx | | 0 | none | The "identity function": The | RFC xxxx |
| | | value of an encrypted hash is | | | | | value of an encrypted hash is | |
| | | the hash itself | | | | | the hash itself | |
| 1 | RSA | [RFC3447] | RFC xxxx | | 1 | RSA | [RFC3447] | RFC xxxx |
| 2 | DSA | [NIST-FIPS-186-3] | RFC xxxx | | 2 | DSA | [NIST-FIPS-186-3] | RFC xxxx |
| 3 | HMAC | [RFC2104] | RFC xxxx | | 3 | HMAC | [RFC2104] | RFC xxxx |
| 4 | 3DES | [NIST-SP-800-67] | RFC xxxx | | 4 | 3DES | [NIST-SP-800-67] | RFC xxxx |
| 5 | AES-128 | [NIST-FIPS-197] | RFC xxxx | | 5 | AES-128 | [NIST-FIPS-197] | RFC xxxx |
| 6 | ECDSA | [ANSI-X9-62-2005] | RFC xxxx | | 6 | ECDSA | [RFC6090] | RFC xxxx |
| 7-251 | | Unassigned; Expert Review | | | 7-251 | | Unassigned; Expert Review | |
| 252-255 | | Experimental Use | RFC xxxx | | 252-255 | | Experimental Use | RFC xxxx |
+---------+-----------+---------------------------------+-----------+ +---------+-----------+---------------------------------+-----------+
Table 11: Cryptographic Function Registry Table 11: Cryptographic Function Registry
14. Security Considerations 14. Security Considerations
This document does not specify a protocol. It provides a syntactical This document does not specify a protocol. It provides a syntactical
component for cryptographic ICVs of messages and packets, as defined component for cryptographic ICVs of messages and packets, as defined
skipping to change at page 27, line 28 skipping to change at page 27, line 28
[NIST-FIPS-197] National Institute of Standards and [NIST-FIPS-197] National Institute of Standards and
Technology, "Specification for the Technology, "Specification for the
Advanced Encryption Standard (AES)", Advanced Encryption Standard (AES)",
FIPS 197, November 2001. FIPS 197, November 2001.
[NIST-FIPS-186-3] National Institute of Standards and [NIST-FIPS-186-3] National Institute of Standards and
Technology, "Digital Signature Standard Technology, "Digital Signature Standard
(DSS)", FIPS 186-3, June 2009. (DSS)", FIPS 186-3, June 2009.
[ANSI-X9-62-2005] American National Standards Institute, [NIST-SP-800-107] National Institute of Standards and
"Public Key Cryptography for the Technology, "Recommendation for
Financial Services Industry: The Elliptic Applications Using Approved Hash
Curve Digital Signature Algorithm Algorithms", SP 800-107, Revision 1,
(ECDSA)", ANSI X9.62-2005, November 2005. August 2012.
[RFC6090] McGrew, D., Igoe, K., and M. Salter,
"Fundamental Elliptic Curve Cryptography
Algorithms", RFC 6090, February 2011.
[NIST-SP-800-67] National Institute of Standards and [NIST-SP-800-67] National Institute of Standards and
Technology, "Recommendation for the Technology, "Recommendation for the
Triple Data Encryption Algorithm (TDEA) Triple Data Encryption Algorithm (TDEA)
Block Cipher", Special Block Cipher", Special
Publication 800-67, Revision 1, Publication 800-67, Revision 1,
January 2012. January 2012.
[NIST-FIPS-180-4] National Institute of Standards and [NIST-FIPS-180-4] National Institute of Standards and
Technology, "Secure Hash Standard (SHS)", Technology, "Secure Hash Standard (SHS)",
 End of changes. 16 change blocks. 
25 lines changed or deleted 34 lines changed or added

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