RE: [SIP] DNS SRV and authentication challenges

[Jonathan Rosenberg <jdrosen@dynamicsoft.com>]

> -----Original Message-----
> From: Bob Penfield [mailto:bpenfield@acmepacket.com]
> Sent: Friday, June 15, 2001 4:19 PM
> To: adam.roach@ericsson.com; 'Rich Schaaf'; sip@ietf.org
> Subject: Re: [SIP] DNS SRV and authentication challenges
> 
> 
> > > So, if my reading of the spec is correct, the SIP client 
> is behaving
> > > correctly.  The SIP proxy behavior and DNS configuration also seem
> > > reasonable.  However, the end result is that the call 
> fails to get set
> > > up.
> > >
> > > Please let me know if my reasoning is correct and I welcome any
> > > suggestions on what _should_ happen in this situation.
> >
> > I would contend that, in these cirucumstances, you would
> > need to have some sort of coordination between these
> > "equivalent" nodes. They can share a back-end database
> > or a deterministic algorithm for generating challenges
> > based on, say, a synchronized clock.
> >
> 
> I think it is just as reasonable to allow (or maybe require) 
> the client to
> send the INVITE with authentication to the same network address as the
> initially rejected request. It seems clear to me that the 
> intention of the
> referenced text (section 1.4.2 I believe) was to ensure that 
> any request
> that required state in the "next-hop" server created by a recent prior
> request is sent to the same SIP server. Although technically, 
> it is a new
> transaction, it is still the same "transaction" (placing a 
> call) from the
> user's point of view.

I strongly disagree.

One of the nice things about the current SRV mechanism is that its nicely
layered. To properly implement it, I don't need to know the conditions under
which the transaction is being initiated. If, all of a sudden, I need to
know call level or header-level semantics in order to do the right thing
with SRV, we get a code nightmare. Therefore, requiring that the request for
the INVITE after a challenge result in the same SRV decision as the previous
INVITE is a big mistake, IMHO.

The real problem is this:
>      The SIP client sends a new INVITE request that includes
>      proxy authorization information.  Since this is a new
>      transaction, a DNS SRV lookup is performed by the SIP client
>      (which returns HostB) and the request is sent to the SIP
>      proxy at HostB.
> 
>      The SIP proxy at HostB is not the proxy that issued the challenge
>      to the SIP client so it sends back a "403 Non-Trusted Caller"
>      response and the call fails.

There are at least two things wrong with this proxy. First, and foremost,
since both proxies are the result of lookups for the given domain, they
should be equivalent, in the sense that both have access to the users
username and password, and both are similarly configured. The idea with SRV
is to provide load balancing and failure recovery across a set of
homogeneous servers for a specific domain. This means that when the new
INVITE arrives with credentials, they should be valid at this proxy as well.
The nonce computation will be identical in this proxy, if it follows the
recommended mechanisms in rfc2617 and the two proxies have synced time
(which you want for other reasons).

The second problem is the 403. Why on earth would the proxy send this? The
digest and basic authentication mechanisms are stateless. That is, the
treatment of a request with an invalid Proxy-Authorization header is
identical to the case where no Proxy-Authorization header is present. As a
result of this, the proxy does not need to remember that it issued the
challenge, in order to process the response in the next INVITE. If you have
a proxy which creates state when it issues the challenges, and uses this for
the next INVITE, well, time to throw that one out and buy a good one. This
proxy is easily the subject of a massive DoS attack, since it creates state
for unauthorized requests.

So, in the worst case, the second proxy uses a different set of
configuration params, and is not time-synchronized with the first. What
happens here? This second proxy should have sent a 401, with its own realm
and its own nonce. The UAC generates credentials for this challenge as well,
and in the third INVITE, includes both sets of credentials. It hits one of
the two servers, and since the request has credentials valid at both, it
works just dandy.

In a properly configured network with good proxies, the second transaction
would succeed at the second proxy.

-Jonathan R.

---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
Sip mailing list
Sip@ietf.org
http://www.ietf.org/mailman/listinfo/sip