************************************************************************

IETF-90 Authentication and Authorization for Constrained Environments
(ace) WG notes

Wed, 23 July 2014, EDT

0900 Intro remarks (Hannes Tschofenig (HT))

 - BoF in London, interim mtg in Stokholm
 - Charter agreed
 - "Use cases and Requirements" are the first deliverable


0920 Problem Description (Ludwig Seitz (LS))

 - Three logical components: Client (C), Resource Server (RS),
   Authorization Server (AS).  AS is assumed to be unconstrained.
 - Discussion: Which commSec approach?  Session (CoAP over DTLS)
   or Object Security (e.g. JWS/JWE)

   Kerry Lynn: Can we compare the two approaches in terms of typical
   device constraints (memory, CPU, bandwidth, etc)?
   LS: Not yet

 - Discussion: Different Authorization models [RFC2904] depending on
   whether C or RS is the more constrained device (or is sleepy, etc)

   Rene Struik (Rene): Isn't it desirable to limit C's interaction with
   AS?
   HT: We can assume some shared (persistent?) state

   Dave Robin (DR): RS <-> AS interaction is always an option. In a
   hybrid approach, DTLS between RS and AS could extend trust to
   verification of tokens or other signed objects.
   Carsten Bormann (CB): Good point. Think of network access control
   as the primary line of defense; good appSec eases demands (reliance?)
   on NAC.

   Samita Chakrabarti: Are the model topologies too simplistic? Should
   we consider middle boxes?
   LS: Not as a first step

   Lionel Morand: Do we always assume mutual authentication between
   C & RS?
   DR: If C is providing a bearer token, it better be sure which RS
   it's talking to

   LS: Is there ever a case where we don't care about authenticity of
   server?  Yes, in the case of sending a command to a light bulb.
   
   DR: Is it necessary to distinguish between device and app?

   Subhir Das: Must support pub/sub (i.e. CoAP observe) model

   Rene: What do we mean by offload?
   LS: e.g. ACL evaluation
   Andrew MacGregor (AM): Unconstrained AS has storage for ACLs
   HT: AS may also need to perform database operations.  Clarify in
   draft


1000 Use Cases and Design Patterns (LS)

 - Discussion: Are the three components sufficient to cover all use
   cases? (KL: This can be re-cast as "Is it acceptable to limit
   ourselves to use cases that can be addressed by this architecture?")

   Rys Smith: Owner may want to know who has accessed data. Consider
   adding auditing as well -> aaace

   Robby Simpson: May want to consider multiple ASs (although painful)
   LS: Cross-domain authentication may be useful

   DR: Consider redirects; allow the RS to inform C where to find AS
   HT: May want to re-use CoRE work, e.g. Resource Directory.  Need
   more detailed scenarios.

   AM: Airliners are the building automation use case; leased from
   and maintained by different parties, high potential for inside
   attacks  (KL: consider also embassies on hostile soil)

   Michael Richardson (MR): Show federated relationships (if in-scope)
   Declare NAC out-of-scope

   Pascal Thubert (PT): Which WG is responsible for provisioning (re:
   UCAN BoF)

   Jabber: "Push" model is Active Directory, not Kerberos, style
   authentication

   Rene: AS may change
   DR: Is the requirement that C must deal with several ASs OVER time
   or AT A time?

   ACTION: Dave Robin and Martin Murillo will review Use Cases doc
   HT: Target end of July for review, bring discussion of mutual auth
   to the list for discussion


1030 Design Considerations (Corinna Schmitt)

 - Discussion (HT): Is there a pref for a/symmetric encryption?

   Rene: If heterogeneous trust domains are considered, this indicates
   PKI.  Must consider use cases.

   Zach Shelby: Don't be afraid of asymm; re-use (AES128?) h/w support

   Mike Jones: Use cases for both; don't constrain here

   DR: 1:m different from m:m use cases

   Zach: Raw Public Key is mandatory in CoAP

   MR: How do we incorporate legacy devices?  Just auth the proxy?

   PT: Industrial automation AAA is described in terms of "zones" &
   "conduits"


1100 Cross-Domain Support (CB)

 - IoT class taxonomy [RFC7228] doesn't assume h/w crypto
 - Either or both of C, RS may be constrained
 - C, RS may belong to different "owners"
 - C, RS may have different default AS
 - Assume RS is in a "less constrained" layer of the architecture;
   mandate that ASs must be able to federate?
 - Do constrained devices ever need to talk directly to each other?  
   Yes, for resilience (or privacy).  Different degrees of "offline"