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

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

> On 11 Jul 2019, at 16:24, Paul Kyzivat <[e-mail]> wrote:
> 
> On 7/11/19 10:07 AM, Christer Holmberg 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?
>>     That depends on how your protect it.
>>     If the oauth2 token itself is encrypted, and only authorized entities can decrypt it, then I guess it does not matter if a non-authorized user gets it, as it will not be able to use it.
> 
> Is this going to be defined, or is the intent to leave it open?
> I don't understand how things can work if it is left open.
> 
>>     But, if the oauth2 token is sent in "plain text", then the SIP signaling needs to be protected/encrypted. But, in that case, if I make a phone call to you, and the call itself is valid, then I should not send you the oauth2 token unless it's meant for you, because once you decrypt the signaling you will have access to it.
>>    What is important is that a non-authorized user should not have access to a non-protected oauth2 token.
> 
> I don't see how this can work. How does the UAC *know* if the server it is sending credentials to is authorized to receive those credentials?
> 
> In general the UAC doesn't know what proxies and UAS the request will visit. All it knows is the request-URI. Since there generally isn't a direct connection from UAC to UAS TLS authentication doesn't help.
The UAC will have to know which SIP domain that - in Oauth2 terms - is the intended audience for authentication and/or authorization. When requesting authenticiation 
with the Oauth2 authorization server this needs to be part of the request. The server may them, provided that it has a trusted certificate or a key that is shared witih the
service, encrypt the requested access token in a way that only the audience can decrypt.

The SIP domain is part of the solution here. That will be stated as a SIP uri.

/O
> 
> 	Thanks,
> 	Paul
> 
> _______________________________________________
> sipcore mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sipcore