draft-ietf-manet-rfc6622-bis-05.txt   draft-ietf-manet-rfc6622-bis-06.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: March 14, 2014 C. Dearlove Expires: May 19, 2014 C. Dearlove
BAE Systems ATC BAE Systems ATC
September 10, 2013 November 15, 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-05 draft-ietf-manet-rfc6622-bis-06
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 March 14, 2014. This Internet-Draft will expire on May 19, 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 25 skipping to change at page 3, line 25
8. Packet TLVs . . . . . . . . . . . . . . . . . . . . . . . . . 9 8. Packet TLVs . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. ICV Packet TLV . . . . . . . . . . . . . . . . . . . . . 9 8.1. ICV Packet TLV . . . . . . . . . . . . . . . . . . . . . 9
8.2. TIMESTAMP Packet TLV . . . . . . . . . . . . . . . . . . 10 8.2. TIMESTAMP Packet TLV . . . . . . . . . . . . . . . . . . 10
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 . . . . . . . . 13
12.1. General ICV TLV Structure . . . . . . . . . . . . . . . . 13 12.1. General ICV TLV Structure . . . . . . . . . . . . . . . . 13
12.1.1. Rationale . . . . . . . . . . . . . . . . . . . . . . 14 12.1.1. Rationale . . . . . . . . . . . . . . . . . . . . . . 15
12.2. Considerations for Calculating the ICV . . . . . . . . . 15 12.1.2. Parameters . . . . . . . . . . . . . . . . . . . . . 15
12.2.1. ICV Packet TLV . . . . . . . . . . . . . . . . . . . 15 12.2. Considerations for Calculating the ICV . . . . . . . . . 16
12.2.2. ICV Message TLV . . . . . . . . . . . . . . . . . . . 15 12.2.1. ICV Packet TLV . . . . . . . . . . . . . . . . . . . 16
12.2.3. ICV Address Block TLV . . . . . . . . . . . . . . . . 16 12.2.2. ICV Message TLV . . . . . . . . . . . . . . . . . . . 17
12.3. Example of a Message Including an ICV . . . . . . . . . . 16 12.2.3. ICV Address Block TLV . . . . . . . . . . . . . . . . 17
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 12.3. Example of a Message Including an ICV . . . . . . . . . . 18
13.1. Expert Review: Evaluation Guidelines . . . . . . . . . . 18 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
13.2. Packet TLV Types . . . . . . . . . . . . . . . . . . . . 18 13.1. Expert Review: Evaluation Guidelines . . . . . . . . . . 19
13.3. Message TLV Types . . . . . . . . . . . . . . . . . . . . 18 13.2. Packet TLV Types . . . . . . . . . . . . . . . . . . . . 19
13.4. Address Block TLV Types . . . . . . . . . . . . . . . . . 19 13.3. Message TLV Types . . . . . . . . . . . . . . . . . . . . 20
13.5. ICV Packet TLV Type Extensions . . . . . . . . . . . . . 19 13.4. Address Block TLV Types . . . . . . . . . . . . . . . . . 20
13.6. TIMESTAMP Packet TLV Type Extensions . . . . . . . . . . 20 13.5. ICV Packet TLV Type Extensions . . . . . . . . . . . . . 20
13.7. ICV Message TLV Type Extensions . . . . . . . . . . . . . 21 13.6. TIMESTAMP Packet TLV Type Extensions . . . . . . . . . . 21
13.8. TIMESTAMP Message TLV Type Extensions . . . . . . . . . . 22 13.7. ICV Message TLV Type Extensions . . . . . . . . . . . . . 22
13.9. ICV Address Block TLV Type Extensions . . . . . . . . . . 22 13.8. TIMESTAMP Message TLV Type Extensions . . . . . . . . . . 23
13.10. TIMESTAMP Address Block TLV Type Extensions . . . . . . . 23 13.9. ICV Address Block TLV Type Extensions . . . . . . . . . . 23
13.11. Hash Functions . . . . . . . . . . . . . . . . . . . . . 24 13.10. TIMESTAMP Address Block TLV Type Extensions . . . . . . . 24
13.12. Cryptographic Functions . . . . . . . . . . . . . . . . . 25 13.11. Hash Functions . . . . . . . . . . . . . . . . . . . . . 25
14. Security Considerations . . . . . . . . . . . . . . . . . . . 25 13.12. Cryptographic Functions . . . . . . . . . . . . . . . . . 26
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26 14. Security Considerations . . . . . . . . . . . . . . . . . . . 26
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27
16.1. Normative References . . . . . . . . . . . . . . . . . . 26 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
16.2. Informative References . . . . . . . . . . . . . . . . . 28 16.1. Normative References . . . . . . . . . . . . . . . . . . 27
16.2. Informative References . . . . . . . . . . . . . . . . . 29
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 specifies 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
skipping to change at page 12, line 32 skipping to change at page 12, line 32
described in Section 7. If one or more TIMESTAMP TLVs and one or described in Section 7. If one or more TIMESTAMP TLVs and one or
more ICV TLVs are associated with an address, the relevant TIMESTAMP more ICV TLVs are associated with an address, the relevant TIMESTAMP
TLV <time-value>(s) MUST be included before calculating the value of TLV <time-value>(s) MUST be included before calculating the value of
the ICV to be contained in the ICV TLV value (i.e., concatenated with the ICV to be contained in the ICV TLV value (i.e., concatenated with
the associated addresses and any other values as described in the associated addresses and any other values as described in
Section 10.1). Section 10.1).
11. ICV: Basic 11. ICV: Basic
The basic ICV, represented by way of an ICV TLV with type extension = The basic ICV, represented by way of an ICV TLV with type extension =
0, is a simple bit-field containing the cryptographic ICV. This 0, has as TLV value a simple bit-field without specified structure
assumes that the mechanism stipulating how ICVs are calculated and (i.e, without explicitly included hash function, crypto function, key
verified is established outside of this specification, e.g., by ID or other parameters). Moreover, it is not specified how to
administrative configuration or external out-of-band signaling. calculate the <ICV-value>. It is assumed that the mechanism
Thus, the <ICV-value>, when using type extension = 0, is: specifying how ICVs are calculated and verified, as well as which
parameters (if any) need to be exchanged prior to using the TLV with
type extension 0, is established outside of this specification, e.g.,
by administrative configuration or external out-of-band signaling.
The <ICV-value>, when using type extension = 0, is:
<ICV-value> := <ICV-data> <ICV-value> := <ICV-data>
where: where:
<ICV-data> is a field, of length <length> octets (or single-length <ICV-data> is a field, of length <length> octets (or single-length
octets in a multivalue Address Block TLV) that contains the octets in a multivalue Address Block TLV) that contains the
cryptographic ICV. cryptographic ICV.
12. ICV: Hash Function and Cryptographic Function 12. ICV: Hash Function and Cryptographic Function
skipping to change at page 14, line 16 skipping to change at page 14, line 23
any currently specified hash-function. 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 MUST be as specified for the relevant cryptographic
function (and, if appropriate, hash function). When using function (and, if appropriate, hash function).
truncation, it is RECOMMENDED to follow the guidelines for minimal
ICV length set out in [NIST-SP-800-107]. In particular, the <ICV- o When using truncation, the guidelines for minimal ICV length set
data> field HMAC SHOULD NOT be truncated below 4 octets. out in [NIST-SP-800-107] MUST be followed. In particular the
<ICV-data> field when using HMAC MUST NOT be truncated below 4
octets.
o The truncated ICV length MUST be so large that the probability of
success of a dictionary attack is acceptably small. Such a
success will arise if the ICV of a spoofed packet or message is
verified. The probability of success is a function of (a) how
many routers can be attacked, (b) how fast a router can receive
packets or messages and attempt to verify their ICV, (c) the
truncated ICV length, and (d) the lifetime of the network. If the
truncated ICV length in bits is L, then 2^L packets or messages
are required to attack with certainty of success. With a
verification rate of R packets/messages per second, applied to N
routers over an available time of T, the probability of success is
given by NRT/2^L. If this is to not exceed a probability of P,
then L > log2(NRT/P). For example if N is 32, R is 1000, T is
86400 (I day) and P is 10^-6, then L must be at least 52 bits.
Some of the cryptographic and hash functions listed in Section 13
require the length of the content to be digitally signed to be a
multiple of a certain number of octets. As a consequence, they
specify padding mechanisms, e.g., AES-CMAC [RFC4493] specifies a
padding mechanism for message lengths that are not equal to a
multiple of 16 octets. Implementations of the framework in this
document MUST support appropriate padding mechanisms, as specified in
the cryptographic or hash function specifications.
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 15, line 5 skipping to change at page 15, line 34
entail an extra overhead, to transmit the parameters within every entail an extra overhead, to transmit the parameters within every
message. message.
The rationale for the addition of type extension 2 is that the source The rationale for the addition of type extension 2 is that the source
code address is used in some cases, such as when processing HELLO code address is used in some cases, such as when processing HELLO
messages in [RFC6130]. This is applicable only to packets (which messages in [RFC6130]. This is applicable only to packets (which
only ever travel one hop) and messages (and their Address Blocks) only ever travel one hop) and messages (and their Address Blocks)
that only travel one hop. It is not applicable to messages that may that only travel one hop. It is not applicable to messages that may
be forwarded more than one hop, such as TC messages in [OLSRv2]. be forwarded more than one hop, such as TC messages in [OLSRv2].
12.1.2. Parameters
As described in Section 12.1.1, parameters such as RSA signature
scheme, RSA common exponent etc. are selected administratively on
each router before using this framework in a MANET, in addition to
exchanging the keys between MANET routers. This was a design
decision in [RFC6622] and is kept in this specification for reasons
of backwards-compatibility.
The following parameters are RECOMMENDED and SHOULD be those chosen
administratively, unless there are good reasons otherwise:
o For crypto function RSA:
* Signature scheme: RSASSA-PSS with the default parameters:
rSASSA-PSS-Default-Identifier (as defined in [RFC3447])
* Common exponent: 65537
o For crypto function ECDSA:
* Curve name: exchanged as part of key distribution
* Hash function: The hash function MUST be pinned to the curve,
i.e., use SHA-256 for the p-256 curve, SHA-384 for p-384 etc.
o For crypto function AES:
* Authentication algorithm: CMAC (as defined in [RFC4493]
* Hash function: None
12.2. Considerations for Calculating the ICV 12.2. Considerations for Calculating the ICV
The considerations listed in the following subsections MUST be The considerations listed in the following subsections MUST be
applied when calculating the ICV for Packet, Message, and Address applied when calculating the ICV for Packet, Message, and Address
Block TLVs, respectively. Block TLVs, respectively.
12.2.1. ICV Packet TLV 12.2.1. ICV Packet TLV
When determining the <ICV-data> for a packet, with type extension = When determining the <ICV-data> for a packet, with type extension =
1: 1:
skipping to change at page 25, line 36 skipping to change at page 26, line 36
Initial assignments and allocation policies are specified in Initial assignments and allocation policies are specified in
Table 11. IANA is requested to modify this allocation as indicated. Table 11. IANA is requested to modify this allocation as indicated.
+---------+-----------+---------------------------------+-----------+ +---------+-----------+---------------------------------+-----------+
| 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-4] | 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 | [NIST-FIPS-197] | RFC xxxx |
| 6 | ECDSA | [RFC6090] | 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
skipping to change at page 26, line 44 skipping to change at page 27, line 44
16. References 16. References
16.1. Normative References 16.1. Normative References
[BCP26] Narten, T. and H. Alvestrand, "Guidelines [BCP26] Narten, T. and H. Alvestrand, "Guidelines
for Writing an IANA Considerations for Writing an IANA Considerations
Section in RFCs", BCP 26, RFC 5226, Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
[NIST-FIPS-186-4] National Institute of Standards and
Technology, "Digital Signature Standard
(DSS)", FIPS 186-4, July 2013.
[NIST-FIPS-197] National Institute of Standards and
Technology, "Specification for the
Advanced Encryption Standard (AES)",
FIPS 197, November 2001.
[NIST-SP-800-107] National Institute of Standards and
Technology, "Recommendation for
Applications Using Approved Hash
Algorithms", SP 800-107, Revision 1,
August 2012.
[RFC2104] Krawczyk, H., Bellare, M., and R.
Canetti, "HMAC: Keyed-Hashing for Message
Authentication", RFC 2104, February 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs [RFC2119] Bradner, S., "Key words for use in RFCs
to Indicate Requirement Levels", BCP 14, to Indicate Requirement Levels", BCP 14,
RFC 2119, March 1997. RFC 2119, March 1997.
[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key
Cryptography Standards (PKCS) #1: RSA
Cryptography Specifications Version 2.1",
RFC 3447, February 2003.
[RFC4493] Song, JH., Poovendran, R., Lee, J., and
T. Iwata, "The AES-CMAC Algorithm",
RFC 4493, June 2006.
[RFC5444] Clausen, T., Dearlove, C., Dean, J., and [RFC5444] Clausen, T., Dearlove, C., Dean, J., and
C. Adjih, "Generalized Mobile Ad Hoc C. Adjih, "Generalized Mobile Ad Hoc
Network (MANET) Packet/Message Format", Network (MANET) Packet/Message Format",
RFC 5444, February 2009. RFC 5444, February 2009.
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., [RFC5905] Mills, D., Martin, J., Ed., Burbank, J.,
and W. Kasch, "Network Time Protocol and W. Kasch, "Network Time Protocol
Version 4: Protocol and Algorithms Version 4: Protocol and Algorithms
Specification", RFC 5905, June 2010. Specification", RFC 5905, June 2010.
[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key
Cryptography Standards (PKCS) #1: RSA
Cryptography Specifications Version 2.1",
RFC 3447, February 2003.
[RFC2104] Krawczyk, H., Bellare, M., and R.
Canetti, "HMAC: Keyed-Hashing for Message
Authentication", RFC 2104, February 1997.
[NIST-FIPS-197] National Institute of Standards and
Technology, "Specification for the
Advanced Encryption Standard (AES)",
FIPS 197, November 2001.
[NIST-FIPS-186-3] National Institute of Standards and
Technology, "Digital Signature Standard
(DSS)", FIPS 186-3, June 2009.
[NIST-SP-800-107] National Institute of Standards and
Technology, "Recommendation for
Applications Using Approved Hash
Algorithms", SP 800-107, Revision 1,
August 2012.
[RFC6090] McGrew, D., Igoe, K., and M. Salter, [RFC6090] McGrew, D., Igoe, K., and M. Salter,
"Fundamental Elliptic Curve Cryptography "Fundamental Elliptic Curve Cryptography
Algorithms", RFC 6090, February 2011. 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.
 End of changes. 14 change blocks. 
65 lines changed or deleted 133 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/