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

[Stefanie Gerdes <[e-mail]>]

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

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

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

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