On 11/12/2018 21:38, Jim Schaad wrote:
-----Original Message-----
From: Ace <[email protected]> On Behalf Of Stefanie Gerdes
Sent: Tuesday, December 11, 2018 4:11 AM
To: Ludwig Seitz <[email protected]>; [email protected]
Subject: Re: [Ace] Fwd: New Version Notification for
draft-ietf-ace-oauth-authz-
17.txt and draft-ietf-ace-oauth-params-01.txt
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.
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.
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.
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.
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
required.
Indeed no claim is specifically required in the framework.
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.
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.
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.
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.
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.
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
_______________________________________________
Ace mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ace
