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

[Christer Holmberg <[e-mail]>]

Hi,

>>>>>>>>> All I am saying is that one should not send a token to someone that it has NOT been issued for.
>>>>>>>>      Then you are saying that a token should *never* be included 
>>>>>>>> in a request  to a target for which you have not received a 
>>>>>>>> challenge some time in the  past.
>>>>>>>>      That is a bit extreme, but I guess you can specify that if 
>>>>>>>> you think it  is the right thing to do.
>>>>>>> That is my understanding of the generic OAuth security considerations: you don't give a token to someone it was not intended for.
>>>>>>> Of course, if you know (based on whatever configuration/policy) that it's ok to give the token to the target I guess you could do it.
>>>>>>> 
>>>>>>>>  But note that this logic won't always work for 
>>>>>>>> Proxy-Authenticate. You
>>>>>>>>  *might* know that a particular proxy will be visited (if it is 
>>>>>>>> mentioned  on a Route header), but it is pretty common for the 
>>>>>>>> request to visit  proxies unknown (at least in advance) to the UAC.
>>>>>>> It is important to remember that, since the token needs to be protected, a proxy needs to have the associated protection credentials to be able to access the token.
>>>>>> 
>>>>>> I'm lost here. How is the token protected? Is it because it is passed by reference, and other credentials are needed to dereference it? Or is it passed by value but encrypted?
>>>>>> 
>>>>>> If it is protected, then why is there any concern over who it is given to?
>>>>> 
>>>>> Normally most tokens are just digitially signed, but clear text. It 
>>>>> can be encrypted, but then the auth server need to know which key pair to encrypt it with, which in turn means that the client needs 
>>>>> to tell the auth server that which leads to a requirement to have parseable access tokens.
>>>> 
>>>>   I think the oauth2 token can be delivered non-encrypted to the SIIP UA over HTTPS. The SIP UA can then encrypt the oauth2 token before sending it over SIP.
>>> Now you have to have a shared key pair between every UA and the intended SIP server. That’s far more complex than having it in the authorization server.
>> 
>>    Now we are coming back to where this would actually be used :)
>> 
>>    Again, the only use-case I am aware of is SIP registration, and then the only "intended SIP server" is the registrar.
> And you may pass through a number of SIP proxys on the way.

Yes, but they will not be "intended server" (read: authorized to see the oauth2 token), so no need to store any keys for those proxies. Only the registrar is the "intended server".

> There has been many mails questioning the focus on registration. You keep coming back to that - what is so different with authentication 
> for a REGISTER than other SIP methods in your view? I’m curious.

The number or entities that will authenticate the UA. You were talking about having keys for the UA and every intended server. In case of registration, the only "intended server" is the registrar.

Of course, there may also be other use-cases where there is only one (or a few) intended server, e.g,, a SIP subscription service. I am not saying registration is the only one. 

>> In any case, I think this is a deployment question, so we don't need to mandate one way or another. What matters is that the JWT is protected on the SIP interface.
> I believe others are working on that part - confidentiality between authorization server and resource server.

Yes. 

>>> You put a lot of trust in TLS, which is fine. How do you handle intercepting TLS proxys in the path in this scenario?
>> 
>>    I guess we'd have to ask the OAuth experts about that, but in 
>> general I think we can put as much trust in HTTPS as any else does :)
> Which means almost no trust any more...

Well, if one doesn't trust OAuth then he/she should obviously not use it. But, I don't think this is the place to discuss/improve the generic security of OAuth.

>> At the end of the day, you have to choose a solution that fits your use-case. Maybe this solution isn't feasible for all use-cases, even if it technically 
>> supports them. OAuth may fit certain use-cases better than others, and there is nothing we can do about that.
>
> Depends on the definition of “this solution”.

OAuth in general, and the usage of OAuth for SIP authentication.

> I do agree that Oauth2 may not fit all use cases for SIP, but any step away from the current Digest Auth is a step forward.

Sure, but I personally don’t think OAuth will be feasible for all use-cases where Digest is currently used - especially not for user-to-user authentication. It's not what OAuth was designed for, AFAIK.

> If you read up on the large amount of drafts and RFCs from the Oauth wg and OpenID connect you’ll find that they are targeting many types of situations 
> that would fit not only browser-based SIP ua’s but also SIP desktop phones and maybe ATA-like boxes.

Absolutely.

> Mutual TLS cert auth hasn’t taken off, which is the only alternative we currrently have. I do hope we can sort this out and document a good framework.

Me too :)

Regards,

Christer