On 18/12/2018 14:51, Hannes Tschofenig wrote:
Hi Steffi, Hi Ludwig,
~snip~
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)?
[Hannes] I would do the check when the field is actually there.
However, it is a good question why it is not mandatory in OAuth. Let
me drop a mail to the list.
Now that I got a response from the OAuth working group (in the sense
that I was thinking about the claims in the access token rather than
the parameters in the response from the AS) I think checking the
expires_in field has to be optional since * the expires_in parameter
is optional, and * it only has an advisory nature.
It is useful to send the parameter so that the client can determine
when to request a new access token (for example, via the refresh
token) but it is not absolutely necessary for the protocol
operation.
Ciao Hannes
Hannes,
Steffi's point was (and remains) that if we don't give the client a way
to determine whether the token is not expired (except for client
introspection), it might use an expired token and old keys to
communicate with the RS.
The argument if I understood Steffi correctly is that the client's
request may contain sensitive data (think a POST/PUT with some
significant payload) and that sending it to an RS with outdated keys
might be a risk.
My take would be that in cases where this is relevant, one would specify
a profile where the expires_in parameter is mandatory. Furthermore we
should add text to the security considerations describing the issue.
/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
