On 28/11/2018 18:06, Jim Schaad wrote:
Ludwig,
It looks good. A couple of additional things that have occurred to me.
(Always a problem when on reads drafts again and again.)
1. I don't really have a problem with figure 6, but I don't know if we want
to more correctly reflect what an OSCORE message would look like in this
location. This would basically be a re-write of the entire example
structure to reflect that you have an outer and an inner CoAP message. It
might be confusing for people who are not fully immersed in the OSCORE
world.
As far as the example goes, we would need to add an OSCORE option, I
wouldn't want to expand the encrypted payload to reflect the full OSCORE
structure, since that is likely going to be more confusing than helpful.
2. I have no idea of where this would go and it is perhaps something that
the OAuth people need to think about as well. If an AS receives a request
which has message level security (OSCORE/CWT/JWT) over a session level
security connection (TLS/DTLS/IPSEC) are there any rules/suggestions about
which keys should be used for evaluating the resulting request. While I
assume that message security wins and the session security is ignored, I
have not seen this anyplace.
Good point. I would think that message level security would prevail, but
that would need to be specified in a profile.
3. In section 5.8.1 - It says that for a CWT access token that the
application/cwt content type MUST be used. There are two possible issues
with this. 1) How does the client know what the type of the token is. It
could be a CWT, an introspection token, or something else entirely. 2) Is
it an error if a CWT token is received and the content type is not present?
Right, the token is supposed to be opaque to the client. I will remove
that requirement.
/Ludwig
--
Ludwig Seitz, PhD
Security Lab, RISE
Phone +46(0)70-349 92 51
_______________________________________________
Ace mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ace
