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 +46(0)70-349 92 51
_______________________________________________
Ace mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ace
