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
signature.asc
Description: PGP signature
_______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace