Subject: Re: [Sip] Open Issue #204: Password in To/From URL

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 27 Dec 2001 00:35:07 -0500

Henning G. Schulzrinne wrote:

> Jonathan Rosenberg wrote:
> 
>>Issue:
>>
>>Minor issue.
>>
>>The From field allows a password in the URL, but not the To field. This is
>>not discussed and seems inconsistent. We should either allow it in both or
>>document the reason.
>>
>>Discussion:
>>
>>I suspect the main application of the password in From is for things like
>>PIN codes; it provides a simple, yet thoroughly insecure, way to identify a
>>user. Its not clear what a password in To would mean. Perhaps it provides a
>>password valid to talk to the specific user in the To field. However, as
>>requests can be forwarded, this password would not be valid in many cases,
>>and would potentially directly provide password information to the wrong
>>user.
>>
>>Its probably sensible to restrict usage of the password as much as possible.
>>
>>Proposal:
>>
>>Keep restriction. Document usage in From as identifying subscriber, and
>>indicate that it makes no sense to have in in the To.
>>
> 
> I can't quite parse your initial statement: "The From field allows a
> password in the URL, but not the To field." Theoretically, passwords
> could appear in
> 
> - request-uri
> - To
> - From
> 
> Having it in the destination (request-URI) has some modest value, but
> adding it to the To header field doesn't seem to add any. Thus, I think
> we're in agreement, but just wanted to make sure:
> 
> - request-uri = yes(*)
> - To = no (since already in the request-uri for the destination)
> - From = yes(*)
> 
> (*) with the usual caveats

Yes, this was my proposal. More specifically, the proposal was to add a 
line or two of motivating text explaining why.

> 
> The only reason I can see to allow this in the To header is that
> typically, if you click on a web link such as
> sip:alice:[email-masked], it would be copied into both request-URI
> and To. Since we wanted to treat the user:pw as effectively a single
> string, it would seem easier not to special-case this and forcing the
> program to strip the 'pw' part.

Hmm. This is quite a good point.

Another point worth noting, thinking about it some more, is that in the 
most basic case, the r-uri will be rewritten with the registered contact 
of the called party, so the called party won't ever see the password 
(I'm assuming that the password is NOT part of the address-of-record). 
Thus, it does need to be in the To field to get to the called party, as 
it has e2e significance supposedly....

OK, so now I am going to back track, and rather propose to allow 

the password in the To field, documenting its real uses and limitations 
of course.

Comments?

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[email-masked]                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
Sip mailing list  http://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: Henning Schulzrinne <[email-masked]>
Date: Thu, 27 Dec 2001 03:36:05 -0700

> the password in the To field, documenting its real uses and limitations

The fewer special cases, the better, so allowing it (with caveats) in
the three places seems like the right approach. It really is just a user
name convention (something that some people emulate in email, but which
requires special software help, as in joe+ or joe+lists.)