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

From: Fredrik Thulin <[email-masked]>
Date: Mon, 19 Apr 2004 08:15:24 +0200

On Wednesday 07 April 2004 17.41, Alex Bligh wrote:
> --On 06 April 2004 18:39 +0200 Fredrik Thulin <[email-masked]> wrote:
> > 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.
>
> 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)?

I think you have a very good point here. Now that people should be well back 
from their easter vacation I would like to ask again that someone explains 
the reason for explicitly forbidding proxys to respond to 407 challenges.

/Fredrik

_______________________________________________
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: Mon, 19 Apr 2004 21:31:22 +0200

Hi!

I think I found another problem - if the proxy inserts the 
Authentication header, the authentication user will likely be different 
to the user in the From: header. Such messages typically will be refused 
by a SIP proxy as this allows to fake the sender id.

regards,
Klaus

---

From: Alex Bligh <[email-masked]>
Date: Mon, 19 Apr 2004 21:00:32 +0100

--On 19 April 2004 21:31 +0200 Klaus Darilion 
<[email-masked]> wrote:

> I think I found another problem - if the proxy inserts the Authentication
> header, the authentication user will likely be different to the user in
> the From: header. Such messages typically will be refused by a SIP proxy
> as this allows to fake the sender id.

That should not create a problem. The original proxy (the one inserting
the header) will presumably have already authorized the user to /its/
satisfaction if it is going to then give its own credentials to the
downstream proxy, i.e. in
   UAC ------> P1 ------> P2 ------> UAS
P1 can authenticate UAC against its own database; only if it is
authenticated will it in turn respond to an authentication request
from either P2 or UAS.

It is /desirable/ that the authentication user is different from the From:
user. This allows P1 to identify /itself/ (in the authentication user). The
idea of the scheme is to prevent P2, UAC from having to know credentials
about UA's such as UAC.

Whether the SIP Proxy P2 or the UAS refuses packets with an authentication
user different from the From: user is a matter of local policy, and is
explicitly not mandated in the standard. In SER, for example, you
have to explicitly require that it checks this. It is quite legal for
the auth user to differ from the From: user.

All P2/UAS wants to know is that the call has been authorized **BY P1**.
Whether this is the "remote media gateway in different administrative
zone" problem, or the "I wish to authorize this SIP call to be diverted
at my expense to my cellphone" problem...

Alex

---

From: Klaus Darilion <[email-masked]>
Date: Mon, 19 Apr 2004 22:32:22 +0200

Alex Bligh wrote:
...
> the auth user to differ from the From: user.
I do this check - but only for local users. So if P2 is the proxy of any 
  termination provider, the From: will be an external domain for P2 and 
no check is necessary.

Short answer: you are right - i shot too fast.

I'm currently thinking about a really dirty hack for this:
before forwarding the request in P1, the request will be handled to an 
externel script (exec module in ser). The script takes the request, 
decreases cseq by 1, sends the request to P2, catches the response, 
filters realm and nonce, calculates the hash and gives the new 
Authentication header back to ser (exec must be enhanced to add 
headers). Then ser will forward the request, which should now include 
proper credentials.

Yes of course this is terrible and wont scale. :-)

klaus

---

From: Alex Bligh <[email-masked]>
Date: Mon, 19 Apr 2004 22:22:30 +0100

...
> Then ser will forward the request, which should now include proper
> credentials.

It doesn't actually look that hard to hack it in ser. But I know I will
(rightly) get far more support from the iptel.org folks if there is some
support for this "not being against the standard" or rather "a useful
modification to the standard", hence my asking the question. I am
sufficiently confident/pigheaded to think "it will work" anyway.

[ your hack decrements cseq by one - I think you will run into the
  possibility with a collision with a previous message, and that the
  proxy etc. may thus ignore it thinking it's a retransmission - you
  would be better to use the same cseq but insert a bogus branch
  value; but even better, do it properly :-) ]

Alex

---

From: Klaus Darilion <[email-masked]>
Date: Mon, 19 Apr 2004 23:56:34 +0200

I just come around another problem:

The reason for me to let the proxy doing the authentication is for 
example the following scenario:

A small company (@smallcomp.com) has its own sip proxy (P1). Local and 
IP calls will work fine. Now, the company wants to make also PSTN calls, 
and gets a single account by any termination provider (vonage, sipgate, 
nikotel...) -> P2. So, their proxy P1 should forward PSTN calls to P2 
and add credentials.

And here is my problem - P2 will verify the From: header. P2 identifies 
an external user (@smallcomp.com != @nikotel.com) and refuses the 
request as externel users are not allowed to access the gateway, even if 
they would send proper credentials. Only local users will be asked for 
credentials.

So, I can't use such a workaround anyway.

and more generic: how will P2 know if the request from P1 should be 
challenged or handled as incoming call (without challenging)?

klaus