Authenticated Chunks for the Stream Control Transmission Protocol (SCTP)
RFC 4895

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

( Cullen Jennings ) No Objection

( David Kessens ) No Objection

( Jon Peterson ) No Objection

( Dan Romascanu ) No Objection

( Mark Townsley ) No Objection