Document: draft-ietf-tsvwg-sctp-auth-07.txt
Reviewer: David L. Black
Review Date: 20 Feb 2007
IESG Telechat date: 22 Feb 2007

Summary:

This draft is on the right track, but has open issues, described
in the review.

Comments:

There are two open issues:
(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 below.

All of the comments on Sections other than Section 6 (and its
subsections) are nits.

Sections 3.2 and 3.3 include Padding in the ASCII diagrams
of the chunk formats without describing it.  Both need a
sentence saying that padding is included only when needed
to make the chunk length a multiple of 4 bytes.

In contrast, I think the 2 bytes of Padding in Section 4.1
are always present, and that should be stated.

Section 5.1 needs to include the (obvious) statement that
the size of the HMAC output MUST be a multiple of 4 bytes.

Section 6.1 should reference RFC 4086/BCP 106 on generation
of good random numbers for security purposes.

Section 6.1:

   The RANDOM parameter, the CHUNKS parameter and the HMAC-ALGO
   parameter sent by each endpoint are concatenated as byte vectors.

Do the concatenated entities include the type and length fields?

   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 second and third sentences are almost certainly wrong, as
the second one makes no sense, and the third one can lead to
inconsistent results (different association keys) at the two
endpoints.  I think this may have been what was intended:

   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 they may be concatenated
   to the endpoint pair key in any order.

Section 6.1 is inconsistent about whether there are endpoint shared
keys (plural) or key (singular).  Multiple keys are apparently possible,
so this needs to specify how the same endpoint shared key is selected
by both endpoints.  Section 6.2 says one of them MUST be selected,
but doesn't say how.  Section 6.3 finally explains the role of the
Shared Key Identifier - this needs to be explained in Sections 6.1
and 6.2.

Section 6.2:

Placement of the AUTH chunk before the chunks it authenticates
prevents pipelined computation and checking of the MAC.  This
was a serious issue with IPsec AH, and lead to the use of
authenticate-only ESP because ESP's MAC is after the data it
covers.  This design choice needs to be carefully considered.
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.

Also:

   The 'data' used for the computation of
   the AUTH-chunk is given by Figure 6 and all chunks that are placed
   after the AUTH chunk in the SCTP packet.

Need to say the data in Figure 6 is prepended to "all chunks that are
placed after the AUTH chunk in the SCTP packet."

Section 6.3:

   If the receiver does not find a STCB for a packet
   containing an AUTH chunk as a first chunk and a COOKIE-ECHO chunk as
   the second chunk and possibly more chunks after them, the receiver
   MUST authenticate the chunks by using the random numbers included in
   the COOKIE-ECHO, and possibly the local shared secret.

Which random numbers located where in the COOKIE-ECHO chunk?  How
are they used?

Section 7's discussion of the upper layer interaction (e.g.,
COMMUNICATION-UP notification) needs a reference to the interface
being used for that discussion, probably the SCTP sockets API.

In Section 8.4, please tell IANA what to do with the unused
value 2 in the new HMAC identifier table, as the values 1
and 3 are used.  The easiest thing to do is mark it Reserved.