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

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

> On 11 Jul 2019, at 17:13, Christer Holmberg <[e-mail]> wrote:
> 
> Hi,
> 
>>>>>>>>>> The tokens generally, but if I understand it right not always, are JWT structures that contain various data. In 
>>>>>>>>>> OpenID connect both the access and identity token are JWTs.
>>>>>>>>>> We can either specify specific claims that  are standardised for various SIP functions or let that be open for 
>>>>>>>>>> the SIP implementors to specify or a combination. 
>>>>>>>>> 
>>>>>>>>> For backward compatibility, we should at least let SIP implementors specify
>>>>>>>> Maybe, but at least we should write something about the usage of claims and scopes.
>>>>>>>> I think a base level for this draft is specifying a way to say “this access token is valid for SIP usage” or
>>>>>>>> “this is also a SIP identity"
>>>>>>> 
>>>>>>> Perhaps we can add some text about scope and claims, but I don't want to mandate usage of specific values, because that 
>>>>>>> may not be backward compatible with existing implementations using JWT. 
>>>>>> 
>>>>>> We can mandate *if* the access token is a jwt (and there’s an identity token like OpenID Connect). 
>>>>> 
>>>>>  It may not work with existing implementations that DO use JWT access tokens (not sure whether they use OpenID Connect, though).
>>>> 
>>>> Ok, you are making me interested - what are these implementations?
>>> 
>>>  Unfortunately I am not able to give information regarding that.
>>> 
>>>> When writing a new standard document, should we really be blocked by pre-standard implementations? I would assume that we
>>>> should be inspired by them, learn by their experiences, but not be hindered by them. 
>>> 
>>>   The implementations are based on earlier versions of the draft.
>>> 
>>>   And, yes, there is the old saying that one should not deploy a draft before the draft becomes RFC. 
>>> 
>>>   But, in this case, the first version of Rifaat's individual draft was submitted in 2014. Then, for whatever reason, it took 3(!) years before it 
>>>  got adopted, and after that we have so far worked on it for two years. How long is one expected to wait for an RFC before deploying???
>>> 
>>>    Of course, if something is broken we need to fix it. But, I don't think what you suggest is fixing something that is broken, it is adding new 
>>>    functionality. And, I have no problem with that, as long as it is backward compatible.
>> 
>> 
>> Christer, 
>> I’ve been thinking about this. We are almost in the same situation as the old discussion about the DIversion: header. While waiting
>> for another better solution, that’s what all of us implemented. Then came SIP HIstory and we had no docs to refer to for interoperability…
>> The old draft was later published as an informational RFC.
>> 
>> Can we look into the same solution? Publishing the current draft wiith minor nits as an informational RFC that your implementation is compliant with
>> and then work on something more up-to-par with current OAuth2/OpenID connect BCPs and thinking?
> 
>    I really think that is an unfair request, considering how many years some of us have been working on this, especially since I don't think the current solution is broken.
> 
>    Yes, there are lots of things that need to be clarified, and some things may be added, so let's first try to do that and see where it takes us.
Let’s do that. My apologies for stepping in late, but I haven’t felt blocked by an early implementation of a draft before. I do understand it’s been
some time.
> 
>> As an example: When reading the docs I see ways of protecting the access token so that only a specific service (read SIP domain)  may decrypt and
>> use it. That way we don’t need to disallow forwarding of SIP messages with a bearer token, as the token will be useless beyond that point.
> 
>    JWT gives you that property, doesn't it? There is nothing in the current draft that forbids or prevents you from using JWT. As we noted earlier, it's probably 
>    what most (all?) people are using anyway.
The implementations I’ve seen is mostly signed JWTs, but you are right, JWTs can be encrypted.
> 
>> Starting to go down that road, wlil definitely mean that we leave the implementation you currently have behind. And that is just
>> one issue. The other is having a parsable access token, which I think would be a requirement to follow the BCP and propably to get through
>> the hole security audit for any standard-track RFC publication.
> 
>    JWT is parsable :)
> 
>    Is your issue that we don't mandate JWT? If so, why don't we liaise (as you suggested earlier) with the oauth wg to see whether it would be safe to assume that everyone uses JWT.
I don’t think we can reach any level of acceptable security in this without parseable access (and identity) tokens. All new Oauth documents from the WG seems to 
assume you can transport metadata from the authorization server to the resource server in tokens in order to limit access token usage. 

In addition I think putting the bearer token in a SIP header is dangerous - it will require a lot for existing non-compliant browsers not to leak this header out in the wild.
Protecting it in a way that only the targeted audience can decode it and validate it would make the situation better.

/O