Authenticated Chunks for the Stream Control Transmission Protocol (SCTP)
Summary: Needs a YES. Needs 9 more YES or NO OBJECTION positions to pass.
Note: This ballot was opened for revision 07 and is now closed.
( Magnus Westerlund ) Yes
Jari Arkko No Objection
Comment (2007-02-22 for -)
Does this document expect a separate shared secret to be configured between all pairs of communicating parties? This may be a big assumption. How does one "using TLS" create such a key? That may be a good approach, but I'm sure details are needed. Is there an IETF policy for defining key management and not just reliance on shared secrets for new protocols?
( Ross Callon ) No Objection
( Brian Carpenter ) (was Discuss) No Objection
( Lars Eggert ) No Objection
( Bill Fenner ) No Objection
( Ted Hardie ) No Objection
Comment (2007-02-21 for -)
During a private exchange with the authors, it was clarified that this document works with the partial reliability extensions to SCTP. This will be made clear in an upcoming document (add-ip), but I believe it would be useful to add a short informational statement to this document to that effect.
( Russ Housley ) (was Discuss) No Objection
Comment (2007-02-19 for -08)
Section 1 says: > > ... SCTP sender to sign chunks ... > I really dislike this use of "sign." I greatly prefer "authenticate." Since the specification demands that the random value must be exactly 32 octets in length, it would help the reader to say so in Section 3.1.