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 protected]> 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 protected] > https://www.ietf.org/mailman/listinfo/ace >
_______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
