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

[Ludwig Seitz <[e-mail]>]

On 11/12/2018 21:38, Jim Schaad wrote:
> 
> 
>> -----Original Message-----
>> From: Ace <[e-mail]> On Behalf Of Stefanie Gerdes
>> Sent: Tuesday, December 11, 2018 4:11 AM
>> To: Ludwig Seitz <[e-mail]>; [e-mail]
>> 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 [phone]