Replying to my original email interspersing Michael's comments
and my new comments to indicate where we are. My new comments
are set off by DLB>. I think this is very close to settled.
> 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.
I think this got misread as a request for a design change; it's
actually a request for a design explanation. It should suffice to
add a paragraph or two summarizing some of the design rationale
from this email discussion around why the ESP (IPsec) decision
to put the MAC in the trailer is not appropriate for SCTP.
> (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.
DLB> For the most part, Michael's proposed changes are sufficient.
DLB> I've snipped out items where the resolution has been agreed to.
> All of the comments on Sections other than Section 6 (and its
> subsections) are nits.
>
[... snip ...]
> Section 5.1 needs to include the (obvious) statement that
> the size of the HMAC output MUST be a multiple of 4 bytes.
It is better to allow a padding here, too. In RFC 2960 (if
I remember right) we used this kind
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
\ HMAC /
/ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
of things for arbitrary length things.
So I would prefer to add show a padding here and make the
above statement that the padding is optionally there for
32-bit alignment.
DLB> Apparently it wasn't obvious. The proposed change is fine.
[... snip ...]
> 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?
Sure: this is why we used "parameter" and not "parameter value".
Even padding is considered part of the parameter.
DLB> Please add a sentence saying so, as the distinction between
DLB> "parameter" and "parameter value" is somewhat subtle.
Regarding this quoted text:
> 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.
Please note that when the key numbers are equal as numbers, they
can be represented in multiple ways as byte vectors.
DLB> Ok, "almost" only counts in horseshoes, hand grenades, etc. ;-).
DLB> The treatment of "key number" as a byte string is unexpected, and
DLB> is what threw me (and appears to be what Russ Housley also found
DLB> confusing (cf. his "Discuss" on this draft). If the "key numbers"
DLB> were instead called "key strings", the following rewrite should
DLB> be sufficient:
The resulting two vectors are called the two key strings.
From the endpoint pair shared keys and the key strings the
association shared keys are computed. This is performed by selecting
the numerically smaller key string and concatenating it to the
endpoint
pair shared key, and then concatenating the numerically larger key
string to that. If the key strings are equal as numbers but differ
in length, then the concatenation order is the endpoint shared key,
followed by the shorter key string, followed by the longer key
string.
Otherwise, the key strings are identical, and may be concatenated to
the endpoint pair key in any order. The concatenation is performed
on byte vectors, and all numerical comparisons use network byte order
to convert the key string to a number. The result of the
concatenation
is the association shared key.
DLB> With luck, that will also resolve Russ Housley's "Discuss".
> 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.
6.1 contains:
Both endpoints of an association MAY have endpoint pair shared keys
which are byte vectors and pre-configured or established by another
mechanism. They are identified by the shared key identifier. If no
endpoint pair shared keys are preconfigured or established by
another
mechanism an empty byte vector is used.
DLB> That's not enough because it doesn't indicate *which* shared key
DLB> identifier to use to find the shared key. The problem is that
DLB> the text below goes from "endpoint shared keys" to "endpoint shared
DLB> key" without explaining how to determine which key to use:
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,
DLB> The text needs to explain how to select the endpoint pair shared
DLB> key. I believe that this selection is based on the identifier sent
DLB> or received in the AUTH chunk - that needs to be stated in Section
DLB> 6.1. Then Section 6.2 needs to say that the key to use can be
DLB> independently selected for each AUTH chunk when there are multiple
DLB> valid shared key identifiers - any key is ok because the receiver
DLB> has all of them.
> Section 6.2:
>
[... Issue (1) text snipped ...]
>
> 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."
We can write
The 'data' used for the computation of the AUTH-chunk
is given by the AUTH chunk shown in Figure 6 followed
by all chunks that are placed after the AUTH chunk in
the SCTP packet.
DLB> Looks good - I'd suggest that "AUTH chunk shown in Figure 6"
DLB> be replaced by "AUTH chunk with its HMAC field set to zero
DLB> (as shown in Figure 6)".
>
> 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?
The ones in the RANDOM parameter which were contained in the
INIT and INIT-ACK chunk. The structure of the COOKIE is not
defined and only relevant to the sender of the COOKIE parameter
which is the receiver of the COOKIE chunk.
DLB> Add a statement this to the draft, please.
> How are they used?
As described in 6.3.
DLB> And also add a statement of this, please.
> 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.
We can not reference the socket API, because that is not yet an RFC...
And we need to protocol specified before having experience with
the API. We could reference UNP or section 10 of RFC 2960.
DLB> Ok, need to reference something that defines COMMUNICATION-UP.
> 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.
We can do that.
DLB> Please do.
> 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
