Re: [Ace] AD review of draft-ietf-ace-oauth-authz-24

[Ludwig Seitz <[e-mail]>]

On 10/11/2019 04:28, Benjamin Kaduk wrote:

>>> 1.)
>>> Perhaps the most far-reaching changes needed
>>> will be to rename the "profile" claim, since that has already been
>>> allocated to OIDC Core for a very different usage.
>>
>> [LS] FIXED. I renamed the "profile" claim and parameters to "ace_profile"
>> Note that this will require changes in all of the profile drafts as well.
> 
> Indeed.  It would be great if someone (the chairs? Other volunteers are
> surely welcome) could make a list of changes that affect the profile
> documents, and make a pass over each in turn to find the affected areas.
> 

Mostly a search and replace of "profile" with "ace_profile" would be in 
order, perhaps with a subsequent proof reading that nothing was borked 
up in the process.

I can do this, but sadly not before IETF.


>>> 6.)
>>> Section 1
>>>
>>>     Authorization is the process for granting approval to an entity to
>>>     access a resource [RFC4949].  The authorization task itself can best
>>>     be described as granting access to a requesting client, for a
>>>     resource hosted on a device, the resource server (RS).  This exchange
>>>
>>> I had to pause for a while after reading this and ponder whether I
>>> agreed with it.  I think that my reticence stems from some friction
>>> between the most generic abstract definition of "resource" and a more
>>> specific one used in the web/HTTP world and, to a lesser extent, the
>>> world of URIs and URNs in general.  The resources we are discussing here
>>> are not always specific named resources, but can also refer to
>>> attributes or capabilities mediated by a RS; similarly, we may be
>>> creating/modifying named resources as part of the resource access
>>> performed by a client in the OAuth model.  I don't think it's wise to
>>> diverge from the RFC 4949 definition just yet, but am still considering
>>> whether adding some additional clarifying text here is worthwhile.
>>
>> [LS] I would argue that this specification is applicable even to the wider
>> definition of "resource" that you are thinking of. Since OAuth 2.0 leaves
> 
> Oh, I agree, and was not intending to say otherwise with my comments above.
> Rather, I was considering that some [other] readers might see the word
> "resource" and go straight to "web resource named by URI", and wondering if
> we could reword slightly to avoid that.
>  >> the definition of "scope" up to the specific applications, and the ACE
>> framework does not change this, we can deal with both web/HTTP/CoAP
>> resources
>> (named by URIs or URNs) and any other type of resources where the
>> application
>> can map the resource in question to a set of scopes.
>> I am therefore inclined to say that this section is fine, but I'd be glad to
>> hear the result of your considerations on that matter.
> 
> I see three potential options so far:
> 
> (1) no change
> (2) in the first sentence, s/resource/generic resource/
> (3) add a new sentence as the third sentence, similar to "This resource
> might be a Web or similar resource addressed by URI, but in general can be
> a more generic or abstract resource provided by the RS".
> 
> I'm happy to advance the document with any of those three (and probably
> with other versions, if any arise).
>

I'll go with option 2 which seems to be a fine compromise with minimal 
text breakage.

> 
>>> 16.)
>>> Section 3.2
>>>
>>>     One application of COSE is OSCORE [I-D.ietf-core-object-security],
>>>     which provides end-to-end confidentiality, integrity and replay
>>>     protection, and a secure binding between CoAP request and response
>>>     messages.  In OSCORE, the CoAP messages are wrapped in COSE objects
>>>     and sent using CoAP.
>>>
>>>     This framework RECOMMENDS the use of CoAP as replacement for HTTP for
>>>     use in constrained environments.
>>>
>>> Do we have a reason to mention OSCORE if we're not going to make a
>>> recommendation about its use?
>>
>> [LS] We also mention DTLS and TLS without making any recommendation about
>> which to use. I would suggest to either remove all of it or to add a
>> sentence
>> noting that this is an enumeration of some security options, and the choice
>> depends on the specific application scenario.
> 
> Adding a sentence feels like a slightly better option to me, though it
> could easily go either way.
> 
Fixed

>>> 19.)
>>> Section 5
>>>
>>>     Credential Provisioning
>>>        For IoT, it cannot be assumed that the client and RS are part of a
>>>        common key infrastructure, so the AS provisions credentials or
>>>        associated information to allow mutual authentication.  These
>>>        credentials need to be provided to the parties before or during
>>>        the authentication protocol is executed, and may be re-used for
>>>        subsequent token requests.
>>>
>>> nit: either "before or during the execution of the authentication
>>> protocol" or "before or during the authentication protocol's execution".
>>> And just to double-check that we mean the authentication protocol of
>>> provisioning in the last sentence, not the authorization protocol that
>>> occurs between the client and RS.
>>
>> [LS] The whole last sentence was a bit off. I would suggest:
>> "The resulting security association between client and RS may then be
>> re-used
>> by binding these credentials to additional access tokens." Does that
>> sound better?
> 
> That definitely reads more coherently, yes.  It makes implicit the fact
> that there is an authentication protocol that gets run, which is probably
> okay, and I'm not sure whether "additional" is quite in line with the way
> the previous sentence is formulated.  (Maybe it makes more sense in
> context, which I don't have in front of me right now.)
> 

You are right that was still off. Fixed that now.


>>> 39.)
>>>     Refresh tokens are typically not stored as securely as proof-of-
>>>     possession keys in requesting clients.  Proof-of-possession based
>>>     refresh token requests MUST NOT request different proof-of-possession
>>>     keys or different audiences in token requests.  Refresh token
>>>     requests can only use to request access tokens bound to the same
>>>     proof-of-possession key and the same audience as access tokens issued
>>>     in the initial token request.
>>>
>>> This is perhaps something of a philosophical question, but if a refresh
>>> token is only usable at the token endpoint, in some sense its audience
>>> is definitionally the AS.  So there's a little bit of a mismatch in
>>> treating it as having the audience value that the access tokens issued
>>> from it will have.  I don't know the background for audience-restriced
>>> refresh tokens in regular OAuth 2.0, though, so hopefully someone can
>>> educate me.
>>
>> [LS] I'm equally confused. I suggest that Hannes or one of the other OAuth
>> experts give us a hint on that one.
> 
> [We had some stab at this in the other thread, but additional input might
> still be in order]


Let's hear with OAuth people in Singapore.


>>> 58.)
>>>     Profiles MUST specify whether the authz-info endpoint is protected,
>>>     including whether error responses from this endpoint are protected.
>>>     Note that since the token contains information that allow the client
>>>     and the RS to establish a security context in the first place, mutual
>>>     authentication may not be possible at this point.
>>>
>>> We'll need some careful reasoning about this for the security
>>> considerations, since the authz-info transaction can impact what profile
>>> the RS thinks is in use.  E.g., whether a network attacker could
>>> cause the client to think that a different (vulnerable) profile is in
>>> use than the one the RS expects to use.
>>
>> [LS] Noted. Do you think the reasoning in section 6.5 needs to be extended?
> 
> I think we should add some more text, yes.
> Specifically, we should mention that the authz-info interaction can affect
> what profile RS will use (e.g., via "ace_profile"), and that profile
> developers should be conscious of the risk of downgrade attacks that
> involve other profile types.  (Am I reading this right that the client will
> know what profile to use by the time it is ready to post to the authz-info
> endpoint and that the response will not change what profile the client
> uses?  Specifically, even if a client supports multiple profiles that use
> different methods for token transport, a client is not going to try one
> method/profile and then fall back to a different one if the first one
> (transiently) fails?)
> 


I'm not sure how you would mount such a downgrade attack. The client 
receives the profile to use either by implicit configuration or 
explicitly through the "profile" parameter from the AS.
If the client does not receive a "profile" parameter and has no implicit 
profile configured this is an error.

The RS either has the profile pre-configured or receives it via an 
authenticated "profile" claim in the access token (again if the claim is 
missing and no pre-configured profile exists this is an error). Even 
though the token is sent to authz-info over an insecure channel and the 
client is not yet authenticated, the access token itself is, and 
therefore I find it hard to see how an attacker would trick the RS to 
use a different profile.

>>> 65.)
>>>        specification defines the following approach: The claim "exi"
>>>        ("expires in") can be used, to provide the RS with the lifetime of
>>>        the token in seconds from the time the RS first receives the
>>>        token.  This approach is of course vulnerable to malicious clients
>>>        holding back tokens they do not want to expire.  Such an attack
>>>
>>> It also has suboptimal behavior if the RS loses state (e.g., by
>>> rebooting), and possibly requires the RS to store indefinitely all
>>> tokens with an "exi" value.  I have mixed feelings about specifying it
>>> at all, though I concede it probably does have some value.  Regardless,
>>> I think a dedicated subsection in the security considerations is in
>>> order.
>>
>> [LS] We wanted to provide some solution for expiring tokens for RSes
>> that have
>> no connectivity and no synchronized clocks. Using the "exp" claim in
>> such cases
>> would have pretty unpredictable results.
>> I have extended section 6.3 in the security considerations to go into
>> the detail
>> of "exi", please have a look if this covers the necessary issues.
> 
> I think we should also say something about the amount of such persistent
> storage potentially growing without bound, as those counters (or some
> similar indication) are the only thing that will cause the RS to reject
> tokens that have been used the requisite number of times.  So, RS state
> requirements grows with the number of 'exi'-bearing tokens that are issued
> for them.  I suppose a bloom filter might be a way out, though...
> 

I don't see why storage requirements would grow more compared to regular 
tokens with the "exp" claim. The way exi is intended to be implemented 
is as follows:

1. C ---Token(exi=100)---> RS  (internal_clock=54645)
2. RS generates a new 'exp' for the token, sets it to 54745 and discards 
the exi claim.
3. RS expires token according to internal clock (i.e. at 54745)

If you send the RS a lot of tokens it will eventually exhaust its 
memory, but that would happen with regular exp claims as well if the 
attacker can craft/obtain enough tokens with sufficiently long lifetime.
Note that these would have to be tokens for different clients, since the 
framework currently recommends to only store one token per client.

The advantage for the attacker with exi is that it could hold back any 
tokens without having to worry about the expiration, but it would still 
have to hoard enough tokens for different clients, all applicable to the 
RS in order to exhaust the RS's storage.

> 
>>> 68.)
>>>     o  The client performs an introspection of the token.  Although this
>>>        is not explicitly forbidden, how exactly a client does
>>>        introspection is not currently specified for OAuth.
>>>
>>> I'm pretty sure this is overtaken by events (sorry for my part in
>>> that!).  E.g., draft-ietf-oauth-jwt-introspection-response discusses
>>> clients doing introspection, and even RFC 7662 itself discusses using a
>>> client secret to authenticate to the introspection endpoint.  I think
>>> there's another document between those two that's also relevant, but
>>> can't find it right now
>>
>> [LS] I am not so sure. When reading the fine print in both RFC 7662 and
>> draft-ietf-oauth-jwt-introspection-response, I find that when they mention
>> the term "client", they refer to the protected resource / RS as being a
>> client of
>> the AS introspection endpoint.  A client holding an access token and
>> performing introspection is never explicitly mentioned in both
>> documents, to my best
>> knowledge.
> 
> It seems like we should try to check on this in Singapore, while the usual
> suspects are easily at hand.

Yes together with the other OAuth questions.



> 
>>> 78.)
>>> Section 6.1
>>>
>>> I think we should have a little bit more discussion about what attacks
>>> are possible even when a client hard-codes a list of trustworthy ASes,
>>> e.g., when a device in one AS's purview is compromised and tries to get
>>> the client to use a different (possibly also compromised, or maybe just
>>> buggy) AS than the one that's supposed to be responsible for the device
>>> in question.  In short, yes, spoofing is only possible within that set
>>> of trusted ASes, but spoofing can still cause problems.
>>
>> [LS] I have added some text in section 6.4 Please have a look if this
>> covers what you were aiming at.
> 
> That's pretty good, thanks!
> I'd prefer to also have (in the second sentence of the second paragraph) a
> mention about what an AS (in the hard-coded list) would do when receiving
> the incorrect request from the misdirected client, though.
> (Also, nit, s/ redentials/ credentials/)
> 

Done and fixed.

>>> 79.)
>>> Are there any AS parameters other than URI that might be useful for an
>>> out-of-band-configured list of valid values?
>>
>> [LS] One might want to include the public key or certificate of the AS.
>> Do you want us to expand this section to include such parameters?
> 
> I'd consider adding another sentence like "Information used to authenticate
> the AS, such as a public key or certificate fingerprint, might be
> provisioned alongside an AS's URI, depending on the deployment scenario".
> What do you think?
> 

Done

>>> 88.)
>>> Section 8.3
>>>
>>>     Name  The OAuth Error Code name, refers to the name in Section 5.2.
>>>        of [RFC6749], e.g., "invalid_request".
>>>
>>> We should refer to the OAuth registry as the authority on names, not the
>>> immutable RFC.  (Similarly for the other mappings registries; I won't
>>> repeat it each time, though for the later ones we're already doing the
>>> right thing.)
>>
>> [LS] This is interesting. The referenced section (5.2 of RFC6749) is not
>> mirrored in any IANA registry. I have put the question to the OAuth WG.
> 
> IIRC, you filed https://www.rfc-editor.org/errata/eid5873 for this and I
> submitted a registration request at
> https://mailarchive.ietf.org/arch/msg/oauth-ext-review/4WaM6n6JetFsLI6_T9S8wNVqP74
> .  It's been more than two weeks, so I should follow up there...
> 

Ok, I'll wait to hear more.

>>> 97.)
>>> Section 10.1
>>>
>>> We may get some debate about whether IANA registries are properly
>>> Normative of Informative references, but we can wait for that to happen
>>> -- no need to do anything now.
>>
>> [LS] Noted. Does the AD have a position on this?
> 
> I think there's a reasonable argument for keeping them as normative.  We
> probably see them as informative more often (in general), though, probably
> because people are concerned about having downrefs to something that's not
> a standards-track RFC (which would happen due to a misunderstanding of the
> rules surrounding downrefs, IMO).

Ok no action taken at this point.

> 
>>> 98.)
>>> Section 10.2
>>>
>>> If we're using RFC 4949 for terminology definitions, I think that makes
>>> it a normative reference.
>>>
>>> If we REQUIRE CBOR when used with CoAP, that also feels like a normative
>>> reference.
>>>
>>> I also think 7519 needs to be normative, since we mandate some of its
>>> processing rules.
>>
>> [LS] RFC 4949 is informational, so it cannot be normative. I would argue
>> that we are just using it to clarify the meaning of our terminology.
> 
> It's okay to have a normative reference to an informational document; we
> just need to call it out in the IETF LC announcement (which the
> tooling/secretariat should take care of "automagically").
> Furthermore, RFC 4949 is already listed at
> https://datatracker.ietf.org/doc/downref/ as an "acceptable downref", so we
> don't even have to do that, in this case.
> 

Ok I made RFC 4949 normative, I didn't know about the "acceptable 
downref" arrangement with the secretariat.


> 
> 
> If you want to get a new revision up to make these last few changes during
> the blackout period, I'm happy to approve a manual posting by the
> secretariat.  (OTOH, since IETF LCs that overlap with the meeting week get
> extended automatically, it wouldn't necessarily get the document on an IESG
> telechat any sooner.)

I have made a few changes, but there are still some points to discuss. 
If you think the updates still warrant a new submission, I can do a 
submission with manual approval.

/Ludwig


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