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).
(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.
-Ekr
_______________________________________________
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
