> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Eric Rescorla > Sent: Tuesday, April 08, 2008 10:28 PM > To: Dan Wing > Cc: [email protected] > Subject: Re: [Sip] E.164 - who owns it > > At Tue, 8 Apr 2008 17:01:40 -0700, > Dan Wing wrote: > > > If you mean "the E.164 number +123456789", say <tel:+123456789>. > > > > > > I don't see anything that will go wrong if people pay attention > > > to what URIs are defined to mean. > > > > > > Now there is a problem with signing tel: URIs, how do you > determine > > > that the signer has the authority to sign a particular > tel: URI, but > > > that's a delegation-of-authority problem that is not inherently > > > different from other delegation-of-authority problems -- > you need a > > > publicly-known root authority and a tree of delegations. > > > > That is one approach to determining who owns something. > > > > I have a different approach, which I derived from how we > determine if > > someone owns an IP address when we receive a TCP SYN that is > > proportedly from that IP address: challange them to prove that > > packets route the other way. Afterall, the Internet does not have > > a central authority for who owns an IP address (or else we could > > secure BGP routing better than we secure it today). > > > > 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. > > While withholding judgement on draft-wing-sip-e164-rrc-01, I don't > think this is that accurate a description of what can be inferred > from the fact that a peer can complete a TCP connection initiated with > a given source IP address. > > As you say, in order to allow a TCP connection to be established, > the passive endpoint requires the active endpoint to prove > (for some value of prove) that it received the passive endpoint's > SYN/ACK by ACKing the passive endpoint's ISN. This arguably serves > at least two security purposes: > > - Prevention of DoS: TCP connections consume resources on the > client. Forcing the client to ACK the ISN prevents blind > resource consumption attacks on the passive endpoint. > (This can also be combined with a stateless cookie technique, > aka SYN cookies) to produce a system where no state is consumed > on the passive endpoint until the liveness check is passed. > > - Endpoint authentication: the ability of the active endpoint > to ACK the ISN demonstrates that the active endpoint is on-path > from the passive endpoint to the claimed initiating source > IP address. > > This second guarantee is very weak for three reasons: > > (1) Many TCP stacks do not use sufficiently random PRNGs to > generate the ISN, in which case sequence number prediction > attacks are a real problem. > (2) Even if the ISN is randomly generated, there are only > 32 bits of ISN, so it's at least theoretically possible > to guess it in a blind attack (though of course very > expensive).
Fortunately SIP does not suffer from a 32-bit number space, so (1) and (2) are not a limitation with draft-wing-sip-e164-rrc. > (3) Even if we ignore the previous two considerations, > all that the ability to ACK the ISN indicates is that > the attacker is on-path. There are many situations > in which an attacker is on-path (wireless being a > commonly cited case). > > It's precisely for these reasons that one cannot use source IP > authentication for TCP connections on the public Internet, that > mechanisms such as .rhosts are deprecated, and that cryptographic > mechanisms such as IPsec were designed. > > Incidentally, this third deficiency seems to me to be shared > by draft-wing-sip-e164-rrc. Any attacker who is on path > between the relying party and the target of the return > routability check (either because they are on-path in > the SIP routing fabric or because they are able to > observe one of the links) will be able to pass the return > routability check. That is correct. A signature generated by the originating domain (e.g., RFC4474) would protect from such an on-path attacker -- unless of course the on-path attacker is also generated the original message and is also on-path for the return routability check. But, then, if the attacker is on-path for the return routability check, they already 'own' that E.164. Ignoring draft-wing-sip-e164-rrc for a minute, any normal INVITE for that E.164 will go to that very same attacker. -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
