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

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 17 May 2001 03:15:08 -0400

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, May 15, 2001 8:32 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: RE: [SIP] WWW-Authenticate in 2xx responses
> 
> 
> Hi,
> 
> > > 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.
> 
> 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;

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.

 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.  

It is, by reference now to rfc2617.

> 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.

There is no Proxy-Authentication-Info defined in rfc2617; if we want such a
thing we will need to define it. Its not clear that we want this.

-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: "Bob Penfield" <[email-masked]>
Date: Thu, 17 May 2001 09:42:28 -0400

In section 13.3 of bis-02, item 5 on page 116 says that Authentication-Info
and
Proxy-Authentication-Info are not used by SIP. Is there any reason why?

This would need to be removed and the headers would need to be added to the
grammar in Table 3 if we want to include them in SIP.

(-:bob

Robert F. Penfield
Chief Software Architect
Acme Packet, Inc.
130 New Boston Street
Woburn, MA 01801
[email-masked]

---

From: Jonathan Lennox <[email-masked]>
Date: Thu, 17 May 2001 10:49:55 -0400 (EDT)

> have this feature. Also note that nextnonce requires state in the server.

No it doesn't.  The server can encode all the state it needs into the nonce.
2617 mentions the possibility of making your nonce values
    time-stamp H(time-stamp ":" ETag ":" private-key)
where H is a one-way-hash function and ETag is a unique value for the
requested entity.

The server just has to re-compute the hash after getting the request to make
sure it hasn't been forged, and then decide if it thinks the timestamp is
recent enough.

> thing we will need to define it. Its not clear that we want this.

It's not formally defined with a grammar and all, but section 3.6 of 2617
says
   On subsequent responses, the server sends Proxy-Authentication-Info
   with directives the same as those for the Authentication-Info header
   field.
so I'd say it's technically there.

-- 
Jonathan Lennox
[email-masked]

---

From: "Brett Tate" <[email-masked]>
Date: Thu, 17 May 2001 16:25:59 -0400

Thanks for pointing out Proxy-Authentication-Info 
and Authentication-Info.  They do appear to be 
better for next nonce than WWW-Authenticate in 
2xx responses.

Usage of these headers would help improve call 
setup time and system/network capacity by 
reducing 401/407 responses from registrars,
outbound-proxies, etcetera.

Henning/Jonathan:
Since authentication and security in the bis 
is slated for rework anyway, can headers
Proxy-Authentication-Info and 
Authentication-Info be added?  If you think 
that there might not be enough interest, can we 
ask the list for comments about its need or 
usefulness?