Re: [sipcore] draft-ietf-sipcore-sip-token-authnz - Security of the token

[Christer Holmberg <[e-mail]>]

Hi Yehoshua,

Thanks for your input!

I think OPTIONS 3 and 5 are outside the scope. The mechanism shall work with the existing OAuth infrastructure. OPTION 4 is too narrow – there are cases where the token is verified by the registrar.

However, I DO agree with Olle that the token needs to be protected so that non-intended entities will not have access to it. But, that doesn’t always mean it has to be encrypted. For example, in your home gateway example you know that the header field will be removed before the SIP request is forwarded to non-intended entities.

Also, we need to address the protection of the token, or the draft will never pass IESG review 😊

Regards,

Christer




Lähettäjä: sipcore <[e-mail]> Puolesta Yehoshua Gev
Lähetetty: sunnuntai 21. heinäkuuta 2019 14.55
Vastaanottaja: [e-mail]
Aihe: [sipcore] draft-ietf-sipcore-sip-token-authnz - Security of the token

Hi,

Looking at the discussion regarding the way to secure the access token, I think it will be good to summarize the options.

OPTION 1 - Bearer authorization (as appears in the draft):
Send the token as plain text on the Authorization header.
This option is very straight-forward, but lacks the ability of the UAC to verify that the token is not exposed by some intermediary proxy.

OPTION 2 - Token encryption (a proposal by Olle Johansson):
Encrypt the token using a public key that is provided in a challenge.
I believe that a public key of a UA doesn't normally change between challenges, so this method is prone to reply attacks (if the challenge be kept constant).
Of course, this method can be extended to include a nonce, but it will make it more complicated.

OPTION 3 - Digest scheme (a proposal by Dale Worley):
Use a "digest"-like scheme to send a hashed value of the token.
I believe this is problematic, as digest can only be used if both parties knows the password (or token) in advance, so it's enough to compare its hash value..
In our case, tokens can usually be validated only when their full value is revealed (e.g., validation of JWT token is done without pre-knowledge of the token).

OPTION 4 - HTTP Authorization:
Assuming that we resort to having only the first hop (the home proxy) perform the authentication, and restricting ourselves to WebRTC clients, the authorization can be done on the HTTP level of WebSocket creation.
This option is available to use creating new standards, but apparently it's not enough (or the draft would not have been written).

OPTION 5 - New challenge-response mechanism:
Probably some combination of options 2 and 3, but having it standardized and performed by 3rd-party OAuth server.
Just like RFC 5090 proposed a way for a RADIUS server to perform digest authentication, an extension to OAuth introspection endpoint (RFC 7662), can possibly be made to validate a token using a challenge-response mechanism.
With this option, the "security burden" will fall on OAuth servers and not on the SIP UAs.


Having laid out the options above (I'm sure there are options I've missed),
I think that the scope of the current draft should remain minimal, and OPTION 1 should be used.

For example, a common use case is that the home proxy perform the authentication, and remove the Authorization header when forwarding the request. For this use case, it will be nice if option 1 will remain available.

Still, even for this scenario, maybe a simple challenge-response mechanism should be required, so the UAC will have a way to know that the home proxy supports
this kind of authentication. Without it (if the proxy is not supporting), the UAC might send the token, and the proxy forward it to un-trusted entities.

For the long run (on other drafts), the other options should probably be looked into, so the security restriction imposed by option 1 could be relaxed.


Regards,
Yehoshua