Skip to main content

Use Cases for Authentication and Authorization in Constrained Environments
RFC 7744

Yes

(Barry Leiba)
(Kathleen Moriarty)

No Objection

Alvaro Retana
(Deborah Brungard)
(Joel Jaeggli)
(Martin Stiemerling)
(Terry Manderson)

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

Alvaro Retana No Objection

(Barry Leiba; former steering group member) Yes

Yes (for -09)

                            

(Ben Campbell; former steering group member) Yes

Yes (2015-10-21 for -09)
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.

(Kathleen Moriarty; former steering group member) Yes

Yes (for -09)

                            

(Spencer Dawkins; former steering group member) Yes

Yes (2015-10-21 for -09)
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; former steering group member) Yes

Yes (2015-10-22 for -09)
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

(Benoît Claise; former steering group member) No Objection

No Objection (2015-10-20 for -09)
"ACE use cases." And ACE stands for :-)

(Deborah Brungard; former steering group member) No Objection

No Objection (for -09)

                            

(Jari Arkko; former steering group member) No Objection

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

(Joel Jaeggli; former steering group member) No Objection

No Objection (for -09)

                            

(Martin Stiemerling; former steering group member) No Objection

No Objection (for -09)

                            

(Terry Manderson; former steering group member) No Objection

No Objection (for -09)