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

[Christer Holmberg <[e-mail]>]

Hi,

...

    >>> 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.

    What do you mean by "existing non-compliant browsers"?

    > Protecting it in a way that only the targeted audience can decode it and validate it would make the situation better.

    Again, JWT :)

    You can include JWT encoded information in a SIP header. We already do that elsewhere.    

   Regards,

   Christer