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