> -----Original Message-----
> From: Ludwig Seitz <[email protected]>
> Sent: Tuesday, October 23, 2018 7:43 AM
> To: Jim Schaad <[email protected]>; draft-ietf-ace-oauth-
> [email protected]
> Cc: [email protected]
> Subject: Re: [Ace] WGLC for draft-ietf-ace-authz
>
> Hallo Jim,
>
> thank you for the review! Comments inline.
>
> /Ludwig
>
> On 22/10/2018 21:09, Jim Schaad wrote:
> > * 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.
Ok - so the client has this cti - what could it use it for?
> > * 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?
The RS has just received a token. The RS wants to validate said token. It can
do it on its own or it can do it with introspection. If it is going to do it
with introspection can it defer this validation until first use or does it need
to do it immediately so it is not going to store an invalid token? It is
possible that an RS is going to both support some tokens and require
introspection on others. In that case it would decide the token was not valid,
but would not necessarily know if it was a legal introspection token.
>
>
> > * 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 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.
I am not sure that I think this is an issue that needs to be mitigated. It
needs to be acknowledged, but the assumption would be that if you have three
resource servers that are hosting the same audience they are going to be run by
the same RO and already be coupled. After all it should not matter which of
them you do a GET from, you should get the same answer. Similarly a PUT to one
should propagate to the others so that it is available to all clients.
>
> > * 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.
I would only because it would delay that document. I just could not remember
where if it was there and was too lazy to look.
>
> >
> > * 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).
Reference This contains a pointer to the public specification of the
grant type abbreviation, if one exists.
This is not about grant types.
>
> >
> > * 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.
I have no opinion either way - was just asking.
> > * 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 +46(0)70-349 92 51
_______________________________________________
Ace mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ace
