Re: [Ace] WGLC for draft-ietf-ace-authz

[Ludwig Seitz <[e-mail]>]

Hallo Jim,

thank you for the review! Comments inline.

/Ludwig

On 22/10/2018 21:09, Jim Schaad wrote:
> * Section 3.1 - Refresh Token - I don't think that refresh tokens are going
> to be strings because binary is more efficient.

This refers to the way it is defined in OAuth. I'll add a word to clarify.

> 
> * Section 3.2 - we need to reference TLS 1.3 even if DTLS 1.3 is not yet
> available.
> 
Agree.

> * Description for Figure 6 -  Should the example somehow indicate in the
> message that it is going to be an application/ace+cbor content.   Also, I
> don't know that this is a good example in some ways because this is not a
> currently documented profile anywhere.
True. I'll change this to OSCORE.


> 
> * Section 5.6.3 - Should the content type for an error response be
> application/ace+cbor ?
That makes sense. I'll add a sentence to that effect.

> 
> * Section 5.7.1 - Is the content format for a request application/ace+cbor?
> I assume it is but that is not documented in this section.I'll add that.

> 
> Section 5.8 - bytes arrays or byte strings?  I think CBOR uses the latter
Right that slipped through. I'll replace it.

> 
> * Section 5.8.1 - What is the purpose of creating an identifier for a token?
> Is this supposed to be used rather than the one from the AS for something
> like shared secret TLS?  Note that this is an unprotected value.
> 
AFAIK cti is not a mandatory claim of an access token, thus a RS might 
want to create an identifier for tokens that do not have a cti.


> * Section 5.8.1 - Given the change in the OSCORE profile, you might want to
> make this an application/ace+cbor structure as well.
Right

> 
> * Section 5.8.1 - If the token is "not valid" is the RS required (i.e. MUST)
> to try introspection before returning a response if the RS does
> introspection?  The text currently says MAY.  If this is really MAY then the
> text should say that the token is always successfully accepted by the RS.
>
I'm not sure I understand the issue. Introspection is optional in 
general, and may be required in specific use cases. If the RS determines 
that the token is not valid on its own, why would it want to do 
introspection on top of this?


> * Section 5.8.2 - If the RS is going to do introspection, can it send some
> type of "Server Busy - try again in xxx" while it does the introspection
> rather than just doing an ack of the request and possibly waiting a long
> time?

This is probably transport protocol specific, and we were asked not to 
link the framework to a specific protocol, thus I don't know if we can 
provide guidance here.

> 
> * Section 5.8.3 - third point - I think that the correct text would be "The
> method does not provide timely expiration, but it makes sure that older
> tokens will cease to be valid after newer issued tokens are registered with
> the RS."  My problem is that just issuing tokens is not enough as they may
> be going to a different RS for use.  This may also need to have some type of
> rate limit to issued tokens or making the sequence number be on an
> RS/audience basis.

I think the sentence here: "The AS increments this number for each 
access token it issues" needs to be ammended to "... for each access 
token it issues for this RS".

> 
> * Section 6. - The recommendation not to use a shared secret for an audience
> which is hosted by multiple servers is interesting.  This does require that
> a multiple recipient COSE structure be used and it may be worth calling that
> out.  Also the size of the CWT is going to grow for that.  You are also now
> losing the low-level authentication and thus a signature wrapping is now
> also needed.
> 
Right, I'll extend the paragraph to add this information.


> * Section 6 - "Developers MUST" para - May want to add that this can also be
> mitigated to some extent by making sure that keys roll over more frequently.
> 
Ok

> * Section 6 - I am not sure that I agree with the SHOULD NOT in the last
> paragraph.  Think multicast.
Any suggestions on how to mitigate the issue then? If I issue a token 
bound to a symmetric key for audience {R1, R2, R3}, as soon as R1 got 
this token it can impersonate the client and gain access to R2 and R3.

> 
> * Section 6.4 - This also applies to sending back some type of identifier
> from the RS->C when a token is registered.
> 
That is correct, however the token identifier should be just as opaque 
to attackers as the token itself.

> * Section 8.6.1 - Is pop still this document or is it Mike's document?

The token type pop is currently not part of 
draft-ietf-ace-cwt-proof-of-possession. I wouldn't argue against putting 
it there.

> 
> * Section 8.9 - The description of reference is wrong.

Can you explain how? I'm not seeing the issue (assuming you mean the 
reference to RFC8126).

> 
> * Section 8.12 - some of these should move to the OAuth parameters document?
> 
These are new claims. We could move them to the params draft, which 
would then become the params and claims draft. I have not strong opinion 
either way.

> * Section 8.13 - ditto
> 
> * Appendix A -  para "CBOR, COSE, CWT"  - Is it really a requirement to use
> CBOR or is that a recommended?  I thought this was part of what Hannes was
> looking at.
> 
Yes that should be RECOMMENED as well.

> * Appendix A - para Client Credentials Grant  s/can the/can then/
> 
Ok

> * Registries -  I am wondering if we should think about re-writing a couple
> of the registries.  As things stand it appears that the application/ace+cbor
> content type is being used in 5 or 6 places.  It might make more sense to
> have a registry for all of the CBOR abbreviations that are being used in a
> single table and have multiple columns for each of the different places were
> the content format is being used.  This would make it easier to keep
> everything constant and can make re-use of integer values easier to see.
> 
> * Comments on protection of CWT/Token:  I am wondering if there needs to be
> any comments on how a CWT is going to be protected.  While it is ok to use
> either a symmetric key or a direct key agreement operation for a single
> recipient without forcing a signature operation to occur.  If the token is
> going to be targeted a single audience hosted on multiple RSs then a
> signature operation would be required for the purposes of authentication.
> 
> * I am not sure where this issue should be raised so I am putting it here.
> Both of the profiles have as their last security consideration a statement
> that the use of multiple access tokens is a bad idea.  Both of them also
> devote a large section of text to how to deal with multiple access tokens as
> does this document.  More methods of having multiple access tokens seem to
> be coming down the path from the OAuth group.  This appears to be a distinct
> contradiction within the set of documents that should be resolved.
> 
I will get back to those last 3 comments (running out of time).

Regards,

Ludwig


-- 
Ludwig Seitz, PhD
Security Lab, RISE
Phone [phone]