Subject: Re: [Ace] Fwd: New Version Notification for draft-ietf-ace-oauth-authz-17.txt and draft-ietf-ace-oauth-params-01.txt

From: Stefanie Gerdes <[email-masked]>
Date: Tue, 11 Dec 2018 13:11:29 +0100

Hi,

I looked through the document again. Many issues have been fixed, but I
still have some comments:

I still think that Section 5.8.1, in particular 5.8.1.1 should point out
that RS must check the integrity of the token und validate that it stems
from an authorized AS. Checking the iss field does not help in this case
and I don't see much value in this check; cryptographic assurance such
as AS' signature or MAC of the token is required to ascertain the
authenticity, and in this case the issuer, of the token.

5.8.1. exiting -> existing

Section 5.8.1. states that RS must check that the expiration time given
in the exp field is in the future. This is difficult if the RS is not
time synchronized. Option 3 in section 5.8.3 seems to suggest that this
field is not always required. Instead of demanding that the exp field is
checked the document should demand that the RS somehow validates that
the token is not expired. Checking the exp field may be one example.

C may receive keying material for the communication with RS from AS.
Unfortunately, the AS does not inform C how long the keying material is
valid. C therefore may use outdated keying material for the
communication. C cannot rely on RS to reject messages that were sent
with outdated keying material because 1. the information in the request
sent by C may be confidential and is then compromised and 2. C cannot be
sure that it is actually communicating with the intended RS if the
keying material is no longer valid.

I did not find any indication how the client knows how to choose the
correct req_aud for RS. The document must point out that C may
communicate with the wrong RS unless C and AS have a common
understanding how RS is identified.

Viele Grüße
Steffi

---

From: Jim Schaad <[email-masked]>
Date: Tue, 11 Dec 2018 12:38:32 -0800

> -----Original Message-----
> From: Ace <[email-masked]> On Behalf Of Stefanie Gerdes
> Sent: Tuesday, December 11, 2018 4:11 AM
> To: Ludwig Seitz <[email-masked]>; [email-masked]
> Subject: Re: [Ace] Fwd: New Version Notification for
draft-ietf-ace-oauth-authz-
> 17.txt and draft-ietf-ace-oauth-params-01.txt
> 
> Hi,
> 
still
> have some comments:
that RS must
> check the integrity of the token und validate that it stems from an
authorized
> AS. Checking the iss field does not help in this case and I don't see much
value
> in this check; cryptographic assurance such as AS' signature or MAC of the
> token is required to ascertain the authenticity, and in this case the
issuer, of the
> token.

I would agree with this.  I have never been sure why the 'iss' field is
going to be useful.  The only place that I can see this would be an AS which
is using one key but two identities.  I would argue that this is a situation
that is prone to configuration errors and incorrect security.

> Section 5.8.1. states that RS must check that the expiration time given in
the
> exp field is in the future. This is difficult if the RS is not time
synchronized.
> Option 3 in section 5.8.3 seems to suggest that this field is not always
required.
> Instead of demanding that the exp field is checked the document should
> demand that the RS somehow validates that the token is not expired.
Checking
> the exp field may be one example.
> 
valid. C
> therefore may use outdated keying material for the communication. C cannot
> rely on RS to reject messages that were sent with outdated keying material
> because 1. the information in the request sent by C may be confidential
and is
> then compromised and 2. C cannot be sure that it is actually communicating
> with the intended RS if the keying material is no longer valid.

Would you feel that this would be eased by requiring the expires_in field to
be required as part of the response?  It is the expiration of the token, but
I have never understood the difference between the expiration of the token
and the expiration of keying material myself.  Keying material never
expires, you just cannot use it without a valid token.

> I did not find any indication how the client knows how to choose the
correct
> req_aud for RS. The document must point out that C may communicate with
> the wrong RS unless C and AS have a common understanding how RS is
> identified.

Scope is also something that the client does not know how to build.  

Jim

> 
> Viele Grüße
> Steffi
> 
> _______________________________________________
> Ace mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ace

---

From: Ludwig Seitz <[email-masked]>
Date: Wed, 12 Dec 2018 10:09:39 +0100

On 28/11/2018 18:06, Jim Schaad wrote:
> Ludwig,
> 
> It looks good.  A couple of additional things that have occurred to me.
> (Always a problem when on reads drafts again and again.)
> 
> 1.  I don't really have a problem with figure 6, but I don't know if we want
> to more correctly reflect what an OSCORE message would look like in this
> location.  This would basically be a re-write of the entire example
> structure to reflect that you have an outer and an inner CoAP message.  It
> might be confusing for people who are not fully immersed in the OSCORE
> world.

As far as the example goes, we would need to add an OSCORE option, I 
wouldn't want to expand the encrypted payload to reflect the full OSCORE 
structure, since that is likely going to be more confusing than helpful.

> 
> 2.  I have no idea of where this would go and it is perhaps something that
> the OAuth people need to think about as well.  If an AS receives a request
> which has message level security (OSCORE/CWT/JWT) over a session level
> security connection (TLS/DTLS/IPSEC) are there any rules/suggestions about
> which keys should be used for evaluating the resulting request.  While I
> assume that message security wins and the session security is ignored, I
> have not seen this anyplace.
> 

Good point. I would think that message level security would prevail, but 
that would need to be specified in a profile.

> 3. In section 5.8.1 - It says that for a CWT access token that the
> application/cwt content type MUST be used.  There are two possible issues
> with this.  1) How does the client know what the type of the token is.  It
> could be a CWT, an introspection token, or something else entirely.  2)  Is
> it an error if a CWT token is received and the content type is not present?
> 

Right, the token is supposed to be opaque to the client. I will remove 
that requirement.

/Ludwig

-- 
Ludwig Seitz, PhD
Security Lab, RISE
Phone +46(0)70-349 92 51

---

From: Stefanie Gerdes <[email-masked]>
Date: Wed, 12 Dec 2018 10:27:43 +0100

Hi Jim,

thank you for your quick response.

> expires, you just cannot use it without a valid token.

As long as it is clear that the expires_in field describes the time
until the keying material expires, this is at least better than nothing,
although it leaves the problem that the client does not know when the
token was created and how much time has already passed since then.

The ACE framework should also point out that a client must check if its
keying material for RS is still valid before it makes a request.

BTW, I don't think keying material should be valid forever, especially
if there is no useful revocation mechanism.

> Scope is also something that the client does not know how to build.  

In the worst case, a wrong scope can only prevent a client from
accessing a certain resource. Even if the client does not specify any
scope, the AS can still grant it permissions. If they are broad enough,
they will likely cover the resource that C wants to access.
A wrong req_aud however may cause the client to communicate with the
wrong RS. Even worse, C will not be able to notice that it communicates
with the wrong RS. This is a serious security risk. Currently, the ACE
framework does not even acknowledge that such a risk exists.

Viele Grüße
Steffi

---

From: Stefanie Gerdes <[email-masked]>
Date: Wed, 12 Dec 2018 10:33:48 +0100

Hi again,

I have one additional comment to ace-oauth-17:

Section 5.8.1 recommends that RS stores only one token per key and that
existing tokens are overwritten by new tokens. I wonder how the RS knows
which token is the most recent. I don't think the expiration time helps
in this case because it should be possible for the AS to
provide a token that expires earlier than the previous token.

Viele Grüße
Steffi

---

From: Ludwig Seitz <[email-masked]>
Date: Wed, 12 Dec 2018 10:47:20 +0100

> that is prone to configuration errors and incorrect security.

The value of checking the iss field is indeed limited, but if present I 
feel it MUST be checked.

The text does say that the RS must check the integrity of the token (see 
5.8.1.1.)

"Since the cryptographic wrapper of the token (e.g. a COSE message) 
could include encryption, it needs to be verified first, based on shared 
cryptographic material with recognized AS."

This implies that the RS must check that the AS is recognized, I will 
rephrase this to clarify that "recognized" means that the AS is 
authorized to issue tokens for the RS.

>> 5.8.1. exiting -> existing
Fixed.

>> exp field is in the future. This is difficult if the RS is not time

Indeed, but in those cases one wouldn't use the exp claim in the first 
place. I will add some text to the assumptions on AS knowledge about C 
and RS to the effect that the AS should know if the RS can manage 
synchronized time.

>> Option 3 in section 5.8.3 seems to suggest that this field is not always
Indeed no claim is specifically required in the framework.

>> the exp field may be one example.
The document demands that exp is checked _if present_.
I don't like to normatively require something that is not concrete such 
as "somehow validate that the token is not expired". If we define other 
ways than exp and exi, then normative requirements should be placed in 
the documents that define those.

> expires, you just cannot use it without a valid token.

Well you have several cases of keying material here:

a.) A symmetric pop-key bound to one or more tokens. That will only be 
valid as long as there is a valid token.

b.) An asymmetric key belonging to either client of RS, which may be 
bound to a token, or used to authenticate (e.g. in a DTLS-RPK 
handshake). Those are valid independently of the ACE framework and need 
to be managed, updated and expired by some other mechanisms.

c.) A symmetric key shared between C-AS or RS-AS for authentication 
purposes. ACE has no mechanisms for managing and updating this kind of 
keys. Starting to look into this looks lite a rat-hole to me.

Does any of you feel we should document this in the framework? I'm 
currently leaning towards no, but could be convinced otherwise.

> Scope is also something that the client does not know how to build.

Learning the correct req_aud and scope is out of scope (no pun intended) 
for ACE. This would either be part of the configuration of a client, or 
a client could look it up in some resource directory.
I'll add the note about needing to have a common understanding about how 
RS's are identified.

/Ludwig

-- 
Ludwig Seitz, PhD
Security Lab, RISE
Phone +46(0)70-349 92 51

---

From: Ludwig Seitz <[email-masked]>
Date: Wed, 12 Dec 2018 11:04:20 +0100

> if there is no useful revocation mechanism.

Note that expires_in (exi) is currently defined as "expires in x seconds 
from the time at which the RS first saw the token".

I am aware that this is quite weak since malicious clients can hoard 
tokens that would be valid indefinitely. I do not currently see any 
other means of expiration when the RS has no connectivity to the AS and 
no synchronized clock. I would be open for suggestions if you have 
better ideas.

> with the wrong RS. This is a serious security risk.  > Currently, the ACE
We do acknowledge that, in the security considerations of 
draft-ietf-ace-oauth-params where req_aud is defined. I'll add 
additional clarification to that text though, since it currently only 
talks about the needing to RS know which audiences it recognizes.

-- 
Ludwig Seitz, PhD
Security Lab, RISE
Phone +46(0)70-349 92 51

---

From: Ludwig Seitz <[email-masked]>
Date: Wed, 12 Dec 2018 11:05:43 +0100

> provide a token that expires earlier than the previous token.

"Recent" here is meant as "most recently received". That is something 
the RS definitely can track.

/Ludwig

-- 
Ludwig Seitz, PhD
Security Lab, RISE
Phone +46(0)70-349 92 51

---

From: Stefanie Gerdes <[email-masked]>
Date: Wed, 12 Dec 2018 11:16:57 +0100

Hi Ludwig,

> the RS definitely can track.

The token most recently received by RS is not necessarily the newest.
A client may (accidentally or not) send the older token later than the
newer token.

Viele Grüße
Steffi

---

From: Jim Schaad <[email-masked]>
Date: Wed, 12 Dec 2018 11:16:29 -0800

> Sent: Wednesday, December 12, 2018 2:17 AM
> To: [email-masked]
> Subject: Re: [Ace] Overwriting Tokens
> 
> Hi Ludwig,
> 
> >> Section 5.8.1 recommends that RS stores only one token per key and
> >> that existing tokens are overwritten by new tokens. I wonder how the
> >> RS knows which token is the most recent. I don't think the expiration
> >> time helps in this case because it should be possible for the AS to
newer
> token.

And as you stated above, the older token may have a longer expiration than
the newer because of a different set of permissions.  I think that having
the RS use the most recently received token is probably the best strategy
for an RS that I only going to keep one token.   The client will know which
token is tagged to what original request if it is keeping more than one
token itself.  If it is must immediately posting tokens as it goes along,
then the AS could provide an older, but still valid, token on the next
request.

Jim

---

From: Stefanie Gerdes <[email-masked]>
Date: Thu, 13 Dec 2018 15:42:12 +0100

Hi Ludwig,

> authorized to issue tokens for the RS.

I cannot find the term "integrity" in section 5.8.1.1. Encryption is not
the same as integrity protection. Also, providing a "cryptographic
wrapper" for the token seems to be optional, which means that RS does
not necessarily check the authenticity of the token. The RS must check
that the token stems from an authorized AS, otherwise anyone can issue a
token to RS.

BTW, "shared cryptographic material with recognized AS" implies that
only symmetric solutions can be used between RS and AS. Is that what you
intend here?

The current text to the iss field implies that this field somehow helps
RS to determine the origin of the token, but this is not the case.
Anyone can write an authorized issuer into an issuer field. Authenticity
can only be achieved with cryptographic measures.

> the documents that define those.

So you say that the exp field is optional. And the exi field is
optional. If they are missing, the RS does not check if the token is
still valid and may use outdated tokens. For the security of the
solution it is required that the RS checks if the token is still valid.
You should point out this requirement to achieve a secure solution.

> keys. Starting to look into this looks lite a rat-hole to me.

I am currently only referring to the keying material that AS provides to
C, i.e., the symmetric key shared between C and RS or, if asymmetric
keys are used, RS's RPK. Since it is clear to you that symmetric keys
are only valid as long as the token, you should point that out in the
document. C then has at least some clue how long the token is valid.
Which is better than nothing.

In the RPK case, the AS may be the one that provides C with RS's RPK.
RPKs do not contain semantic information. Therefore, C must be able
assume that the RPK is valid as long as the access token.

As I said, the framework must also state that the client must check if
its keying material is still valid each time before it sends a request
to the RS. Otherwise the confidentiality of the request data may be
breached.

Viele Grüße
Steffi

---

From: Ludwig Seitz <[email-masked]>
Date: Thu, 13 Dec 2018 17:14:30 +0100

On 13/12/2018 15:42, Stefanie Gerdes wrote:
> the same as integrity protection. 

"Cryptograpic wrapper" can include integrity protection.

The reason encryption is specifically mentioned here is that you have to 
process the crypto wrapper first, before doing any checks on the claims, 
since they could be encrypted. I have tried to rephrase this in the 
editor's version to clarify.

(Side note: Basically you would want to do it the other way around, 
since it is much less resource consuming to verify the claims compared 
to verifying the crypto wrapper. Thus if you could discard a token due 
to some issue with the claims without having to check the crypto you 
would save some energy and time. Sadly since the token could be 
encrypted you cannot do it in that order)

> Also, providing a "cryptographic

In OAuth you have different types of tokens, CWTs and JWTs typically 
have a cryptographic wrapper (but see section 6 of RFC 7519), but a 
token could just as well only be a random identifier, that the RS has to 
perform introspection on to learn the associated claims. Such a 
"reference token" would not have a cryptographic wrapper.

> only symmetric solutions can be used between RS and AS. Is that what you

Not really, "shared cryptographic material" could be public keys that 
the AS and RS have shared with each other.

> can only be achieved with cryptographic measures.
I agree that the iss claim is not really useful to authenticate the 
issuer, however if it is present in the token the RS should process it. 
The text I wrote was not intended to imply that it helps with anything:

"The issuer claim must identify an AS that has the authority to issue 
access tokens for the receiving RS. If that is not the case the RS MUST 
respond with a response code equivalent to the CoAP code 4.01 
(Unauthorized)."

This text is just instructions on how to process the claim.

The authenticity of the issuer would either be verified by the the 
cryptographic wrapper or by introspection.

(Side note: If an RS gets a "reference token" it would implicitly verify 
the authenticity of the issuer by doing introspection at the AS that is 
authorized to issue tokens for it).

> still valid and may use outdated tokens.

No if both fields are missing, the token is valid indefinitely, until 
explicitly revoked.

> For the security of the

Yes but the RS can only do this based on the claims associated to the 
token. Certain profiles may require certain sets of claims to be in the 
token (e.g. aud, scope, exp/exi), but putting such requirements in the 
framework would be quite a big divergence from OAuth.

> Which is better than nothing.

How would that give C a clue? There is no metadata associated to 
proof-of-possession keys that would tell C how long they are valid. Are 
you proposing we define such meta-data?

If symmetric pop-keys are created for an access token, what point would 
there be to give them another lifetime than the token? Do you really 
think we need to write that out.

> to the RS. Otherwise the confidentiality of the request data may be

How are you proposing this should be done? There is no metadata 
associated to pop keys that would enable the client to do this.
This would require some mechanisms outside of ACE.

/Ludwig

-- 
Ludwig Seitz, PhD
Security Lab, RISE
Phone +46(0)70-349 92 51

---

From: Stefanie Gerdes <[email-masked]>
Date: Fri, 14 Dec 2018 16:14:43 +0100

Hi all,

as I understand the current proposal of the ACE framework, an attacker
can send an access token to the RS that only contains a scope and is not
signed or otherwise protected. Section 5.8.1.1 (titled verifying an
access token) does not state that RS must check the authenticity of the
token, therefore RS can accept it. Since the token does not contain an
exp field, it is infinitely valid. The attacker thus gains infinite
unconditional access. Is this really what we want from a security framework?

I would expect section 5.8.1.1 to provide information if and when RS
must check that the token stems from an authorized AS to prevent this
scenario.

Viele Grüße
Steffi

---

From: Stefanie Gerdes <[email-masked]>
Date: Fri, 14 Dec 2018 16:16:18 +0100

Hi Ludwig,

> think we need to write that out.

I really think you should point out that symmetric keying material that
the AS provides to the client is valid as long as the token.

I also think that the client must be able to assume that RS' RPK that C
receives from AS is also valid as long as the token, unless C has
additional information.

The access information optionally can contain an expires_in field. It
would help to prevent security breaches under the following conditions:
1. the keying material is valid as long as the ticket, 2. the expires_in
field is present in the access information that AS sends to C, 3. the
client checks the expires_in field when it gets the access information
from the AS, and 4. the client checks if the keying material is still
valid each time before it sends a request to RS.

Without these steps, the confidentiality of the request data that C
sends to RS may be breached, and C may communicate with the wrong RS
using outdated keying material.

Viele Grüße
Steffi

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 14 Dec 2018 16:18:16 +0000

Hi Steffi,

I anticipate that the use of tokens with IoT devices works similar to OAuth deployments today. As such, if you distribute self-contained tokens then you sign or mac them.
We have registered the necessary claims already, which includes the expiry. As such, I expect it to be used as well.

If we forgot to mention explicitly that we follow the best current practices in OAuth then we should add that reference. I will check the text...

Ciao
Hannes

-----Original Message-----
From: Ace <[email-masked]> On Behalf Of Stefanie Gerdes
Sent: Freitag, 14. Dezember 2018 16:15
To: Ludwig Seitz <[email-masked]>; Jim Schaad <[email-masked]>; [email-masked]
Subject: [Ace] Token (In)Security

Hi all,

as I understand the current proposal of the ACE framework, an attacker can send an access token to the RS that only contains a scope and is not signed or otherwise protected. Section 5.8.1.1 (titled verifying an access token) does not state that RS must check the authenticity of the token, therefore RS can accept it. Since the token does not contain an exp field, it is infinitely valid. The attacker thus gains infinite unconditional access. Is this really what we want from a security framework?

I would expect section 5.8.1.1 to provide information if and when RS must check that the token stems from an authorized AS to prevent this scenario.

Viele Grüße
Steffi

_______________________________________________
Ace mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ace
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 15 Dec 2018 14:58:18 +0000

Hi Steffi

I checked the text and the text is indeed confusing.

I have made an attempt to update it to address your comment. Here is the pull request:
https://github.com/ace-wg/ace-oauth/pull/168

Let me know if you think I captured everything properly.

Ciao
Hannes

-----Original Message-----
From: Ace <[email-masked]> On Behalf Of Hannes Tschofenig
Sent: Freitag, 14. Dezember 2018 17:18
To: Stefanie Gerdes <[email-masked]>; Ludwig Seitz <[email-masked]>; Jim Schaad <[email-masked]>; [email-masked]
Subject: Re: [Ace] Token (In)Security

Hi Steffi,

Ciao
Hannes

-----Original Message-----
From: Ace <[email-masked]> On Behalf Of Stefanie Gerdes
Sent: Freitag, 14. Dezember 2018 16:15
To: Ludwig Seitz <[email-masked]>; Jim Schaad <[email-masked]>; [email-masked]
Subject: [Ace] Token (In)Security

Hi all,

Viele Grüße
Steffi

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 15 Dec 2018 15:04:14 +0000

Hi Steffi,

~snip~

> I really think you should point out that symmetric keying material that the AS provides to the client is valid as long as the token.

I think that's a useful recommendation. I do, however, believe that we are not making the same assumption for an asymmetric key bound to the token.

> I also think that the client must be able to assume that RS' RPK that C receives from AS is also valid as long as the token, unless C has additional information.

I would think that it is rather unlikely that the RS will change its public/private key pair so quickly. Right?

> The access information optionally can contain an expires_in field. It would help to prevent security breaches under the following conditions:
1. the keying material is valid as long as the ticket, 2. the expires_in field is present in the access information that AS sends to C, 3. the client checks the expires_in field when it gets the access information from the AS, and 4. the client checks if the keying material is still valid each time before it sends a request to RS.

These checks make sense to me.

> Without these steps, the confidentiality of the request data that C sends to RS may be breached, and C may communicate with the wrong RS using outdated keying material.

Not sure how you came to this conclusion. Why is the request sent by the C to the RS revealed to an attacker when the token expires?

Ciao
Hannes

Viele Grüße
Steffi

---

From: Ludwig Seitz <[email-masked]>
Date: Tue, 18 Dec 2018 09:21:19 +0100

> Let me know if you think I captured everything properly.

I agree that your text improves the "verification" section.

I'm holding off with merging in order to wait for Steffi's confirmation 
that it addresses her comments.

/Ludwig

-- 
Ludwig Seitz, PhD
Security Lab, RISE
Phone +46(0)70-349 92 51

---

From: Ludwig Seitz <[email-masked]>
Date: Tue, 18 Dec 2018 09:27:27 +0100

On 15/12/2018 16:04, Hannes Tschofenig wrote:
> Hi Steffi,
> 
> ~snip~
> 
>> I really think you should point out that symmetric keying material
>> that the AS provides to the client is valid as long as the token.
> 
> I think that's a useful recommendation. I do, however, believe that
> we are not making the same assumption for an asymmetric key bound to
> the token.
> 

Ok, I'll add text to the draft that says this.

Note that this can be trouble if a client asks the AS to bind an 
existing symmetric pop-key to another (new) token it is requesting.
Which one of the two tokens bound to that key is now steering the 
expiration of the key?

>> I also think that the client must be able to assume that RS' RPK
>> that C receives from AS is also valid as long as the token, unless
>> C has additional information.
> 
> I would think that it is rather unlikely that the RS will change its
> public/private key pair so quickly. Right?
> 

Agree with Hannes here. RPKs wouldn't typically be changed that fast.

>> The access information optionally can contain an expires_in field.
>> It would help to prevent security breaches under the following
>> conditions:
> 1. the keying material is valid as long as the ticket, 2. the
> expires_in field is present in the access information that AS sends
> to C, 3. the client checks the expires_in field when it gets the
> access information from the AS, and 4. the client checks if the
> keying material is still valid each time before it sends a request to
> RS.
> 
Are you proposing we make the expires_in field mandatory? If so, why 
isn't it mandatory already in OAuth (currently only RECOMMENDED)?

/Ludwig

-- 
Ludwig Seitz, PhD
Security Lab, RISE
Phone +46(0)70-349 92 51

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 18 Dec 2018 08:47:17 +0000

Hi Ludwig,

A few remarks inline:

-----Original Message-----
From: Ludwig Seitz <[email-masked]>
Sent: Dienstag, 18. Dezember 2018 09:27
To: Hannes Tschofenig <[email-masked]>; Stefanie Gerdes <[email-masked]>; Jim Schaad <[email-masked]>; [email-masked]
Subject: Re: [Ace] Security of the Communication Between C and RS

On 15/12/2018 16:04, Hannes Tschofenig wrote:
> I think that's a useful recommendation. I do, however, believe that we
> are not making the same assumption for an asymmetric key bound to the
> token.
>

Note that this can be trouble if a client asks the AS to bind an existing symmetric pop-key to another (new) token it is requesting.
Which one of the two tokens bound to that key is now steering the expiration of the key?

[Hannes] Normally, the client would only request a symmetric PoP token from the AS and the AS would create the symmetric key and return the PoP token + the symmetric key.
Hence, in the normal case this shouldn't be happen.

> expires_in field is present in the access information that AS sends to
> C, 3. the client checks the expires_in field when it gets the access
> information from the AS, and 4. the client checks if the keying
> material is still valid each time before it sends a request to RS.
>
Are you proposing we make the expires_in field mandatory? If so, why isn't it mandatory already in OAuth (currently only RECOMMENDED)?

[Hannes] I would do the check when the field is actually there. However, it is a good question why it is not mandatory in OAuth. Let me drop a mail to the list.

Ciao
Hannes

/Ludwig

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 18 Dec 2018 13:51:43 +0000

Hi Steffi, Hi Ludwig,

~snip~

Now that I got a response from the OAuth working group (in the sense that I was thinking about the claims in the access token rather than the parameters in the response from the AS) I think checking the expires_in field has to be optional since
* the expires_in parameter is optional, and
* it only has an advisory nature.

It is useful to send the parameter so that the client can determine when to request a new access token (for example, via the refresh token) but it is not absolutely necessary for the protocol operation.

Ciao
Hannes

---

From: Ludwig Seitz <[email-masked]>
Date: Tue, 18 Dec 2018 15:38:34 +0100

On 18/12/2018 14:51, Hannes Tschofenig wrote:
> Hi Steffi, Hi Ludwig,
> 
> ~snip~
> 
>>> The access information optionally can contain an expires_in
>>> field. It would help to prevent security breaches under the
>>> following conditions:
>> keying material is still valid each time before it sends a request
>> to RS.
>> 
> [Hannes] I would do the check when the field is actually there.
> However, it is a good question why it is not mandatory in OAuth. Let
> me drop a mail to the list.
> 
> 
> Now that I got a response from the OAuth working group (in the sense
> that I was thinking about the claims in the access token rather than
> the parameters in the response from the AS) I think checking the
> expires_in field has to be optional since * the expires_in parameter
> is optional, and * it only has an advisory nature.
> 
> It is useful to send the parameter so that the client can determine
> when to request a new access token (for example, via the refresh
> token) but it is not absolutely necessary for the protocol
> operation.
> 
> Ciao Hannes

Hannes,

Steffi's point was (and remains) that if we don't give the client a way 
to determine whether the token is not expired (except for client 
introspection), it might use an expired token and old keys to 
communicate with the RS.
The argument if I understood Steffi correctly is that the client's 
request may contain sensitive data (think a POST/PUT with some 
significant payload) and that sending it to an RS with outdated keys 
might be a risk.

My take would be that in cases where this is relevant, one would specify 
a profile where the expires_in parameter is mandatory. Furthermore we 
should add text to the security considerations describing the issue.

/Ludwig

-- 
Ludwig Seitz, PhD
Security Lab, RISE
Phone +46(0)70-349 92 51

---

From: Stefanie Gerdes <[email-masked]>
Date: Tue, 18 Dec 2018 15:46:39 +0100

Hi Hannes,

> It is useful to send the parameter so that the client can determine when to request a new access token (for example, via the refresh token) but it is not absolutely necessary for the protocol opera…

In OAuth, the expires_in field is usually used to inform the client how
long the access token is valid. If the client uses the access token in a
request after the token expired, the RS will reject the request, which
usually is not a big problem for the client.

In ACE, AS provides the client with keying material for the RS, which is
a completely different situation. If the client does not know how long
the keying material is valid, it may use outdated keying material to
communicate with RS. The expires_in field can be used to inform the
client how long the keying material for RS is valid, if the keying
material is valid as long as the access token.

The main reason to change keying material from time to time is to avoid
that it is compromised. I therefore think that it is necessary for the
security of the solution that C knows how long the keying material is
supposed to be valid.

Viele Grüße
Steffi

---

From: Stefanie Gerdes <[email-masked]>
Date: Tue, 18 Dec 2018 15:47:52 +0100

Hi Hannes,

> I would think that it is rather unlikely that the RS will change its public/private key pair so quickly. Right?

I don't really know what you mean with "quickly". Access tokens may be
valid for a long time, depending on the application scenario. Also, RS
may already have its RPK for a while at the time when AS generates the
access token. RPKs do not contain semantic information and C may not
have additional information about the RPK. Therefore, C must be able to
assume that the RS' RPK is valid as long as the access token.

> Not sure how you came to this conclusion. Why is the request sent by the C to the RS revealed to an attacker when the token expires?

I did not refer to the token, but to the keying material for RS that AS
provides to C. If it is outdated, it may have been compromised.

Viele Grüße
Steffi

---

From: Stefanie Gerdes <[email-masked]>
Date: Tue, 18 Dec 2018 15:48:45 +0100

Hi Hannes,

I think the text is much better now. Protecting the integrity of
self-contained tokens is not sufficient, however. The RS must not only
ascertain that the token is integrity-protected but also validate its
authenticity, i.e., that it stems from an authorized AS.

Viele Grüße
Steffi

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 18 Dec 2018 15:26:00 +0000

Hi Steffi,

> In OAuth, the expires_in field is usually used to inform the client how long the access token is valid. If the client uses the access token in a request after the token expired, the RS will reject the request, which usually is not a big problem for the client.

> In ACE, AS provides the client with keying material for the RS, which is a completely different situation. If the client does not know how long the keying material is valid, it may use outdated keying material to communicate with RS. The expires_in field can be used to inform the client how long the keying material for RS is valid, if the keying material is valid as long as the access token.

> The main reason to change keying material from time to time is to avoid that it is compromised. I therefore think that it is necessary for the security of the solution that C knows how long the keying material is supposed to be valid.

If a client uses either an old key or an old token then the request will fail. I don't see much difference here between OAuth and ACE.

Adding a note to recommend the use of the expires_in field appears still useful to me.

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 18 Dec 2018 15:32:42 +0000

Hi Steffi,

> I don't really know what you mean with "quickly". Access tokens may be valid for a long time, depending on the application scenario. Also, RS may already have its RPK for a while at the time when AS generates the access token. RPKs do not contain semantic information and C may not have additional information about the RPK. Therefore, C must be able to assume that the RS' RPK is valid as long as the access token.

>From an AS point of view it would make sense to make sure they hand out information to client that actually works. If the token is still valid while the information about the RPK of the RS isn't then there may indeed be a failure case.
This isn't too bad since the client will then (hopefully) contact the AS again to get a new access token.

We could nevertheless add a note saying that the operator of the AS needs to consider these cases and that the client should contact the AS again in an error situation.

Ciao
Hannes

---

From: Stefanie Gerdes <[email-masked]>
Date: Wed, 19 Dec 2018 12:26:13 +0100

Hi Hannes,

> If a client uses either an old key or an old token then the request will fail. I don't see much difference here between OAuth and ACE.

The difference is that C cannot authenticate RS with an outdated key.
And even if the correct RS rejects the request, the confidentiality of
the request may already have been breached, i.e., the damage is already
done. C therefore must know how long the keying material is valid.

Viele Grüße
Steffi

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 19 Dec 2018 11:36:11 +0000

Hi Steffi,

Are you focused on token expiry or the case where a token + symmetric key has been leaked?

Is the threat you are describing the case where the client uses DTLS/TLS with the RS (potentially long after a token has been presented), or the case where the client contacts the RS and presents a token?

Ciao
Hannes

-----Original Message-----
From: Stefanie Gerdes <[email-masked]>
Sent: Mittwoch, 19. Dezember 2018 12:26
To: Hannes Tschofenig <[email-masked]>; Ludwig Seitz <[email-masked]>; Jim Schaad <[email-masked]>; [email-masked]
Subject: Re: [Ace] Security of the Communication Between C and RS

Hi Hannes,

The difference is that C cannot authenticate RS with an outdated key.
And even if the correct RS rejects the request, the confidentiality of the request may already have been breached, i.e., the damage is already done. C therefore must know how long the keying material is valid.

Viele Grüße
Steffi

---

From: Stefanie Gerdes <[email-masked]>
Date: Wed, 19 Dec 2018 12:46:24 +0100

Hi Hannes,

> Are you focused on token expiry or the case where a token + symmetric key has been leaked?

I am talking about the expiry of the keying material for RS that AS
provides to C.

> Is the threat you are describing the case where the client uses DTLS/TLS with the RS (potentially long after a token has been presented), or the case where the client contacts the RS and presents a…

I am worried about cases where the client communicates securely with RS,
e.g., using DTLS/TLS or object security, not about presenting the token
to RS.

Viele Grüße
Steffi

---

From: Ludwig Seitz <[email-masked]>
Date: Wed, 19 Dec 2018 13:21:48 +0100

> e.g., using DTLS/TLS or object security, not about presenting the token

The scenario Steffi is thinking of is this (if I understood correctly):

1.) C obtains token and pop-key from AS
2.) C transmits token to RS and sets up secure communication (e.g. 
DTLS-PSK) using the pop-key
3.) C sends secure requests to the RS
4.) token expires, an attacker manages to get hold of the pop-key
5.) C continues to send requests containing sensitive information to the 
RS , attacker can now read the messages and spoof positive responses 
from the RS. C never notices that the token is invalid and that it is 
actually talking to the attacker.

A reasonable way to prevent this is to give the client a way to 
determine whether a token has been revoked or is expired.
This former can be done through some form of client introspection, the 
latter can be achieved with the expires_in parameter.

/Ludwig

-- 
Ludwig Seitz, PhD
Security Lab, RISE
Phone +46(0)70-349 92 51

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 19 Dec 2018 13:04:51 +0000

Thanks, Ludwig. The list of steps below help me to understand the concern.

----

5.) C continues to send requests containing sensitive information to the RS , attacker can now read the messages and spoof positive responses from the RS. C never notices that the token is invalid and that it is actually talking to the attacker.

----

In step (4) you tie the expiry of the token to the attacker getting hold of the key. What happens if the attacker gets hold of the pop key before the token expires?
Additionally, if you use DTLS/TLS just having the PoP key still requires the attacker to run a new DTLS/TLS handshake with the RS.
It would also be useful to know where the attacker got the PoP key from and how you can even detect the compromise.

Additionally, there is the question why the RS wouldn't stop communicating if the token expired since it has that information. Normally, the idea is that the RS has a protected resource and the client wants to access it. That's why the RS is asking the client to send a token that gives it access.

Ciao
Hannes

---

From: Ludwig Seitz <[email-masked]>
Date: Wed, 19 Dec 2018 14:23:51 +0100

> ----
> 
> In step (4) you tie the expiry of the token to the attacker getting
> hold of the key. What happens if the attacker gets hold of the pop
> key before the token expires?

If it is detected the AS would revoke the token. Then the client _could_ 
use client introspection to get that information. Note that this is what 
the CMU people are looking at.

> Additionally, if you use DTLS/TLS just
> having the PoP key still requires the attacker to run a new DTLS/TLS
> handshake with the RS.

If the pop-key was used as a basis for doing a DTLS-PSK handshake, the 
attacker should be able to hijack the connection and impersonate either 
party.

> It would also be useful to know where the
> attacker got the PoP key from and how you can even detect the
> compromise.

That is a different story entirely. You could imagine the case of an RS 
improperly deleting an expired token and the associated pop-key, and 
then being subject to a physical attack that recovers that information.

> 
> Additionally, there is the question why the RS wouldn't stop
> communicating if the token expired since it has that information.

The RS would indeed stop, but since the token is opaque to the client, 
it has no way of knowing that the token has expired, and our clever 
attacker is using the pop-key to impersonate the RS and maintain the 
illusion that the connection is still alive an running.

> Normally, the idea is that the RS has a protected resource and the
> client wants to access it. That's why the RS is asking the client to
> send a token that gives it access.
>

Yes but say e.g. that the RS is a message broker and the client is a 
publisher, writing sensitive data to the RS.

I think Steffi's point definitely warrants text in the security 
considerations, outlining how a client could detect that a token has 
expired.

/Ludwig

-- 
Ludwig Seitz, PhD
Security Lab, RISE
Phone +46(0)70-349 92 51

---

From: Jim Schaad <[email-masked]>
Date: Wed, 19 Dec 2018 12:22:32 -0800

> Sent: Wednesday, December 19, 2018 5:24 AM
> To: Hannes Tschofenig <[email-masked]>; Stefanie Gerdes
> <[email-masked]>; Jim Schaad <[email-masked]>; [email-masked]
> > 5.) C continues to send requests containing sensitive information to the RS ,
> attacker can now read the messages and spoof positive responses from the RS.
> C never notices that the token is invalid and that it is actually talking to the
> attacker.
> >
> 
> > ----
> >
> > hold of the key. What happens if the attacker gets hold of the pop key
> > before the token expires?
> 
> If it is detected the AS would revoke the token. Then the client _could_ use
> client introspection to get that information. Note that this is what the CMU
> people are looking at.

I am having a real problem with the idea that we are going to start adding the idea of revocation to the entire system.   I would much rather make sure that both sides are given an idea of when things are going to expire and just make things expire relatively quickly.

> 
> > Additionally, if you use DTLS/TLS just having the PoP key still
> > requires the attacker to run a new DTLS/TLS handshake with the RS.
> 
> If the pop-key was used as a basis for doing a DTLS-PSK handshake, the attacker
> should be able to hijack the connection and impersonate either party.

This depends on the version of PSK that you are doing.  If you use PSK+ECDH then the attacker cannot hijack the connection.

> 
> 
> > It would also be useful to know where the attacker got the PoP key
> > from and how you can even detect the compromise.
> 
> improperly deleting an expired token and the associated pop-key, and then
> being subject to a physical attack that recovers that information.

It would be more reasonable to say that if you are doing a physical attack, then it would be easy to get an RPK and then you are the RS until such a time as the AS is told that the key is no longer trusted.  In this case you will just continue getting tokens as a client which are still valid and none of this is helpful in any event.

Jim

> The RS would indeed stop, but since the token is opaque to the client, it has no
> way of knowing that the token has expired, and our clever attacker is using the
> pop-key to impersonate the RS and maintain the illusion that the connection is
> still alive an running.
> 
> Yes but say e.g. that the RS is a message broker and the client is a publisher,
> writing sensitive data to the RS.
> 
>

---

From: Ludwig Seitz <[email-masked]>
Date: Thu, 20 Dec 2018 08:40:11 +0100

On 19/12/2018 21:22, Jim Schaad wrote:

>>> In step (4) you tie the expiry of the token to the attacker
>>> getting hold of the key. What happens if the attacker gets hold
>>> of the pop key before the token expires?
>> 
>> If it is detected the AS would revoke the token. Then the client
>> _could_ use client introspection to get that information. Note that
>> this is what the CMU people are looking at.
> 
> I am having a real problem with the idea that we are going to start
> adding the idea of revocation to the entire system.   I would much
> rather make sure that both sides are given an idea of when things are
> going to expire and just make things expire relatively quickly.
> 

It's quite unlike the revocation in PKI, it's just that an AS can mark a 
token as invalid, and this information would then be available to those 
who can do introspection.

>> If the pop-key was used as a basis for doing a DTLS-PSK handshake,
>> the attacker should be able to hijack the connection and
>> impersonate either party.
> 
> This depends on the version of PSK that you are doing.  If you use
> PSK+ECDH then the attacker cannot hijack the connection.
>

Right of course. I suspect however that not all constrained devices 
would implement the PSK+ECDH handshake, or are the other PSK handshakes 
deprecated?

>> 
>>> It would also be useful to know where the attacker got the PoP
>>> key from and how you can even detect the compromise.
>> 
>> That is a different story entirely. You could imagine the case of
>> an RS improperly deleting an expired token and the associated
>> pop-key, and then being subject to a physical attack that recovers
>> that information.
> 
> It would be more reasonable to say that if you are doing a physical
> attack, then it would be easy to get an RPK and then you are the RS
> until such a time as the AS is told that the key is no longer
> trusted.  In this case you will just continue getting tokens as a
> client which are still valid and none of this is helpful in any
> event.

Ok my example was perhaps not ideal, since it has an even bigger breach 
as precondition. So under what conditions would an attacker get access 
to a pop-key of an expired token? Steffi any ideas?

/Ludwig

-- 
Ludwig Seitz, PhD
Security Lab, RISE
Phone +46(0)70-349 92 51

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 20 Dec 2018 09:11:24 +0000

Hi Ludwig, Hi Jim

A few remarks below:

-----Original Message-----
From: Ludwig Seitz <[email-masked]>
Sent: Donnerstag, 20. Dezember 2018 08:40
To: Jim Schaad <[email-masked]>; Hannes Tschofenig <[email-masked]>; 'Stefanie Gerdes' <[email-masked]>; [email-masked]
Subject: Re: [Ace] Security of the Communication Between C and RS

On 19/12/2018 21:22, Jim Schaad wrote:

> going to expire and just make things expire relatively quickly.

It's quite unlike the revocation in PKI, it's just that an AS can mark a token as invalid, and this information would then be available to those who can do introspection.

[Hannes] I see revocation and expiry of credentials as two somewhat different concepts.
In OAuth, we have a spec that deals with a limited form of revocation but the best mitigation IMHO is to issue "short-lived" tokens (short lived in the context of the given application domain). The token introspection interface also provides additional capabilities for real-time checking the status of a token. Finally, it is worth mentioning the SecEvents work here as well.

In practice it is difficult to revoke tokens in a timely fashion since you have to find out that there has been a leakage in the first place, which (as media reports indicate) often takes months if not years for companies to notice.

Regarding expiry of the token, we have the ability for the AS to tell the client as well as the RS how long the token is valid. Do we want to mandate it? Even if I don't see the harm in not providing the info to the client I am saying "why not". I am just not sure whether mandatorily sending the expired_in parameter to the client will help to prevent any attacks.

>> the attacker should be able to hijack the connection and impersonate
>> either party.
>

Right of course. I suspect however that not all constrained devices would implement the PSK+ECDH handshake, or are the other PSK handshakes deprecated?

[Hannes] It really depends what assumptions you make about how the attacker managed to get access to the PoP key in the first place, which we haven't really gone into any level of detail.
From my experience (as I mentioned to John  Mattsson in his DTLS/TLS vs. OSCORE performance analysis) use of PSK+ECDH(E) is rather unlikely since you are essentially dumping the positive effects of the PSK-based mechanism while maintaining all the negative aspects of the long-term PSK credential.

>> That is a different story entirely. You could imagine the case of an
>> RS improperly deleting an expired token and the associated pop-key,
>> and then being subject to a physical attack that recovers that
>> information.
>
> until such a time as the AS is told that the key is no longer trusted.
> In this case you will just continue getting tokens as a client which
> are still valid and none of this is helpful in any event.

Ok my example was perhaps not ideal, since it has an even bigger breach as precondition. So under what conditions would an attacker get access to a pop-key of an expired token? Steffi any ideas?

[Hannes] We definitely need some more details about the type of attack we would like to prevent. Maybe it is worthwhile to think about what information the attacker steals from whom at what point in time could be a way to progress the topic.

Ciao
Hannes

/Ludwig

---

From: Sebastian Echeverria <[email-masked]>
Date: Thu, 20 Dec 2018 14:26:24 +0000

Hello,

>> If it is detected the AS would revoke the token. Then the client _could_ use client introspection to get that information. Note that this is what the CMU people are looking at.

Yes, handling compromised RSs is in fact something that we have been looking into. Our main concern is that in our scenarios, the environment is expected to be very hostile and connection is limited and intermittent (disadvantaged or DIL networks). Since we wanted to add some support for revoking tokens, without having to modify the framework to handle token revocation explicitly, what we ended up doing was using client introspection, along with some caveats and some considerations, to be able to add this functionality, besides also having ways to handle expired tokens. The main advantage of this is, again, that we aren't really modifying or even extending the ACE framework, but just taking advantage of functionality that is already there to implement this functionality, which makes sense in our use case.

In fact, we were looking into writing a BCP-like document suggesting ways to do this based on what we did. We were envisioning this as maybe the starting point of a document containing practices on how to better handle client communications with OAuth/ACE when we are dealing with disadvantaged networks and hostile environments. If there is interest in the group, we could share that document here, and maybe discuss what other practices could be added to it.

Thanks,

---
Sebastian Echeverria
Tactical Technologies Group (TTG)
Software Engineering Institute
Carnegie Mellon University

-----Original Message-----
From: Ludwig Seitz [mailto:[email-masked]] 
Sent: Wednesday, December 19, 2018 8:24 AM
To: Hannes Tschofenig <[email-masked]>; Stefanie Gerdes <[email-masked]>; Jim Schaad <[email-masked]>; [email-masked]
Subject: Re: [Ace] Security of the Communication Between C and RS

> before the token expires?

If it is detected the AS would revoke the token. Then the client _could_ use client introspection to get that information. Note that this is what the CMU people are looking at.

> requires the attacker to run a new DTLS/TLS handshake with the RS.

If the pop-key was used as a basis for doing a DTLS-PSK handshake, the attacker should be able to hijack the connection and impersonate either party.

> from and how you can even detect the compromise.

That is a different story entirely. You could imagine the case of an RS improperly deleting an expired token and the associated pop-key, and then being subject to a physical attack that recovers that information.

> communicating if the token expired since it has that information.

The RS would indeed stop, but since the token is opaque to the client, it has no way of knowing that the token has expired, and our clever attacker is using the pop-key to impersonate the RS and maintain the illusion that the connection is still alive an running.

> send a token that gives it access.

Yes but say e.g. that the RS is a message broker and the client is a publisher, writing sensitive data to the RS.

/Ludwig

-- 
Ludwig Seitz, PhD
Security Lab, RISE
Phone +46(0)70-349 92 51