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

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

> On 13 Jul 2019, at 09:25, Christer Holmberg <[e-mail]> wrote:
> 
> 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.
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.

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

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

/O