Re: [Ace] Security of the Communication Between C and RS

[Ludwig Seitz <[e-mail]>]

On 15/12/2018 16:04, Hannes Tschofenig wrote:
> Hi Steffi,
> 
> ~snip~
> 
>> I really think you should point out that symmetric keying material
>> that the AS provides to the client is valid as long as the token.
> 
> I think that's a useful recommendation. I do, however, believe that
> we are not making the same assumption for an asymmetric key bound to
> the token.
> 

Ok, I'll add text to the draft that says this.

Note that this can be trouble if a client asks the AS to bind an 
existing symmetric pop-key to another (new) token it is requesting.
Which one of the two tokens bound to that key is now steering the 
expiration of the key?


>> I also think that the client must be able to assume that RS' RPK
>> that C receives from AS is also valid as long as the token, unless
>> C has additional information.
> 
> I would think that it is rather unlikely that the RS will change its
> public/private key pair so quickly. Right?
> 

Agree with Hannes here. RPKs wouldn't typically be changed that fast.


>> The access information optionally can contain an expires_in field.
>> It would help to prevent security breaches under the following
>> conditions:
> 1. the keying material is valid as long as the ticket, 2. the
> expires_in field is present in the access information that AS sends
> to C, 3. the client checks the expires_in field when it gets the
> access information from the AS, and 4. the client checks if the
> keying material is still valid each time before it sends a request to
> RS.
> 
> These checks make sense to me.
> 
Are you proposing we make the expires_in field mandatory? If so, why 
isn't it mandatory already in OAuth (currently only RECOMMENDED)?

/Ludwig


-- 
Ludwig Seitz, PhD
Security Lab, RISE
Phone [phone]