Minutes IETF100: ace
minutes-100-ace-00

ACE WG Meeting
IETF 100 - Singapore

The ACE WG met Tuesday morning.  There were two new chairs from the last
meeting with Ben Kaduk and Jim Schaad replacing Hannes Tschofenig and Kepeng
Li.  Our thanks go out to the past chairs for the work they have done to get
the WG to this point.

Mike Jones gave a presentation on draft-ietf-ace-cbor-webtoken.  The document
is in WGLC which will end on 29 Nov 2017.  There have been a couple of issues
that have been found so far in the LC which will need to be addressed, it is
expected that a revised document should be done soon.  Issues raised during the
discussion were: •        JWT intentionally used strings for fields since they
were supposed to be human readable.  It would make sense to look for smaller
formats for CWTs. (Hannes) •       Should scope be defined in this document as
the OAuth Profile document uses it? (Hannes) •       Not defined in JWT and the
intention was to make these documents as parallel as possible. •       What
should be happening as documents like the framework defines new claims? (Ludwig
Seitz) •       Register the claims, include a numeric claim number if desired,
in the IANA registry.

Mike then gave a presentation on draft-ace-cwt-proof-of-possession.  Still some
outstanding issues that need to be addressed from the previous version.  He
believes that the technical aspects of the document are stable, mostly
editorial type issues left.  No issues were raised during discussions.

Ludwig Seitz gave a presentation on draft-ietf-ace-oauth-authz.  There is a
desire to try and do an interop event on this document no later than the London
Hackathon.  Issues raised during discussion were: •       It seems that the
framework is mandating CBOR and CoAP formats. (Hannes) •       Ludwig believes
that these are not mandated, but will review the document again to ensure this
is true. •       The client token concept is new in this document and is not in
base OAuth.  It feels like there has not been sufficient thought put into this.
 Perhaps it should be moved to a different document.  (Hannes) •       This
needs to have some discussion on the mailing list and a decision made. •      
There were people who both supported removal and keeping client tokens. •      
There was worry about possibly needing to support multiple forms of tokens. •  
    Should there be the possibility of sending multiple profiles from the AS to
the client so it can choose which of the supported profiles to use?  (Francesca
Palombini) •       Need to have a better use case before being considered.  The
AS knows the supported profiles both CS and R and thus can always send back a
usable one.

Francesca Palombini gave a presentation on draft-seitz-ace-oscoap-profile.  The
title of the document has been changed to reflect the change of OSCOAP to
OSCORE.  The document finished an adoption call and the chairs have called
consensus to adopt the document.  No issues were raised in discussions.  Paul
(?) and Dave Thaler volunteered to review the document.

Göran Selander gave a presentation on draft-ietf-ace-dtls-authorize.  The
following individuals volunteered to review:  Francesca.  Issues discussed
were: •       Two methods to send authorization to the server.  Authz-info
resource and psk_identity both documented. •       Authz-info mandatory, but
permission may not be granted (Carsten Borman) •       Does client have to
implement both (Hannes) •       Authz-info is required for doing
re-authorization, cannot be done by psk_identity unless you reconnect the DTLS
session. •       Should PSK and RPK be two different profiles or aspects of the
same profile? •       Problem is probably more of an issue for different
transports (Hannes) •       AS knows the capabilities of the client and
resource server, it can always return the right one. •       How does a server
identify a token in the psk-identity slot?  Current proposal is try different
options. •       Ericsson might have an IPR issue on this document.  Should be
announced later in the week.

Marco Tiloca gave a presentation on draft-aragon-ace-ipsec-profile.  Issues
discussed were: •       The access token request can be sent without a
proof-of-possession in the request since it uses IKE.  This can be an unknown
key share attack.  Should be either in the security considerations or dealt
with.  (Dan Harkins)

Marco Tiloca then gave a presentation on draft-tiloca-ace-oscoap-joining.  The
following people volunteered to review:  Carsten, Eliot Lear, Göran, Peter.
Issues discussed were: •       This work closely mirrors the pub-sub document. 
It would be good to try and consolidate the work. (Carsten) •       Would like
to get the document adopted by the WG. •       Chairs will need to review the
status of this document and the pub-sub document and make some decisions. 
Document is dependent on a the multicast OSCORE draft in CORE.

Peter van der Stok gave a presentation on draft-vanderstok-ace-coap-est.  The
following people volunteered to do reviews:  Eliot Lear, Brian Weis, Dan
Harkin, Max Pritikin.  The chairs intend to do an adoption call on the document
in December.  Issues raised during the discussion were: •       Server-side key
generation, what is the value and should this be here or separate. (Hannes) •  
    What level of BRSKI should be in this document.

The chairs then led a discussion on the issues surrounding doing a group
communication protocol with particular emphasis on the really lightweight
protocol that some believe is needed for use with a lighting protocol.

This is an attempt to provide the issues discussed, but no attempt is made to
either give attribution for the discussions or to maintain chronology. •      
It was clear from the discussion that there are going to be many different
levels of security and latency that exist in the scenario.  In some cases
(nuclear power plants) it is far more important that high security is
maintained while others (office lighting) have significantly less problems. 
Even within a single setup there may be some actions (fire department door
opener) that are going to have different security requirements. •       One
different way to layout the problem space might be to divide it into those
where all of the devices have a homogeneous vs heterogeneous levels of
privilege.  In the first case, all elements in the security group can cause any
other element to execute a command.  In the latter case the set of elements
that can issues commands is a designated sub-set of the entire group.  This
distinction makes a big difference if one is looking at the security model from
an escalation of privilege problem.  Can a node gain the ability to do
something that it should not be able to do? •       Discussions of what latency
means as a security concept is fraught with problems.  Some cases, such as room
lighting have specific latency issues that need to be considered, but are not
necessarily security specific.  In other cases, such as phones, latency can be
faked by generating feedback to a user independent of any actual completed
event. (I.e. the phone on the other side is reached.)  Latency is more of a
problem when dealing with people rather than machines as they may have
incorrect assumptions about how long things need to take. •       Worries exist
over the problem of solution creep.  If a solid proposal is adopted for dealing
with a case like home lighting, what types of restrictions can be put into
place to prevent this from also drifting into cases where it is either less or
not appropriate.  The proposed solution would have both a key distribution
protocol and a set of requirements when authentication are required, but how
easy is it to ignore these and then claim to conform to a security protocol.

The chairs then attempted to conduct a set of hums to get a sense of the room.

•       Are low security systems a class that should be solved by the IETF? 
Not all devices share the same privilege, compromise allows for an elevation of
privilege o       No strong consensus shown. •       Reformulate as: In systems
where a breach of security is deemed to have minimal impact by the owner of the
system. o       No consensus, but a stronger lean towards ‘No’ •       All
devices share the same privileges.  Compromise of a device does not allow for
additional privileges to be given. o       Strong consensus that this is work
the group would like to see done.