Subject: RE: [SIP] The Null authentication scheme

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 26 Sep 2000 22:36:30 -0400

I would argue that the server should have well defined mappings from
strength of authentication to services provided. That is, if the UAC chooses
the null scheme, the server will accept that, but won't do much useful for
that user.

-Jonathan R.

----
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com 
-----Original Message-----
From: Phil Hoffer [mailto:[email-masked]]
Sent: Tuesday, September 26, 2000 11:50 AM
To: [email-masked]
Subject: RE: [SIP] The Null authentication scheme

Hi,

Just a quick point/question?

Section 1.2 of rfc2617.txt states that the authenticating entity MUST
include
a WWW-Authenticate (or Proxy-Authenticate) header with at least one
challenge
applicable to the requested resource.

It goes on to state that the user agent responding to the challenge MUST
choose to
use one of the challenges with the strongest auth-scheme it understands.

Consider then if a WWW-Authenticate header is returned with multiple
challenges,
e.g. Digest and Null

Does the selection by the user agent break the "strongest challenge rule" if
it chooses
to use the Null authentication scheme?

In the strictest terms I suppose it does.
However, I can also see the argument that the caller didn't get to contact
the original callee directly.

Maybe a clarification is required !???

WDYT?

Phil

http://www.ubiquity.net

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: "Phil Hoffer" <[email-masked]>
Date: Wed, 27 Sep 2000 10:07:32 +0100

> the null scheme, the server will accept that, but won't do much useful for

Hi Jonathan,

I agree with your sentiments, but the UAC is forced to select the strongest
scheme from the ones detailed in the challenge.
That criteria is a MUST in rfc2617.

So for a UAC faced with two authentication schemes in a challenge, e.g.
Digest & Null, then the UAC has no choice (assuming it can perform Digest
authentication), according to rfc2617, but to respond using Digest
credentials. If the UAC selects the weaker scheme it violates rfc2617.

Presumably, a couple of things must occur:

1) The strength of the Null scheme must be defined with respect to other
schemes. I'm assuming that it will be classed as the weakest of the current
schemes.

2) If the mandatory strength condition for the UAC defined by 2617 is to be
loosened by the Null scheme then it must be documented. (Are you allowed to
loosen the mandatory condition?)

Phil

http://www.ubiquity.net

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 27 Sep 2000 11:26:30 -0400

> schemes. I'm assuming that it will be classed as the weakest of the current

Yes.

> loosen the mandatory condition?)

Before getting to worried about this aspect, it might be worthwhile to
review the motivation. The "UAC must choose strongest scheme" is meant
to avoid that the UAC or some third party snoop substitutes Basic when
Digest was called for, thus allowing it to subvert the authentication
intent. (Since the outcome after authentication is the same regardless
of whether a stronger or a weaker scheme was used.) Substituting Null
when the UAC can do Digest, say, helps neither the UAC (since it will
get inferior service) nor the intruder (since it could have generated
that unauthenticated request by itself).

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: Michael Thomas <[email-masked]>
Date: Wed, 27 Sep 2000 08:36:53 -0700 (PDT)

There seems to be a lot of conflation of
algorithms and users going on here.

I still don't understand why this is more desirable
than having a BCP which says that if you want to
authenticate as an anonymous user, use Basic with
guest/anonymous/null/whatever and no password.

This works for ftp, there doesn't seem to be a
burning need in http; why is SIP different in this
regard?

		Mike

---

From: [email-masked]
Date: 27 Sep 2000 17:35:31 -0000

I think Michael is making a very good point here. There
is no real need to invent the NULL authentication scheme -
simply use another username which may have limited privileges.
(e.g user: anonymous, pass: [email-masked] pretty much like anonymous
ftp). The system administrator can also create/allow/disallow such
a user, at will, with ease and without having to learn about a
new authentication scheme)

Actually Michael's idea seems more powerful as you can define
many classes of users, if one needs to do so at some other
time.

Thoughts?

Shiv

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 27 Sep 2000 19:51:43 -0400

> burning need in http; why is SIP different in this

One could argue that if Null had existed, we wouldn't have to have a
special name :-)

I generally agree that this is roughly equivalent. One advantage is that
it makes it more explicit whether anon. "login" is permissible or not.
With just a Basic challenge, I would have to try anon., then be told
"sorry". 

That said, I'm not wedded to the particular proposal, just to the need
for doing something along this line. Adding a sentence like

"It is RECOMMENDED that SIP servers utilize the user name "anonymous"
and password "[what should this be - empty?]" if it is desired to allow
non-authenticated requests. Such requests MAY receive treatment that
differs from authenticated requests."

doesn't require a BCP, I believe.
-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: "Phil Hoffer" <[email-masked]>
Date: Fri, 29 Sep 2000 10:34:38 +0100

> burning need in http; why is SIP different in this

Well the difference is that with http is that if authentication is enabled
you either have access or you don't.
What is being proposed is a mechanism which says I know I don't have access
to this service/resource, but can you help me out here with a lesser
service/resource.

This mechanism does seem more straightforward, and presents no security risk
as the anonymous nature of the username and password is not compromised by
the Basic authentication scheme.

My earlier concerns about the mandatory requirement of strongest
authentication scheme selection still stands.
That said I'm sure that this can be documented.

HTH
Phil

http://www.ubiquity.net

---

From: Michael Thomas <[email-masked]>
Date: Fri, 29 Sep 2000 11:26:37 -0700 (PDT)

> you either have access or you don't.

   That's only pertinent for static content.

	       Mike