Subject: RE: [SIP] WWW-Authenticate in 2xx responses

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 15 May 2001 01:43:00 -0400

> -----Original Message-----
> From: Brett Tate [mailto:[email-masked]]
> Sent: Monday, May 14, 2001 3:58 PM
> To: SIP (E-mail)
> Subject: [SIP] WWW-Authenticate in 2xx responses
> 
> 
> The bis currently reflects that the WWW-Authenticate 
> header can only be in requests and 401 responses.
> Can the WWW-Authenticate header be passed within a 
> 2xx response (updating nonce) to hopefully avoid 
> some extra 401's during subsequent 
> registrations/requests directed to the same 
> registrar/UAS?

No.

The way to avoid the extra 401s is to cache the credentials, and resubmit
them for any subsequent requests to the same URI. In other words, you don't
wait for a 401 to insert an Authorization header. Each request for the same
URI contains any Authorization header sent previously to that same URI. The
nonce may have become stale, in which case the request will generate a 401
which effectively refreshes the nonce.

> 
> The bis currently reflects that Proxy-Authenticate 
> can only be in 401 and 407.  Can the Proxy-Authenticate 
> header be passed within a 2xx response (updating nonce) 
> to hopefully avoid some extra 401/407's for subsequent
> requests/calls through an outbound proxies?

Same as above.

-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

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementor's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to 
[email-masked] with "subscribe" in the body.

---

From: [email-masked]
Date: Tue, 15 May 2001 15:31:57 +0300

Hi,

> which effectively refreshes the nonce.

But isn't the point here, that nonces ultimately do become stale, and must
at some point be refreshed in the 401s. Hence generating "extra" 401s,
sooner or later.

In my opinion, this is not entirely necessary. HTTP Authentication does
specify a header to be inserted to responses by the server, namely
Authentication-Info, which is used to convey next nonce as well as provide
for mutual authentication in HTTP.

It is beyond me, why this functionality wasn't originally copied to SIP; the
registration scenario at least is analogous to where Authentication-Info is
used in HTTP. Henning's current draft on registrations addresses this issue
shortly, but I really think that the Authentication-Info (and possibly
Proxy-Authentication-Info) header should be added to the bis draft.  

Old-school clients can always ignore the header and only pick up nonces from
401s. Or does this add some additional complexity, that I have missed? The
extra added value in Authentication-Info would then be mutual
authentication, i.e. the client authenticating the server, which can't be
done in current SIP. So isn't bringing these info headers to SIP worth
serious considering?

Of course, Proxy-Authentication-Info in SIP is tricky, since I guess it
would demand the authenticating server to Record-Route and be stateful. But
a registrar using Authentication-Info would be perfectly in-line with HTTP
Authentication.

BR,
Aki

---

From: [email-masked]
Date: Thu, 17 May 2001 12:42:49 +0300

Hi,

> 
> Because 2617 > 2543. Digest in rfc2543 is based on rfc2069, 
> which didn't
> have this feature. Also note that nextnonce requires state in 
> the server.

OK. But how does nextnonce require any more state in the server than does a
simple 401 conveyed nonce? Even with Authentication-Info, the server only
needs to cache the nonces it has sent, right? Again, Authentication-Info
would only be sent by a server terminating the request, e.g. a registrar.
After a registrar has sent the new nonce and cached it, it can forget about
it. Doesn't matter whether the nonce left in a 401/WWW-Authenticate, or a
200/Authentication-Info.

As far as the mutual authentication part is concerned, sending
server-credentials in Authentication-Info should be as stateless by nature
as sending client-credentials in Authorization. In my opinion, neither case
introduces a need for state in the server.

It's a different case for Proxy-Authentication-Info, in which the server has
to maintain state in order to be able to insert the header into a returning
2xx response. But this shouldn't be a problem if we just add a disclaimer
saying that if Proxy-Authentication-Info is used, the server must be
stateful.

>  the
> It is, by reference now to rfc2617.

Then it has to be made a lot clearer. At least the bis-02 says in chapter
13.3:
"
	5.   The Authentication-Info and Proxy-Authentication-Info
           fields are not used in SIP.
"
And since the BNFs of Authorization, Proxy-Authorization, and
WWW-Authenticate and Proxy-Authenticate are spelled out in the SIP bis
draft, I think it would be nice to have them for the Info headers as well.

BTW, Proxy-Authentication-Info is defined in rfc2617. Its semantics are
equal to those of  Authentication-Info. The only difference is that
Proxy-Authentication-Info is used with Proxy-Authenticate and
Proxy-Authorization headers with 407s, whereas Authentication-Info is used
with WWW-Authenticate and Authorization headers with 401s. 

BR,
Aki