[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sip] Enrollment in SIP services (and should we undeprecatebasic auth)
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:
On Fri, 2002-12-20 at 13:56, Jonathan Rosenberg wrote:
> 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.
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.
>
> 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.
>
> Cullen Jennings wrote:
> > 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 sip-implementors@cs.columbia.edu for questions on current sip
> > Use sipping@ietf.org for new developments on the application of sip
> >
>
> --
> Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave.
> Chief Scientist First Floor
> dynamicsoft East Hanover, NJ 07936
> jdrosen@dynamicsoft.com FAX: (973) 952-5050
> http://www.jdrosen.net PHONE: (973) 952-5000
> http://www.dynamicsoft.com
>
> _______________________________________________
> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip