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

[Paul Kyzivat <[e-mail]>]

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 about 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.

	Thanks,
	Paul