> 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.
Yes, I agree.
> > 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"?
draft-wing-sip-e164-rrc-01.txt says to turn the SIP URI into a TEL URI,
and then generate a Return Routability Check (RRC) towards that TEL URI:
"1. Strip the domain name of the From: of the incoming INVITE. This
results in a TEL URI. For example,
"sip:[EMAIL PROTECTED];user=phone" is rewritten to
"tel:+14085551212".
2. Rewrite the TEL URI to a SIP URI, following the Verifier's
default routing rules. For example, if outgoing calls are sent
to the service provider example.net, then "tel:+14085551212" is
rewritten to "sip:[EMAIL PROTECTED];user=phone".
3. Generate a random nonce.
4. Using the SIP URI constructed in step (2), construct a SIP
SUBSCRIBE message with Request-URI and To headers that use that
SIP URI, and an "Expires" header of 0. The SUBSCRIBE contains
the random nonce in its body as Content-Type application/
return-routability-nonce.
5. Send the SUBSCRIBE message. This will cause the calling party to
send a NOTIFY."
> 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.
(I assume the omission of "+" in those two URIs was an accident.)
If I receive two Invites on one day from
(a) sip:[EMAIL PROTECTED];user=phone
and
(b) sip:[EMAIL PROTECTED];user=phone
I expect that they were both originated by someone who really does 'own' that
number.
If I turn the SIP URL into a TEL URI (tel:+1234), and route it using my
default routing rules, it could be routed somewhere else
(sip:[EMAIL PROTECTED];user=phone), and then to somewhere else again
(sip:[EMAIL PROTECTED];user=phone). But as long as it eventually arrives at
the same
place as (a) or (b) originated from -- then I am happy that my own outbound
SIP routing thinks that (a) or (b) really do "own" the E.164 number "+1234" --
because that is what my SIP routing says is true.
> > 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.
Doing such would require something, somewhere, to assert who owns a certain
E.164. I don't know how to do that. An ENUM system cannot do that, because
of a pile of reasons (ITU politics, service provider business models, LNP, and
so on). Certificate Authorities, at least as they currently exist, are not
capable of asserting that a company 'owns' a certain E.164 or a range of
E.164s.
draft-wing-sip-e164-rrc is my pragmatic approach to the problem at hand. It
does not require ENUM, does not require CA's to assert who owns an E.164 -- it
uses SIP itself to test if the message was originated from the same place we
would route an E.164 call to.
-d
_______________________________________________
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
