Re: [sipcore] I-D Action: draft-ietf-sipcore-sip-token-authnz-02.txt

[Christer Holmberg <[e-mail]>]

Hi,

...

>> My main point here is not to get you to explain it to me in this email thread. What I want is to see this discussed adequately in the security considerations of the document. If it isn't "safe" to send the token to everybody, then how do I decide who I can safely send it to?
>>
>> One partial answer might be: if a challenge results in asking the user to authenticate for the realm, then the user gets to decide if he wants to, and if so then the resulting token should be sent to the same target just then. But this doesn't address when the same token can be used preemptively later. That still needs discussion.
>>
> This is an interesting topic that we really need to look into seriously. Consider an access token that has a validity of one hour. That token can be copied by any proxys or network elements on the path and be re-used by others within the validity period to get access.
>
> RFC 6749 Section 10.3 clearly states the need for confidentiality of the access token:
>
> "Access token credentials (as well as any confidential access token
>   attributes) MUST be kept confidential in transit and storage, and
>   only shared among the authorization server, the resource servers the
>   access token is valid for, and the client to whom the access token is
>   issued."
>
> One solution would be that the challenge indicates a pointer to a valid cert with a public key to use for encryption of the tokens. We have the identity-info header in RFC 4474 
> as an example of pointing to a cert. The implementation supporting this draft already supports https…

As I indicated in another e-mail, the token needs to be protected, so that proxies between the UA and registrar (in the case of REGISTER) can't use it.

Regards,

Christer