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

[Christer Holmberg <[e-mail]>]

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.
  
Sure, and that we do need to cover: the token needs to be protected.
  
>    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?
  
I assume most people trust their registrar. If you don't, you obviously can't use the mechanism. We can for sure add text to clarify that, if needed.

And, you can for sure decide to trust the one you are calling. But, again, I still think we could leave user-to-user authentication out of scope of the draft. The scope has been using OAuth for registrations from day one, and that is what people have been asking for. 

Also, after people had raised issues with the previous draft, we agreed to only move the current parts into the new draft.

>    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.
  
OAuth allows you to re-use the token as many times as you want (until it expires) for the same service. So, for SIP, re-using the token in binding refresh REGISTER requests is fine.

But, you should not re-use a token you got for one "service" (e.g., your registration authentication) with another "service" (e.g., user-to-user authentication for a SIP call). It most likely wouldn't even work.

Regards,

Christer