> -----Original Message-----
> From: Ace <ace-boun...@ietf.org> On Behalf Of Stefanie Gerdes
> Sent: Tuesday, December 11, 2018 4:11 AM
> To: Ludwig Seitz <ludwig.se...@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
_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
