Subject: [Sip] RFC3261 and authenticating PROXIES to other proxies & UAS - 2 possible solutions

From: Alex Bligh <[email-masked]>
Date: Thu, 08 Apr 2004 13:49:17 +0100

I am still trying to work out how one might authenticate that a call has
been transmitted by a proxy that the headers claimed transmitted it. SIP
provides facilities (in protocol) for proxies and UAS's to determine that a
call originated at a UAC with credentials, but no manner of determining
whether the call passed through a proxy with credentials. Whilst in some
circumstances this can be handled with network layer or transport layer
security, (a) this requires support on a hop by hop basis from the proxy
downstream, (b) the overhead may be substantial, and (c) it is somewhat
inconsistent that SIP supports this type of authentication for the UAC but
not proxies.

I've come up with 2 mechanisms to provide the support - one I posted
earlier (which requires only a change on the proxy with credentials) and
goes into the "Despite being against RFC3261, I can't see what this would
break" category, and the second (which requires a change both at the proxy
supplying credentials and at the server authenticating them) certainly
breaks nothing, but is less functional.

I'd appreciate comments, particularly on what the first mechanism breaks.
I (now) know that it is (today) against various bits of RFC3261. But I
cannot see what in practice it would break. And as a couple of people
(on and off list) have pointed out, it would be very useful (even for
reasons I hadn't thought of).

BACKGROUND
==========

The (general) problem I am trying to solve looks like this:

   UAC <-----/\/\/\/\/---> P1 <--/\/--> P2 <---> UAS => PSTN
  (CPE)                 (proxy)      (proxy)  (media
                                              gateway)

P2 may or may not be present.

Let us assume UAC and P1 are very distant, and P1 & either P2 or UAS are
sufficiently distant that host security is impractical without adding some
additional layer (ipsec, tls etc.).

UAC is CPE on a site of a customer of SP1, who operates P1. UAS is a media
gateway, and P2 a (possibly) intervening proxy, operated by SP2.

Let us further assume that UAC registers to P1, and that P1 has already
authenticated UAC, and that any INVITE passed through P1 has already been
authenticated as coming from UAC and been authorized by P1 according to
SP1's local policy, prior to being forwarded to P2.

Let us further assume that it is the local policy of SP1 that any such
authorized calls it passes to SP2 would be authorized by SP1. So for
instance SP2 is a VoIP termination provider, and SP1 a VoIP service
provider.

SP2 wishes to authenticate & authorize calls made to UAS. It uses some form
of authentication. What it in essence is trying to authenticate is that the
call actually came from P1, not that the call actually came from UAC. This
could either be done at P2, or at UAS.

I have two mechanisms of doing this

MECHANISM (AB)USING HTTP DIGEST AUTHENTICATION
==============================================

As per previous email, (ab)use HTTP digest authentication so
that the proxy retries the Invite with the same CSeq but with
a different branch parameter. This seems to me indistinguishable
from a spiraling scenario where the proxy concerned happens to
call the same Request-URI twice but other information in the message
header (in this case authentication) that may be used to route the
call has changed.

As such, I can't see what it would break, and it has the major
advantage it works with all existing (challenging) UA's & proxies,
and that being challenge-response, it is more secure than
other mechanisms.

But, for the sake of argument

ALTERNATIVE MECHANISM USING vauth Via-Parameter
===============================================

This mechanism introduces a new Via Parameter (vauth).

A UAC or Proxy inserting a Via Header with a RFC3261 compliant branch
parameter MAY introduce one or vauth parameter into the Via header, in each
case to identify authenticate the via header to one or more downstream
proxies or UAS's. Such UAS's or proxies MAY use a vauth header to take
local-policy dependent routing or access decisions. A UAC or Proxy which
does not insert a Via Header with a RFC3261 compliant branch parameter MUST
NOT insert any vauth parameters.

The vauth parameter is intended to allow a server to authenticate a subset
of the Via: header (being the sent-by entry and the branch token), together
with an opaque string, to downstream servers. Multiple vauth parameters MAY
be used in order to support multiple realms of authentication. The vauth
parameter supports extensible mechanisms of authentication, but the
mechanism specified herein is MD5 authentication using a shared secret.
The mechanism of exchange of the shared secret and authentication realm
is outside the scope of this document.

The vauthid field specifies the realm of authentication. The vauthid field
MUST be unique across instances if the vauth parameter in a single Via:
header. Those specifying vauth fields SHOULD ensure that they are globally
unique, for example a domain name MAY be used.

The vauthopaque field is an opaque field intended to pass information to
servers in the authentication realm which MAY be used to influence their
routing decisions - for instance it might be used to specify that access
should be permitted or denied, or have an accounting function.

The vauthmeth field specifies the mechanism of authentication. The only
currently defined method of authentication is MD5. In this mechanism, the
vauthmd5data field contains a hash of the sent-by field, the branch
parameter (which is, by RFC3261 unique across time and space), the vauthid
field, the vauthopaque field, the vauthexpire field (if any), and the
shared secret, which should be a string of printable characters no more
than 64 octets in length. The hash is calculated using MD5 (RFC 1321 [35]),
expressed in hexadecimal.

The optional vauthexpire field is a date in the SIP date format (i.e. the
preferred RFC1123 format) after which it should be assumed that the
header is not authentic. If a vauthexpire field is inserted, the server
MUST be synchronized to an accurate time source, and the expiry time
MUST be no shorter than 32 seconds beyond the time at which the Via:
header is to be transmitted.

A server MAY check the authenticity of a Via: header using vauth parameters
by performing each of the following checks:

1. Isolate the vauth field(s) corresponding to a realm for which the
   checking server possesses a shared secret.

2. If vauthexpire is present: if the checking server does not support
   vauthexpire, it MUST silently discard the request. If the checking
   server does support vauthexpire, it MUST check that the current
   time is not beyond the expiry time, and if it is, it MUST
   silently discard the request, else proceed.
   The silent discards are used to ensure that excessive
   transmission delays result only in the symptoms of packet loss,
   rather than false authentication refusals.

3. The server MUST recalculate the hash value and check whether
   it corresponds to the hash value in the vauthmd5data field.

4. The result of (3), the vauthopaque field, and the presence or
   absence of a vauthexpire field, MAY then be used
   to influence routing decisions

The vauth mechnanism is primarily designed to protect against spoofing
attacks, as the shared secret will not be known. It provides only limited
protection against replay attacks, in that replays are time-limited by the
vauth-expire header. Further limitation of replay attacks can be given by
the implementor using the vauthopaque field - for instance in an
environment where the Request-URI is known not to change between the server
inserting the Via header and the server checking it, the vauthopaque field
could be set to contain a hash of the Request-URI, which could be checked
upon receipt. Further, it should be noted that mechanism provides no
protection against malicious or accidental modification of the message
between transmission by the server inserting the Via: header and the server
analyzing it. It is not intended as a substitute for network or transport
layer security.

An example of a Via: header with vauth parameters follows:
Via: SIP/2/0/UDP 4.3.2.1:5060 branch=1fe452.12;
 vauth="server.example.com:5061,y,MD5=1234567890abcdef1234567890abcdef";
 vauth="server2.example.com:5060,,MD5=fedcba0987654321fedcba0987654321:Fri, 
13 Oct 1998 23:50:00 GMT"

RFC3261 specifies:

    via-params        =  via-ttl / via-maddr
                         / via-received / via-branch
                         / via-extension
    via-extension     =  generic-param
    generic-param     =  token [ EQUAL gen-value ]
    gen-value         =  token / host / quoted-string
    token             =  1*(alphanum / "-" / "." / "!" / "%" / "*"
                        / "_" / "+" / "`" / "'" / "~" )

This document introduces a new via-param which matches the generic-param
model:

    via-params        =  via-ttl / via-maddr
                         / via-received / via-branch
                         / via-vauth ; new
                         / via-extension
    via-vauth         =  "vauth" EQUAL vauth
    vauth             = LTQUOT vauthid COMMA vauthopaque
                        COMMA vauthmeth [ COLON vauthexpire ]RDQUOT
    vauthid           = vauthstr
    vauthopaque       = [ vauthstr ]
    vauthexpire       = SIP-date
    vauthstr          = 1*(alphanum / "-" / "." / "/" / ":" / "_" /
                        "[" / "]")
    vauthmeth         = vauthmeth-md5 / vauthmeth-ext
    vauthmeth-ext     = vauthextension EQUAL vauthextdata
    vauthextension    = 1*(alphanum)
    vauthextdat       = 1*(alphanum)
    vauthmeth-md5     = vauthmmd5 EQUAL vauthmd5data
    vauthmmd5         = "MD5"
    vauthmd5data      = 32LHEX

Alex

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip