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

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

> On 11 Jul 2019, at 19:21, Christer Holmberg <[e-mail]> wrote:
> 
> 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.

You put a lot of trust in TLS, which is fine. How do you handle intercepting TLS proxys in the path in this scenario?

/O