David:
I will let Michael answer most of this.. but I do
have some comments :-D
[EMAIL PROTECTED] wrote:
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.
There are a couple of issues one runs in to if you attempt
to put the AUTH chunk at the end or a marker in.. not that we could NOT
have done such..
Firstly we end up violating a fundamental premise in SCTP that
control is always first. This of course can be broken but
we did not want to do that.
Secondly the only alternative I remember us discussing was
that you would place the auth in a packet then all parts
of the sctp packet are auth'd. This to me caused a processing
problem in that you had to be willing to back up. Instead
with the current scheme, when you see the auth chunk, you
then auth the rest of the packet.. this then lets you set
a flag that "yes" auth was done. Then when you have chunks
that require auth all you have to do is check for the flag
set.
Another alternative I guess would have been to require it
as the first chunk in the packet... then the current scheme
would have worked I guess.
I am also not sure what you mean by "preventing pipelined
computation of the MAC." thinking about this.. Not all
data may be auth'd in a packet. Secondly if I have the
AUTH afterward then it becomes much more difficult to
then back track and possibly undo anything that has
been done. Example
If I had
----
Add-ip x
----
auth
----
Now if the auth fails, I have to undo:
a) Undo the ADD-IP
or
b) postpone doing all actions until I do the auth
and then reprocess the packet again to pick up the
other chunks.
I think overall we picked the best processing method.. we
have at least 3 implementations of this in stacks already
and I think more will be at the next inter-op :-D
(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.
I would agree with your assessment.. and I like your wording here better :-D
I will let Michael answer other of your issues :-D
R
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
----------------------------------------------------
--
Randall Stewart
NSSTG - Cisco Systems Inc.
803-345-0369 <or> 803-317-4952 (cell)
_______________________________________________
Gen-art mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
