[sipcore] Thoughts about draft-ietf-sipcore-sip-token-authnz-02.txt

[[e-mail] (Dale R. Worley)]

I've finally gotten out from under a bureaucratic problem with my
employer and taken a look at sipcore-sip-token-authnz and its e-mail
thread.  My, my...  I haven't read the thread thoroughly, but I've at
least skimmed every message up until some time yesterday.  But I think I
have reasonably well formulated the following observations.

1.  I find the new draft considerably easier to understand than the
older ones.  I'm not sure why; as Christer notes, everything in it is in
the older ones.  But I suspect that the somewhat narrower scope of the
new draft allows me to see the overall concept even when the details
aren't particularly clear.

So that's a significant advance.

I don't see the current version as being near WGLC but rather as a good
presentation of the high-level design concept.  It's the point where you
can start seeing the path to WGLC.

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.

3.  One thing that's clear is that we're really defining a new
authentication scheme, named "Bearer", which is used in coordination
with an OAuth authorization server.

Based on this, it's clear that the scheme can be used in any context any
other scheme could be used, as long as the target supports it.  This
includes for authenticating to a UAS (e.g., a voicemail server) or to a
proxy.  And we get this functionality "for free"; we don't need to
define any more machinery for these uses beyond what is needed to
support REGISTER authentication.

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.

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.

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.

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

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

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.

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.

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.

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.

Dale