Minutes interim-2020-ace-04: Tue 11:00
minutes-interim-2020-ace-04-202002251100-00

ACE Interim Meeting - 25-Feb-2020

MEETING INFO:
* https://datatracker.ietf.org/meeting/interim-2020-ace-04/session/ace

Etherpad:
   https://etherpad.ietf.org:9009/p/interim-ace-20-2-25?useMonospaceFont=true

PRESENT:
    Jim Schaad
    Cigdem Sengul
    Daniel Migault
    Marco Tiloca
    Richard Hoglund
    Francesca Palombini
    Olaf Bergmann
    Carsten
    Dave Robin
    Stefanie Gerdes

AGENDA:
1. Note Well.  https://www.ietf.org/about/note-well/

Area Director Documents

2. OSCORE Ace Framework Profile

    https://datatracker.ietf.org/meeting/interim-2020-ace-04/materials/slides-interim-2020-ace-04-sessa-oscore-profile.pdf

    * https://github.com/ace-wg/ace-oscore-profile/pull/25
    * https://github.com/ace-wg/ace-oscore-profile/issues/26

    Open Points:

    COSE defines algs in one range - can't distinguish between different
    algorithm types. JS - That's the way it has always been - see OIDs

    Replay window - Don't need to send it in the OSCORE security context. -

    C/AS and R/AS do not need to specify the profile - not currently in the
    profile document - This is expected behavior in profiles.  The ACE profile
    is not used between the AS and the C or RS, that uses pure OSCORE w/o the
    ACE changes in how keys are established

    Let the RS pick the client ID:
    JS Issue is an RS which has some resources with ACE and different resources
    with LAKE.
      Happy to just go with an operational consideration at this point
    FP - what about return an error
    JS - If you get the error what are you supposed to do in that case? How
    does the client fix it? DM - THink about the cluster case from IPSec and
    put into the ops section

    - Length of Nonces
    JS will respond to Ben on this issue.
    CB - could the length of the nonce be grown by one side or the other?
    JS - Is is an error to grow the size of the nonce?
    FP - How do you know if this is going to be long enough - when is is going
    to grow?

    - New parameters for the nonces

STATUS UPDATES

3. Pub-Sub Key Managment Profile

    *
    [draft-ietf-ace-pubsub-profile](https://datatracker.ietf.org/doc/draft-ietf-ace-pubsub-profile/)
    https://datatracker.ietf.org/meeting/interim-2020-ace-04/materials/slides-interim-2020-ace-04-sessa-pubsub-profile

    Look at the new TOC for structure of document
    CS - have not looked at last revision - will be happy to review and submit
    text FP - Plan to get a new version in by the cut off date.

4. MQTT Ace Profile

    *
    [draft-ietf-ace-mqtt-tls-profile](https://datatracker.ietf.org/doc/draft-ietf-ace-mqtt-tls-profile/)

    No much change from the previous meeting
    Need to get the implementation done for issues from the previous meeting
    Should get to by around March 1 - should be updated by the cutoff date.
    DM - Are we going to be close to the final version here?
    Are there some people we can have do a careful read of the document -
    suggest names? CS - Hannes recently sent some messages - he might be a
    candidate

5. Group Communication Key Management

    *
    [draft-ietf-ace-key-groupcomm](https://datatracker.ietf.org/doc/draft-ietf-ace-key-groupcomm/)
    https://datatracker.ietf.org/meeting/interim-2020-ace-04/materials/slides-interim-2020-ace-04-sessa-interim2502-ace-key-groupcomm

    DM - How much more work is going to be needed?
    MT - Expect one more update after this to be ready.
    Same expectations for the OSCORE profile of this document
    FP - Do we think it is a valid scenerio talking to a GDC - will use
    different public keys to countersign the communication - potentially
    because of different algorithms.
      Constratrained nodes likely to have only a single algorithm implemented
    JS - Main reason is to prevent coorilation between the groups
    MT - THink it is ok to use multiple keys for a set of groups.  One per
    algorithm. FP - What should be allowed? MT - Group memebers don't have
    control on how the group is configured that is the administrator's setup.
    DM - Don't see why having different keys for different groups is an issue.
    JS - Need multiple groups with a single key.  But can be done the other way
    from the AS w/o the KDC knowing it. MT - Does it make senes for a
    administrator to be able to create groups with different key algorithms? DM
    - Can be an issue for legacy devices where a modern algorithm is not
    supported. MT - Should have each group independently configured. Changing a
    parameter in one group should not affect other groups DM - What is the
    attack space? MT - Problem is mostly summerized on the most recent thread
    w/ Jim
      Also look at the admin drop in CORE

6. Key Managment for OSCORE Groups

    *
    [draft-ietf-ace-key-groupcomm-oscore](https://datatracker.ietf.org/doc/draft-ietf-ace-key-groupcomm-oscore/)
    https://datatracker.ietf.org/meeting/interim-2020-ace-04/materials/slides-interim-2020-ace-04-sessa-interim2502-ace-key-groupcomm-oscore

    JS - Need to match the changes discussed on the OSCORE profile dealing with
    window parameter
      Discussion on the "legal requester" proposal from Jim indicates that it
      is not yet clear what the problem he believes has been clearly stated yet.