Subject: RE: [SIP] DNS SRV and authentication challenges

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 16 Jun 2001 02:34:11 -0400

> -----Original Message-----
> From: Bob Penfield [mailto:[email-masked]]
> Sent: Friday, June 15, 2001 4:19 PM
> To: [email-masked]; 'Rich Schaaf'; [email-masked]
> 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
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
Sip mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/sip

---

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 18 Jun 2001 21:36:42 +0300

Hello,

> INVITE is a big mistake, IMHO.

I agree with you that the protocol should ONLY ensure that
1) retransmissions of a request
2) ACKs for non 2xx reponses
3) CANCELs
are sent to the same network address than the initial request.

Since a second INVITE with authentication stuff is not any of these 3
cases, we should use the randomization algorithm used for choosing one
network address among all the SRV records provided.

However, I do not agree that we run into a code nightmare. I believe
that the code would be even simpler. Right now, in order to send
retransmissions, CANCELs and ACKs to the same network address we
typically use a hash of some fields, such as To, From, the numeric part
of the Cseq and the Call-ID. If intead of using all these variables we
just use the Call-ID, all the requests within a call will be sent to the
same network address.

Folks might argue that we lose some randomization power by excluding the
From, To and Cseq fields in the hash calculation, but I do not think it
really matters. These variables provide randomization only within a
call. Randomization among different calls is equally acomplish by using
just the call-ID.

I also agree that mechanisms that send challenges back to the client
should be stateless, since otherwise the server will be an easy target
for a resource attack. But I can think of different scenarios where
sending requests with the same Call-ID to the same network address might
be useful. For example, a client that sends an INVITE and before the
callee picks up wants to terminate the call attempt. If this client
sends a BYE rather than a CANCEL, it would be nice if it arrives to the
same network address. Mainly if the callee is behind a gateway that was
located using SRV.

Best regards,

Gonzalo

-- 
Gonzalo Camarillo                    Phone :   +1 212 939 71 71
Columbia University                  Mobile:  +358 40 702 35 35
472 Computer Science Building        Fax   :  +358  9 299 30 52
1214 Amsterdam Ave., Mail Code 0401  http://www.hut.fi/~gonzalo
New York, NY 10027                   
USA                              [email-masked]