Subject: [Sip] Enrollment in SIP services (and should we undeprecate basic auth)

From: "Cullen Jennings" <[email-masked]>
Date: Fri, 20 Dec 2002 11:32:56 -0800

I have been thinking about how devices can easily enroll to some sip
service such as a registrar. In some cases it will be complex and
require credit cards and web pages but in some cases it could be very
simple. Imagine someone was offering a basic service and not directly
charging for it. It would be nice if I could send it a message and it
would create an account for me. 

It seems that a I could send a REGISTER to a registrar. If the registrar
had never heard of my user name before, it could just create it as a new
account. However, I would need to somehow provide it with the password I
wish to use. Using basic authentication over a TLS connection to the
registrar would be a nice way to do this. 

I'm wondering if we should undeprecate basic authentication. Is there
better ways to meet this requirement? Are there other uses for basic
that would support it coming back? 

Cullen

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 20 Dec 2002 14:56:23 -0500

User provisioning (aka enrollment) is not the role of the SIP REGISTER 
request. It usually involves far more than just providing a 
username/password, and for many reasons REGISTER is a poor fit (and 
ultimately, was a poor choice of names because of its (ab)use for things 
that seemed like "registrations"). Genreally I like web-based enrollment 
in applications.

I have been thinking about undeprecating basic, but for a totally 
different reason (which was suggested by Christian some time back). When 
you do authentication over TLS, there is no security benefits to digest 
as opposed to basic. However, with basic, it is easier to integrate with 
back-end AAA systems, because you don't need to assume that they've 
stored the password in the form described in rfc 2617.

Of course, if the server doing the authentication is several hops beyond 
the one you've terminated your TLS connection to, you've got problems. 
The combination of sips and basic would always work, however.

-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

---

From: Robert Sparks <[email-masked]>
Date: 20 Dec 2002 14:21:11 -0600

I see no value at all to resurrecting BASIC.

If you are wanting to provide a shared secret and punt all of the
security responsibilities to the transport layer, then express that
secret in its native form (plaintext for a password). Anything else
you do wastes cycles and encourages people to make bad assumptions
about the level of protection they are getting (increasing the risk
that it would get foolishly used outside the environment you intended
to punt to).

More inline:

> stored the password in the form described in rfc 2617.
I don't understand the last statement. A system that accepts digest
credentials is not required to keep its local knowledge of the password
in the hash recommended in 2617.

---

From: Michael Thomas <[email-masked]>
Date: Sun, 29 Dec 2002 17:23:17 -0800 (PST)

> that it would get foolishly used outside the environment you intended

Er, that's what basic does. The reason that the
password is in uuencode format is, I'd assume, to
provide the ability to ship binary passwords, not
security through obscurity.

		 Mike

---

From: Michael Thomas <[email-masked]>
Date: Mon, 30 Dec 2002 13:33:43 -0800 (PST)

> The combination of sips and basic would always work, however.

While not passing judgement one way or the other,
basic is clearly less secure than digest even with
TLS. With digest, intermediate devices don't see
the cleartext password -- including a directly
adjacent (SIPwise) proxy. The AAA benefit you list
specifically takes advantage of lowering the
security bar (eg, so that the proxy can form a
CHAP/PAP authenticator to send to a AAA). My sense
is that if there are reasons people want to take
advantage of basic, it might be better to consider
the root causes first rather than rushing headlong
into undeprecating (precating?) basic.

		   Mike

---

From: Michael Thomas <[email-masked]>
Date: Mon, 30 Dec 2002 13:37:39 -0800 (PST)

One comment:

 > in the hash recommended in 2617.

The problem is that AAA's expect either a CHAP or
PAP formated authenticator. Digest, while it
doesn't chip the cleartext password ain't the same
format so you have a problem. Basic allows you to
hack up an authenticator at the proxy. Maybe
EAP+digest is our friend. Or maybe not.

	Mike

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 30 Dec 2002 16:59:50 -0500

inline.

Michael Thomas wrote:
> CHAP/PAP authenticator to send to a AAA). 

OK, a good point.

> My sense

I wasn't arguing to rush into anything. It was just a thought.

-Jonathan R.

---

From: Juha Heinanen <[email-masked]>
Date: Tue, 31 Dec 2002 14:15:06 +0200

> EAP+digest is our friend. Or maybe not.

what is wrong with draft-sterman-aaa-sip-00.txt?  we use it with digets
authentication without any problems.  leading radius servers support it
as well as all good sip proxies.

-- juha

---

From: "Nataraju A.B." <[email-masked]>
Date: Tue, 31 Dec 2002 18:43:16 +0530

Hi, 
I have a query regarding the server/user-agent coding format:
The ABNF encoding specifies it as : 

Server           =  "Server" HCOLON server-val *(LWS server-val)
server-val       =  product / comment
product          =  token [SLASH product-version]
product-version  =  token

whereas teh SIP-rfc says it should be 
 Server: HomeServer v2
CanI know the correct format to be used. 

If the SIP format is to be used then is it product version is a mandatory argument. 

I feel the example given might be incorrect.

It must have been like Server: HomeServer /v2

Regards,
-------------------------------------------
Nataraju A.B.
Huawei Technologies India Pvt. Ltd.,
Tel : +91-80-5216824/6/7 Xtn 142
-------------------------------------------
  ----- Original Message ----- 
  From: Juha Heinanen 
  To: Michael Thomas 
  Cc: Robert Sparks ; Jonathan Rosenberg ; Cullen Jennings ; [email-masked] 
  Sent: Tuesday, 31 December 2002 17-45
  Subject: Re: [Sip] Enrollment in SIP services (and should we undeprecate basic auth)

  -- juha

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 31 Dec 2002 09:36:38 -0500

inline.

> CanI know the correct format to be used.

The above is just an example of the server header. It is a valid value 
according to the BNF, since the BNF allows a series of lws-separated 
tokens, without any slashes. Thus, either of these is valid:

Server: HomeServer v2
Server: HomeServer/v2

> If the SIP format is to be used then is it product version is a 

Version is not mandatory according to the BNF.

-Jonathan R.