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

[Ludwig Seitz <[e-mail]>]

On 13/12/2018 15:42, Stefanie Gerdes wrote:
> Hi Ludwig,
> 
> On 12/12/2018 10:47 AM, Ludwig Seitz wrote:
> 
>> 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.
> 
> I cannot find the term "integrity" in section 5.8.1.1. Encryption is not
> 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
> 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.
> 

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.

> 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?

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

> 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.
>
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).

>>
>>>> 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.
>> 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.
> 
> 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.

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

> 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. 

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.

>>
>> 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.
>
> 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.

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.

> 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.

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 [phone]