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

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

> On 11 Jul 2019, at 17:02, 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?
>>> 
>>>     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.
> 
>    We normally don't specify HOW to protect SIP information, because it can done in  many different ways, we only say when 
>    some piece of information needs to be protected.
And where have that kind of thinking led us? We need at least one working interoperable solution for implementers to iimplement
as a baseline, while not forbidding others. 
> 
>    Also, in the case of oauth2 tokens, as they can be encoded in many different ways, some of which have their own built-in protections (e.g., JWT), we can't specify a single solution that works for all. We can only specify what security characteristics must be fulfilled.
We can surely specify a working solution that is the base interoperability level. Otherwise we will just produce a
document that goes to the archives and leads to isolated vendor-specific islands. I don’t like that.
I do agree with leaving it open to add other ways of doing things in the future, but  I think we need to deliver
a fully specifieid working solution.

> 
>>> 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.
> 
>    In that case you should use encoding with built-in protection, that only authorized entities are able to decrypt. JWT provides 
>    such protection, so I assume it wouldn't matter if a non-authorized entity receives it. And, as far as the OAuth token is concerned, you don't have to protect the SIP signaling when using JWT (there may of course be other reasons why you need to protect the SIP signaling).

Most SIP signalling protection - TLS - is hop by hop. We need protection from the UA to the service domain - possibly across a few intermediate servers.


/O