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
> >> ----------------------------------------------------
_______________________________________________
Gen-art mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
