Michael,
I think we're basically done here - see a few more inline
comments (and more snips of things that are resolved).
Thanks,
--David
On Feb 21, 2007, at 1:02 AM, [EMAIL PROTECTED] wrote:
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.
I see... So what about adding the following paragraph at the
end of section 1:
<t>The extension described in this document puts the result
of an HMAC computation before the data covered by that computation.
Putting it at the end of the packet would have required putting
a control chunk after DATA chunks in case of authenticating DATA
chunks. This would break the rule that control chunks occur before
DATA chunks in SCTP packets. It should also be noted that putting
the result of the HMAC computation would not allow sending the
packet during the computation of the HMAC because the result
of the HMAC computation is needed to compute the CRC32C checksum
of the SCTP packet which is placed in the common header of the
SCTP packet.</t>
That's fine.
(2) There's a lack of precision in a number of places
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 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.
OK, so what about using:
The RANDOM parameter, the CHUNKS parameter and the HMAC-ALGO
parameter sent by each endpoint are concatenated as byte
vectors.
All parameters include the parameter type, parameter length,
parameter value, and the optional parameter padding if present.
That's fine.
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".
OK, we can do that. But for me "key strings" associates with strings
in C, for example. And this is wrong, because there can be vector
components being 0. This is really the reason why I have chosen
vector
and not string. But I'm not a native speaker...
What about using your text above, but keep vector instead of string?
Using "vector" instead of "string" is fine, and probably clearer.
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:
You compute for *all* endpoint pair shared keys (yes, you can have
none, one, or multiple) the corresponding association shared key.
There is no selection at this point. You can do that at association
setup
time or delay it until you really need them, but that is
implementation
specific.
We could add a note to 6.1 describing this.
Yes, please add that note, and make sure that the resulting text is
clear that *if* there are multiple endpoint shared keys, *then* there
are multiple association shared keys, one for each endpoint shared
key.
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.
For the sending side the selection of the key is done by the
application.
For the receiving side this is done by looking at the ID in the AUTH
chunk.
Therefore the selection process is not mentioned in section 6.1. But
we
could add a statement in 6.2 that the selection is done by the
SCTP user.
Yes, that statement is needed in Section 6.2. Section 6.3 already
covers
receiver key selection.
[... snip ...]
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 of this to the draft, please.
This and your next comment could be covered by using the
following text:
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 information regarding
the RANDOM parameters, CHUNKS parameters and HMAC_ALGO
parameters
included in the COOKIE-ECHO, and possibly the local shared
secret
as described in section 6.3.
That's ok in principle, but I think the text wants to be split
into two sentences and edited somewhat:
If a packet arrives containing an AUTH chunk as a first chunk, a
COOKIE-ECHO chunk as the second chunk and possibly more chunks
after them, and the receiver does not have an STCB for that
packet,
then authentication is based on the contents of the COOKIE-ECHO
chunk.
In this situation, the receiver MUST authenticate the chunks in
the packet by using the RANDOM parameters, CHUNKS parameters and
HMAC_ALGO parameters obtained from the COOKIE-ECHO chunk, and
possibly a local shared secret as inputs to the authentication
procedure specified in section 6.3.
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.
Please note that if the endpoint pair shared key depends on the
client and the server and that it is only known by the upper
layer
this message exchange requires an upper layer intervention
between
the processing of the COOKIE-ECHO chunk (COMMUNICATION-UP
notification followed by the presentation of the endpoint pair
shared
key by the upper layer to the SCTP stack, see for example
section
10 of RFC2960[5]) and the processing of the
AUTH and DATA chunk at the server side.
I'd remove the parenthetical "(COMMUNICATION-UP notification ..."
statement,
and replace by adding another sentence at the end of the above text :
"This
intervention may be realized by a COMMUNICATION-UP notification ..."
[... snip ...]
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
----------------------------------------------------
