From: "Dan Wing" <[EMAIL PROTECTED]> > If those URIs included ";user=phone", there is a transitive > relationship between the SIP URI and the TEL URI. Without > ";user=phone", I agree that no meaning is supposed to be applied > to the user-part (the part to the left of the "@"). > > True. In that case, we have SIP URIs which are essentially aliases > for tel URIs. But in that case, any signing should be of the > fundamental tel URI, which then obviates the problem with an SBC that > translates one alias-URI into another.
But the only mechanism we have to sign, RFC4474, does not provide a way to sign a tel URI. OK, so we have several different URIs, sip:[EMAIL PROTECTED];user=phone, which are understood to be equivalent to tel:1234 and also to each other, and because of that, SBCs feel free to translate each of these into each other, but the signing mechanism generates signatures which depend on which of these particular URIs is present. So you have to change either your signing mechanism to recognize the equivalence, or your SBCs to stop exploiting the equivalence. > In SIP, you accomplish something similar to the TCP SYN cookie by > sending a SIP request towards the E.164, asking them to sign the > request and return it to you. Details are in > draft-wing-sip-e164-rrc-01.txt and comments are welcome. > > It seems like this mechanism is at most as certain as the E.164 > mapping that it uses for the "reverse direction". I gather from the > Enum people there is some trouble with that. I don't understand your statement; draft-wing-sip-e164-rrc-01.txt does not use ENUM, rather it uses the same routing that the SIP network (of proxies, B2BUAs, and SBCs) uses. Sorry, I don't understand. You said "sending a SIP request towards the E.164", by which I understand an Enum lookup. Did you mean "sending a SIP request towards a SIP URI which purposts to represent an E.164"? Once we start thinking about that, it opens the can of worms again, in that validating sip:[EMAIL PROTECTED];user=phone is a different operation than validating sip:[EMAIL PROTECTED];user=phone, so we can validate only one of those two purportedly equivalent SIP URIs. This seems to lead back to the position that assuming those two URIs are equivalent for any purpose is a Bad Idea, and therefore we should change the SBCs behavior. > It seems to me that in practice, people don't validate requestors by > checking their apparent IP address, but rather by whether they can > present certificates. But that is probably an issue that has been > hashed over before... s/people/applications/ draft-wing-sip-e164-rrc-01.txt does not have people perform the reverse routability check. The reverse routability check happens without the users noticing, as part of validating that an E.164 request that just arrived would have a new request (towards that same E.164) routing in the same direction. What I mean is that few security mechanisms that I know of depend on determining that the purported origin of a message is its actual origin. In practice, applications use SSL, where identity is determined by certificates presented. Dale _______________________________________________ Sip mailing list https://www.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
