Subject: Re: [sipcore] Thoughts about draft-ietf-sipcore-sip-token-authnz-02.txt - Dale's comments

From: Christer Holmberg <[email-masked]>
Date: Sat, 13 Jul 2019 07:25:31 +0000

Hi Dale,

Please see inline.

>2.  One somewhat philosophical point is that the current version presents the work as implementing two (somewhat generic) call flows.
>But of course, SIP isn't defined in terms of call flows that SIP entities implement by having telepathic knowledge of where they are in particular 
>call flows, but rather in terms of specific internal states of SIP entities which cause them to respond in defined ways to incoming messages.  
>The collective effect of these action specifications makes an unlimited number of useful call flows work.
>
>So in this case, we need to dissect each step of these call flows and lay out the specific behaviors that have to be executed by the participating entities.
>
>In addition, this is the place to discern which of these behaviors fit into the various existing patterns and structures of SIP.

I think the draft already does that. What do you think it missing?

----

>4.  The question arose on the mailing list whether Proxy-Authenticate is ever used.  I know that the sipX family of PBXs uses it.  The general pattern is 
>that the proxy demands that the UAC authenticate itself, and then passes authenticated INVITEs to their destination UASs.  The destination phones are 
>configured to only accept requests from the IP address of the PBX.  This allows a very simple authentication scheme at the UAS to be leveraged into more 
>sophisticated authentication of all incoming requests by a more intelligent proxy.
>
>This structure also supports the standard SIP usage where the process of permitting an INVITE to flow *from* a UAC is not coupled to whether or not 
>the UAC is registered.  (Of course, a UAS can only *receive* an INVITE to its AOR if it is registered for that AOR.)  The draft seems to presume that the 
>ability to send INVITEs is implicitly controlled by whether the UAC has an active registration ... but that is not standard SIP.

Agreed.

The reason it may look different in the draft is because registration was one of the use-cases we earlier agreed was going to be covered in the draft.

---

>5.  If I understand it correctly, a SIP request is authenticated by an Authorization header containing the Bearer scheme and a valid access token.  
>As others have noted, any device which can copy the access token can issue any request in the name of the token's user.  This situation requires 
>that the SIP messages be fully protected from eavesdropping and that a message containing such an Authorization header must never be handled 
>by an untrusted entity.
>
>This is a particularly strict situation.  The draft recognizes this and the Security Considerations section says
>
>   The UAC MUST always make sure that it is communicating with the right
>   registrar/proxy using TLS and proper validation of the server
>   certificate and the identifier in that certificate to protect the
>   access token in transit.
>
> However, this restriction is sufficiently different from current practice that it should also be mentioned in the 
> earlier, "operational" sections.

Feel free to suggest where you want to add text.

Related to that, Olle commented that TLS may not be enough, as it is hop-to-hop when used with SIP. So, we have been discussing encoding the access token using encoded JWTs.

>This situations sounded familiar to me ... I eventually realized that it is exactly the situation with HTTP Basic authentication.
>
>It's also the reason why SIP rejected using Basic authentication.
>
>We need a way to use OAuth authentication that has the property of Digest authentication that the values in the Authorization 
>header are bound in some way to the particular request.  It seems to me that there are a couple of ways out of this problem.
>
>a) Given that OAuth designates the token we are using as "bearer", it's possible that OAuth provides a different mode of operation with the needed properties.
>
>b) Use the access_token as essentially the "passwd" value in a clone of the Digest algorithm.  This requires that the Authorized header has some other way of indicating 
>to the authenticator what access_token it used.
>Presumably that information could be bundled into a parameter of the (authenticated user) "uri" parameter of the header.

I'd like some more information, and perhaps an example, for this, because I am not sure I understand.

---

>6.  One new UA behavior is where the UAC coordinates the process of the user providing his credentials, forwarding them to the authorization server, 
>and receiving the tokens.  I don't see any need to standardize how this is triggered and operates, other than that the contents of the HTTP POST and 
>its response ([01]/[02] or [10]/[11]) need to be properly specified.  I assume that these are specified by the OAuth specification, but we need to ensure 
>that our draft clearly specifies whatever parameters are needed by the generic OAuth specification.
>
>The reason for being careful with this is that in order to ensure interoperability at the boundary between the UAC and the authorization server, their 
>communication is not truly "out of scope of this specification" but rather "delegated by this specification to the OAuth specification".

Where do you think the draft tries to standardize how OAuth operates? 

---

>7.  Similarly for the conversation between the SIP authenticator and the authorization server.

See comment 6.

---

>8.  Given that Bearer is a new authorization scheme, it doesn't directly demand any new UAC behavior regarding registration.  But the REGISTER [12] may 
>introduce a new behavior:  Currently, a UAC can only REGISTER for a particular AOR; that AOR appears as the To and From URIs.  But in this call flow, it's possible 
>that the UAC does not know which AOR it will eventually attempt to register to, only the SIP domain.
>
>So we may need to extend RFC 3261 to provide a "generic" REGISTER form, whose purpose is not to obtain a registration but rather to provoke a
>401 response containing the authz_server value that the UAC needs,
>
>       REGISTER sip:biloxi.com SIP/2.0
>       Via: SIP/2.0/UDP bobspc.biloxi.com:5060;branch=z9hG4bKnashds7
>       Max-Forwards: 20
>       To: <sip:biloxi.com>
>       From: <sip:biloxi.com>;tag=456248
>       Call-ID: 843817637684230@998sdasdh09
>       CSeq: 1826 REGISTER
>       Contact: <sip:192.0.2.4>
>
> Once the user is done with the OAuth handshake, the UAC will know the AOR to register to and can send a normal REGISTER.

I don't think we shall change or extend the basic concept of SIP registrations, where the user is trying to register an AOR.

---

>9.  It seems to me that there should be a stated constraint that the registrar must not issue a registration that is valid for longer than the future 
>validity of the access_token that is used to authenticate the registration request.  Presumably this is straightforward to implement in an OAuth context.

There is a discussion about that, somewhere in the list thread.

---

>10.  Both call flows show the UAC obtaining a refresh_token from the authorization server but there is no illustration of the operations that the UAC 
>will do to use the refresh_token to obtain an access_token with longer validity.  It is probably worth illustrating this, as it is a different interaction that the authentication server must support.

Agree. We can add that.

---

>11.  In regard to the sip.token media feature tag, it's not clear that it is particularly useful.  Presumably, if the authenticator of a request accepts 
>the Bearer scheme for one of its realms, whenever it gives a 401/407 response, it will always include a WWW-Authenticate/Proxy-Authenticate 
>header for the Bearer scheme and that realm, and that header will include an authz_server parameter.  If the UAC does not accept Bearer for a 
>particular realm, it will ignore such a header, so there is little cost of sending it to a UAC that does not support it.

I'll let Paul comment on this, because I think it raised the need for the indicator.

Regards,

Christer

---

From: "Olle E. Johansson" <[email-masked]>
Date: Mon, 15 Jul 2019 10:01:06 +0200

> On 13 Jul 2019, at 09:25, Christer Holmberg <[email-masked]> wrote:
> 
> Hi Dale,
> 
> Please see inline.
> 
The UA has to know the AOR when authorizing, to get authorization to use that AOR. The AOR will in my theory be inicluded
in the access or identity token.

Specifying a new way to “discover my AOR” in SIP is in my view out of scope for this document.

> There is a discussion about that, somewhere in the list thread.
I think we need to consult with the Oauth group on this. It may be the case that the long-lived expiry times we in many cases have for registrations and subscriptions
is not considered in the world of Oauth. The example from the STUN/TURN Oauth docs is the only one I found.

> I'll let Paul comment on this, because I think it raised the need for the indicator.

/O

---

From: Yehoshua Gev <[email-masked]>
Date: Sun, 21 Jul 2019 14:55:24 +0300

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

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 21 Jul 2019 15:43:53 +0000

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 <[email-masked]> Puolesta Yehoshua Gev
Lähetetty: sunnuntai 21. heinäkuuta 2019 14.55
Vastaanottaja: [email-masked]
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