Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09
-Original Message- From: Benjamin Kaduk Sent: Thursday, January 9, 2020 1:22 PM To: Jim Schaad Cc: 'Olaf Bergmann' ; draft-ietf-ace-dtls-authorize@ietf.org; ace@ietf.org Subject: Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09 On Thu, Jan 09, 2020 at 12:52:56PM -0800, Jim Schaad wrote: > > > -Original Message- > From: Benjamin Kaduk > Sent: Thursday, January 9, 2020 12:17 PM > To: Olaf Bergmann > Cc: Jim Schaad ; ace@ietf.org; > draft-ietf-ace-dtls-authorize@ietf.org > Subject: Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09 > > On Thu, Jan 09, 2020 at 12:32:40PM +0100, Olaf Bergmann wrote: > > Hi Jim, > > > > Jim Schaad writes: > > > > > -Original Message- > > > From: Ace On Behalf Of Olaf Bergmann > > > Sent: Monday, January 6, 2020 2:03 AM > > > To: Jim Schaad > > > Cc: ace@ietf.org; 'Benjamin Kaduk' ; > > > draft-ietf-ace-dtls-authorize@ietf.org > > > Subject: Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09 > > > > > > Jim, > > > > > > Jim Schaad writes: > > > > > > [Ben's review] > > >> We also are potentially in violation of the framework's > > >> requirements > with respect to the independent selection of profiles for client/AS > and client/RS interactions -- at present, when DTLS+RPK is used for > client/RS, we require that DTLS+RPK is also used for client/AS, in > order to prove possession of the key. We could perhaps weasel our way > out by saying that the framework's requirement applies at the profile > granularity, and with symmetric PSK we can be fully independent, but > we still need to say something about this property and the interaction > with the framework's requirements. > > >> > > >> [JLS] I am missing where it is saying this. Can you give a pointer? > I don't believe that the POP of the RPK is required at the time that > the token is obtained. > > > > > > The problem is that AS must bind the Access Token to the RPK that > > > the > Client has presented, and the Client must use the very same RPK to > establish the DTLS channel with RS. Otherwise, RS cannot be sure that > AS has issued the Token to the same entity that is currently communicating with RS. > > > > > > [JLS] What if I do the following sequence of events: > > > 1. The AS is configured with RPK1 for the client and the client > > > is > configured with RPK2 for the AS. > > > 2. The client and the AS run some type of POP algorithm, not > > > currently > specified, to configure RPK3 into the AS for a second RPK to work with > some set of audiences (AUD1). > > > 3. The client then uses RPK1 to authenticate to the AS and asks > > > for a > new token for AUD1 and provides (explicitly or implicitly RPK3). The > AS knows that it is tied to the client due to what happened in step 2. > The AS then creates a new token for AUD1 which contains RPK3 for the > client (and > RPK4 for the RS) and returns it. > > > > > > The AS does a current POP for RPK1 when the token is being asked for. > > > The AS did a POP for RPK3 when it was placed into the system. > > > The AS has not done a POP for RPK4 - that was simply configured > > > without > that step ever being done. The ACE framework has no ability for the > AS to do the POP on RPK4 and ensure that it current. The client would > do a POP when the TLS session is created but has to rely on the AS > that it is for the correct RS. > > > > > > Note that the client can never generate a brand new RPK9 and send > > > it to > the AS in the token request because the AS will never have seen this > before and would need to run the POP algorithm of step 2 in order to > assure that it is bound to the correct client and not pulled out of > thin air. RPK9 could not be used to authenticate the token request > because the AS has no idea what client it is tied to. > > > > okay, I see you have a valid point here. I will try to come up with > > some text that says that the AS must ensure that (in your scenario) > > RPK1 and > > RPK3 are bound to the same entity. > > Jim's proposal seems broadly reasonable (though I think in general > there needs to be some AS contributory nature in order to get proof of > current possession of RPK3 at the time of (2). I think I would phrase > it as "in possession of the same entity" rather than "bound to the > same entity", though. > > [JLS] If I was to write this out as a real protocol, it would end up > something along the lines of Sign(RPK1, Sign(RPK3, RPK1 || RPK3 || > AS Nonce || Client Nonce )) so that we know that both keys are in the > possession of a single entity (or a cabal collaborating) and it is > current to the run of the POP protocol. With a fixed protocol/context string to indicate the intent of what's being signed, of course :) I am too distracted to do a proper analysis right now but seem to recall that usually an indication of "both parties/keys agree to " involves three signatures, so that each party certifies the
Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09
On Thu, Jan 09, 2020 at 12:52:56PM -0800, Jim Schaad wrote: > > > -Original Message- > From: Benjamin Kaduk > Sent: Thursday, January 9, 2020 12:17 PM > To: Olaf Bergmann > Cc: Jim Schaad ; ace@ietf.org; > draft-ietf-ace-dtls-authorize@ietf.org > Subject: Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09 > > On Thu, Jan 09, 2020 at 12:32:40PM +0100, Olaf Bergmann wrote: > > Hi Jim, > > > > Jim Schaad writes: > > > > > -Original Message- > > > From: Ace On Behalf Of Olaf Bergmann > > > Sent: Monday, January 6, 2020 2:03 AM > > > To: Jim Schaad > > > Cc: ace@ietf.org; 'Benjamin Kaduk' ; > > > draft-ietf-ace-dtls-authorize@ietf.org > > > Subject: Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09 > > > > > > Jim, > > > > > > Jim Schaad writes: > > > > > > [Ben's review] > > >> We also are potentially in violation of the framework's requirements > with respect to the independent selection of profiles for client/AS and > client/RS interactions -- at present, when DTLS+RPK is used for client/RS, > we require that DTLS+RPK is also used for client/AS, in order to prove > possession of the key. We could perhaps weasel our way out by saying that > the framework's requirement applies at the profile granularity, and with > symmetric PSK we can be fully independent, but we still need to say > something about this property and the interaction with the framework's > requirements. > > >> > > >> [JLS] I am missing where it is saying this. Can you give a pointer? > I don't believe that the POP of the RPK is required at the time that the > token is obtained. > > > > > > The problem is that AS must bind the Access Token to the RPK that the > Client has presented, and the Client must use the very same RPK to establish > the DTLS channel with RS. Otherwise, RS cannot be sure that AS has issued > the Token to the same entity that is currently communicating with RS. > > > > > > [JLS] What if I do the following sequence of events: > > > 1. The AS is configured with RPK1 for the client and the client is > configured with RPK2 for the AS. > > > 2. The client and the AS run some type of POP algorithm, not currently > specified, to configure RPK3 into the AS for a second RPK to work with some > set of audiences (AUD1). > > > 3. The client then uses RPK1 to authenticate to the AS and asks for a > new token for AUD1 and provides (explicitly or implicitly RPK3). The AS > knows that it is tied to the client due to what happened in step 2. The AS > then creates a new token for AUD1 which contains RPK3 for the client (and > RPK4 for the RS) and returns it. > > > > > > The AS does a current POP for RPK1 when the token is being asked for. > > > The AS did a POP for RPK3 when it was placed into the system. > > > The AS has not done a POP for RPK4 - that was simply configured without > that step ever being done. The ACE framework has no ability for the AS to > do the POP on RPK4 and ensure that it current. The client would do a POP > when the TLS session is created but has to rely on the AS that it is for the > correct RS. > > > > > > Note that the client can never generate a brand new RPK9 and send it to > the AS in the token request because the AS will never have seen this before > and would need to run the POP algorithm of step 2 in order to assure that it > is bound to the correct client and not pulled out of thin air. RPK9 could > not be used to authenticate the token request because the AS has no idea > what client it is tied to. > > > > okay, I see you have a valid point here. I will try to come up with > > some text that says that the AS must ensure that (in your scenario) > > RPK1 and > > RPK3 are bound to the same entity. > > Jim's proposal seems broadly reasonable (though I think in general there > needs to be some AS contributory nature in order to get proof of current > possession of RPK3 at the time of (2). I think I would phrase it as "in > possession of the same entity" rather than "bound to the same entity", > though. > > [JLS] If I was to write this out as a real protocol, it would end up > something along the lines of Sign(RPK1, Sign(RPK3, RPK1 || RPK3 || AS > Nonce || Client Nonce )) so that we know that both keys are in the > possession of a single entity (or a cabal collaborating) and it is current > to the run of the POP protocol. With a fixed protocol/context string to indicate the intent of what's being signed, of course :) I am too distracted to do a proper analysis right now but seem to recall that usually an indication of "both parties/keys agree to " involves three signatures, so that each party certifies the signature of the other over the operation (in addition to the operation itself). -Ben ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09
-Original Message- From: Benjamin Kaduk Sent: Thursday, January 9, 2020 12:27 PM To: Jim Schaad Cc: draft-ietf-ace-dtls-authorize@ietf.org; ace@ietf.org Subject: Re: AD review of draft-ietf-ace-dtls-authorize-09 On Fri, Jan 03, 2020 at 08:36:54PM -0800, Jim Schaad wrote: > > > -Original Message- > From: Benjamin Kaduk > Sent: Thursday, January 2, 2020 3:40 PM > To: draft-ietf-ace-dtls-authorize@ietf.org > Cc: ace@ietf.org > Subject: AD review of draft-ietf-ace-dtls-authorize-09 > > Hi all, > > Some high-level remarks before delving into the section-by-section > comments: > > This document is pretty clearly DTLS 1.2-specific -- it talks about > particular protocol messages, message fields, and cipher suites that simply > do not apply to DTLS 1.3. In order to use this profile with DTLS 1.3, we'd > need to specify the analogous behavior/requirements to these (including > standalone signature schemes and key-exchange groups, which are now both > separately negotiated from the cipher suite). > Given that DTLS 1.3 is past WGLC and only a few documents behind this one in > my review queue, it seems fairly prudent to spend some time and cover how > DTLS 1.3 would work here, since otherwise this document will become stale > shortly after (or even before!) its publication as an RFC. > > [JLS] Yes we need to look at this, but we also know who's fault this is > Part of me wants to punt this off to the CoRE working group because the way > they are currently using DTLS 1.2 is quite restrictive and they really need > to do a DTLS 1.3 document. I hadn't realized that the CoRE usage of DTLS was so restrictive; in that case we may have to wait for them, yes. [JLS] Yeah, I really ought to start writing this document. The first time I read the DTLS section and realized that when a re-key operation occurred that all of the current state on the server is to be cleared as if a new session had just been negotiated I just about went crazy. They were worried about the security implications on the key roll over which made no sense to me, but then I am much more versed in TLS than they were. > > There's probably some additional discussion to include about the usage of key > identifiers in this document versus the potential uses described in the core > framework. Specifically, the framework reminds us that "no assumptions > should be made that it is unique in the domains of either the client or the > RS" yet this document is using the kid as input to a KDF that produces keys > that must be unique across all clients, and allowing live/instant > authorization updates based on matching "kid". > How shall we resolve this apparent conflict? > > [JLS] I am having a problem seeing what the conflict is here. The "kid" is a > publicly known value so that fact that it is included in the KDF is not what > is going to produce unique keys for all clients no matter what. It is the > secret that is going to make things unique. There is a potential problem > with the fact that the RS may get two different entities that register a > token which has the same kid value, but that is a known issue for (D)TLS. > This is one of the reasons that the token itself can be used as the "kid" for > DTLS. I think I'm just thinking about what you note as the "potential problem" where an RS receives two tokens with the same kid value but that are for different clients. For asymmetric PoP we require POST to authz-info, and since "POST a new token with the same kid" is the way we update permissions without changing DTLS keys, the RS needs to know to scope its lookup/storage based on (client,kid) (or more?) and not just 'kid'. Maybe this is obvious, but I wasn't sure. [JLS] No, "POST a new token with the same KEY" is the way that we update permissions without changing the DTLS keys. For RPK this is easy. For symmetric keys this is a harder sell and you really need to add some additional checks to make it something along the lines of same . There may not be a key id if one is using the token as the user identifier when doing the DTLS protocol so matching on kid would seem to be difficult there. What I was referring to as the potential problem is that if client 1 posts a token with a symmetric key and KID1 and uses KID1 as the user name things are fine. Now if client 2 posts a token with a different symmetric key and KID1. Client 2 can use KID1 as the user name to connect to the server but if client 1 attempts to connect with KID1 as the user name it will fail doing the connection. This is a (D)TLS issue as you cannot do a "retry" easily in TLS 1.2. (Ding, ding, ding, ding. Jim just realizes that TLS 1.3 might have solved this problem with the PSK binder and should do research to find out if this is true.) > We also are potentially in violation of the framework's requirements with > respect to the independent selection of profiles for client/AS and
Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09
-Original Message- From: Benjamin Kaduk Sent: Thursday, January 9, 2020 12:17 PM To: Olaf Bergmann Cc: Jim Schaad ; ace@ietf.org; draft-ietf-ace-dtls-authorize@ietf.org Subject: Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09 On Thu, Jan 09, 2020 at 12:32:40PM +0100, Olaf Bergmann wrote: > Hi Jim, > > Jim Schaad writes: > > > -Original Message- > > From: Ace On Behalf Of Olaf Bergmann > > Sent: Monday, January 6, 2020 2:03 AM > > To: Jim Schaad > > Cc: ace@ietf.org; 'Benjamin Kaduk' ; > > draft-ietf-ace-dtls-authorize@ietf.org > > Subject: Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09 > > > > Jim, > > > > Jim Schaad writes: > > > > [Ben's review] > >> We also are potentially in violation of the framework's requirements with respect to the independent selection of profiles for client/AS and client/RS interactions -- at present, when DTLS+RPK is used for client/RS, we require that DTLS+RPK is also used for client/AS, in order to prove possession of the key. We could perhaps weasel our way out by saying that the framework's requirement applies at the profile granularity, and with symmetric PSK we can be fully independent, but we still need to say something about this property and the interaction with the framework's requirements. > >> > >> [JLS] I am missing where it is saying this. Can you give a pointer? I don't believe that the POP of the RPK is required at the time that the token is obtained. > > > > The problem is that AS must bind the Access Token to the RPK that the Client has presented, and the Client must use the very same RPK to establish the DTLS channel with RS. Otherwise, RS cannot be sure that AS has issued the Token to the same entity that is currently communicating with RS. > > > > [JLS] What if I do the following sequence of events: > > 1. The AS is configured with RPK1 for the client and the client is configured with RPK2 for the AS. > > 2. The client and the AS run some type of POP algorithm, not currently specified, to configure RPK3 into the AS for a second RPK to work with some set of audiences (AUD1). > > 3. The client then uses RPK1 to authenticate to the AS and asks for a new token for AUD1 and provides (explicitly or implicitly RPK3). The AS knows that it is tied to the client due to what happened in step 2. The AS then creates a new token for AUD1 which contains RPK3 for the client (and RPK4 for the RS) and returns it. > > > > The AS does a current POP for RPK1 when the token is being asked for. > > The AS did a POP for RPK3 when it was placed into the system. > > The AS has not done a POP for RPK4 - that was simply configured without that step ever being done. The ACE framework has no ability for the AS to do the POP on RPK4 and ensure that it current. The client would do a POP when the TLS session is created but has to rely on the AS that it is for the correct RS. > > > > Note that the client can never generate a brand new RPK9 and send it to the AS in the token request because the AS will never have seen this before and would need to run the POP algorithm of step 2 in order to assure that it is bound to the correct client and not pulled out of thin air. RPK9 could not be used to authenticate the token request because the AS has no idea what client it is tied to. > > okay, I see you have a valid point here. I will try to come up with > some text that says that the AS must ensure that (in your scenario) > RPK1 and > RPK3 are bound to the same entity. Jim's proposal seems broadly reasonable (though I think in general there needs to be some AS contributory nature in order to get proof of current possession of RPK3 at the time of (2). I think I would phrase it as "in possession of the same entity" rather than "bound to the same entity", though. [JLS] If I was to write this out as a real protocol, it would end up something along the lines of Sign(RPK1, Sign(RPK3, RPK1 || RPK3 || AS Nonce || Client Nonce )) so that we know that both keys are in the possession of a single entity (or a cabal collaborating) and it is current to the run of the POP protocol. Jim -Ben ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09
On Fri, Jan 03, 2020 at 08:36:54PM -0800, Jim Schaad wrote: > > > -Original Message- > From: Benjamin Kaduk > Sent: Thursday, January 2, 2020 3:40 PM > To: draft-ietf-ace-dtls-authorize@ietf.org > Cc: ace@ietf.org > Subject: AD review of draft-ietf-ace-dtls-authorize-09 > > Hi all, > > Some high-level remarks before delving into the section-by-section > comments: > > This document is pretty clearly DTLS 1.2-specific -- it talks about > particular protocol messages, message fields, and cipher suites that simply > do not apply to DTLS 1.3. In order to use this profile with DTLS 1.3, we'd > need to specify the analogous behavior/requirements to these (including > standalone signature schemes and key-exchange groups, which are now both > separately negotiated from the cipher suite). > Given that DTLS 1.3 is past WGLC and only a few documents behind this one in > my review queue, it seems fairly prudent to spend some time and cover how > DTLS 1.3 would work here, since otherwise this document will become stale > shortly after (or even before!) its publication as an RFC. > > [JLS] Yes we need to look at this, but we also know who's fault this is > Part of me wants to punt this off to the CoRE working group because the way > they are currently using DTLS 1.2 is quite restrictive and they really need > to do a DTLS 1.3 document. I hadn't realized that the CoRE usage of DTLS was so restrictive; in that case we may have to wait for them, yes. > > There's probably some additional discussion to include about the usage of key > identifiers in this document versus the potential uses described in the core > framework. Specifically, the framework reminds us that "no assumptions > should be made that it is unique in the domains of either the client or the > RS" yet this document is using the kid as input to a KDF that produces keys > that must be unique across all clients, and allowing live/instant > authorization updates based on matching "kid". > How shall we resolve this apparent conflict? > > [JLS] I am having a problem seeing what the conflict is here. The "kid" is a > publicly known value so that fact that it is included in the KDF is not what > is going to produce unique keys for all clients no matter what. It is the > secret that is going to make things unique. There is a potential problem > with the fact that the RS may get two different entities that register a > token which has the same kid value, but that is a known issue for (D)TLS. > This is one of the reasons that the token itself can be used as the "kid" for > DTLS. I think I'm just thinking about what you note as the "potential problem" where an RS receives two tokens with the same kid value but that are for different clients. For asymmetric PoP we require POST to authz-info, and since "POST a new token with the same kid" is the way we update permissions without changing DTLS keys, the RS needs to know to scope its lookup/storage based on (client,kid) (or more?) and not just 'kid'. Maybe this is obvious, but I wasn't sure. > We also are potentially in violation of the framework's requirements with > respect to the independent selection of profiles for client/AS and client/RS > interactions -- at present, when DTLS+RPK is used for client/RS, we require > that DTLS+RPK is also used for client/AS, in order to prove possession of the > key. We could perhaps weasel our way out by saying that the framework's > requirement applies at the profile granularity, and with symmetric PSK we can > be fully independent, but we still need to say something about this property > and the interaction with the framework's requirements. > > [JLS] I am missing where it is saying this. Can you give a pointer? I > don't believe that the POP of the RPK is required at the time that the token > is obtained. [Olaf got this; thanks Olaf!] > This profile is mostly applicable to the client/RS communications and feels > like it only provides some of the picture for use with client/AS > interactions. (It doesn't really say much of anything about RS/AS > interactions.) The introductory discussion does not do a great job of > painting that picture, and I'd like to see it more clearly introduced that > the bulk of our coverage is for the client/RS interaction. We also lean > heavily on the existing out-of-band configuration and key material shared > between client and AS to secure the client/AS communications; we could > probably tighten up the discussion about exactly what parameters of client/AS > communication are specified by this profile. > > [JLS] I think this makes sense. > > We do not say anything about DTLS session resumption (or renegotiation, > though not talking about that one is perfectly fine); that's a fairly core > DTLS concept that we should give some guidance on. > > [JLS] I don't see any reason to talk about renegotiation, either it is done > or it isn't and a new connection would
Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09
On Thu, Jan 09, 2020 at 12:32:40PM +0100, Olaf Bergmann wrote: > Hi Jim, > > Jim Schaad writes: > > > -Original Message- > > From: Ace On Behalf Of Olaf Bergmann > > Sent: Monday, January 6, 2020 2:03 AM > > To: Jim Schaad > > Cc: ace@ietf.org; 'Benjamin Kaduk' ; > > draft-ietf-ace-dtls-authorize@ietf.org > > Subject: Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09 > > > > Jim, > > > > Jim Schaad writes: > > > > [Ben's review] > >> We also are potentially in violation of the framework's requirements with > >> respect to the independent selection of profiles for client/AS and > >> client/RS interactions -- at present, when DTLS+RPK is used for client/RS, > >> we require that DTLS+RPK is also used for client/AS, in order to prove > >> possession of the key. We could perhaps weasel our way out by saying that > >> the framework's requirement applies at the profile granularity, and with > >> symmetric PSK we can be fully independent, but we still need to say > >> something about this property and the interaction with the framework's > >> requirements. > >> > >> [JLS] I am missing where it is saying this. Can you give a pointer? I > >> don't believe that the POP of the RPK is required at the time that the > >> token is obtained. > > > > The problem is that AS must bind the Access Token to the RPK that the > > Client has presented, and the Client must use the very same RPK to > > establish the DTLS channel with RS. Otherwise, RS cannot be sure that AS > > has issued the Token to the same entity that is currently communicating > > with RS. > > > > [JLS] What if I do the following sequence of events: > > 1. The AS is configured with RPK1 for the client and the client is > > configured with RPK2 for the AS. > > 2. The client and the AS run some type of POP algorithm, not currently > > specified, to configure RPK3 into the AS for a second RPK to work with some > > set of audiences (AUD1). > > 3. The client then uses RPK1 to authenticate to the AS and asks for a new > > token for AUD1 and provides (explicitly or implicitly RPK3). The AS knows > > that it is tied to the client due to what happened in step 2. The AS then > > creates a new token for AUD1 which contains RPK3 for the client (and RPK4 > > for the RS) and returns it. > > > > The AS does a current POP for RPK1 when the token is being asked for. > > The AS did a POP for RPK3 when it was placed into the system. > > The AS has not done a POP for RPK4 - that was simply configured without > > that step ever being done. The ACE framework has no ability for the AS to > > do the POP on RPK4 and ensure that it current. The client would do a POP > > when the TLS session is created but has to rely on the AS that it is for > > the correct RS. > > > > Note that the client can never generate a brand new RPK9 and send it to the > > AS in the token request because the AS will never have seen this before and > > would need to run the POP algorithm of step 2 in order to assure that it is > > bound to the correct client and not pulled out of thin air. RPK9 could not > > be used to authenticate the token request because the AS has no idea what > > client it is tied to. > > okay, I see you have a valid point here. I will try to come up with some > text that says that the AS must ensure that (in your scenario) RPK1 and > RPK3 are bound to the same entity. Jim's proposal seems broadly reasonable (though I think in general there needs to be some AS contributory nature in order to get proof of current possession of RPK3 at the time of (2). I think I would phrase it as "in possession of the same entity" rather than "bound to the same entity", though. -Ben ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09
Hi Jim, Jim Schaad writes: > -Original Message- > From: Ace On Behalf Of Olaf Bergmann > Sent: Monday, January 6, 2020 2:03 AM > To: Jim Schaad > Cc: ace@ietf.org; 'Benjamin Kaduk' ; > draft-ietf-ace-dtls-authorize@ietf.org > Subject: Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09 > > Jim, > > Jim Schaad writes: > > [Ben's review] >> We also are potentially in violation of the framework's requirements with >> respect to the independent selection of profiles for client/AS and client/RS >> interactions -- at present, when DTLS+RPK is used for client/RS, we require >> that DTLS+RPK is also used for client/AS, in order to prove possession of >> the key. We could perhaps weasel our way out by saying that the framework's >> requirement applies at the profile granularity, and with symmetric PSK we >> can be fully independent, but we still need to say something about this >> property and the interaction with the framework's requirements. >> >> [JLS] I am missing where it is saying this. Can you give a pointer? I >> don't believe that the POP of the RPK is required at the time that the token >> is obtained. > > The problem is that AS must bind the Access Token to the RPK that the Client > has presented, and the Client must use the very same RPK to establish the > DTLS channel with RS. Otherwise, RS cannot be sure that AS has issued the > Token to the same entity that is currently communicating with RS. > > [JLS] What if I do the following sequence of events: > 1. The AS is configured with RPK1 for the client and the client is > configured with RPK2 for the AS. > 2. The client and the AS run some type of POP algorithm, not currently > specified, to configure RPK3 into the AS for a second RPK to work with some > set of audiences (AUD1). > 3. The client then uses RPK1 to authenticate to the AS and asks for a new > token for AUD1 and provides (explicitly or implicitly RPK3). The AS knows > that it is tied to the client due to what happened in step 2. The AS then > creates a new token for AUD1 which contains RPK3 for the client (and RPK4 for > the RS) and returns it. > > The AS does a current POP for RPK1 when the token is being asked for. > The AS did a POP for RPK3 when it was placed into the system. > The AS has not done a POP for RPK4 - that was simply configured without that > step ever being done. The ACE framework has no ability for the AS to do the > POP on RPK4 and ensure that it current. The client would do a POP when the > TLS session is created but has to rely on the AS that it is for the correct > RS. > > Note that the client can never generate a brand new RPK9 and send it to the > AS in the token request because the AS will never have seen this before and > would need to run the POP algorithm of step 2 in order to assure that it is > bound to the correct client and not pulled out of thin air. RPK9 could not > be used to authenticate the token request because the AS has no idea what > client it is tied to. okay, I see you have a valid point here. I will try to come up with some text that says that the AS must ensure that (in your scenario) RPK1 and RPK3 are bound to the same entity. Grüße Olaf ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
