The rest of your proposed changes are fine with me. Thanks, --David
> Hi David, > > comments in-line. > > Best regards > Michael > > On Feb 21, 2007, at 4:46 PM, [EMAIL PROTECTED] wrote: > > > 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. > OK. > > > >>> > >>>> 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. > So what about replacing > > 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. > > by > > 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. > For each endpoint pair shared key an association shared > key is computed. > If there is no endpoint pair shared key only one > association shared key > is computed by using an empty byte vector as the endpoint > pair 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. > > > What about replacing: > > If the endpoint has no endpoint shared key for the peer, > it MUST use > Shared Key Identifier 0 with an empty endpoint pair shared key. > > with > > If the endpoint has no endpoint shared key for the peer, > it MUST use > Shared Key Identifier 0 with an empty endpoint pair shared key. If > there are multiple endpoint shared keys the sender selects one and > uses the corresponding Shared Key Identifier. > > > [... 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. > OK. > > > >>>> 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 ...] > 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
