Minutes interim-2020-ace-04: Tue 11:00
Authentication and Authorization for Constrained Environments
||Minutes interim-2020-ace-04: Tue 11:00
ACE Interim Meeting - 25-Feb-2020
1. Note Well. https://www.ietf.org/about/note-well/
Area Director Documents
2. OSCORE Ace Framework Profile
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
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
- New parameters for the nonces
3. Pub-Sub Key Managment 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
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
5. Group Communication Key Management
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
Also look at the admin drop in CORE
6. Key Managment for OSCORE Groups
JS - Need to match the changes discussed on the OSCORE profile dealing with
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.