Responses in line, I have trimmed things which did not seem to need a response.
Jim > -----Original Message----- > From: Ace [mailto:[email protected]] On Behalf Of Ludwig Seitz > Sent: Monday, August 7, 2017 6:04 AM > To: [email protected] > Subject: Re: [Ace] Review of draft-ietf-ace-oauth-authz-06 > > On 2017-08-04 23:41, Jim Schaad wrote: > > As promised I finally got finished with this review. > > Thank you for your very thorough review Jim. Comments inline (note that > there are a few questions as well). > > /Ludwig > > > > > > 1. Need to decide if /token, /introspect and /authz-info are under > > /.well-defined or not. If they are then this needs to be noted and > > there needs to be an IANA action if this has not already been done for > OAuth. > > I've added an issue to our issue tracker on this. However I would think that > this is something that would need to apply to OAuth as well. I would agree that it makes sense to have OAuth deal with this issue as well. It is probably less of an issue for /token if the client always gets this from the RS and does not try to find it on its own. The /authz-info point is probably more significant. Be sure to catch Olaf's comment on using a resource type as another way to identify this. > > > > 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. > > > > 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. > > > > 7. In section 4 - 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. > > You mean section 5 right? Yes - this should have been section 5. > > 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. > > 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. > > > > > 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. > > > > 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. > > 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-enhanced-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). > > 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. > > 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]? > > 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. > > 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. > > 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? > > Look @ section 3.3. RFC 6749 about scopes > > That look more like a note to self to me, right? Yes this was a note to self. > > > > > 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. > > 30. Section 5.6.4 - I think this is a required item if introspection is > > going to be able to return a random symmetric key. Not needed otherwise. > > It could also be used to inform the client about the RS's public key for > authentication. True - either way I support having this. > > 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. > > 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. > > 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. > > 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. > > > If the introspection request is done async how is the client > > token communicated back to the client? Would that be done as part of a > > later access. Seems to be dicey. > > It's not designed to be done async. We should mention that. Issue created. > > > 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. > > 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. > > For now I skipped IANA considerations and the appendixes. > > > Noted, those are probably bound to change a bit when we extract cnf. >From previous comments, looks like I should think about reading the appendixes though. 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. > > > Let me know if you would prefer that I place these items into the issue list > > on github or if you prefer doing it. > > > > Jim > > > > I'm creating issues as I go, thanks for the offer. > > > > -- > 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
