Subject: [Sip] RFC3261 & authenticating PROXIES to other proxies & UAS's

From: Alex Bligh <[email-masked]>
Date: Tue, 06 Apr 2004 11:30:09 +0100

First, apologies if this is a dumb suggestion - it seems so
obvious that it must either be an even more obvious reason
not to do it, or someone must have thought of it before.

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 HTTP Digest Authentication (per RFC3261 s.22).
This could either be done at P2, or at UAS.

RFC3261 section 16.7 suggests that Proxies MUST forward such
final 4xx responses received back towards the UAS (as there
will still be Via: header(s)).

This means that credentials for P2 or UAS must be supplied
by UAC, not by P1.

This has a number of disadvantages, for instance
1. The 401/407 response is forwarded hop-by-hop all the
   way to UAC, and a retry made. This causes unnecessary
   network traffic and delay.
2. Either
   a) UAS/P2 must challenge UAC with the same realm as P1
      did, in which case in practice SP2 must be able to
      query SP1's authentication database, which necessitates
      yet another protocol; or
   b) UAS/P2 challenges UAC in a different realm to P1, which
      means UAC must hold two sets of credentials (and, in the
      case where SP3, SP4, etc. are providing similar services
      to SP1, a possibly unlimited set of credentials).
3. In either case, UAC has credentials which allow it to traverse
   P2 / UAS, which may be undesirable from both SP1 and SP2's
   point of view, if (say) the contractual relationship is
   between User and SP1, and SP1 and SP2, but not between
   User and SP2.

What I am trying to determine is why a 401/407 challenge
from P2/UAS could not result in a response by P1, i.e. P1
itself provide the credentials to P2/UAS. Whilst this would
seem to be in breach of RC3261, I can't see what harm it
does, and it would bring considerable benefit - for instance
P1 could authenticate to P2/UAC using its own credentials,
as opposed to credentials belonging to the particular user
making the call. IE P1 detects that the response comes from
P2 with a realm that it knows, and behaves (in essence) a little
like a UAC.

So the traffic flow would look like this (assuming P1 authenticates
to P2)

 UAC              P1                 P2                UAS
  |                |                  |                 |
  |  INVITE        |                  |                 |
  | ------------>  |                  |                 |
  |                |                  |                 |
  |  407 Unauth    |                  |                 |
  | <-----------   |                  |                 |
  |                |                  |                 |
  |    ACK         |                  |                 |
  | ----------->   |                  |                 |
  |                |                  |                 |
  |  INVITE with   |                  |                 |
  |  user creds    |                  |                 |
  |  for SP1       |                  |                 |
  | ----------->   |                  |                 |
  |                |                  |                 |
  | 100 Trying     |    INVITE        |                 |
  | <-----------   |  ------------>   |                 | }
  |                |                  |                 | }
  |                |   407 Unauth     |                 | }
  |                |  <------------   |                 | }
  |                |                  |                 | }
  |                |     ACK          |                 | } new
  |                |  ------------->  |                 | }
  |                |                  |                 | }
  |                |  INVITE with     |                 | }
  |                |  SP1 creds for   |                 | }
  |                |  SP2             |                 | }
  |                |  ------------->  |                 | }
  |                |                  |                 |
  |                |   100 Trying     |    INVITE       |
  |    100 Trying  |  <-----------    | ------------->  |
  | <------------  |                  |                 |
  |                |                  |    200 OK       |
  |                |   200 OK         | <-------------  |
  |   200 OK       |  <-------------  |                 |
  | <------------- |                  |                 |
  |                |                  |                 |
  |                |                  |                 |
  |                |                  |                 |
  |                |                  |                 |

It is relatively easy to imagine variations where P1 alternatively
or additionally authenticates to UAS, or P2 alternatively or
additionally authenticates to UAS.

Now, it seems to me, apart from a slight alteration to section 16.7
of RFC3261, this could be achieved with no protocol changes. To
support it would only require a change at those proxies wishing
to authenticate themselves to other proxies or UAS's, and no change
is required at proxies or UAS's being authenticated to.

So:
1. Is this in fact not in breach of RFC3261 at all?
2. If not, is this a good solution to the problem?
3. If not, why not, and what should I do instead?

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

---

From: Klaus Darilion <[email-masked]>
Date: Tue, 06 Apr 2004 15:36:05 +0200

Hi Alex!

> 2. If not, is this a good solution to the problem?

I think (not sure) another problem is the CSeq - which will be increased 
with every request, and if the proxy P! inreases it on behalf of UAC1, 
then this might cause problems.

> 3. If not, why not, and what should I do instead?

SP2 can authenticate your IP address (IP address of P1) and all requests 
from your IP address will be billed on your account. To avaid spoffing, 
UDP should be disabled on P2 and you should send your requests using TCP.

Klaus

---

From: Fredrik Thulin <[email-masked]>
Date: Tue, 6 Apr 2004 18:39:08 +0200

> then this might cause problems.

Yes, this is even pointed out in RFC3261 #22.3 Proxy-to-User Authentication :

      If a proxy were to resubmit a request adding a Proxy-Authorization
      header field value, it would need to increment the CSeq in the new
      request.  However, this would cause the UAC that submitted the
      original request to discard a response from the UAS, as the CSeq
      value would be different.

> UDP should be disabled on P2 and you should send your requests using TCP.

There is wording in section 22.3 saying proxys MUST NOT add things to 
authorization headers, and that all 407 responses MUST be forwarded 
upstreams. That is a pity, since I think otherwise the following could solve 
the problem :

P1 could, upon receiving the 407 from P2, start a new transaction with a 
different branch parameter and added authentication credentials. The request 
could then be re-submitted to P2.

Perhaps someone can explain what was the reason for not permitting proxy to 
proxy authentication? For example, I would have wanted to do that when 
someone chooses to redirect incoming calls to their cellular phone. In that 
case, it is not fair to send a 3xx to the caller and let them pay for the 
PSTN costs. Instead, I would like for the proxy making the redirection 
decision to send the request to my PSTN gateway, providing credentials for 
the user who requested the redirection.

/Fredrik

---

From: Alex Bligh <[email-masked]>
Date: Tue, 06 Apr 2004 18:01:47 +0100

--On 06 April 2004 18:39 +0200 Fredrik Thulin <[email-masked]> wrote:

> different branch parameter and added authentication credentials. The
> request  could then be re-submitted to P2.

Far neater. And still no need to change UAC, P2 or UAS.

Alex

---

From: Alex Bligh <[email-masked]>
Date: Tue, 06 Apr 2004 17:04:52 +0100

> then this might cause problems.

IE you are saying one has to increment (well, anyway, change) CSeq so that
INVITE can be distinguished by P2/UAS from a delayed retransmit, yes? Which 
is what is meant by:

Which means as UAC will be expecting the remainder of the transaction to be
carrying the first CSeq number, you would have to rewrite CSeq back to the
original CSeq number for the responses, and rewrite the ACK etc. too the
other way. Which is starting to get rather dirty. Hmmm... I shall think
more on that.

Perhaps one option would be for P1, on reception of the 407, to
407 the INVITE *LOCALLY* (i.e. from P1) saying it had a stale nonce,
and effectively ignore the request for authorization from P2/UAS.
UAC would then retry the INVITE (new CSeq) with a new set of
credentials for P1, and P1, now having the challenge from P2/UAS in
relation to that CallID, it could insert the the Proxy-Authorization
header itself.

This does mean that UAC is still going to have to authenticate
the INVITE twice. But at least the other problems I mentioned
are solved.

> UDP should be disabled on P2 and you should send your requests using TCP.

Sadly that does not much help (I don't think).

If P2 is (say) a PSTN voice gatweay, it doesn't take a lot of imagination
to work out how to do sufficient sequence number guessing to open
a channel and issue one invite. If the reward is n calls of infinite
length to an international premium-rate number, then it's going to
be worth trying. Remember once people said "this won't be a problem"
for BGP.

The only (sensible) solutions I can see other than the above tweaks
or relying on TCP and IP address (which I am loath to do as I've
seen it go wrong before) are:

a) IPSec / TLS - proper transport layer authentication - which is
   unfortunate as it is relatively CPU intensive; or

b) Proxy (on every transaction) simply inserts a header which is
   identifies the proxy, and then has a hash of some (shared) secret,
   the proxy name, and To:/From:/CSeq:, which the UA/other proxy then
   checks is there. But that requires a separate authentication scheme
   which I was trying to avoid.

Alex

---

From: Alex Bligh <[email-masked]>
Date: Wed, 07 Apr 2004 16:41:44 +0100

--On 06 April 2004 18:39 +0200 Fredrik Thulin <[email-masked]> wrote:

> upstreams. That is a pity, since I think otherwise the following could
> solve  the problem :
>

If I read things right, the branch parameter is going to be different
/anyway/ for a proxy with loop detection:

16.6 Request Forwarding [Section 8]

...
         If a proxy wishes to detect loops, the "branch" parameter it
         supplies MUST depend on all information affecting processing of
         a request, including the incoming Request-URI and any header
         fields affecting the request's admission or routing.  This is
         necessary to distinguish looped requests from requests whose
         routing parameters have changed before returning to this
         server.

On this basis, if the proxy retries the INVITE with the same CSeq,
what is the problem? IE how is this any different from spiraling
(which is allowed)?

Alex