Integrity Check Value and Timestamp TLV Definitions for Mobile Ad Hoc Networks (MANETs)
draft-ietf-manet-rfc6622-bis-06

[Ballot comment]

Thanks for handling my discuss about truncation.

I didn't check the comments below vs. -06, but feel free to
follow up if needed, or not.

S

- 12.1: You say the truncation should be as specified for
the relevant function(s). I think you mean that each such
function registered in the IANA registry MUST specify if
truncation is allowed and to what length(s). Is that
right? If so, putting it that way would probably be
better. And in this case and for the -sec draft, since
you've not specified any truncation for HMAC-SHA-256 then
that means that all 256 bits must be used - right?

- section 13: I think it'd be good to say that the expert
SHOULD NOT approve registrations where ICVs can be
truncated so as to make them vulnerable given the state
of the art when the registration is requested.

- Please consider the suggestions made in the secdir
review [1] about naming and IANA. And for completeness
I'll note that I did discuss the lack of AKM here with
the authors and am ok with it, as per the justification
in the olsrv2 draft (even though the secdir reviewer
also properly noted this).

  [1] http://www.ietf.org/mail-archive/web/secdir/current/msg04080.html

[Ballot discuss]

-05 says SHOULD NOT be less than 32 bits. I think that's still too
small and mailed the authors.

I've raised the truncation issue to a discuss based on this mail exchange
with Christopher:

On 08/14/2013 02:47 PM, Dearlove, Christopher (UK) wrote:
> (Note that I'm writing as "we" meaning the authors, as I believe this
> is the intent. However I have not actually confirmed this email with
> them, so please read accordingly.)
>
> No, we intend to allow the HMAC-SHA-256 to be truncated after the
> calculation. We intend the default in all cases to be that truncation
> is allowed.
>
> There is, we are informed, an approach that is of interest to some
> (this came from outside the group of authors), which we do not intend
> to disallow, that says that a massively truncated, let's say to one
> octet, ICV is still as difficult to calculate as it would be
> non-truncated. But a random guess can obviously be made, with a 1 in
> 256 chance of creating a successfully spoofed message. This approach
> (and note that this is the general framework RFC, not the application
> to a specific protocol) assumes (or more) that whatever the proposed
> application is can handle such a rate. (Or a lower rate with a less
> massive truncation.) Of course you can flooding with many messages,
> but at this point the flood is probably the immediately greater
> problem.
>
> So we wish to allow people to do that. What they do with it is beyond
> the scope of this draft, but we shouldn't make unnecessary (at this
> point) restrictions. The suggested text for Section 13 could be read
> however as disallowing this in a future ICV, which is not our
> intent.

Ah. That I think is problematic. A one byte ICV is worse
than useless.

Even if the chances of success were 1/256 the fact that I
could send guesses to one set of nodes until one works and
then use that first time at all other nodes sharing the key.
Major gotcha.

And worse, if anyone can truncate and if the verifier doesn't
have to agree to that in advance then the whole ICV is useless.

I think you do need to fix that.

[Ballot discuss]
updated based on -05
--------------
Maybe before answering that I'd like to know why you even need to indicate the algorithms used at all?  Doesn't the key identifier tell the recipient which security association is in place and then it'll know which algorithms got used?  This obviously presupposes that one a manent network is set up it uses the same security settings and doesn't change on the fly, but isn't that a pretty good bet?  Even if you you use the special zero value wouldn't you already know the algorithms to be used?

>> I will just say that my implementation of some of the options here
>> takes the approach that by default it uses zero, and assumes all is
>> known. It has a flag to force using a non-zero option, but that's
>> mainly to allow me to test. On reception, accept either zero or (to
>> allow interworking with possible other implementations, accept an
>> explicit specification that is exactly right. But for this document, I
>> think we are at the "you may specify method, you do not specify
>> parameters" as a locked-in design choice.

Hmm so zero is supposed to me pre-agreed?  The draft says this which is different isn't it:

  Using cryptographic-function "none" is provided
  for symmetry and possible future use, but it SHOULD NOT be used with
  any currently specified hash-function.

--------------
RFC 3447 has two signature schemes to which are you referring?  Actually, are you referring to the signature algorithms or are you also referring to RSA in key transport mode or OAEP?  I assume it's just PKCS v1.5, but I think you need to say that explicitly.  Also, for RSA there are two common exponents 3 and 65537.  3 can be used if you don't care about confidentiality (used by DNS) but 65537 is used pretty much everywhere else.  Do you need to say which exponent is to be used?

>> See discussion above, do we constrain or leave the option open?
>> It's not ideal either way. I'm going to have to take a look at RFC 3447
>> to make my judgement on this, but others may have different ones.

All I'm saying here is that I think you really have to pick one to ensure interop.  If I say pick RSASSA-PKCS1-v1_5 to sign with and you pick RSASSA-PSS to verify with things might not work out so well.

--------------
Along the same lines, ECDSA uses a curve.  You could infer the size of the curve from the hash algorithm - if you linked the curve to the has output size - but is that what you want to do?

>> No, we don't want to link the curve to output size, as we want to
>> allow truncation. So  curve has to be one of the understood and
>> not carried over the air parameters. (Whether that then says
>> the same applies for RSA, and AES mode, is a point.)

Okay I'm not following this: You want to truncate the output of the signature process?  I can see truncating the output of the HMAC process btu the signature process?

[Ballot comment]
I support's Stephen's discussion position wrt truncating outputs.  RFC 2104 makes the following recommendations and I think they should be followed:

  We recommend that
  the output length t be not less than half the length of the hash
  output (to match the birthday attack bound) and not less than 80 bits
  (a suitable lower bound on the number of bits that need to be
  predicted by an attacker).

[Ballot comment]
I find myself concerned that the complexity and manageability considerations become more acute as this suite matures...

Statements like,

  This architecture is a result of the observation that with respect to
  security in MANETs, "one size rarely fits all" and that MANET routing
  protocol deployment domains have varying security requirements
  ranging from "unbreakable" to "virtually none". 

do not give me confidence in the long term usability and interoperability of manet routing protol implementations that employ fully or partially mechanisms in 6622 or 6622-bis.

[Ballot discuss]
I'm actually hoping these are all straight forward ;)

Say there was an environment that wanted to use ICV packet/message/address block tlv extension type 2 with AES-CMAC and AES-128 in GCM mode.  Would we need to register AES as a hash function and CMAC as the cryptographic function?  And, how do we indicate the AES mode - or do you not need to?

Maybe before answering that I'd like to know why you even need to indicate the algorithms used at all?  Doesn't the key identifier tell the recipient which security association is in place and then it'll know which algorithms got used?  This obviously presupposes that one a manent network is set up it uses the same security settings and doesn't change on the fly, but isn't that a pretty good bet?  Even if you you use the special zero value wouldn't you already know the algorithms to be used?

RFC 3447 has two signature schemes to which are you referring?  Actually, are you referring to the signature algorithms or are you also referring to RSA in key transport mode or OAEP?  I assume it's just PKCS v1.5, but I think you need to say that explicitly.  Also, for RSA there are two common exponents 3 and 65537.  3 can be used if you don't care about confidentiality (used by DNS) but 65537 is used pretty much everywhere else.  Do you need to say which exponent is to be used?

Along the same lines, ECDSA uses a curve.  You could infer the size of the curve from the hash algorithm - if you linked the curve to the has output size - but is that what you want to do?

Now on to key formats: Do you need to specify the format of the key?  For example are the public keys encoded as the SubjectPublicKeyInfo like IPsec does?  If you doing AES do you need to specify the encoding for the key (i.e., MSB info?)

s3: Just checking but the additional data that can be carried is only applicable to the control plane or can it also be data that might otherwise be carried on the data plane?

[Ballot comment]
I support's Stephen's discussion position wrt truncating outputs.  RFC 2104 makes the following recommendations and I think they should be followed:

  We recommend that
  the output length t be not less than half the length of the hash
  output (to match the birthday attack bound) and not less than 80 bits
  (a suitable lower bound on the number of bits that need to be
  predicted by an attacker).

And now for something completely different:

Do you also want to make RFC 6622 Historic - that is take it off the standards track completely?

Pretty please can we point to RFC 6090 instead of ANSI X9.62?  It's the RFC that David McGrew put together that uses really old references.  The only upshot here is that if you're going to refer to 6090 then it would also be good to ensure you link the curve to the hash algorithm.  For example, if you're using a p-256 key use SHA-256 and not SHA-1, 224, 384, or 512.

[Ballot discuss]

I've raised the truncation issue to a discuss based on this mail exchange
with Christopher:

On 08/14/2013 02:47 PM, Dearlove, Christopher (UK) wrote:
> (Note that I'm writing as "we" meaning the authors, as I believe this
> is the intent. However I have not actually confirmed this email with
> them, so please read accordingly.)
>
> No, we intend to allow the HMAC-SHA-256 to be truncated after the
> calculation. We intend the default in all cases to be that truncation
> is allowed.
>
> There is, we are informed, an approach that is of interest to some
> (this came from outside the group of authors), which we do not intend
> to disallow, that says that a massively truncated, let's say to one
> octet, ICV is still as difficult to calculate as it would be
> non-truncated. But a random guess can obviously be made, with a 1 in
> 256 chance of creating a successfully spoofed message. This approach
> (and note that this is the general framework RFC, not the application
> to a specific protocol) assumes (or more) that whatever the proposed
> application is can handle such a rate. (Or a lower rate with a less
> massive truncation.) Of course you can flooding with many messages,
> but at this point the flood is probably the immediately greater
> problem.
>
> So we wish to allow people to do that. What they do with it is beyond
> the scope of this draft, but we shouldn't make unnecessary (at this
> point) restrictions. The suggested text for Section 13 could be read
> however as disallowing this in a future ICV, which is not our
> intent.

Ah. That I think is problematic. A one byte ICV is worse
than useless.

Even if the chances of success were 1/256 the fact that I
could send guesses to one set of nodes until one works and
then use that first time at all other nodes sharing the key.
Major gotcha.

And worse, if anyone can truncate and if the verifier doesn't
have to agree to that in advance then the whole ICV is useless.

I think you do need to fix that.

[Ballot comment]
- 12.1: You say the truncation should be as specified for
the relevant function(s). I think you mean that each such
function registered in the IANA registry MUST specify if
truncation is allowed and to what length(s). Is that
right? If so, putting it that way would probably be
better. And in this case and for the -sec draft, since
you've not specified any truncation for HMAC-SHA-256 then
that means that all 256 bits must be used - right?

- section 13: I think it'd be good to say that the expert
SHOULD NOT approve registrations where ICVs can be
truncated so as to make them vulnerable given the state
of the art when the registration is requested.

- Please consider the suggestions made in the secdir
review [1] about naming and IANA. And for completeness
I'll note that I did discuss the lack of AKM here with
the authors and am ok with it, as per the justification
in the olsrv2 draft (even though the secdir reviewer
also properly noted this).

  [1] http://www.ietf.org/mail-archive/web/secdir/current/msg04080.html

[Ballot comment]

- 12.1: You say the truncation should be as specified for
the relevant function(s). I think you mean that each such
function registered in the IANA registry MUST specify if
truncation is allowed and to what length(s). Is that
right? If so, putting it that way would probably be
better. And in this case and for the -sec draft, since
you've not specified any truncation for HMAC-SHA-256 then
that means that all 256 bits must be used - right?

- section 13: I think it'd be good to say that the expert
SHOULD NOT approve registrations where ICVs can be
truncated so as to make them vulnerable given the state
of the art when the registration is requested.

- Please consider the suggestions made in the secdir
review [1] about naming and IANA. And for completeness
I'll note that I did discuss the lack of AKM here with
the authors and am ok with it, as per the justification
in the olsrv2 draft (even though the secdir reviewer
also properly noted this).

  [1] http://www.ietf.org/mail-archive/web/secdir/current/msg04080.html

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-manet-rfc6622-bis-02.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

IANA has several questions about the IANA Actions requested by the authors in this document.

IANA understands that there are either three, four, or five actions to be completed upon approval of this document.

First, in the Packet TLV Types registry of the Mobile Ad hoc NETwork (MANET) Parameters registry located at:

http://www.iana.org/assignments/manet-parameters

a change is made to the existing registry by adding a field for Type Extension.  In addition, the registrations for ICV and TIMESTAMP are changed as follows:

+-----------+------+-----------+------------------------------------+
|    Name  | Type |    Type  |            Description            |
|          |      | Extension |                                    |
+-----------+------+-----------+------------------------------------+
|    ICV    |  5  |    0    |          ICV of a packet          |
|          |      |    1    |    ICV, using a cryptographic    |
|          |      |          |  function and a hash function, as  |
|          |      |          |  specified in Section 12 of      |
|          |      |          |          [ RFC-to-be ]            |
|          |      |    2    |    ICV, using a cryptographic    |
|          |      |          |  function and a hash function, and |
|          |      |          |  including the IP datagram source  |
|          |      |          |      address, as specified in      |
|          |      |          |    Section 12 of [ RFC-to-be ]    |
|          |      |  3-251  |      Unassigned; Expert Review    |
|          |      |  252-255  |          Experimental Use          |
| TIMESTAMP |  6  |    0    |  Unsigned timestamp of arbitrary  |
|          |      |          |  length, given by the TLV Length  |
|          |      |          | field.  The MANET routing protocol |
|          |      |          |  has to define how to interpret  |
|          |      |          |          this timestamp          |
|          |      |    1    |    Unsigned 32-bit timestamp, as  |
|          |      |          |  specified in [IEEE 1003.1-2008  |
|          |      |          |              (POSIX)]              |
|          |      |    2    | NTP timestamp format, as specified |
|          |      |          |            in [RFC5905]            |
|          |      |    3    |    Signed timestamp of arbitrary  |
|          |      |          | length with no constraints such as |
|          |      |          |  monotonicity.  In particular, it  |
|          |      |          |  may represent any random value  |
|          |      |  4-251  |      Unassigned; Expert Review    |
|          |      |  252-255  |          Experimental Use          |
+-----------+------+-----------+------------------------------------+


IANA Question --> are the Packet TLV Types currently marked Unassigned, and Reserved for Experimental Use to be left as they are, with no type extension indicated?

IANA Question --> are any references to RFC6622 in this registry to be changed to [ RFC-to-be ]?

Second, in the Message TLV Types registry of the Mobile Ad hoc NETwork (MANET) Parameters registry located at:

http://www.iana.org/assignments/manet-parameters

a change is made to the existing registry by adding a field for Type Extension.  In addition, the registrations for ICV and TIMESTAMP are changed as follows:

+-----------+------+-----------+------------------------------------+
|    Name  | Type |    Type  |            Description            |
|          |      | Extension |                                    |
+-----------+------+-----------+------------------------------------+
|    ICV    |  5  |    0    |          ICV of a message          |
|          |      |    1    |    ICV, using a cryptographic    |
|          |      |          |  function and a hash function, as  |
|          |      |          |  specified in Section 12 of      |
|          |      |          |          [ RFC-to-be ]            |
|          |      |    2    |    ICV, using a cryptographic    |
|          |      |          |  function and a hash function, and |
|          |      |          |  including the IP datagram source  |
|          |      |          |      address, as specified in      |
|          |      |          |    Section 12 of [ RFC-to-be ]    |
|          |      |  3-251  |      Unassigned; Expert Review    |
|          |      |  252-255  |          Experimental Use          |
| TIMESTAMP |  6  |    0    |  Unsigned timestamp of arbitrary  |
|          |      |          |  length, given by the TLV Length  |
|          |      |          |              field.              |
|          |      |    1    |    Unsigned 32-bit timestamp, as  |
|          |      |          |  specified in [IEEE 1003.1-2008  |
|          |      |          |              (POSIX)]              |
|          |      |    2    | NTP timestamp format, as specified |
|          |      |          |            in [RFC5905]            |
|          |      |    3    |    Signed timestamp of arbitrary  |
|          |      |          | length with no constraints such as |
|          |      |          |  monotonicity.  In particular, it  |
|          |      |          |  may represent any random value  |
|          |      |  4-251  |      Unassigned; Expert Review    |
|          |      |  252-255  |          Experimental Use          |
+-----------+------+-----------+------------------------------------+

IANA Question --> are the Message TLV Types currently marked INTERVAL_TIME, VALIDITY_TIME, MPR_WILLING, CONT_SEQ_NUM, Unassigned and Reserved for Experimental Use to be left as they are - with no type extension indicated?

IANA Question --> are any references to RFC6622 in this subregistry to be changed to [ RFC-to-be ]?

Third, in the Address Block TLV Types subregistry of the Mobile Ad hoc NETwork (MANET) Parameters registry located at:

http://www.iana.org/assignments/manet-parameters

a change is made to the existing registry by adding a field for Type Extension.  In addition, the registrations for ICV and TIMESTAMP are changed as follows:

+-----------+------+-----------+------------------------------------+
|    Name  | Type |    Type  |            Description            |
|          |      | Extension |                                    |
+-----------+------+-----------+------------------------------------+
|    ICV    |  5  |    0    |    ICV of an object (e.g., an    |
|          |      |          |              address)              |
|          |      |    1    |    ICV, using a cryptographic    |
|          |      |          |  function and a hash function, as  |
|          |      |          |  specified in Section 12 of      |
|          |      |          |          [ RFC-to-be ]            |
|          |      |    2    |    ICV, using a cryptographic    |
|          |      |          |  function and a hash function, and |
|          |      |          |  including the IP datagram source  |
|          |      |          |      address, as specified in      |
|          |      |          |    Section 12 of [ RFC-to-be ]    |
|          |      |  3-251  |      Unassigned; Expert Review    |
|          |      |  252-255  |          Experimental Use          |
| TIMESTAMP |  6  |    0    |  Unsigned timestamp of arbitrary  |
|          |      |          |  length, given by the TLV Length  |
|          |      |          |                field              |
|          |      |    1    |    Unsigned 32-bit timestamp, as  |
|          |      |          |  specified in [IEEE 1003.1-2008  |
|          |      |          |              (POSIX)]              |
|          |      |    2    | NTP timestamp format, as specified |
|          |      |          |            in [RFC5905]            |
|          |      |    3    |    Signed timestamp of arbitrary  |
|          |      |          | length with no constraints such as |
|          |      |          |  monotonicity.  In particular, it  |
|          |      |          |  may represent any random value  |
|          |      |  4-251  |      Unassigned; Expert Review    |
|          |      |  252-255  |          Experimental Use          |
+-----------+------+-----------+------------------------------------+

IANA Question --> are the Address Block TLV Types currently marked INTERVAL_TIME, VALIDITY_TIME, LOCAL_IF, LINK_STATUS, OTHER-NEIGHZB, LINK_METRIC, MPR, NBR_ADDR_TYPE, GATEWAY, Unassigned and Reserved for Experimental Use to be left as they are, with no type extension indicated?

IANA Question --> are any references to RFC6622 in this registry to be changed to [ RFC-to-be ]?

Fourth, in the Hash Functions registry of the Mobile Ad hoc NETwork (MANET) Parameters registry located at:

http://www.iana.org/assignments/manet-parameters

IANA understands that no changes are to be made.  However . . .

IANA Question --> are any references to RFC6622 in this registry to be changed to [ RFC-to-be ]?

Fifth, in the Cryptographic Functions subregistry of the Mobile Ad hoc NETwork (MANET) Parameters registry located at:

http://www.iana.org/assignments/manet-parameters

IANA understands that no changes are to be made.  However . . .

IANA Question --> are any references to RFC6622 in this registry to be changed to [ RFC-to-be ]?

IANA understands that these actions are the only ones required upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Integrity Check Value and Timestamp TLV Definitions for Mobile Ad Hoc Networks (MANETs)) to Proposed Standard

The IESG has received a request from the Mobile Ad-hoc Networks WG
(manet) to consider the following document:
- 'Integrity Check Value and Timestamp TLV Definitions for Mobile Ad Hoc
  Networks (MANETs)'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-06-27. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

  This document revises, extends and replaces RFC 6622.  It describes
  general and flexible TLVs for representing cryptographic Integrity
  Check Values (ICVs) and timestamps, using the generalized Mobile Ad
  Hoc Network (MANET) packet/message format defined in RFC 5444.  It
  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
  more addresses, respectively.


The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-manet-rfc6622-bis/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-manet-rfc6622-bis/ballot/


No IPR declarations have been submitted directly on this I-D.

(1) The request is to publish this document as a Standards Track RFC,
and this is indicated in the document header.

(2) Document Announcement Write-Up.

Technical Summary

The abstract of this document is included below.

This document revises, extends and replaces RFC 6622.  It describes general and flexible TLVs for representing cryptographic Integrity Check Values (ICVs) and timestamps, using the generalized Mobile Ad Hoc Network (MANET) packet/message format defined in RFC 5444.  It 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 more addresses, respectively.


Working Group Summary

Working group consensus behind the document is solid. There is strong consensus behind a set of members in the working group that this revision is needed.


Document Quality

The document has received careful review. There are several implementations of the document.

Personnel

The Document Shepherd is Joseph Macker (jpmacker@gmail.com); the
responsible Area Directors are Adrian Farrel and Stewart Bryant.

(3) The document Shepherd has participated in review both in the Working
Group, and has run the "idnits" tool against the draft.

(4) The Document Shepherd has no concerns about the reviews of the
document; they have been thorough and there has been good technical interchange amongst authors and other parties regarding content issues.

(5) The authors do not believe that additional reviews are required,
aside from the usual directorate reviews during IETF last call.

(6) The Document Shepherd has no concerns with the document.

(7) All authors have confirmed that they are unaware of any IPR needing
disclosure; there are no known IPR claims related to this document.

(8) No IPR disclosures have been filed, as none are required.

(9) WG consensus appears to be strong.

(10) WGLC has close and nobody has threatened an appeal or otherwise indicated extreme discontent.

(11) There are two errors according to idnits: two downward normative references (and some possible downrefs to non-RFCs). Refer to point 15.

(12) MIB Doctor, media type, and URI reviews are not required.

(13) All references have been defined as either normative or
informative.

(14) No normative references exist to documents not ready for
advancement. Of the normative references, all are to already published
RFC's (or to non-IETF documents, see point 11).

(15) There are several downward normative references in the document, as well as
non-IETF documents:
  ** Downref: Normative reference to an Informational RFC: RFC 3447
  ** Downref: Normative reference to an Informational RFC: RFC 2104
  -- Possible downref: Non-RFC (?) normative reference: ref. 'NIST-FIPS-197'
  -- Possible downref: Non-RFC (?) normative reference: ref. 'NIST-FIPS-186-3'
  -- Possible downref: Non-RFC (?) normative reference: ref. 'ANSI-X9-62-2005'
  -- Possible downref: Non-RFC (?) normative reference: ref. 'NIST-SP-800-67'
  -- Possible downref: Non-RFC (?) normative reference: ref. 'NIST-FIPS-180-4'

The two downrefs are listed in http://trac.tools.ietf.org/group/iesg/trac/wiki/DownrefRegistry as acceptable downrefs. The other possible downrefs are external standards.

(16) The document will obsolete RFC6622. This obsoleted RFC is listed on the title page header, listed in the abstract, and discussed in the introduction.

(17) The Document Shepherd has reviewed the IANA considerations section
of the document, and it appears wholly consistent with the body of said
document. Extensions are associated with the appropriate reservations in
IANA registries. All IANA registries have been clearly defined.

(18) Impact on IANA registries :

A new type extension has been added to the following registries set up by RFC6622: the ICV Packet TLV Type Extensions registry, the ICV Message TLV Type Extensions and the ICV Address TLV Type Extensions registries.

(19) There are no sections written in a formal language, such as XML code, BNF rules, MIB definitions, etc.