Subject: [Gen-art] Gen-ART review of draft-ietf-tsvwg-sctp-auth-07.txt

From: [email-masked]
Date: Tue, 20 Feb 2007 09:34:03 -0500

I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-tsvwg-sctp-auth-07.txt
Reviewer: David L. Black
Review Date: 20 Feb 2007
IESG Telechat date: 22 Feb 2007

Summary:

This draft is on the right track, but has open issues, described
in the review.

Comments:

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.
(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.

All of the comments on Sections other than Section 6 (and its
subsections) are nits.

Sections 3.2 and 3.3 include Padding in the ASCII diagrams
of the chunk formats without describing it.  Both need a
sentence saying that padding is included only when needed
to make the chunk length a multiple of 4 bytes.

In contrast, I think the 2 bytes of Padding in Section 4.1
are always present, and that should be stated.

Section 5.1 needs to include the (obvious) statement that
the size of the HMAC output MUST be a multiple of 4 bytes.

Section 6.1 should reference RFC 4086/BCP 106 on generation
of good random numbers for security purposes.

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?

   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.  I think this may have been what was intended:

   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 they may be concatenated
   to the endpoint pair key in any order.

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.

Section 6.2:

Placement of the AUTH chunk before the chunks it authenticates
prevents pipelined computation and checking of the MAC.  This
was a serious issue with IPsec AH, and lead to the use of
authenticate-only ESP because ESP's MAC is after the data it
covers.  This design choice needs to be carefully considered.
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.

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."

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?  How
are they used?

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.

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.

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-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

_______________________________________________
Gen-art mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/gen-art

---

From: [email-masked]
Date: Tue, 20 Feb 2007 13:59:22 -0500

Randy,

> There are a couple of issues one runs in to if you attempt
> to put the AUTH chunk at the end or a marker in.. not that we 
> could NOT have done such..
> 
> Firstly we end up violating a fundamental premise in SCTP that
> control is always first. This of course can be broken but
> we did not want to do that.

I don't think it has to violate that premise.  Consider two chunks:
- AUTH-START: Start computing MAC here, includes MAC algorithm
	and key selection.
- AUTH-END: Stop computing MAC here, MAC value is in this chunk.
To a first approximation, this is a control/data split with
control coming first.

> Secondly the only alternative I remember us discussing was
> that you would place the auth in a packet then all parts
> of the sctp packet are auth'd. This to me caused a processing
> problem in that you had to be willing to back up. Instead
> with the current scheme, when you see the auth chunk, you
> then auth the rest of the packet.. this then lets you set
> a flag that "yes" auth was done. Then when you have chunks
> that require auth all you have to do is check for the flag
> set.

That's consistent with the two chunk approach above.

> Another alternative I guess would have been to require it
> as the first chunk in the packet... then the current scheme
> would have worked I guess.

The current location at the start of the authenticated chunks
is fine.

> I am also not sure what you mean by "preventing pipelined
> computation of the MAC." thinking about this.. Not all
> data may be auth'd in a packet.

Ok, see above comment about the possibility of two chunks.

> Secondly if I have the
> AUTH afterward then it becomes much more difficult to
> then back track and possibly undo anything that has
> been done. Example
> 
> If I had
> 
> ----
> Add-ip x
> ----
> auth
> ----
> 
> Now if the auth fails, I have to undo:
> 
> a) Undo the ADD-IP
> or
> b) postpone doing all actions until I do the auth
>     and then reprocess the packet again to pick up the
>     other chunks.

In other words, two passes over the data are needed
on receive:
- One pass for AUTH, and
- One pass to process the authenticated chunks.

The win from MAC in trailer instead of header turns out to
be on the send side.  Assume a staged implementation where
these two passes are functionally separated (e.g., AUTH is
in acceleration hardware that moves stuff to/from the wire).
On send, this gets the AUTH for cheaper (memory accesses)
than running the second software pass.  This probably won't
be seen in software because the computational cost of
HMAC-SHA1 swamps everything else.

On receive, the location doesn't matter much, because if the
MAC is not in the trailer, it's easy to pluck it out of the
AUTH chunk as it goes by and check it against the calculation
that covers the rest of the packet.

> I think overall we picked the best processing method..  we
> have at least 3 implementations of this in stacks already
> and I think more will be at the next inter-op :-D

I'm not going to argue with "rough consensus and running code,"
but I would like the draft to explain why the design is the
way it is.

Thanks,
--David

---

From: Randall Stewart <[email-masked]>
Date: Tue, 20 Feb 2007 14:19:38 -0500

> To a first approximation, this is a control/data split with

So you would classify AUTH-END as a "DATA Chunk".

> - One pass to process the authenticated chunks.

Correct.. but this is NOT true with the current design..

> HMAC-SHA1 swamps everything else.

ok..

> that covers the rest of the packet.

So you trade off the "ease" of doing hardware sending
vs the additional processing overhead on the receive
side... not that its not possible to do the offload
it just requires more gates.. right?

> but I would like the draft to explain why the design is the

Maybe we need to talk about the dual pass on receive avoidance..

Would that make you happy ? ;-)

R

-- 
Randall Stewart
NSSTG - Cisco Systems Inc.
803-345-0369 <or> 803-317-4952 (cell)

---

From: Randall Stewart <[email-masked]>
Date: Tue, 20 Feb 2007 12:54:14 -0500

David:

I will let Michael answer most of this.. but I do
have some comments :-D

There are a couple of issues one runs in to if you attempt
to put the AUTH chunk at the end or a marker in.. not that we could NOT
have done such..

data may be auth'd in a packet. Secondly if I have the

If I had

----
Add-ip x
----
auth
----

a) Undo the ADD-IP
or

>    to the endpoint pair key in any order.

I would agree with your assessment.. and I like your wording here better :-D

I will let Michael answer other of your issues :-D

R

---

From: Michael Tuexen <[email-masked]>
Date: Tue, 20 Feb 2007 20:24:33 +0100

David,

some comments in-line.

Best regards
Michael

> To a first approximation, this is a control/data split with
Assume that you want to authenticate DATA chunks. Then a packet
would look like

SACK; AUTH_START; DATA; DATA; AUTH_END

According to the current definition, an AUTH_END chunk
is following a DATA chunk. And it is not a DATA chunk,
so it is a control chunk.

Using you solution for authenticating DATA chunks breaks the
rule that DATA chunk follow control chunks.

Please note that breaking this rule has some substantial
impact on existing implementations.

(It would allow a
COOKIE-ECHO; SACK; AUTH_START; DATA; AUTH_END; ABORT
packet which would be very hard to process: You would
set up a connection, transfer data and bring the connection
down in *one* packet.)
> HMAC-SHA1 swamps everything else.
But you need to compute the CRC32C in hardware after you
computed the HMAC and put the CRC32C in the packet header,
not the SCTP trailer (which does not exist).
> that covers the rest of the packet.
See the argument above: There is also no gain for the sender.

---

From: Michael Tuexen <[email-masked]>
Date: Tue, 20 Feb 2007 20:24:33 +0100

David,

some comments in-line.

Best regards
Michael

(It would allow a
COOKIE-ECHO; SACK; AUTH_START; DATA; AUTH_END; ABORT
packet which would be very hard to process: You would
set up a connectio1068006D97;
	Tue, 20 Feb 2007 20:13:10 +0100 (CET)
	(KNF-authenticated sender: macmic)
From: Michael Tuexen <[email-masked]>
Date: Tue, 20 Feb 2007 20:13:08 +0100
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked],
	[email-masked], [email-masked], [email-masked], [email-masked]
Subject: [Gen-art] Re: Gen-ART review of draft-ietf-tsvwg-sctp-auth-07.txt

Hi David,

see my comments in-line.

Best regards
Michael

> 	considered in the WG, the reason for rejecting it needs
SCTP currently requires that DATA chunks can not be followed by
control chunks. We would have to break that rule to be able to
authenticate DATA chunks or not allow DATA chunks to be authenticated.
But or something like DTLS over SCTP it is important to be able
to authenticate DATA chunks. So your suggestion requires breaking
one of the "base" rules for SCTP packet generation.

The other problem with your suggestion is that the receiver
is required to process chunks in the packet in the sequence
they appear in the packet. But your suggestion would require
that you process the last chunk (HMAC check) before processing
the chunks which are authenticated.

We did think about a different way to put the HMAC after
the stuff being authenticated by encapsulating the chunks
being authenticated into the AUTH chunk and having the the
HMAC after the chunk. But this would make processing them
much more complicated.

What would you gain? Not much, I guess. The implementations
I know consider a packet as a sequence of memory objects
holding a chunk (for example an mbuf chain). When you put
in a chunk which needs to be authenticated you insert also
the AUTH chunk. Before sending the packet (almost when you
are about to compute the checksum) you compute the
HMAC and put it where it has to be. Even if there
would be hardware support for the algorithms one can not
do it in hardware and insert it when the corresponding field
is put on the wire (like you would do for a checksum in
a n, transfer data and bring the connection
down in *one* packet.)

---

From: Randall Stewart <[email-masked]>
Date: Tue, 20 Feb 2007 14:27:31 -0500

> HMAC after the chunk. But this would make processing them
Ahh.. yes that was the alternate method we were considering..
I had forgotten the details :-)

R

> a packet trailer) because you need the HMAC also for the CRC-32C
> computation and the SCTP checksum is in the packet header not
> trailer.
> 
> So for me this looks like:
> - I do not get anything by putting the HMAC at the end,
>   or at least not much.
> - I have to break multiple SCTP rules to put the HMAC
>   at the end.
> 
>  From this the decision we made seems to be appropriate.

Thats true.. if you shoved it to  hardware you would need
to have CRC32C in hardware and chained after the HMAC..
that gets kinda ugly :-D

> 
> David, did I understand your point correctly?
> I agree: the spec has to be clear. I already commented the
> mail from Russ. I'll do this for your points, too. Please
> let me what you think about the comments.
>>
> We can add that... This is the general concept for all parameters.
>>
> We can add that, too.
> 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.
> OK.
> Sure: this is why we used "parameter" and not "parameter value".
> Even padding is considered part of the parameter.
>>
> No it is intended as written.
> 
> Please note that when the key numbers are equal as numbers, they
> can be represented in multiple ways as byte vectors.

Hmmm I obviously did not read David's responsebv the same way
you did.. teaches me for worrying about global routing table
growth (the meetings I am in ;-D) and take care of SCTP at the
same time :-D

> 
> For example 1 01 001 0001 are four representations of the number
> one. Only if the key numbers represent the same number and are
> of equal length, they are equal as byte vectors.
> 
> So I think the spec is correct.

ok.. I see.. I think the original wording is better.. thinking
about it more :-D

> 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.
> 
> The term key is used only in the text for the computation of the 
> association
> shared keys. This is done, because you do the computation for each endpoint
> pair shared key.
> 

> See my arguments above. Let me know if they are wrong.
>>
>> Also:
>>
> 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.
>> Section 6.3:
>>
>> 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.
>>   How
>> are they used?
> As described in 6.3.
>>
> 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.
>>
> We can do that.

---

From: [email-masked]
Date: Tue, 20 Feb 2007 19:02:31 -0500

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.

> 	considered in the WG, the reason for rejecting it needs

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.

> 	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
[... snip ...]

DLB> Apparently it wasn't obvious.  The proposed change is fine.

[... snip ...]

DLB> Please add a sentence saying so, as the distinction between
DLB> "parameter" and "parameter value" is somewhat subtle.

Regarding this quoted text:

> endpoints. 

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".

6.1 contains:

    endpoint pair shared keys are preconfigured or established by
another

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 ...]

We can write

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)".

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.

DLB> Ok, need to reference something that defines COMMUNICATION-UP.

We can do that.

DLB> Please do.

---

From: Michael Tuexen <[email-masked]>
Date: Wed, 21 Feb 2007 11:06:26 +0100

David,

see my comments in-line.

Best regards
Michael

> 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>
OK.
> 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.

> 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?
> 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.
> DLB> valid shared key identifiers - any key is ok because the receiver
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.
> DLB> (as shown in Figure 6)".
That is a good idea. OK.
> 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.

> 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.

OK.

---

From: [email-masked]
Date: Wed, 21 Feb 2007 10:46:42 -0500

Michael,

I think we're basically done here - see a few more inline
comments (and more snips of things that are resolved).

Thanks,
--David

> of the SCTP packet which is placed in the common header of the

That's fine.

> >> (2) There's a lack of precision in a number of places
[... snip ...]

>     parameter value, and the optional parameter padding if present.

That's fine.

> > DLB> confusing, cf. his "Discuss" on this draft).  If the "key
numbers"
endpoint
string.
concatenation
> What about using your text above, but keep vector instead of string?

Using "vector" instead of "string" is fine, and probably clearer.

another
setup
> 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.

application.
chunk.
> could add a statement in 6.2 that the selection is done by the SCTP  

Yes, that statement is needed in Section 6.2.  Section 6.3 already
covers
receiver key selection.

[... snip ...]

> > DLB> Add a statement of this to the draft, please.
>

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.

shared
>     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 ...]

---

From: Randall Stewart <[email-masked]>
Date: Wed, 21 Feb 2007 10:59:55 -0500

David/Magnus:

So with these comments should Michael submit a new draft?

Thanks

R

---

From: Michael Tuexen <[email-masked]>
Date: Wed, 21 Feb 2007 21:02:53 +0100

Randy,

there are a number of small changes / added text which are
(for me) easiest handled by just updating the ID.

I would do it anyway and use a CVS diff to generate a
diff on the xml and then transform that in the RFC editor
style comments.

But I think it is also easier for the RFC editor to get
the xml sources with all the changes included.

Best regards
Michael

On Feb 21, 2007, at 4:59 PM, Randall Stewart wrote:

>>>>>    shared key, and then concatenating the larger of the key  
>>>>> numbers
>> to
>>>>    Otherwise, the key strings are identical, and may be  
>>>> concatenated
>> to
>>> could add a statement in 6.2 that the selection is done by the  
>>> SCTP  user.
>>>     containing an AUTH chunk as a first chunk and a COOKIE-ECHO  
>>> chunk
>> as

---

From: Michael Tuexen <[email-masked]>
Date: Wed, 21 Feb 2007 21:14:36 +0100

Hi David,

comments in-line.

Best regards
Michael

OK.
> are multiple association shared keys, one for each endpoint shared  
So what about replacing

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.

> Yes, that statement is needed in Section 6.2.  Section 6.3 already
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.

> chunk as
OK.
OK.

---

From: Randall Stewart <[email-masked]>
Date: Wed, 21 Feb 2007 15:16:49 -0500

Michael:

That was my thoughts as well.. less chance for errors
too.

Magnus .. is that ok?

Thanks

R

Michael Tuexen wrote:
>>> If no
>> --Randall Stewart

---

From: [email-masked]
Date: Wed, 21 Feb 2007 15:51:32 -0500

The rest of your proposed changes are fine with me.

Thanks,
--David

> >>>>    shared key, and then concatenating the larger of the 
> key numbers
> > to
> >>> DLB> confusing, cf. his "Discuss" on this draft).  If the 
> "key numbers"
> >>>    the numerically smaller key string and concatenating 
> it to the endpoint
> >>>    followed by the shorter key string, followed by the 
> longer key string.
> concatenated to
> >>>    to convert the key string to a number.  The result of 
> the concatenation
> >> There is no selection at this point. You can do that at 
> association setup
>     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.
> 
> >
> >> 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.
> >> 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:
> 
> > 	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.
> >>     notification followed by the presentation of the 
> endpoint pair shared
> > I'd remove the parenthetical "(COMMUNICATION-UP 
> notification ..." statement,
> > and replace by adding another sentence at the end of the 
> above text : "This