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

> -----Original Message-----
> From: Ace <ace-bounces@ietf.org> On Behalf Of Stefanie Gerdes
> Sent: Tuesday, December 11, 2018 4:11 AM
> To: Ludwig Seitz <ludwig.seitz@ri.se>; ace@ietf.org
> 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.

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

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
> Ace@ietf.org
> https://www.ietf.org/mailman/listinfo/ace