Subject: RE: [SIP] The Null authentication scheme

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 25 Sep 2000 09:56:12 -0400

I think its a good idea. It allows a server to distinguish:

1. I haven't provided credentials yet,
2. I don't have any valid credentials for this domain

The treatment of these two will, in many cases, be different. Case (1)
usually results in a challenge. Case 2 might allow the call to proceed, or
be rejected definitively, or something.

-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: (973) 952-5000
http://www.dynamicsoft.com

> -----Original Message-----
> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Sunday, September 24, 2000 9:47 AM
> To: [email-masked]
> Subject: [SIP] The Null authentication scheme
> 
> 
> Following some internal discussions, I wrote up a very short 
> I-D on the
> Null authentication scheme. Motivation is in the draft:
> 
> http://www.cs.columbia.edu/~hgs/sip/drafts/draft-schulzrinne-s
> ip-null-00.txt
> 
> Before I submit this as an I-D, I'd like to know if this is a 
> completely
> brain-dead idea.
> -- 
> Henning Schulzrinne   http://www.cs.columbia.edu/~hgs
> 
> 
> 
> _______________________________________________
> SIP mailing list
> [email-masked]
> http://lists.bell-labs.com/mailman/listinfo/sip
> 

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

---

From: [email-masked]
Date: Tue, 26 Sep 2000 09:10:11 +0530

jo> Imagine the following scenario:
jo> I make a SIP call from my UA, which is challenged.  The Realm of
jo> the challenge is unrecognised by my UA, so it gives me some sort
jo> of way to enter my credentials.  I have no credentials for this
jo> Realm, but I would like to try the call anyway.  With the normal
jo> "OK"/"Cancel" (use-this-username-password/hang-up-call) approach,
jo> what can I possibly do?  Having a `Null' scheme allows the UA
jo> to add an extra button: "Please take my call even though you don't
jo> know me".

Actually what I was pointing at was that if my client had made the call,
and the
server did support a "Null" Auth scheme, the first call itself would not be
rejected -
the server would see that the client had not supplied auth info, and so by
default goes
to the 'Null' handler anyway. Basically I see no harm in the server being
active in this
role rather than being passive.If it does not find an auth scheme, let it
go ahead and
put the call in its Null auth handler anyway. Why does it have to first
reject the call,
and only if the client specifies Null later it accepts it ?
I think this I-D suggestion comes into use if the server plays a passive
role.

Regds
Arjun
--
Arjun Roychowdhury @ Hughes Software Systems

"Jo Hornsby" <[email-masked]> on 09/25/2000 07:15:28 PM

To:   archow, "Henning Schulzrinne" <[email-masked]>
cc:   [email-masked]

Subject:  RE: [SIP] The Null authentication scheme

> Hi, this seems to be useful if its the server who prompts the
> question of "I support Null, if you care".  However, if I take the
> approach of the client saying "Here is an unauthenticated request,
> process as you may" to the server:
>
> A client passes its authentication info to the server if it wants
> to. If it does not, and the server supports 'no authentication'
> scheme, it anyway proceeds to treat this request as an unknown.

Hmmm... I'm not sure that this is necessarily true.

Cheers,

 - Jo.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 26 Sep 2000 10:51:09 -0400

> Sent: Tuesday, September 26, 2000 9:44 AM
> To: Jo Hornsby
> Cc: [email-masked]
> Subject: Re: [SIP] The Null authentication scheme
> 
> 
> Jo Hornsby wrote:
> > 
> > Hi,
> > 
> > I've just noticed a small discrepancy.
> > 
> > 2617 specifies the following:
> >         challenge   = auth-scheme 1*SP 1#auth-param
> > which:
> >         challenge   _  "Null"
> > would seem to disobey.  It's a small problem, but it made me
> > think...
> > 
> > How about requiring that a Realm is specified along with the
> > Null challenge; this way, if a UA receives multiple challenges
> > (say due to a forking proxy), it will potentially be able to
> > pick a preferred Realm that it has no credentials for?
> 
> Indeed, I missed the sentence in 2617 that says
> 
> The authentication parameter realm is defined for all authentication
>    schemes ...
> 
> Not sure what a realm means here, but it would allow to do something
> like
> 
> realm="For unauthenticated calls"
> 
> I added this to the text.

I think realm should be what it always is; a token specific to the
challenging server.

The idea is that if there are two proxies on the path, each of which
requires proxy authorization, and I have credentials on just one, my
Proxy-Authorize header might look like:

Proxy-Authorize: Null realm="proxy1"
Proxy-Authorize: Digest realm="proxy2", username="Mufasa",
    response="6629fae49393a05397450978507c4ef1"

-Jonathan R.
---

---

From: "Phil Hoffer" <[email-masked]>
Date: Tue, 26 Sep 2000 16:50:00 +0100

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 28 Sep 2000 12:55:07 -0400

Actually, I like this better too.

It does need to be documented somewhere, though.

-Jonathan R.

---

> From: Michael Thomas [mailto:[email-masked]]
> Sent: Wednesday, September 27, 2000 11:37 AM
> To: Henning Schulzrinne
> Cc: Phil Hoffer; Jonathan Rosenberg; [email-masked]
> 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
> 
> Henning Schulzrinne writes:
>  > Phil Hoffer wrote:
>  > > 
>  > > > 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.
>  > > 
>  > > 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.
>  > 
>  > Yes.
>  > 
>  > > 
>  > > 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?)
>  > 
>  > 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).
>  > 
>  > --