Re: [Ace] Assignment of OSCORE Sender and Recipient IDS - was RE: Review of draft-ietf-ace-oscore-profile

[Christian Amsüss <[e-mail]>]

Hello John, Jim,
and ACE in general,

I agree with Jim that namespacing is the obvious solution to this
problem; we've had a brief discussion in a WG meeting shared with OCF
earlier this year.

However, the namespacing of KIDs is a difficult matter[1] and moreover
little understood so far. I'm unaware of any document describing how the
association between a device and an AS comes to be, let alone how the
device indicates to the AS which shard of its recipient IDs it may use.
(And is that a prefix or a suffix to the KID? Is it by bits or by
bytes?)

Having multiple AS involved with a device is a situation we should be
prepared for, especially when considering that even in a closed system
under single administration, the AS may be distributed for reasons of
reliability. Managing those (as well as other sources of OSCORE contexts
like LAKE) would be easier if the device didn't have to think through
its namespacing, especially given that there might be ad-hoc decisions
to be made: A server may be OK with giving out a short recipient ID to a
device on the network (where it can use the source IP to pick the right
context), but would pick a longer KID for a client ringing in through a
proxy that has no information in its source address.

At the same, time, getting endpoint chosen KIDs right is a bit harder
than it is with AS-provided ones: An scenario that came up in a recent
chat with John showed that if RS and C would happen to both pick the
same KID and a MITM modifies the token POST, both would derive identical
security contexts. Then, it suddenly becomes crucial for the security of
the whole construct that the RS first verifies a request coming from C
before sending any message whatsoever with that context.


So to summarize, I like the idea, and I'd like to see it thought through
(preferably before we even have to work out how that namespacing is
manged precisely), but I'm not sure that that all the questions that'd
come up in the process are realistic to address at this stage.

KR
Christian

[1]: See https://tools.ietf.org/html/draft-amsuess-lwig-oscore-00#section-4
  for a poem and some notes

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom