I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Please wait for direction from your document shepherd
or AD before posting a new version of the draft.
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.
Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA 01748
+1 (508) 293-7953 FAX: +1 (508) 293-7786
[EMAIL PROTECTED] Mobile: +1 (978) 394-7754
----------------------------------------------------
_______________________________________________
Gen-art mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
