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

[Yehoshua Gev <[e-mail]>]

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