David,
see my comments in-line.
Best regards
Michael
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>
(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.
OK.
[... 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.
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?
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.
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.
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)".
That is a good idea. OK.
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.
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.
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.
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.
OK.
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
