Re: [Ace] Review Comments on -03

[Olaf Bergmann <[e-mail]>]

Hi Jim,

Thanks again for your review. I have addressed a bunch in -04 and opened
a couple of issues in the tracker at
https://github.com/ace-wg/ace-dtls-profile/issues for those that I still
need to look into.

Please find a few additional answers inline:

Jim Schaad <[e-mail]> writes:

> Meta Question - Is there a check list that I can run through which says that
> these are the things that a profile needs to cover.  Part of this question
> about how the document is structured.  I was of the opinion that a profile
> was going to need to cover one or both of the following issues:  How does
> this profile deal with communications between the C and the RS?  How does
> this profile deal with communications between the C and the AS?  How does
> this profile deal with communications between the RS and the AS?

I was under the impression that Appendix C of draft-ietf-ace-oauth-authz
is supposed to serve this purpose.

> *  If the document discusses how to do communications between the client and
> the AS, I do not believe that you can rule how mutual authentication between
> those two entities as being out of scope.  You don't need to specific how
> the initial configuration is done, but the fact that you are using DTLS with
> pre-configured credentials needs to be in scope.

I am currently not sure what to say in the document. I will come back to
this later.

> * It is too bad that we don't have the generic coap schemas defined yet so
> that we can use that as part of the URL returned with an access denied
> response.
>
> * Point to Authz document for the details of getting the AS URL back in
> section 2 p 3

Done.

> * Update section 2 to talk about the use of the rs_cnf parameter.  For RPK
> no cnf parameter would be expected to be returned.

Done.

> *  Deal with RPK and PSK in separate paragraphs.  Yes you may have some
> duplication of text but the details are sufficiently different that it would
> read better.  Section 2

Done.

> * Section 2.1 - PSK is not a session key.  The session key is inside of TLS.
> This means that the session  key is not the identity.

Depending on the level of abstraction. But yes, to avoid confusion, this
has been changed now to "shared secret".

> * Section 2.2 - Is there an intent in this paragraph that if the kid does
> not match the current DTLS session that the CWT would be rejected?  That
> appears to me to be what the text says but I am not sure.  Next paragraph
> appears to say any active DTLS session rather than just the current one.

There is no "current DTLS session". The server may have multiple DTLS
sessions, one of which may have been established using a key that
happens to be associated with the given kid. Any DTLS session where this
is the case (usually, this would not be more than one DTLS session)
needs to be updated as described.

> * Section 2.3 p 3 - How is a check done for the PSK being the same if one
> has deleted all of the CWTs and then get an update over the secure channel.
> Just having the kid be the same should not be sufficient.

I am not sure that I understand this question correctly. But there
should be no secure channel associated with a deleted CWT.

> * Section 2.3 - Is the kid parameter still needing to be defined given the
> CWT POP key id option?  (Assuming that it does not disappear.)

You are probably right. But then, we would have to include a cnf claim
containing the kid accourding to
draft-ietf-ace-cwt-proof-of-possession. Otherwise, there would be a
conflict with the numbers proposed for oauth-authz (specifically, the
aud parameter from CWT as listed by Ludwig in
https://mailarchive.ietf.org/arch/msg/ace/cX-DjWxSC4PehY0bEmbaNeeT2pI)

> * Section 3 - YEAH you are doing POP on the RPK as part of the request.  I
> like this!!!!!!!

Thanks :-)

> *  Section 3 - The last 2 sentences in this section are giving me problems.
> I don't understand when  and where you are putting kids and why.

Ok, I will revisit this.

> * Section 4 - if the token is already secure then no secure channel would be
> needed.  Hard to have a secure channel if you have not setup anything yet.

Ok, I will revisit this.

> * Section  4 - Are we really using MAX-AGE and not expires in for duration.

Changed. (Removed as it does not contain new information.)

> * Section 4 - Update the pointer to a PoP token description

Okay, will do.

> * Section 4.1 - I think that this is not what the COSE_Encrypt structure is
> defined in the POP structure for.  Revisit this.

Okay, will do.

> * Section 4.2 - Remove everything to do with renegotiation of TLS - It is no
> longer present in 1.3

Done.

> s/Is also adds/It also adds/

Done. (I hope — did not find it anymore).

Grüße
Olaf