I think this is different than listed vs. unlisted. If I register a SIPS URI with my registrar and receive only SIPS calls, then no one except my registrar and perhaps the folks that successfully contact me, know the details of my registration binding(s). A 3rd party would not know who I am or who called me. If someone calls me using SIP, all of this can be learned by a 3rd party observing the traffic, even if I reject the request. Note, I am assuming the SIP request was not sent via TLS for at least one hop. If each hop uses TLS, then it really does not matter whether the URI was SIP or SIPS.
Cheers, Charles > -----Original Message----- > From: Paul Kyzivat (pkyzivat) > Sent: Tuesday, April 17, 2007 5:55 AM > To: Dean Willis > Cc: sip@ietf.org > Subject: Re: [Sip] SIPS question: How to prevent plaintext > requests from beingdelivered to a UA > > Dean, > > I think you are trying to associate two distinct semantics > with sips URI: > - that sessions established using this URI should be secured > hop by hop from end to end > - that such a URI should be considered "unlisted" and so kept > "secret". > > IMO these semantics should not be conflated because: > > - I may want to have a sip (or tel or IM or PRES) URI > that is "unlisted", and I may want to have a sips URI > that is "listed". > > - The semantics of of being "unlisted" are likely to be > just as hard to pin down as the semantics of sips for > e22 security is. IMO we don't want to hold up the clarification > of sips until that can be done. > > Paul > > > Dean Willis wrote: > > Paul Kyzivat wrote: > >>> > >>> If Alice had just not sent the request via SIP, but used > SIPS, the it > >>> would have been solved. > >> > >> Unless Alice believes that the address itself is a secret to be > >> protected, she may not protect it. > > > > Exactly my point. She needs to KNOW that if she's given a > SIPS address, > > that it should be protected by using it only for SIPS requests. > > > >> > >> AFAIK, there has never been any expectation that the presence of > >> "sips" in the URI carried an expectation that somebody > possessing such > >> an address keep it confidential. Quite to the contrary, I > have assumed > >> that the expectation was that it might be put on business cards, > >> stored in directories, ENUM, etc. > > > > True. But if I give you my private unlisted number for > encrypted calls > > and you start posting it on web pages with text that says > "For a good > > time, call" , I'm gonna be angry. And I'll be only > marginally less angry > > if you start schlepping it across the net in unprotected > SIP INVITEs. > > > >>>>> Since traceroute on biloxi.example.com may well give us > a good idea > >>>>> of the physical location of biloxi.example.com, an interceptor > >>> > >>> In the call flow described (from 3665) there is no home proxy. > >>> > >>> THERE IS NO REQUIREMENT THAT SIP USERS HAVE A HOME PROXY > AND I WOULD > >>> BE VERY HAPPY IF PEOPLE WOULD REMEMBER THAT! > >> > >> Its fine for there to be no home proxy. But if so, then Bob must > >> publicize his actual address, and expect that bad guys may > get access > >> to it. > >> > > But Bob may publicize his actual address only within the > confines of a > > directory or location server that makes that address > available only to > > authenticated and authorized parties. > > > > Alice sends INVITE for Bob' s SIPS AOR to Bob's LS. > > Bob's LS returns a WWW-Auth to Alice. > > Alice replies with credentials. > > Bob's LS returns a SIPS contact. > > Alice sends a SIP INVITE to the equivalent contact. > > > > This is perfectly legal by the current draft as I > understand it, and > > Alice would expect that it would work. > > > > But it will completely compromise the secrecy of Bob's AOR->Contact > > binding, and Bob has no way to say "DON"T DO THIS TO ME!". > > > >>> But IF there had been a home proxy in this example, and > the request > >>> were intercepted between Bob's home proxy and Bob, then it would > >>> reveal Bob's location as understood by Bob's home proxy. > >> > >> I thought the idea was that Bob himself had only the sips > address. So > >> the link between Bob's home proxy and Bob would always be > via TLS. So > >> the message won't be intercepted on that leg. It would have to be > >> intercepted before reaching his home proxy. And there it > would only > >> reveal his AOR. > >> > > > > No, that wasn't the case I was trying to (and apparently > failing to) > > explain. > >> > >> I guess we are making some significantly different > assumptions about > >> what is going on. > >> > > Ah, that's probably true. > > > > > > -- > > Dean > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use [EMAIL PROTECTED] for questions on current sip > Use [EMAIL PROTECTED] 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 [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
