Simple Authentication Schemes for the Asynchronous Layered Coding (ALC) and NACK-Oriented Reliable Multicast (NORM) Protocols
RFC 6584

Note: This ballot was opened for revision 06 and is now closed.

(David Harrington) (was Discuss, Yes) Yes

(Jari Arkko) No Objection

(Ron Bonica) No Objection

(Stewart Bryant) No Objection

Comment (2012-01-31)
No email
send info
The terms ALC and NORM need to be expanded on first use.

(Gonzalo Camarillo) No Objection

(Ralph Droms) (was Discuss) No Objection

Comment (2011-11-01)
No email
send info
I'm looking forward to reading responses to the Discuss positions
posted by Pete and Stephen.

(Wesley Eddy) No Objection

(Adrian Farrel) No Objection

Comment (2011-11-03 for -)
No email
send info
I support Pete Resnick's Discuss

---

Section 1

s/transfer reliably objects/reliably transfer objects/

--

   More precisely this document details the EXT_AUTH==1 header extension
   defined in [RFC5651].

Should read

   More precisely this document details the HET=1 (EXT_AUTH) header 
   extension defined in [RFC5651].

(Stephen Farrell) (was Discuss, No Objection, Discuss) No Objection

(Russ Housley) No Objection

Comment (2011-11-02 for -)
No email
send info
  Throughout the document, the use of "Signature Cryptographic Function"
  ought to be replaced by "One-way Hash Function" or "Message Digest
  Algorithm" (please pick just one).

(Pete Resnick) (was Discuss) No Objection

(Dan Romascanu) No Objection

(Peter Saint-Andre) No Objection

Comment (2012-01-30)
No email
send info
Section 1.2 states:

      Key sizes of length between 1024 and 2048
      bits, inclusive, SHOULD be used.  Key sizes of length strictly
      superior to 2048 MAY be used.

It seems strange to prefer smaller keys to larger keys. Why not just say that keys should be larger than 1024? (By the way, this text is substantially repeated in Section 3.2; it would be better to provide it only once.)

Section 3.4 states:

   All receivers MUST recognize EXT_AUTH but MAY not be able to parse
   its content, for instance because they do not support digital
   signatures.

I think you mean "might" instead of "MAY", unless it is truly OPTIONAL to parse the content or support digital signatures. (This text recurs in Sections 4.4, 5.4, and 6.4.)

Section 8.3 states:

   This specification requires several parameters to be communicated to
   the receiver(s) via an out-of-band mechanism that is out of the scope
   of this document.  This is in particular the case for the mapping
   between an ASID value and the associated authentication scheme
   (Section 1).  Since this mapping is critical, this information SHOULD
   be carried in a secure way from the sender to the receiver(s).

Given the security implications, wouldn't it be prudent to at least suggest one or more out-of-band mechanisms for the sake of interoperability?

(Robert Sparks) No Objection

(Sean Turner) (was Discuss) No Objection