Subject: Re: [Ace] Review of draft-ietf-ace-oauth-authz-06

From: Samuel Erdtman <[email-masked]>
Date: Thu, 28 Sep 2017 11:09:00 +0200

Thanks Jim for a great review.

Here comment a late comment on the .well-known comment

I have done some research and my opinion is to not create .well-known
resources.

When reading up on well-known I can see that two ways of using is has
evolved.
The first one is to have a path under .well-known (e.g. /.well-known/ace)
that returns a set of links to the endpoints defined by the specification.
(When reading the .well-known RFC (RFC5785) this is how I interpret it). In
this case it would be easy to add .well-known support later on (maybe for
both vanilla OAuth and the ACE flavor).

The second solution I have seen is to place yourendpoints under the
.well-known prefix (e.g. /.well-known/ace/token) this is how EST does it
/.well-known/est/simpleenroll, /.well-known/est/cacerts etc. I don’t think
to mandate this solution is a good solution for the simple reason that the
path becomes long and requires several unnecessary bytes.

Looking at the OAuth 2.0 framework I can see that they have not registered
.well-known paths and also phrased the language around endpoints slightly
differently. In the ace framework text we talk about the '/token' endpoint,
the slash gives the reader the impression that this is a specific location
while OAuth talks about the 'token' endpoint i.e. giving the impression
that the path can be anything.

I therefor suggest that we to start with change '/token' to 'token',
'/introspection' to 'introspection' and '/authz-info' to 'authz-info'

//Samuel

On Tue, Aug 8, 2017 at 5:02 PM, Ludwig Seitz <[email-masked]> wrote:

> On 2017-08-07 19:57, Jim Schaad wrote:
>
>
>>>> 3.  Still unhappy about the lack of POP between C and AS.  How does the
>>>>
>>> AS
>>
>>> know that the key it is binding to the token is the right one.  The RS
>>>>
>>> has
>>
>>> no problems, but assumes that the AS did its job.
>>>>
>>>
>>> I'm not sure what problem that would solve. That C binds the token to a
>>> key it doesn't own? What benefit would C have from that?
>>>
>>> If C wants to relay a token to a "friend" it could always share the
>>> pop-key with said friend.
>>>
>>
>> If I can fool C into thinking that my key is it's key, when the process is
>> finished the RS has an access token with the privileges of C, but with my
>> key.  I now can do anything that C would be able to do.  This would only
>> need to be done the first time the AC sees the key as it could keep track
>> that the key is associated with C for later requests.
>>
>>
> Ok, we could fix this by requiring that the key used by C when
> authenticating to AS is the one that is used as PoP key.
>
>
>
>>>> 4.  If I want to use the SCOPES field as defined by Carsten, then I do
>>>>
>>> not
>>
>>> want the current restriction that is being imposed on the scope
>>>>
>>> parameter
>>
>>> in
>>>
>>>> Section 3 (?) Under "Scopes and Permissions".
>>>>
>>>
>>> I'm just reiterating the definition of the scope parameter from the
>>> OAuth spec. I think Carsten's approach can be modified to fit into that
>>> spec.
>>>
>>
>> A sentence that says that other methods of doing scopes is permitted would
>> satisfy my desires.
>>
>
> I would favor a solution that says that scopes are strings by default,
> unless the AS and the RS specifically agree on something else. That way an
> implementation does not have to deal with binary data by default.
>
>
>>>> 7.  In section 5 - Under "ACE Profiles" - RECOMMENDS seems to be an odd
>>>> thing to have here - this is not really a protocol recommendation is it?
>>>> Are we allowing for JSON to be used rather than CBOR?  The text here on
>>>>
>>> what
>>>
>>>> encodings to use could be made more declarative.  Are we expecting any
>>>>
>>> JSON
>>>
>>>> use at this point for any profile define?  If so then a list of
>>>>
>>> tradeoffs
>>
>>> for profile creators and how to detect would be in order rather than the
>>>>
>>> big
>>
>>> RECOMMENDS.
>>>>
>>>
> Yes the intention is to allow profiles to specify JSON (or something
>>> else) as data format instead of CBOR.
>>>
>>
>> If one were to be using JSON why would one not just use OAuth rather than
>> ACE?  If JSON is really going to be a legal option then I think it should
>> be
>> fully fleshed out as part of this document.  Otherwise you might end up
>> with
>> MTI problems.
>>
>
> Sounds reasonable to me, I'll propose that change
>
>
>
>> 10.  Section 5.4 appears to create a new endpoint that has not been
>>>> discussed in other contexts.  Is this intentional?
>>>>
>>>
>>> No that's just an existing OAuth endpoint. Since I've had mostly on
>>> client credentials in mind, this endpoint wasn't discussed that much.
>>>
>>> My impression is that this endpoint would mostly be used by
>>> non-constrained clients (towards the obviously non-constrained AS), and
>>> therefore it wouldn't need an ACE profiling, it could just be used as
>>> specified in OAuth.
>>>
>>
>> You might think about moving the out-of-scope statement closer to the
>> front
>> of the section so that is clearer.
>>
>>
> Ok I will try to clarify this.
>
>
>>>
>>>> 11. Section 5.5.1 - OK - I am reversing thinking.  However I need to get
>>>>
>>> a
>>
>>> summary of what a profile is going to need to specify a long ways before
>>>>
>>> I
>>
>>> get to this point.  Perhaps has part of the overview.
>>>>
>>>
>>> The summary of what a profile needs to specify is collected in Appendix
>>> C currently. This appendix reiterates points that are spread out (in
>>> contextually appropriate places) in the main body of the spec.
>>>
>>
>> You should have an early pointer to this so people know it is there and
>> read
>> it then.
>>
>>
> Done.
>
>
>>>
>>> One of the questions
>>>> is going to be can the C-AS section of one profile be used with the
>>>> C-RS of
>>>> another profile and keep the same security guarantees.  The overview is
>>>> going to need to talk about this at some point.
>>>>
>>>
>>> This seems to be a "it depends" issue. We should have some text on this,
>>> the security considerations seem the right place to me for this.
>>> Creating issue.
>>>
>>
>> I think that this should be part of the "main" text and goes to what St
>> Johns (I think it was him) brought up at the mic where it needs to be
>> clear
>> someplace what the security assumptions/requirements are for each leg of
>> the
>> conversation are that a profile needs to be sure to include.  And how
>> using
>> different profiles might interact.
>>
>>
> Note that in discussion with Hannes today, he came up with the very
> reasonable scenario of  C<->AS with DTLS/CoAP and C<->RS with TLS/MQTT.
>
>
> 12. Section 5.5.1 - I would like to add some additional parameters at
>>>>
>>> this
>>
>>> point.  The first is a RS_Data field which is copied from the RS->C
>>>>
>>> message
>>
>>> verbatim.  It allows for encrypted data to be passed from the RS to the
>>>>
>>> AS
>>
>>> as part of the request.  Data type is COSE_Encrypt.
>>>>
>>>
>>> Are you referring to the "nonce" that can be part of the AS discovery
>>> message?  I'm not sure if that should go in this document or in a
>>> separate draft. What does the group think?
>>>
>>
>> I am referring to more than just the "nonce" value, although that is one
>> such value.  If you look at draft-cuellar-ace-pat-priv-enh
>> anced-authz-tokens
>> in section 4.3, they have a whole set of parameters that are to be
>> transferred from the RS to the AS via C.  One some parameter would be the
>> RS
>> having an idea of what the scope is that needs to be authorized based on
>> the
>> request (thus allowing C not to have to understand scopes).
>>
>
> I would be in favor of moving these things into a separate document. The
> current draft is already quite long, and it doesn't feel like essential
> functionality to me.
>
>
> 13. Section 5.5.1 - I would like to see an AS field documented here so
>>>>
>>> th
>>
>>> that the 4 corner model can work.
>>>>
>>>
>>> Could you be more specific about the "4 corner model"? I'm not familiar
>>> with that.
>>>
>>
>> It is an old term that I learned early on in my career which actually
>> refers
>> to how your credit card is setup to get authorized.  You have four parties
>> one on each corner - Card holder, Card Bank, Merchant bank, Merchant.
>> Looks
>> just the security model from actors if you omit the owners.  This is
>> basically short hand for saying that CAS != AS.
>>
>
> The the 4 corner model would use the CAS as intermediary between C and AS.
> This means on the one hand that the CAS would need some token request
> parameters that indicate for which client it is requesting a token from the
> AS. On the other hand the client could query the CAS just like it queries
> the AS /token endpoint, so I don't see an immediate need for measures on
> that side of the communication.
>
> Since I haven't seen strong industry demands for supporting the CAS so
> far, I'd suggest to move such specifications into a separate document.
>
>
>> 14. Section 5.5.1 - What is the default - use this for "aud"?  How is a
>>>> client supposed to know what to put here for a new RS?
>>>>
>>>
>>> "aud" should contain be the identifier of the RS or a group of RS that
>>> the client wants to access.
>>>
>>> Since the client ought to know which RS it wants to access with the
>>> token, I assumed it would know what to put in this field.
>>>
>>
>> So the answer is [2001::1]?
>>
>
> For example, or just "aud" : "myTemperatureSensors", where the RS and the
> AS have a mapping of which RS correspond to "myTemperateSensors".
>
>
>> 17. Figure 4 - need to check out if client_secret is a real secret or
>>>>
>>> not -
>>
>>> it seems odd to say don't use symmetric and then have an example of
>>>>
>>> passing
>>>
>>>> one. Could be something else as I don't have RFC 6749 w/ me.
>>>>
>>>
>>> True, this method is specified on section 2.3.1. of RFC 6749, so we
>>> thought we'd offer an example.
>>>
>>> I don't think this is a good feature security-wise.
>>>
>>
>> That is for Client Password authorization - This is not going to be
>> something that you ever want to support in this profile.  There are other
>> better ways to deal with a shared secret and you don't want the potential
>> multiple round trips to do http authorization here.
>>
>
> Indeed. I will modify that example to use some other method.
>
>
>> 19. Is there a reason for a client not being able to request a profile
>>>> rather than having it be configured into the AS?
>>>>
>>>
>>> We had that in a previous version and decided it was over-engineered.
>>> The client needs to be registered at the AS anyways, and could then also
>>> specify preferred profiles.
>>>
>>
>> The AS also needs to know the network layout as well since C and RS may
>> not
>> be able to use DTLS if they need to go through a proxy.
>>
>
> These kind of things should be covered implicitly since RS and C are
> registered at the AS together with a list fo the profiles they support. I
> would expect that if either C or RS are deployed on a network that requires
> proxies, DTLS will simply not be a supported profile.
>
>
>> 23. Section 5.5.4.4 - Please define profile as being part of a CWT so
>>>>
>>> that
>>
>>> it can be communicated to the RS in the event that more than one profile
>>>>
>>> is
>>
>>> supported. Optional if RS only does one.
>>>>
>>>
>>> Wouldn't the RS be able to determine the profile from the message it
>>> receives from the Client?
>>>
>>> Say the AS tells the client to use DTLS, the RS would notice receiving a
>>> DTLS handshake. Are there any scenarios where two profiles could be
>>> confused?
>>>
>>
>> Say the AS tells the client to use DTLS.  C then posts the token to
>> /authz-info.  Is this DTLS, OSCOAP, PAT, IPSec?
>>
>
> Why would the RS need to know at that point? When a token is posted to
> /authz-info the only thing the RS needs to do is to make sure that it is
> valid and store it for future use. That does not require knowledge of the
> profile the client is going to use when requesting a resource later.
>
>
> 27. Need to know how to think about the idea of a client doing an
>>>> introspection.  Is the response going to be different than a RS doing
>>>>
>>> the
>>
>>> query?  I assume that the distinction would be based on the
>>>>
>>> authentication
>>
>>> and internal knowledge - does not need to be documented except for
>>>>
>>> response
>>>
>>>> differences.
>>>>
>>>
>>> You mean if a client would do introspection on an access token it
>>> received? Depending on the AS its not sure it would be authorized to do
>>> so (mine has policies for determining who gets to introspect). I believe
>>> this can be left to the implementers. I might be convinced that it needs
>>> a security consideration though (if you insist).We need to specify that
>>>
>> the
>>
>> The first sentence of section 5.6 says that the client can query for the
>> introspection point.  I this is not what is desired then just remove that.
>>
>> If it is desired, then I assume that some of the response elements would
>> be
>> different.  If so then that needs to be documented.
>>
>
> Why would the response elements be different? The response is the claims
> associated to the token subject to introspection. They are the same
> regardless whether the client or the RS asks. It's another question whether
> they are meaningful to the client.
>
>
>> 32. Section 5.6.4 - establish MTI algorithms here?
>>>>
>>>
>>> For encrypting the client token? Is that really necessary? The AS should
>>> know what algorithms the client supports.
>>>
>>
>> That is fine, until I have an AS that only does CCM and a client which
>> only
>> does ChaCha-Poly1305.
>>
>
> I see, but that would be noticed when the client is registered at the AS
> (btw. see Appendix D for a list of assumptions what the AS knows about C
> and RS).
>
>
>> 35. Section 5.7.1 - Why would the RS respond with the cti - given a lack
>>>>
>>> of
>>
>>> text it is not clear when the MAY would be triggered.
>>>>
>>>
>>> It's just a suggestion to the implementer, not really necessary but
>>> useful in some scenarios (e.g. if the client later wants to delete or
>>> overwrite the token this could be good to have).
>>>
>>
>> This is not at all clear or documented.
>>
>
> Ok I'll try to clarify.
>
>
>> 36. Section 5.7.1 - Not sure how much information is being leaked by
>>>>
>>> having
>>
>>> different error codes being returned in these situations.  May only want
>>>>
>>> to
>>
>>> have one code.
>>>>
>>>
>>> This is a difficult one. One the one hand you are right some information
>>> is leaked, but on the other hand, withholding that information makes it
>>> very hard for the client to fix erroneous access tokens.
>>>
>>
>> Should probably have a security consideration on this.
>>
>
> Issue created.
>
>
>> 37.  Section 5.7.1 - under what circumstances is the introspection
>>>>
>>> request
>>
>>> not made?
>>>>
>>>
>>> If the RS is not configured to do so. E.g. if it has intermittent
>>> connectivity and the token is self contained.
>>>
>>
>> That was assumed.  The question is what are you doing in the 3rd to last
>> paragraph where you say the RS MAY introspect.  But does not say anything
>> about when or why.  I would take it as a given that if the token is
>> self-contained then it would never been done.
>>
>
> Why not? Even a self-contained token might be revoked before it expires,
> which would only work with introspection.
>
>
>> 40.  Section 5.7.2 - Another "long running request" might be the case of
>>>> sending back an ACK for a request followed by a 4.01 because the token
>>>> expires before the request has finished processing.  Re-doing
>>>>
>>> introspection
>>
>>> might also cause this sequence of messages
>>>>
>>>>
>>> Do you think it would be useful to give these additional examples?
>>>
>>
>> I am not really happy with how the paragraph is designed.  But no they
>> probably do not help.
>>
>
> Ok I'll try to rephrase then.
>
>
>> 48.  Section 6 - Please explain the reasoning behind the last paragraph.
>>>>
>>> It
>>
>>> does not make a great deal of sense to me.
>>>>
>>>
>>> If you issue an access token bound to a symmetric pop-key that is valid
>>> for a group of RS, then any of these RS that receives the token can use
>>> to towards the other RS, impersonating the client.
>>>
>>> I'll try to clarify the text in the draft (I also noted that the context
>>> to using a symmetric pop key got lost in the second sentence of that
>>> paragraph).
>>>
>>
>> The problem with that statement is that the client is using an asymmetric
>> key pair here.
>>
>
> Right, as I said the context got lost in some rewriting. I'll try to
> rephrase to make it clearer that only symmetric keys are affected (since in
> the symmetric case the RS has the symmetric key and thus can perform the
> PoP itself.
>
>
> By the way, a quick republish to update email addresses might be desirable
>> so that the author list does not send back so many bounces.
>>
>>
>>
> I'll do that.
>
> /Ludwig
>
>
>
> --
> Ludwig Seitz, PhD
> Security Lab, RISE SICS
> Phone +46(0)70-349 92 51
>
> _______________________________________________
> Ace mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ace
>