Authenticated Chunks for the Stream Control Transmission Protocol (SCTP)
draft-ietf-tsvwg-sctp-auth-08

[Ballot discuss]
The last paragraph of Section 6.1 is vital to the security service
  that is being specified, but I cannot figure out what it means.  It
  talks about three inputs (which are byte vectors):
 
    endpoint_pair_shared_key /* already known to both patries */
    key_number_1 :=
      RANDOM_parameter_1 || CHUNKS_parameter_1 || HMAC-ALGO_parameter_1
    key_number_2 :=
      RANDOM_parameter_2 || CHUNKS_parameter_2 || HMAC-ALGO_parameter_2
 
  And then the association shared key is computed as follows:
 
    if (key_number_1 is_smaller_than key_number_2) then
      association_shared_key :=
        key_number_1 || endpoint_pair_shared_key || key_number_2
    else if (key_number_2 is_smaller_than key_number_1) then
      association_shared_key :=
        key_number_2 || endpoint_pair_shared_key || key_number_1
    /* both key numbers are equal */
    else if (key_number_1 is_shorter_than key_number_2) then
      association_shared_key :=
        endpoint_pair_shared_key || key_number_1 || key_number_2
    else if (key_number_2 is_shorter_than key_number_1) then
      association_shared_key :=
        endpoint_pair_shared_key || key_number_2 || key_number_1
    /* key number lengths are the same */
    else if (heads == flip_coin()) then
      association_shared_key :=
        endpoint_pair_shared_key || key_number_1 || key_number_2
    else
      association_shared_key :=
        endpoint_pair_shared_key || key_number_2 || key_number_1

  I do not see a definition for "selecting the smaller key number."
  This is not obvious since the key numbers are byte vectors.  Are they
  treated as large unsigned integers or character strings?  Also, the
  last part is a waste.  The algorithm would be deterministic if the
  fourth possible construction is used if the second key number is
  shorter than or the same length as the first key number 1.  My guess
  is that the two key numbers are the same if you get the this point
  in the algorithm (but I am not totally sure).

***

I have agreed to the following revised text:

  The RANDOM parameter, the CHUNKS parameter and the HMAC-ALGO
  parameter sent by each endpoint are concatenated as byte vectors.
  Parameters which were not sent are simply omitted from the
  concatenation process.  The resulting two vectors are called the two
  key numbers.

  From the endpoint pair shared keys and the key numbers the
  association shared keys are computed.  This is performed by selecting
  the smaller key number and concatenating it to the endpoint pair
  shared key, and then concatenating the larger of the key numbers to
  that.  If both key numbers are equal, then the concatenation order is
  the endpoint shared key, followed by the key number with the shorter
  length, followed by the key number with the longer length.  If the
  key number lengths are the same, then they may be concatenated to the
  endpoint pair key in any order.  The concatenation is performed on
  byte vectors representing all numbers in network byte order.  The
  result is the association shared key.

***

  Section 6.3 says:
  >
  > It should be noted that if the receiver wants to tear down an
  > association in an authenticated way only, the handling of malformed
  >  packets should be in tune with this.
  >
  I do not know what implementers should do based on this paragraph.
  Please clarify it or remove it.

***

I have agreed to the following revised text:

  It should be noted that if the receiver wants to tear down an
  association in an authenticated way only, the handling of malformed
  packets should not result in tearing down the association.

***

[Ballot discuss]
The last paragraph of Section 6.1 is vital to the security service
  that is being specified, but I cannot figure out what it means.  It
  talks about three inputs (which are byte vectors):
 
    endpoint_pair_shared_key /* already known to both patries */
    key_number_1 :=
      RANDOM_parameter_1 || CHUNKS_parameter_1 || HMAC-ALGO_parameter_1
    key_number_2 :=
      RANDOM_parameter_2 || CHUNKS_parameter_2 || HMAC-ALGO_parameter_2
 
  And then the association shared key is computed as follows:
 
    if (key_number_1 is_smaller_than key_number_2) then
      association_shared_key :=
        key_number_1 || endpoint_pair_shared_key || key_number_2
    else if (key_number_2 is_smaller_than key_number_1) then
      association_shared_key :=
        key_number_2 || endpoint_pair_shared_key || key_number_1
    /* both key numbers are equal */
    else if (key_number_1 is_shorter_than key_number_2) then
      association_shared_key :=
        endpoint_pair_shared_key || key_number_1 || key_number_2
    else if (key_number_2 is_shorter_than key_number_1) then
      association_shared_key :=
        endpoint_pair_shared_key || key_number_2 || key_number_1
    /* key number lengths are the same */
    else if (heads == flip_coin()) then
      association_shared_key :=
        endpoint_pair_shared_key || key_number_1 || key_number_2
    else
      association_shared_key :=
        endpoint_pair_shared_key || key_number_2 || key_number_1

  I do not see a definition for "selecting the smaller key number."
  This is not obvious since the key numbers are byte vectors.  Are they
  treated as large unsigned integers or character strings?  Also, the
  last part is a waste.  The algorithm would be deterministic if the
  fourth possible construction is used if the second key number is
  shorter than or the same length as the first key number 1.  My guess
  is that the two key numbers are the same if you get the this point
  in the algorithm (but I am not totally sure).

***

I have agreed to the following revised text:

  The RANDOM parameter, the CHUNKS parameter and the HMAC-ALGO
  parameter sent by each endpoint are concatenated as byte vectors.
  Parameters which were not sent are simply omitted from the
  concatenation process.  The resulting two vectors are called the two
  key numbers.

  From the endpoint pair shared keys and the key numbers the
  association shared keys are computed.  This is performed by selecting
  the smaller key number and concatenating it to the endpoint pair
  shared key, and then concatenating the larger of the key numbers to
  that.  If both key numbers are equal, then the concatenation order is
  the endpoint shared key, followed by the key number with the shorter
  length, followed by the key number with the longer length.  If the
  key number lengths are the same, then they may be concatenated to the
  endpoint pair key in any order.  The concatenation is performed on
  byte vectors representing all numbers in network byte order.  The
  result is the association shared key.

***

  Section 6.3 says:
  >
  > It should be noted that if the receiver wants to tear down an
  > association in an authenticated way only, the handling of malformed
  >  packets should be in tune with this.
  >
  I do not know what implementers should do based on this paragraph.
  Please clarify it or remove it.

***

No text to resolve this has been proposed yet.

***

[Ballot comment]
Does this document expect a separate shared secret to be configured between all pairs of communicating parties? This may be a big assumption.

How does one "using TLS" create such a key? That may be a good approach, but I'm sure details are needed. Is there an IETF policy for defining key management and not just reliance on shared secrets for new protocols?

[Ballot comment]
During a private exchange with the authors, it was clarified that this document works with
the partial reliability extensions to SCTP.  This will be made clear in an upcoming document
(add-ip), but I believe it would be useful to add a short informational statement to this
document to that effect.

[Ballot discuss]
Waiting for resolution of Gen-ART review comments by David Black:

(1) The AUTH chunk comes before the material it authenticates,
preventing pipelined computation of the MAC.  IPsec experience
indicates that this may not be a good design choice.  If
the alternative of putting the MAC after the data it covers
(need another chunk to indicate start of covered data) was
considered in the WG, the reason for rejecting it needs
to be explained.
(2) There's a lack of precision in a number of places in
in Section 6's specifications of the authentication
calculations to be performed (Russ Housley found one of
them, but there are more).  All of these are relatively
easy to fix, but they do have to be fixed, as even minor
issues in specifying how to compute a MAC lead to
lack of interoperability - see specific comments ...

See discussion threads starting at
http://www1.ietf.org/mail-archive/web/gen-art/current/msg01764.html
and
http://www1.ietf.org/mail-archive/web/gen-art/current/msg01765.html

[Ballot comment]
Section 1 says:
  >
  > ... SCTP sender to sign chunks ...
  >
  I really dislike this use of "sign."  I greatly prefer "authenticate."

  Since the specification demands that the random value must be exactly
  32 octets in length, it would help the reader to say so in Section 3.1.

[Ballot discuss]
The last paragraph of Section 6.1 is vital to the security service
  that is being specified, but I cannot figure out what it means.  It
  talks about three inputs (which are byte vectors):
 
    endpoint_pair_shared_key /* already known to both patries */
    key_number_1 :=
      RANDOM_parameter_1 || CHUNKS_parameter_1 || HMAC-ALGO_parameter_1
    key_number_2 :=
      RANDOM_parameter_2 || CHUNKS_parameter_2 || HMAC-ALGO_parameter_2
 
  And then the association shared key is computed as follows:
 
    if (key_number_1 is_smaller_than key_number_2) then
      association_shared_key :=
        key_number_1 || endpoint_pair_shared_key || key_number_2
    else if (key_number_2 is_smaller_than key_number_1) then
      association_shared_key :=
        key_number_2 || endpoint_pair_shared_key || key_number_1
    /* both key numbers are equal */
    else if (key_number_1 is_shorter_than key_number_2) then
      association_shared_key :=
        endpoint_pair_shared_key || key_number_1 || key_number_2
    else if (key_number_2 is_shorter_than key_number_1) then
      association_shared_key :=
        endpoint_pair_shared_key || key_number_2 || key_number_1
    /* key number lengths are the same */
    else if (heads == flip_coin()) then
      association_shared_key :=
        endpoint_pair_shared_key || key_number_1 || key_number_2
    else
      association_shared_key :=
        endpoint_pair_shared_key || key_number_2 || key_number_1

  I do not see a definition for "selecting the smaller key number."
  This is not obvious since the key numbers are byte vectors.  Are they
  treated as large unsigned integers or character strings?  Also, the
  last part is a waste.  The algorithm would be deterministic if the
  fourth possible construction is used if the second key number is
  shorter than or the same length as the first key number 1.  My guess
  is that the two key numbers are the same if you get the this point
  in the algorithm (but I am not totally sure).

  Section 6.3 says:
  >
  > It should be noted that if the receiver wants to tear down an
  > association in an authenticated way only, the handling of malformed
  >  packets should be in tune with this.
  >
  I do not know what implementers should do based on this paragraph.
  Please clarify it or remove it.

IANA Last Call Comments:

Upon approval of this document, IANA understands that five
actions need to be completed.

First, in the SCTP Parameters located at:

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

in the subregistry called CHUNK TYPES a new value will be
registered:

ID Value Chunk Type
----- ----------
TBD Authentication Chunk (AUTH)

IANA notes that the draft suggests the value 15 for this
Chunk Type.

Second, in the SCTP Parameters located at:

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

in the subregistry called CHUNK PARAMETER TYPES, three
new values will be registered:

Chunk Parameter Type Value
-------------------- -----
Random TBD
Chunk List TBD
Requested HMAC Algorithm Parameter TBD

IANA notes that the draft provides suggestions for each
of the new Chunk Parameter Types in the IANA
Considerations section.

Third, in the SCTP Parameters located at:

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

in the subregistry called INIT ACK Chunk Parameter Types,
three new INIT ACK Chunk Parameter Types will be registered:

INIT ACK Chunk Parameter Type Value
-------------------- -----
Random TBD
Chunk List TBD
Requested HMAC Algorithm Parameter TBD

IANA notes that the draft provides suggestions for each of
the new Chunk Parameter Types in the IANA Considerations
section.

Fourth, in the SCTP Parameters located at:

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

in the subregistry called CAUSE CODES a new value will
be added:

VALUE CAUSE CODE
----- ----------------
TBD Unsupported HMAC Identifier

IANA notes that the document provides suggestions for
this Cause Code.

Finally, in the SCTP Parameters located at:

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

a new registry will be created for HMAC IDENTIFIERS. This
registry will have three initial values. New values will
be added to the HMAC IDENTIFIERS registry through IETF
Consensus.

HMAC IDENTIFIERS

HMAC Identifier Message Digest Algorithm
--------------- ------------------------
0 Reserved
1 SHA-1
3 SHA-256

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

PROTO Write-up

1.a) Have the chairs personally reviewed this version of the Internet
Draft (ID), and in particular, do they believe this ID is ready
to forward to the IESG for publication? Which chair is the WG
Chair Shepherd for this document?

Yes, Shepherd is James Polk

1.b) Has the document had adequate review from both key WG members
and key non-WG members? Do you have any concerns about the
depth or breadth of the reviews that have been performed?

Yes, this document has received adequate review. There are no concerns.

1.c) Do you have concerns that the document needs more review from a
particular (broader) perspective (e.g., security, operational
complexity, someone familiar with AAA, internationalization,
XML, etc.)?

No, this document does not require boarder review

1.d) Do you have any specific concerns/issues with this document that
you believe the ADs and/or IESG should be aware of? For
example, perhaps you are uncomfortable with certain parts of the
document, or have concerns whether there really is a need for
it. In any event, if your issues have been discussed in the WG
and the WG has indicated it that it still wishes to advance the
document, detail those concerns in the write-up.

There are no issues with this document.

1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?

There was solid consensus. It has been reviewed by a number of people.

1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarize the areas of conflict in
separate email to the Responsible Area Director. (It should be
separate email because this questionnaire will be entered into
the tracker).

No, no threats of an appeal.

1.g) Have the chairs verified that the document checks out against
all the ID nits? (see http://www.ietf.org/ID-Checklist.html).
Boilerplate checks are not enough; this check needs to be
thorough.

There are no nits according to the Tools webpage. There is an incorrect
RFC-2119 warning, as Section 2 covers RFC-2119 within this document. The
experimental warning regarding RFCXXXX is misplaced, as XXXX will be
replaced with the RFC number for this document if it should be assigned one
by the RFC-Editor.

1.h) Has the document split its references into normative and
informative? Are there normative references to IDs, where the
IDs are not also ready for advancement or are otherwise in an
unclear state? The RFC Editor will not publish an RFC with
normative references to IDs (will delay the publication until
all such IDs are also ready for RFC publication). If the
normative references are behind, what is the strategy for their
completion? On a related matter, are there normative references
that are downward references, as described in BCP 97, RFC 3967
RFC 3967 [RFC3967]? Listing these supports the Area Director in
the Last Call downref procedure specified in RFC 3967.

The references are not split in this document, as there are only normative
references given.

There are no normative references to drafts.


1.i) For Standards Track and BCP documents, the IESG approval
announcement includes a write-up section with the following
sections:

* Technical Summary

This document describes a new chunk type, several parameters and procedures
for SCTP. This new chunk type can be used to authenticate SCTP chunks by
using shared keys between the sender and receiver. The new parameters are
used to establish the shared keys. Using TLS as defined in RFC3436 (TLS
over SCTP) does not help with this requirement because it only secures SCTP
user data. Therefore an SCTP extension is created by this document which
provides a mechanism for deriving shared keys for each association. These
association shared keys are derived from endpoint pair shared keys, which
are configured and might be empty, and data which is exchanged during the
SCTP association setup. The extension presented in this document allows an
SCTP sender to sign chunks using shared keys between the sender and
receiver. The receiver can then verify that the chunks are sent from the
sender and not from a malicious attacker as long as the attacker does not
know an association shared key.

* Working Group Summary

There is strong consensus in the WG to publish this document. It has been
reviewed by several people in the WG last call. Comments raised has been
addressed

* Protocol Quality

This document extends the for Stream Control Transmission Protocol (SCTP),
and has had many comments, all of which have been reviewed within the TSVWG
to the WG's satisfaction.