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-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).
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
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
