Use Cases for Authentication and Authorization in Constrained Environments
draft-ietf-ace-usecases-10

[Ballot comment]

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

[Ballot comment]
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.

[Ballot comment]
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 ... :-)

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-ace-usecases-09, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any IANA actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, IANA does not object.

If this assessment is not accurate, please respond as soon as possible.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (ACE use cases) to Informational RFC


The IESG has received a request from the Authentication and Authorization
for Constrained Environments WG (ace) to consider the following document:
- 'ACE use cases'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2015-10-22. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  Constrained devices are nodes with limited processing power, storage
  space and transmission capacities.  These devices in many cases do
  not provide user interfaces and are often intended to interact
  without human intervention.

  This document includes a collection of representative use cases for
  authentication and authorization in constrained environments.  These
  use cases aim at identifying authorization problems that arise during
  the lifecycle of a constrained device and are intended to provide a
  guideline for developing a comprehensive authentication and
  authorization solution for this class of scenarios.

  Where specific details are relevant, it is assumed that the devices
  use the Constrained Application Protocol (CoAP) as communication
  protocol, however most conclusions apply generally.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-ace-usecases/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-ace-usecases/ballot/


No IPR declarations have been submitted directly on this I-D.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (ACE use cases) to Informational RFC


The IESG has received a request from the Authentication and Authorization
for Constrained Environments WG (ace) to consider the following document:
- 'ACE use cases'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2015-10-21. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  Constrained devices are nodes with limited processing power, storage
  space and transmission capacities.  These devices in many cases do
  not provide user interfaces and are often intended to interact
  without human intervention.

  This document includes a collection of representative use cases for
  authentication and authorization in constrained environments.  These
  use cases aim at identifying authorization problems that arise during
  the lifecycle of a constrained device and are intended to provide a
  guideline for developing a comprehensive authentication and
  authorization solution for this class of scenarios.

  Where specific details are relevant, it is assumed that the devices
  use the Constrained Application Protocol (CoAP) as communication
  protocol, however most conclusions apply generally.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-ace-usecases/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-ace-usecases/ballot/


No IPR declarations have been submitted directly on this I-D.