Thank you Jonathan.
How ironic you cite the need to minimize user entry problems.
Our interface is limited, and our end users are unfamiliar,
so we are as sensitive or more to the need of entering multiple
username/passwords. Without a username context this
is less possible when calling multiple realms.
Alternatively, the username would likely need to become
a full length globalized number (like +18475551212) or nearly so.
In reality SIP proxies and resources will adapt, so
your problem is not so big.
I see the argument of needing to keep only the
hash of the "username:realm:password" in the authenticating
database for security, and this is made difficult with
many domain aliases. Although, databases will already code
multiple hashes per user to support shorter
centrex style nicknames, and stealing the backup tapes
is not safe because users don't enter enough entropy
to thwart dictionary attack.
If I am advocating dialing plans based on clues in the
"from" field, I suppose an authenticating resource can
cheat as well. Nevermind, authentication has more
problems because of non-initiated calls where the
"from" is remotely chosen.
Nonetheless, we will probably appease you on this one, and
spare you a longer analysis.
If a visitor enters a globalized number and the phone appends
the wrong domain this would be fairly broken.
Cheers,
Rick
3Com
P.S. Is it more okay to mention company names and
implementation specifics on the sip-implementors
list than the IETF ones? I should think
it is, and more useful to speak about implementations
directly.
On Wed, Jan 24, 2001 at 10:26:14PM -0500, Jonathan Rosenberg wrote:
> Folks,
>
> An issue seems to have come up amongst several production implementations,
> and some folks are claiming that what they are doing is "within the scope of
> the spec", when indeed it is not.
>
> The issue is the value of the username attribute for the digest
> Authorization header. When the proxy (or UAS) issues a challenge, the client
> is supposed to query the caller for their username and password within the
> specified realm. Apparently, one client implementation takes that username
> value, and automatically appends a "@domain.com", where domain.com is some
> domain name extracted from either the 401/407 or a static configuration (not
> sure which). This user@host value is then placed in the username parameter
> of the Authorization header. They apparently do this because a proxy vendor
> claimed that this was allowed within the spec, and was required by that
> particular proxy vendor.
>
> This is simply wrong.
>
> The username and password have NO SEMANTIC SIGNIFICANCE to any SIP system.
> Their values are pre-arranged between the provider and the user. If one
> provider wishes for users to type in their full user@host names, thats fine;
> they simply tell their subscribers that this is what to enter, and they set
> up their databases to be keyed off of the whole thing. Other providers may
> choose to just use a username. Others may use phone numbers. A SIP system
> cannot make any assumptions about the meaning or construction of these
> fields, period. A client should pass exactly the username and password
> received into the algorithm, and return that username exactly in the
> Authorization header.
>
> If this problem persists, end users will need to be told to enter different
> values depending on the client software and/or proxy in use. Very bad. Fix
> this problem, please.
>
> -Jonathan R.
>
> ---
> Jonathan D. Rosenberg 72 Eagle Rock Ave.
> Chief Scientist First Floor
> dynamicsoft East Hanover, NJ 07936
> [EMAIL PROTECTED] FAX: (973) 952-5050
> http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000
> http://www.dynamicsoft.com
>
> _______________________________________________
> Sip-implementors mailing list
> [EMAIL PROTECTED]
> http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
