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

["Olle E. Johansson" <[e-mail]>]

> On 9 Jul 2019, at 18:55, Paul Kyzivat <[e-mail]> wrote:
> 
> On 7/9/19 12:28 PM, Christer Holmberg wrote:
>> Hi,
>>>>>> As I said in another reply, if you by default place a REGISTER token in a non-REGISTER request the token may reach the remote peer, which could be a security concern.
>>>>>          I would like to hear more about this. Is there something uppoabout the token
>>>>>     that reveals stuff that might not be suitable to expose to everyone? I
>>>>>     personally don't know. This seems like something that ought to be
>>>>>     discussed in security considerations.
>>>>>    
>>>> The token itself does not reveal anything, but in OAuth the token is used to access the requested resource, so it is considered sensitive information.
>>>> 
>>>> As far as I know, OAuth for SIP has only been used for REGISTER requests, between the UA and the registrar. I have never heard about anyone using
>>>> it for non-REGISTER authentication, and I wonder whether we even need to cover it in the draft. We could limit the scope the REGISTER requests.
>>>> Then, if anyone ever needs OAuth for non-REGISTER requests, a separate draft can be written.
>>>        Yes, you can do that if you wish. But ISTM that the issues are largely
>>>    the same so I don't know why you would do that.
>> The REGISTER request, and the token, will only reach the registrar.
> 
> And any proxies on the path to the registrar.
> 
> But if I send an INVITE, am challenged by the target of the INVITE, and then send the token in a retry of the INVITE then it only goes there, where it is supposed to go. How is that any different from the registrar case? Is it because I somehow trust the registrar more that I trust who I am calling?
> 
> ISTM that what is more important is the relationship between the domain of the UAS I'm trying to contact and the realm of the challenge. (Do I think this server has any business claiming to be authenticate for this realm?)
> 
> The other tricky part is deciding whether to send the cached credentials (token) in a new request that hasn't just immediately challenged. But note that the request "in response" to a challenge is indistinguishable from a request sent to the same target later other than by time delay. The security concerns should be the same. Sending the token to some other target before being challenged by that target is a different leap of faith, so has different concerns.
> 
> 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…

/O