See below. > -----Original Message----- > From: Dean Willis [mailto:[EMAIL PROTECTED] > Sent: Tuesday, April 17, 2007 10:56 > To: IETF SIP List > Subject: [Sip] Use case: Location server with SIPS and SIP > > > The "sips" thread is getting too darned long to follow. > > I'll try and clearly state my issue, because I think it's > gotten muddled up. > > > Let's assume a very simple model with two users, Alice and > Bob, and a registrar/location server to which Bob registers. > > Bob registers a SIPS contact with the LS. > > Alice sends an authenticated INVITE to the LS. The R-URI of > this INVITE is Bob's AOR expressed as a SIP AOR. > > The LS returns a 302 with a SIPS contact for Bob. > > Alice's UA doesn't understand SIPS, so it sends a SIP INVITE > to Bob's Contact. > > Whether or not Bob's UA rejects the INVITE, information > potentially sensitive to Bob has been disclosed outside of > the authorization model. > > > Does the preceding violate the current specification? If so, > in what way?
There is a violation of RFC 3261 in your model. If Alice receives a 3XX with a SIPS contact, it shouldn't "try SIP". That is a violation of 3261. That being said, as we know, not all UACs are perfect. If it blindly ignores the scheme, it is possible that it will send a new INVITE with the wrong scheme. This is functionaly the same scenario is the dumb user who sees a SIPS scheme, ignores it and use sip instead. There is nothing that can be done to stop the "damage" being done until we reach either Bob's proxy or Bob's UA. Bob proxy may have a rule to reject anything not SIPS. Or Bob's UAS's may reject otherwise. > Consider also that the LS could be replaced by an LDAP > database, or by the REGISTER-as-lookup mechanism of dSIP, or > any number of other analogous location-query protocols. I don't think it would change anything to the description above. _______________________________________________ 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
