Use Cases for Authentication and Authorization in Constrained Environments
RFC 7744

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

(Ben Campbell) Yes

Comment (2015-10-21 for -09)
No email
send info
While I'm not ordinarily a big fan of publishing use cases as RFCs, I think this one has value.

Otherwise, I have only a few minor comments:

-Please  expand ACE in the title, abstract, and body.

- 2.6.1: Is it reasonable to expect wearable devices to have what sound like multi-user-profile capabilities?

- 2.7: An informational reference for stuxnet might be helpful.

(Spencer Dawkins) Yes

Comment (2015-10-21 for -09)
No email
send info
This draft seems especially worth the effort of publishing a use case draft as an RFC. I learned a lot while reviewing it. 

The security considerations section seemed unusually valuable for a use case draft. Do the title and abstract call enough attention to that?

The section title "2.1.1. Bananas for Munich" would also be a great name for a rock band ... :-)

(Stephen Farrell) Yes

Comment (2015-10-22 for -09)
No email
send info
Excellent and well written document, thanks. I think there are
five things you could usefully add, see below. That said, I
agree that this cannot and should not try to be fully complete
so I won't argue (much:-) if you prefer to omit these. We/you
can figure out what if any text to add I'm sure, but I'm happy
to chat about that.

1. Software update is really needed and often missing and
usually hard. There's at least a need to authenticate and
authorize new firmware, when there is any update. That may not
be the same as authorizing a new config.

2. Alice buys a new device, and would like to know if it is
calling home or what it is doing before she configures it, or
perhaps before she accepts it in her network. Even if she
accepts it, she may want to be able to monitor the data it
is sending "home" e.g. to ensure her TV is not sending 
data when she inserts a USB stick, if that is undesired.

3. Device fingerprinting is a threat that ought be considered
by solution developers, especially if there is no reliable
software update. Probably the best to be done is to try to
make it hard for unauthorized parties to fingerprint a device,
but that's also hard.

4. Commercial Devices will be end-of-lifed by vendors, and yet
Alice still needs to be able to use, and perhaos to update,
the device. That calls for some kind of authorization handover
which is not quite the same as a change of ownership.

5. Penetration testing will happen and devices should not barf
even then. Maybe that's a security consideration worth a
mention.

See also the secdir review. [1] It'd be good to see a 
response to that.

   [1] https://www.ietf.org/mail-archive/web/secdir/current/msg06101.html

Barry Leiba Yes

(Kathleen Moriarty) Yes

(Jari Arkko) No Objection

Comment (2015-10-22 for -09)
No email
send info
The comment from Joel Halpern's Gen-ART review might be something to take into account in the final version of the RFC.

Deborah Brungard No Objection

(Benoît Claise) No Objection

Comment (2015-10-20 for -09)
No email
send info
"ACE use cases." And ACE stands for :-)

(Joel Jaeggli) No Objection

(Terry Manderson) No Objection

Alvaro Retana No Objection

(Martin Stiemerling) No Objection