Subject: [Tsvwg] Comments about draft-ietf-tsvwg-sctp-auth-00.txt

From: [email-masked]
Date: Thu, 8 Sep 2005 16:55:19 +0300

Hi all!

	I have been for a long while out of this list, but I'm back again, at least for a little while :-)=

	You know I'm quite picky, so here comes my long list of comments, as usual (sorry if they have been already mentioned in this list):

	- There are many tables in the draft that are called "Figure X" instead of "Table X". These are Figure 1, Figure 5, Figure 6 and Figure 8. Obviously changing them to Table 1, Table 2... makes it necessary to change all the other Figures and the references in the text.

	- Last paragraph of section 3.1: "... If the sender wants to send of receive authenticated...". Well, the RANDOM chunk is sent only if the sender wants to RECEIVE authenticated chunks. Please, change this, as it is quite confusing which is the aim of the chunk.

	- Figure 3: You can see that there are two "Chunk Type 4" there.

	- Last paragraph of section 3.2: I assume that the restrictions about which chunks can be authenticated and which cannot is due to the impossibility of accessing the association's shared key at some points. However, SHUTDOWN-COMPLETE is included in that list, but the ABORT is left apart, why?

	- Figure 4, HMAC-ALGO chunk: I guess that giving the peer a list of algorithms to be used, makes him able to use whichever he wants. However, does the list imply any preference at the sender? I.e., wouldn't it be wise to advice the peer to use the uppermost algorithm it understands?

	- Three paragraphs below Figure 4: "The values is a a requested HMAC Identifier". It should be "The value is a requested..."

	- Figure 5: The reference [10] should be [7] instead.

	- Section 5.1, last paragraph: It might be wise to remind here that DATA chunks cannot appear before control chunks inside the datagram... Something like: "Please, remember that DATA chunks can never appear before control chunks."

	- Section 6.1, first paragraph: "... authenticated chunks has to send...", I guess that it should be "... authenticated chunks HAS TO send..."

	A little bit later on top of page 9, it says that the "RANDOM parameter SHOULD contain a 32 byte random number". It is stated everywhere else that the number can be of any length. A SHOULD doesn't completely forbid the guy to use any other length instead of 32 byte (bit?) number, but I guess that this is a typo coming from a previous decision.

	Also, a little bit later, it says "This random number is handled like the verification tag in case of INIT collisions." I don't know what that means. Do you mean something like:

	 "In case of INIT collision, the rules governing the handling of this random number follow the same pattern as those for the Verification Tag, as explained in section 5.2.4 of [5]."

	- Section 6.1, second paragraph: "Since this list is for an endpoint there is no..." Hmm... Do you mean something like:

	"Since this list doesn't change in the lifetime of an endpoint there is no..."

	- Section 6.1, third paragraph: "An SCTP Endpoint MUST not change the parameters listed in the HMAC-ALGO parameter during the lifetime of the endpoint". This might be a nice thing, but I guess that also a nice thing to do is having different HMAC-ALGO parameters depending with whom we are talking with (typical example of intra/extra net). I don't know if this should be stated here... :-/=

	- Section 6.2, first paragraph: It says that the AUTH chunk can only be sent while in the ESTABLISHED state. I would also add the SHUTDOWN-PENDING and SHUTDOWN-RECEIVED states...

	I would add a "or not" at the end of the paragraph, as the first time you read it can be confusing.

	- Section 6.3, last paragraph: I don't understand what it means :-(=

	- Section 7, second example: Actually, I don't think that such a message exchange is legal, as when the client sends the COOKIE-ECHO; AUTH; DATA it is still in the COOKIE-ECHOED state and not in the ESTABLISHED one as stated in section 6.2 above.

	- Section 11.1: The reference [2] is not referenced at all :-)=

	- Section 11.2: Same happens for reference [8].

	I hope those comments were helpful!

	Thanks for your excellent work with SCTP!

	BR Iván Arias Rodríguez

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

---

From: Michael Tuexen <[email-masked]>
Date: Thu, 8 Sep 2005 22:18:46 +0200

Hi Ivan,

thanks for the comments. They are really appreciated. I'll go through 
the
comments over the weekend. I'm just on my way to the SIGTRAN Interop...

Best regards
Michael

On Sep 8, 2005, at 15:55 Uhr, [email-masked] wrote:

> 	You know I'm quite picky, so here comes my long list of comments, as 
> usual (sorry if they have been already mentioned in this list):
>
> 	- There are many tables in the draft that are called "Figure X" 
> instead of "Table X". These are Figure 1, Figure 5, Figure 6 and 
> Figure 8. Obviously changing them to Table 1, Table 2... makes it 
> necessary to change all the other Figures and the references in the 
> text.
>
> 	- Last paragraph of section 3.1: "... If the sender wants to send of 
> receive authenticated...". Well, the RANDOM chunk is sent only if the 
> sender wants to RECEIVE authenticated chunks. Please, change this, as 
> it is quite confusing which is the aim of the chunk.
>
> 	- Last paragraph of section 3.2: I assume that the restrictions about 
> which chunks can be authenticated and which cannot is due to the 
> impossibility of accessing the association's shared key at some 
> points. However, SHUTDOWN-COMPLETE is included in that list, but the 
> ABORT is left apart, why?
>
> 	- Figure 4, HMAC-ALGO chunk: I guess that giving the peer a list of 
> algorithms to be used, makes him able to use whichever he wants. 
> However, does the list imply any preference at the sender? I.e., 
> wouldn't it be wise to advice the peer to use the uppermost algorithm 
> it understands?
>
> 	- Three paragraphs below Figure 4: "The values is a a requested HMAC 
> Identifier". It should be "The value is a requested..."
>
> 	- Section 5.1, last paragraph: It might be wise to remind here that 
> DATA chunks cannot appear before control chunks inside the datagram... 
> Something like: "Please, remember that DATA chunks can never appear 
> before control chunks."
>
> 	- Section 6.1, first paragraph: "... authenticated chunks has to 
> send...", I guess that it should be "... authenticated chunks HAS TO 
> send..."
>
> 	A little bit later on top of page 9, it says that the "RANDOM 
> parameter SHOULD contain a 32 byte random number". It is stated 
> everywhere else that the number can be of any length. A SHOULD doesn't 
> completely forbid the guy to use any other length instead of 32 byte 
> (bit?) number, but I guess that this is a typo coming from a previous 
> decision.
>
> 	Also, a little bit later, it says "This random number is handled like 
> the verification tag in case of INIT collisions." I don't know what 
> that means. Do you mean something like:
>
> 	 "In case of INIT collision, the rules governing the handling of this 
> random number follow the same pattern as those for the Verification 
> Tag, as explained in section 5.2.4 of [5]."
>
> 	- Section 6.1, second paragraph: "Since this list is for an endpoint 
> there is no..." Hmm... Do you mean something like:
>
> 	- Section 6.1, third paragraph: "An SCTP Endpoint MUST not change the 
> parameters listed in the HMAC-ALGO parameter during the lifetime of 
> the endpoint". This might be a nice thing, but I guess that also a 
> nice thing to do is having different HMAC-ALGO parameters depending 
> with whom we are talking with (typical example of intra/extra net). I 
> don't know if this should be stated here... :-/=
>
> 	- Section 6.2, first paragraph: It says that the AUTH chunk can only 
> be sent while in the ESTABLISHED state. I would also add the 
> SHUTDOWN-PENDING and SHUTDOWN-RECEIVED states...
>
> 	- Section 7, second example: Actually, I don't think that such a 
> message exchange is legal, as when the client sends the COOKIE-ECHO; 
> AUTH; DATA it is still in the COOKIE-ECHOED state and not in the 
> ESTABLISHED one as stated in section 6.2 above.
>

---

From: Michael Tuexen <[email-masked]>
Date: Mon, 19 Sep 2005 13:37:22 +0200

Hi Ivan,

here are my comments in-line.

Best regards
Michael

> necessary to change all the other Figures and the references in the 
This was automatically generated by the xml2rfc tool. I changed it to 
the new 'texttable' about we got real tables. The references
are changed automatically.
> it is quite confusing which is the aim of the chunk.
No, you are wrong.
Both sides have to send RANDOM parameters, even if only one side wants 
to send and the other receive authenticated chunks.
The association shared key depends on both.
> 	- Figure 3: You can see that there are two "Chunk Type 4" there.
Fixed.
> ABORT is left apart, why?
RFC 2960 says that SHUTDOWN-COMPLETE chunk MUST not be bundled. So they 
can not be sent authenticated.
> wouldn't it be wise to advice the peer to use the uppermost algorithm 
Section 6.1 already states:
The receiver of a HMAC-ALGO parameter SHOULD use the first listed 
algorithm it
supports.

> Identifier". It should be "The value is a requested..."
Fixed. I have changed it to

The values is an HMAC Identifier which should be used. The
values are listed by priority. Highest priority first.

> 	- Figure 5: The reference [10] should be [7] instead.

Fixed
> Something like: "Please, remember that DATA chunks can never appear 
Done.
> send...", I guess that it should be "... authenticated chunks HAS TO 
????
I changed it to authenticated chunks MUST send
> (bit?) number, but I guess that this is a typo coming from a previous 
The packet format is defined that random number of arbitrary
> Tag, as explained in section 5.2.4 of [5]."
Done.
> 	"Since this list doesn't change in the lifetime of an endpoint there 
Done. replaced 'in' by 'during'.
> don't know if this should be stated here... :-/=
The decision was for simplicity. I though that these differences would 
be addressed by different shared keys (they are per association).
What do others think?
> SHUTDOWN-PENDING and SHUTDOWN-RECEIVED states...
That sentence has already been deleted...
>
> 	I would add a "o
> r not" at the end of the paragraph, as the first time you read it can 
> be confusing.
Done.
> 	- Section 6.3, last paragraph: I don't understand what it means :-(=
The peers can request all allowed chunks to be authenticated. This 
would especially include ABORT chunks.
So if an implementations ABORTS an association when it received some 
malformed/illegal/whatever packet,
an attacker can just send such an packet to bring down an association.
> ESTABLISHED one as stated in section 6.2 above.
After the COOKIE-ECHO has been processed the left side is in 
ESTABLISHED I think. This is just the normal bundling of DATA with the
COOKIE-ECHO.
> 	- Section 11.1: The reference [2] is not referenced at all :-)=
Reference deleted.

> 	I hope those comments were helpful!
They are very useful and also very appreciated!