Re: [Ace] draft-ietf-ace-oauth-authz
On 2020-05-05, at 17:39, Jim Schaad wrote: > > I don't see how the four-corner model solves the issue that I highlighted. > If the client does not have a key for any local AS, then nothing helps. The > four-corner model deals with the issue of the client and the RS not trusting > the same AS, but the different AS entities trust each other on the back side. > > Getting trust in a local AS seems to be a bootstrapping problem. If you only have one security domain, there is no benefit. But in general is it much easier to bootstrap a device once into its own security domain, instead of having to do the bootstrapping again and again for each server that device needs to access. Grüße, Carsten > > Jim > > > -Original Message- > From: Carsten Bormann > Sent: Monday, May 4, 2020 10:38 PM > To: Jim Schaad > Cc: Benjamin Kaduk ; Olaf Bergmann ; Peter > van der Stok ; peter van der Stok > ; Ace > Subject: Re: [Ace] draft-ietf-ace-oauth-authz > > On 2020-05-05, at 06:54, Jim Schaad wrote: >> >> I have much the same problem. While a client could find an AS which >> would authenticate the client, I don't know how the client would >> establish any degree of trust in the AS which is going to give it tokens. > > Hence the four-corner model [1]. > > Grüße, Carsten > > [1]: https://tools.ietf.org/html/draft-ietf-ace-actors > ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] draft-ietf-ace-oauth-authz
-Original Message- From: Michael Richardson Sent: Tuesday, May 5, 2020 11:07 AM To: Jim Schaad ; 'Ace' Subject: Re: [Ace] draft-ietf-ace-oauth-authz Jim Schaad wrote: > I have much the same problem. While a client could find an AS which > would authenticate the client, I don't know how the client would > establish any degree of trust in the AS which is going to give it > tokens. Is your question that you don't know how to trust that the AS is the correct AS for RS-foo? [JLS] No, my question is how do I know to trust the AS period. I don't have a key to establish a secure session with the AS. I guess doing full X.509 certificate processing would be an answer, but that could be difficult in the event of a key compromise. > If you have already put a local public key for the AS into the > client, then you might as well put in a name for the AS as well. I > suppose you could get by with a shared secret but that does not seem to > be a good way to build up the system. Maybe there are redundant instances of the AS, or maybe there are multiple ways (thus different IP addresses) by which to reach the AS. [JLS] It could be that there are redundant instances of the AS, but then you have the problem of either doing key sharing between all of them or needing the ability to validate the key assigned to each of them. If you have different addresses, that might be interesting, but you are going to need to do trial connections to each possible AS found until you get one that works. Jim -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] draft-ietf-ace-oauth-authz
Jim Schaad wrote: > I have much the same problem. While a client could find an AS which > would authenticate the client, I don't know how the client would > establish any degree of trust in the AS which is going to give it > tokens. Is your question that you don't know how to trust that the AS is the correct AS for RS-foo? > If you have already put a local public key for the AS into the > client, then you might as well put in a name for the AS as well. I > suppose you could get by with a shared secret but that does not seem to > be a good way to build up the system. Maybe there are redundant instances of the AS, or maybe there are multiple ways (thus different IP addresses) by which to reach the AS. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] Update of access rights
Hi Michael,
On 05/05/2020, 18:01, "Ace on behalf of Michael Richardson"
wrote:
Francesca Palombini
wrote:
> 7. Client wants to update its access rights: retrieves T2 from AS.
Note
> that this T2 has different authorization info, but does not contain
> input keying material ("osc"), only a reference to identify Sec1
("kid"
Is there an assumption that the access rights(T2) >= access rights(T1)?
FP: No. But at the same time if access rights(T2) is a subset of access
rights(T1), then there is no point in the client requesting T2 from the AS...
These could be a disjoint sets of access rights.
> Moreover, while comparing with DTLS profile, we realized there is no
> reason for which 8. should be sent unprotected. In fact, doing so
opens
> up to possible attacks where an old update (token non expired) is
> re-injected to the RS by an adversary:
I agree and I see your point.
Thank you for explaining it so well.
FP: Thank you! I tried to be as clear as possible :)
My question is whether step 8 results in Sec Ctx sec1 being deleted?
Could Client want to keep it alive in the case that T1 and T2 actually do
different things?
FP: As currently defined in the document, yes, Sec1 ends up being deleted as
soon as Sec2 is validated (i.e. a request is correctly decrypted by the
receiving endpoint using Sec2). If T1 and T2 do different things and the client
wants to (and is allowed to - T1 is not expired or revoked for some reason)
keep T1 alive, then we are not in the case of "update of access rights", i.e.
the case where T2 replaces T1. My "Final point" was to cover exactly the case
you mention, where T1 and T2 are used to derive 2 different security contexts,
where the RS does not realize they come from the same Client. It is up to the
AS to make sure that T1 and T2 are disjoints: why would the AS even send 2
different tokens that cover part of or the entire same scope at the same RS to
the same client? By the way, if it is not already in there, I think that that
is another excellent consideration point for the Ace framework.
Thanks,
Francesca
--
] Never tell me the odds! | ipv6 mesh
networks [
] Michael Richardson, Sandelman Software Works|IoT architect
[
] m...@sandelman.ca [
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] draft-ietf-ace-oauth-authz
HI Jim, Agree. That's a new draft then with an rt value for a given upload protocol. Peter Jim Schaad schreef op 2020-05-05 17:43: Thanks Peter, that makes things a lot clearer. However I think that you are not asking for who is an AS, but who is an AS that has a particular interface. It would make more sense to define a new interface identifier for the upload/control protocol rather than just identifying who is an AS. Jim From: Ace On Behalf Of Peter van der Stok Sent: Tuesday, May 5, 2020 12:26 AM To: Benjamin Kaduk Cc: Jim Schaad ; Olaf Bergmann ; 'Ace' Subject: Re: [Ace] draft-ietf-ace-oauth-authz HI all, I agree about the authorization/trust problem. My request concerns something more trivial. Suppose we have this new network with a set of servers, an (AS) (may be more) and a controller. The servers, controller and AS may have used BRSKI to enter the network. The servers will only provide their service when a token has been sent. The AS is completely empty, not aware of the servers or its clients. The controller wants to fill the AS with the necessary information. Both controller and AS have agreed on an initialization protocol, and are equipped with the necessary secrets. (A protocol to be standardized in general, but not my concen here) Now, what IP address does the controller use to start the communication? Typing in the IP address is a possibility, switching off all other devices is another, etc... I hoped that a coap discovery could be used such that the controller learns the IP address of the AS. When several AS servers are present, the controller can access each one of them out till it accesses the AS with the correct credentials. I hope my request has become a bit clearer. Peter Benjamin Kaduk schreef op 2020-05-05 06:09: On Mon, May 04, 2020 at 09:21:06AM +0200, Olaf Bergmann wrote: Hi Peter, Peter van der Stok writes: When I want to access an OCF device I can find its IP address through service discovery (rfc7252 section 7) using an rt-value registered at the IANA core parameters registry. For example, when I want to initialize the AS I have to type in the IP address of the AS. From that moment on keys and certificates can be compared to continue initialization. Using service discovery can automate that process. My request is that authz draft registers an rt-value in core parameters registry for service discovery of the AS, unless a different process has already been established for AS initialization. That is exaclty what originally has been done in section 9 of draft-gerdes-ace-dcaf-authorize [1]. Somehow, this got lost in the process. I think I'm still a little confused as to what good being able to "discover" that the network says something is an AS is, without some prior trust and/or key material for that AS. How would the necessary trust be established as part of such a discovery scheme? Thanks, Ben___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] Update of access rights
Francesca Palombini wrote:
> 7. Client wants to update its access rights: retrieves T2 from AS. Note
> that this T2 has different authorization info, but does not contain
> input keying material ("osc"), only a reference to identify Sec1 ("kid"
Is there an assumption that the access rights(T2) >= access rights(T1)?
> Moreover, while comparing with DTLS profile, we realized there is no
> reason for which 8. should be sent unprotected. In fact, doing so opens
> up to possible attacks where an old update (token non expired) is
> re-injected to the RS by an adversary:
I agree and I see your point.
Thank you for explaining it so well.
My question is whether step 8 results in Sec Ctx sec1 being deleted?
Could Client want to keep it alive in the case that T1 and T2 actually do
different things?
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works|IoT architect [
] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[
signature.asc
Description: PGP signature
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] draft-ietf-ace-oauth-authz
Thanks Peter, that makes things a lot clearer. However I think that you are not asking for who is an AS, but who is an AS that has a particular interface. It would make more sense to define a new interface identifier for the upload/control protocol rather than just identifying who is an AS. Jim From: Ace On Behalf Of Peter van der Stok Sent: Tuesday, May 5, 2020 12:26 AM To: Benjamin Kaduk Cc: Jim Schaad ; Olaf Bergmann ; 'Ace' Subject: Re: [Ace] draft-ietf-ace-oauth-authz HI all, I agree about the authorization/trust problem. My request concerns something more trivial. Suppose we have this new network with a set of servers, an (AS) (may be more) and a controller. The servers, controller and AS may have used BRSKI to enter the network. The servers will only provide their service when a token has been sent. The AS is completely empty, not aware of the servers or its clients. The controller wants to fill the AS with the necessary information. Both controller and AS have agreed on an initialization protocol, and are equipped with the necessary secrets. (A protocol to be standardized in general, but not my concen here) Now, what IP address does the controller use to start the communication? Typing in the IP address is a possibility, switching off all other devices is another, etc... I hoped that a coap discovery could be used such that the controller learns the IP address of the AS. When several AS servers are present, the controller can access each one of them out till it accesses the AS with the correct credentials. I hope my request has become a bit clearer. Peter Benjamin Kaduk schreef op 2020-05-05 06:09: On Mon, May 04, 2020 at 09:21:06AM +0200, Olaf Bergmann wrote: Hi Peter, Peter van der Stok mailto:stokc...@bbhmail.nl> > writes: When I want to access an OCF device I can find its IP address through service discovery (rfc7252 section 7) using an rt-value registered at the IANA core parameters registry. For example, when I want to initialize the AS I have to type in the IP address of the AS. From that moment on keys and certificates can be compared to continue initialization. Using service discovery can automate that process. My request is that authz draft registers an rt-value in core parameters registry for service discovery of the AS, unless a different process has already been established for AS initialization. That is exaclty what originally has been done in section 9 of draft-gerdes-ace-dcaf-authorize [1]. Somehow, this got lost in the process. I think I'm still a little confused as to what good being able to "discover" that the network says something is an AS is, without some prior trust and/or key material for that AS. How would the necessary trust be established as part of such a discovery scheme? Thanks, Ben ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] draft-ietf-ace-oauth-authz
I don't see how the four-corner model solves the issue that I highlighted. If the client does not have a key for any local AS, then nothing helps. The four-corner model deals with the issue of the client and the RS not trusting the same AS, but the different AS entities trust each other on the back side. Getting trust in a local AS seems to be a bootstrapping problem. Jim -Original Message- From: Carsten Bormann Sent: Monday, May 4, 2020 10:38 PM To: Jim Schaad Cc: Benjamin Kaduk ; Olaf Bergmann ; Peter van der Stok ; peter van der Stok ; Ace Subject: Re: [Ace] draft-ietf-ace-oauth-authz On 2020-05-05, at 06:54, Jim Schaad wrote: > > I have much the same problem. While a client could find an AS which > would authenticate the client, I don't know how the client would > establish any degree of trust in the AS which is going to give it tokens. Hence the four-corner model [1]. Grüße, Carsten [1]: https://tools.ietf.org/html/draft-ietf-ace-actors ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] Update of access rights
Hi Ludwig,
What you state is in fact the change proposed below, I'm happy you support
making this change. The reason why it does not work that way already is because
of the way authz-info is defined for the "general" case (exchange of nonces is
necessary, and derivation of sec ctx). The change I am making suggests to
differentiate processing between this general case and the update case, but
doing so without reaching a different endpoint, (which in my opinion would have
been the cleaner solution) might be slightly annoying for implementers, as you
also mention.
Francesca
On 05/05/2020, 16:07, "Seitz Ludwig" wrote:
Hello Francesca,
I have not followed this discussion in detail so excuse me if I missed an
important detail. That said: I cannot understand why you would want to
negotiate a new context in step 8 by sending N1'? At that point you have a
functional OSCORE context established and could just send T2 associated to the
same context Sec1. That is how I assumed it would work, if that is not clear we
need to add text to the profiles to clarify.
It is a bit complicated code-wise to have an endpoint that is accessible
both unprotected and with OSCORE, but I think it is feasible (however not be my
in the ACE-Java codebase, @Marco?).
/Ludwig
-Original Message-
From: Francesca Palombini
Sent: den 5 maj 2020 15:37
To: Ace Wg ; Benjamin Kaduk ; Jim Schaad
Cc: draft-ietf-ace-dtls-author...@ietf.org;
draft-ietf-ace-oscore-prof...@ietf.org
Subject: Update of access rights
Hi Ace chairs, DTLS authors, Ace framework authors, Ben,
TL;DR: we propose some changes on the OSCORE profile for the "update of
access rights" scenario. We have comments for the DTLS profile and the ACE
framework regarding this scenario, and we ask for feedback from ACE OSCORE
implementers and Ace in general.
In an attempt to answer Jim's
(https://protect2.fireeye.com/v1/url?k=17a4fe0f-49044461-17a4be94-86b1886cfa64-00f9c0b2a1a8d8cb=1=8a619c43-1ab6-414f-b576-6511488153e9=https%3A%2F%2Fgithub.com%2Face-wg%2Face-oscore-profile%2Fissues%2F20)
and Ben's
(https://protect2.fireeye.com/v1/url?k=371c3a3f-69bc8051-371c7aa4-86b1886cfa64-9410fc645a865781=1=8a619c43-1ab6-414f-b576-6511488153e9=https%3A%2F%2Fgithub.com%2Face-wg%2Face-oscore-profile%2Fpull%2F30)
review of the OSCORE profile, we have been thinking more about the case of
updating access rights. This has revealed to us authors that something is
missing from the document, and I believe that this part is not explicitly
covered in the DTLS profile either, hence this email.
This is the scenario, and what is currently defined in the OSCORE profile:
1. Client retrieves access token T1 from AS 2. Client posts T1 to RS,
together with nonce N1 3. RS replies with 2.01 and nonce N2 4. Client and RS
derive OSCORE Sec Ctx "Sec1" from T1 ("osc" object), N1, N2 5. Client uses Sec1
to protect its request to RS 6. RS uses Sec1 to verify request. Verification
success => Sec1 is validated and associated with T1 (at the RS)
7. Client wants to update its access rights: retrieves T2 from AS. Note
that this T2 has different authorization info, but does not contain input
keying material ("osc"), only a reference to identify Sec1 ("kid" in "cnf") 8.
Client posts T2 to RS, together with nonce N1'
9. RS replies with 2.01 and nonce N2'
10. Client and RS derive OSCORE Sec Ctx "Sec2" from T1 keying input
material ("osc" object), N1', N2'
11. Client uses Sec2 to protect its request to RS 12. RS uses Sec2 to
verify request. Verification success => Sec2 is validated and associated with
T2 (at the RS) ; T1 is removed ; Sec1 is removed
In the document right now, we are missing the exact description of how in
8. RS identifies that this is an update of access rights for C, aiming at
replacing T1. We propose to add text stating that (in 3. and 9.) RS MUST check
the kid (in the "kid" in the "cnf" of the access token), and match it with
existing security contexts, to realize that this is an update for an existing
token associated to the sec ctx identified by kid.
Moreover, while comparing with DTLS profile, we realized there is no reason
for which 8. should be sent unprotected. In fact, doing so opens up to possible
attacks where an old update (token non expired) is re-injected to the RS by an
adversary:
* Client sends T1 to RS --> accepted
* Client sends update of access rights T2 --> accepted
* Client sends update of access rights T3 --> accepted
* Malicious node re-sends T2 --> accepted
Of course that could be mitigated with expiration times and with checking
"issued at time" field (which is optional). But we believe even though these
are good points (which might actually be worth adding to the framework),
sending the token to the RS over the existing protected channel solves this
issue. So we propose that 8. is protected with OSCORE and Sec
Re: [Ace] Update of access rights
Hello Francesca,
I have not followed this discussion in detail so excuse me if I missed an
important detail. That said: I cannot understand why you would want to
negotiate a new context in step 8 by sending N1'? At that point you have a
functional OSCORE context established and could just send T2 associated to the
same context Sec1. That is how I assumed it would work, if that is not clear we
need to add text to the profiles to clarify.
It is a bit complicated code-wise to have an endpoint that is accessible both
unprotected and with OSCORE, but I think it is feasible (however not be my in
the ACE-Java codebase, @Marco?).
/Ludwig
-Original Message-
From: Francesca Palombini
Sent: den 5 maj 2020 15:37
To: Ace Wg ; Benjamin Kaduk ; Jim Schaad
Cc: draft-ietf-ace-dtls-author...@ietf.org;
draft-ietf-ace-oscore-prof...@ietf.org
Subject: Update of access rights
Hi Ace chairs, DTLS authors, Ace framework authors, Ben,
TL;DR: we propose some changes on the OSCORE profile for the "update of access
rights" scenario. We have comments for the DTLS profile and the ACE framework
regarding this scenario, and we ask for feedback from ACE OSCORE implementers
and Ace in general.
In an attempt to answer Jim's
(https://github.com/ace-wg/ace-oscore-profile/issues/20) and Ben's
(https://github.com/ace-wg/ace-oscore-profile/pull/30) review of the OSCORE
profile, we have been thinking more about the case of updating access rights.
This has revealed to us authors that something is missing from the document,
and I believe that this part is not explicitly covered in the DTLS profile
either, hence this email.
This is the scenario, and what is currently defined in the OSCORE profile:
1. Client retrieves access token T1 from AS 2. Client posts T1 to RS, together
with nonce N1 3. RS replies with 2.01 and nonce N2 4. Client and RS derive
OSCORE Sec Ctx "Sec1" from T1 ("osc" object), N1, N2 5. Client uses Sec1 to
protect its request to RS 6. RS uses Sec1 to verify request. Verification
success => Sec1 is validated and associated with T1 (at the RS)
7. Client wants to update its access rights: retrieves T2 from AS. Note that
this T2 has different authorization info, but does not contain input keying
material ("osc"), only a reference to identify Sec1 ("kid" in "cnf") 8. Client
posts T2 to RS, together with nonce N1'
9. RS replies with 2.01 and nonce N2'
10. Client and RS derive OSCORE Sec Ctx "Sec2" from T1 keying input material
("osc" object), N1', N2'
11. Client uses Sec2 to protect its request to RS 12. RS uses Sec2 to verify
request. Verification success => Sec2 is validated and associated with T2 (at
the RS) ; T1 is removed ; Sec1 is removed
In the document right now, we are missing the exact description of how in 8. RS
identifies that this is an update of access rights for C, aiming at replacing
T1. We propose to add text stating that (in 3. and 9.) RS MUST check the kid
(in the "kid" in the "cnf" of the access token), and match it with existing
security contexts, to realize that this is an update for an existing token
associated to the sec ctx identified by kid.
Moreover, while comparing with DTLS profile, we realized there is no reason for
which 8. should be sent unprotected. In fact, doing so opens up to possible
attacks where an old update (token non expired) is re-injected to the RS by an
adversary:
* Client sends T1 to RS --> accepted
* Client sends update of access rights T2 --> accepted
* Client sends update of access rights T3 --> accepted
* Malicious node re-sends T2 --> accepted
Of course that could be mitigated with expiration times and with checking
"issued at time" field (which is optional). But we believe even though these
are good points (which might actually be worth adding to the framework),
sending the token to the RS over the existing protected channel solves this
issue. So we propose that 8. is protected with OSCORE and Sec Ctx Sec1. For
DTLS authors: I believe Jim has extrapolated from your document that that is
the case for the DTLS profile already, i.e. POST token to RS for update of
access rights is over DTLS; I think it would be worth explicitly stating that
in the DTLS profile.
Additionally, analogously to DTLS where the same channel is kept even if access
rights are updated, I do not see any reason at this point to have the endpoints
re-derive a new security context. This is the biggest change I propose, and can
be summarized by replacing the points above as follows:
7. Client wants to update its access rights: retrieves T2 from AS. Note that
this T2 has different authorization info, but does not contain input keying
material, only a reference to identify Sec1 8. Client posts T2 to RS, *without
nonce* *protected with Sec1* 9. RS *verifies that this is an update of access
right, replacing T1 (associated with Sec1) ; Sec1 is associated with T2; T1 is
removed *; RS replies with 2.01 *without nonce* *protected with Sec1* 10.
[Ace] Update of access rights
Hi Ace chairs, DTLS authors, Ace framework authors, Ben,
TL;DR: we propose some changes on the OSCORE profile for the "update of access
rights" scenario. We have comments for the DTLS profile and the ACE framework
regarding this scenario, and we ask for feedback from ACE OSCORE implementers
and Ace in general.
In an attempt to answer Jim's
(https://github.com/ace-wg/ace-oscore-profile/issues/20) and Ben's
(https://github.com/ace-wg/ace-oscore-profile/pull/30) review of the OSCORE
profile, we have been thinking more about the case of updating access rights.
This has revealed to us authors that something is missing from the document,
and I believe that this part is not explicitly covered in the DTLS profile
either, hence this email.
This is the scenario, and what is currently defined in the OSCORE profile:
1. Client retrieves access token T1 from AS
2. Client posts T1 to RS, together with nonce N1
3. RS replies with 2.01 and nonce N2
4. Client and RS derive OSCORE Sec Ctx "Sec1" from T1 ("osc" object), N1, N2
5. Client uses Sec1 to protect its request to RS
6. RS uses Sec1 to verify request. Verification success => Sec1 is validated
and associated with T1 (at the RS)
7. Client wants to update its access rights: retrieves T2 from AS. Note that
this T2 has different authorization info, but does not contain input keying
material ("osc"), only a reference to identify Sec1 ("kid" in "cnf")
8. Client posts T2 to RS, together with nonce N1'
9. RS replies with 2.01 and nonce N2'
10. Client and RS derive OSCORE Sec Ctx "Sec2" from T1 keying input material
("osc" object), N1', N2'
11. Client uses Sec2 to protect its request to RS
12. RS uses Sec2 to verify request. Verification success => Sec2 is validated
and associated with T2 (at the RS) ; T1 is removed ; Sec1 is removed
In the document right now, we are missing the exact description of how in 8. RS
identifies that this is an update of access rights for C, aiming at replacing
T1. We propose to add text stating that (in 3. and 9.) RS MUST check the kid
(in the "kid" in the "cnf" of the access token), and match it with existing
security contexts, to realize that this is an update for an existing token
associated to the sec ctx identified by kid.
Moreover, while comparing with DTLS profile, we realized there is no reason for
which 8. should be sent unprotected. In fact, doing so opens up to possible
attacks where an old update (token non expired) is re-injected to the RS by an
adversary:
* Client sends T1 to RS --> accepted
* Client sends update of access rights T2 --> accepted
* Client sends update of access rights T3 --> accepted
* Malicious node re-sends T2 --> accepted
Of course that could be mitigated with expiration times and with checking
"issued at time" field (which is optional). But we believe even though these
are good points (which might actually be worth adding to the framework),
sending the token to the RS over the existing protected channel solves this
issue. So we propose that 8. is protected with OSCORE and Sec Ctx Sec1. For
DTLS authors: I believe Jim has extrapolated from your document that that is
the case for the DTLS profile already, i.e. POST token to RS for update of
access rights is over DTLS; I think it would be worth explicitly stating that
in the DTLS profile.
Additionally, analogously to DTLS where the same channel is kept even if access
rights are updated, I do not see any reason at this point to have the endpoints
re-derive a new security context. This is the biggest change I propose, and can
be summarized by replacing the points above as follows:
7. Client wants to update its access rights: retrieves T2 from AS. Note that
this T2 has different authorization info, but does not contain input keying
material, only a reference to identify Sec1
8. Client posts T2 to RS, *without nonce* *protected with Sec1*
9. RS *verifies that this is an update of access right, replacing T1
(associated with Sec1) ; Sec1 is associated with T2; T1 is removed *; RS
replies with 2.01 *without nonce* *protected with Sec1*
10. Client uses *Sec1* to protect its request to RS
I can already see the objection from implementers: the authz-info endpoint at
the RS becomes accessible both unprotected (in case the Client is posting a
token for the first time, points 1. to 6.) and protected (in case Client needs
to update rights, points 7. to 10.) I believe that defining a NEW endpoint at
the RS for the "update rights" mechanism would be the best solution, but I
understand that would require modifications to the framework that Ludwig
probably would not want to do, as it might delay the document. I think these
would in practice be 2 different endpoints with the same URI, one OSCORE
protected and one unprotected. But I need more input from our implementers to
know if this absolutely cannot be done.
Our proposal:
An RS receiving a token (point 2 and 8) MUST check the kid of the token against
existing security
Re: [Ace] draft-ietf-ace-oauth-authz
HI all, I agree about the authorization/trust problem. My request concerns something more trivial. Suppose we have this new network with a set of servers, an (AS) (may be more) and a controller. The servers, controller and AS may have used BRSKI to enter the network. The servers will only provide their service when a token has been sent. The AS is completely empty, not aware of the servers or its clients. The controller wants to fill the AS with the necessary information. Both controller and AS have agreed on an initialization protocol, and are equipped with the necessary secrets. (A protocol to be standardized in general, but not my concen here) Now, what IP address does the controller use to start the communication? Typing in the IP address is a possibility, switching off all other devices is another, etc... I hoped that a coap discovery could be used such that the controller learns the IP address of the AS. When several AS servers are present, the controller can access each one of them out till it accesses the AS with the correct credentials. I hope my request has become a bit clearer. Peter Benjamin Kaduk schreef op 2020-05-05 06:09: On Mon, May 04, 2020 at 09:21:06AM +0200, Olaf Bergmann wrote: Hi Peter, Peter van der Stok writes: When I want to access an OCF device I can find its IP address through service discovery (rfc7252 section 7) using an rt-value registered at the IANA core parameters registry. For example, when I want to initialize the AS I have to type in the IP address of the AS. From that moment on keys and certificates can be compared to continue initialization. Using service discovery can automate that process. My request is that authz draft registers an rt-value in core parameters registry for service discovery of the AS, unless a different process has already been established for AS initialization. That is exaclty what originally has been done in section 9 of draft-gerdes-ace-dcaf-authorize [1]. Somehow, this got lost in the process. I think I'm still a little confused as to what good being able to "discover" that the network says something is an AS is, without some prior trust and/or key material for that AS. How would the necessary trust be established as part of such a discovery scheme? Thanks, Ben___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
