> -----Original Message-----
> From: Elwell, John [mailto:john.elwell siemens.com]
> Sent: Tuesday, November 27, 2007 2:46 AM
> To: Dan Wing; Jonathan Rosenberg
> Cc: Cullen Jennings; IETF SIP List; Paul Kyzivat
> Subject: RE: SIP E.164 Return Routability Test [was RE:
[Sip]
> comments ondraft-ietf-sip-dtls-framework]
>
> Dan,
>
> I am missing something here. Let me try to explain my
concern.
>
> Suppose I have an INVITE request from +123456789example1.com, which
> goes through domains example2.com and example3.com
before arriving at
> example4.com, where the signature (according to RFC
4474 or
> draft-wing-sip-identity-media) is verified. Domain
example2.com or
> example3.com remembers information from the INVITE
request (e.g., the
> cookie, the certificate fingerprint). Domain
example4.com issues a
> SUBSCRIBE request, which let's assume gets routed
through domain
> example3.com or example2.com, which terminates the
SUBSCRIBE
> request and
> sends a NOTIFY request, using the saved cookie and
> fingerprint. In this
> case, the verifier should see that the RFC 4474 or
> draft-wing-sip-identity-media signature is from domain
example2.com or
> example3.com, i.e., a different domain from that of the
> original INVITE
> request. On this basis the verifier could decide not to
trust it.
>
> But this still requires draft-wing-sip-identity-media,
> because with RFC
> 4474, if example2.com or example3.com resigns the
original INVITE
> request using +123456789example2/3.com, the INVITE
and
> NOTIFY requests
> will still be signed by the same domain, so the
verifier in
> example4.com
> still has no evidence that the INVITE request
originated in
> example1.com.
Right. But, what the verifier in example4.com now knows is
that SIP routing towards that E.164 gets routed through
example2/3. The verifier in example4.com knows and trusts
his own forward routing; the verifier in example4.com has
no idea how other SIP nodes are routing SIP messages
towards
example4.com.
My strawman is akin to a TCP SYN cookie, and akin to the
nonce in SIP's Digest authentication. Neither my strawman,
nor TCP SYN cookies, nor SIP's Digest authentication nonce,
prove that you're really talking to the same source that
sent you the original message (SIP INVITE, TCP SYN,
SIP REGISTER). Rather, they prove you have return
routability
to an attacker (who now needs to be on the forward and
reverse paths) or to the originating endpoint.
It's a strawman idea to provide additional identity; perhaps
it has insufficient value for the problem at hand.
-d
> John
>
> > -----Original Message-----
> > From: Dan Wing [mailto:dwingcisco.com]
> > Sent: 27 November 2007 08:30
> > To: Elwell, John; 'Jonathan Rosenberg'
> > Cc: 'Cullen Jennings'; 'IETF SIP List'; 'Paul
Kyzivat'
> > Subject: RE: SIP E.164 Return Routability Test
[was RE: [Sip]
> > comments ondraft-ietf-sip-dtls-framework]
> >
> >
> >
> >
> > > -----Original Message-----
> > > From: Elwell, John [mailto:john.elwellsiemens.com]
> > > Sent: Tuesday, November 27, 2007 12:05 AM
> > > To: Dan Wing; Jonathan Rosenberg
> > > Cc: Cullen Jennings; IETF SIP List; Paul
Kyzivat
> > > Subject: RE: SIP E.164 Return Routability
Test [was RE: [Sip]
> > > comments ondraft-ietf-sip-dtls-framework]
> > >
> > > Dan,
> > >
> > > What prevents an intermediate domain saving a
copy of the
> > > cookie and the fingerprint and using them to
construct the
> > > NOTIFY?
> >
> > I used a Notify is a SIP request, and would be
signed (using
> > RFC4474 or SIP-Identity-Media) by the originating
domain.
> >
> > -d
> >
> > > For
> > > scenarios where
> > > the return routing goes through an
intermediate domain that
> > the INVITE
> > > came through, this would appear to eliminate
the
> usefulness of this
> > > technique. Perhaps the calling UA needs to
sign something in
> > > the NOTIFY
> > > to prove ownership of the private key whose
certificate
> > > fingerprint has
> > > been sent.
> > >
> > > John
> > >
> > > > -----Original Message-----
> > > > From: Dan Wing [mailto:dwingcisco.com]
> > > > Sent: 27 November 2007 01:15
> > > > To: 'Jonathan Rosenberg'
> > > > Cc: 'Cullen Jennings'; 'IETF SIP List';
Elwell, John;
> > 'Paul Kyzivat'
> > > > Subject: SIP E.164 Return Routability
Test [was RE: [Sip]
> > > > comments on
draft-ietf-sip-dtls-framework]
> > > >
> > > > In one message, Jonathan Rosenberg
wrote:
> > > >
> > > > > My current view, unfortunately, is
that, in environments that
> > > > > use phone numbers as identifiers,
4474 and DTLS-SRTP add no
> > > > > security whatsoever above their
"weaker" cousins - 3325 and
> > > > > sdescriptions. If we all agree this
is in fact true, that
> > > > > better be amazingly clear in
documents we are
> > > > > producing. Since right now it
isn't.
> > > >
> > > > This is not a defect or deficiency of
DTLS-SRTP, as Eric
> > > > pointed out. Rather, it is a deficiency
caused by SIP's
> > > > use of the E.164 namespace (which humans
understand) in
> > > > conjunction with domain names; mixing
them doesn't work
> > > > well. It comes down to the question:
are these
> > > > equivalent:
> > > >
> > > > +1-408-555-1234att.net
> > > > +1-408-555-1234toms-pizza.sj.ca.us
> > > >
> > > >
> > > > In another message, Jonathan Rosenberg
wrote:
> > > >
> > > > > The root issue is that
FUNDAMENTALLY, phone numbers are
> > > not scoped
> > > > > within a domain. For this reason,
the mapping that exists
> > > > in peoples
> > > > > heads from identifiers to users is
of one of two forms:
> > > > >
> > > > > "userdomain" --> some
person
> > > > > "1 (408) 902-5000"
---> some person
> > > > >
> > > > > so, even if you user interface
could render the fact that,
> > > > > the call was from
sip:14089025000somedomain.com, I believe
> > > > > that users would anyway ignore the
domain part since there is
> > > > > no domain part for phone numbers.
> > > >
> > > > Right. The problem is mixing E.164
namespace with SIP
> namespace.
> > > >
> > > > But for SIP identity, we need to decide
if an entity
> > > > that signed an E.164 is authorized, by
our own domain's view
> > > > of 'authorized', to sign for it.
> > > >
> > > > Cullen suggests that the RFC4474
Verifier have a list of
> > > > domains that the Verifier will trust to
sign any E.164. That
> > > > is the best that can be done with
RFC4474 by itself. As you
> > > > stated, this allows that trusted entity
to violate that
> > > > trust (insert their own a=fingerprint,
and do their own
> > > > DTLS handshake).
> > > >
> > > > As Paul and Francois suggested, using
ENUM could provide a way
> > > > to determine if the signer was
authorized to sign for a certain
> > > > E.164. However, ENUM is not widely
deployed and is mired in
> > > > non-technical issues. Furthermore, even
if the non-technical
> > > > issues were resolved, and we had ENUM
available everywhere,
> > > > operators that use SBCs and use RFC4474
would have to re-sign
> > > > SIP requests, destroying the original
signature in the process.
> > > > So ENUM is not a viable path (unless we
also invent a way to
> > > > do end-to-end identity, along the lines
of
> > > > -wing-sip-identity-media).
> > > >
> > > >
> > > > Another approach that I have considered
is a SIP return-
> > > > routability test. This provides better
flexibility and
> > > > does not require a priori configuration
of policy for which
> > > > domains you trust to sign or to resign;
of course, if you
> > > > do trust certain domains to resign
certain things, you can
> > > > short-cut this return-routability
(because it will always
> > > > return the same information you already
have). Thus, you
> > > > can consider the SIP return-routability
an additional
> > > > enhancement for a SIP network where you
don't already
> > > > know which domains are going to send you
Invites.
> > > >
> > > > I have written this up, but it is still
immature. However,
> > > > there seems to be interest in this
thanks to Jonathan's
> > > > good analysis of how RFC4474 and today's
use of E.164
> > > > collide to reduce the value of RFC4474
signatures (and,
> > > > thus, DTLS-SRTP that relies on RFC4474
signatures to
> > > > prevent active MitM attacks).
> > > >
> > > > Please consider this a straw-man idea.
> > > >
> > > >
> > > > SIP E.164 Return Routability Test
> > > > ---------------------------------
> > > >
> > > > Introduction:
> > > >
> > > > On today's Internet, many protocols have
had to protect
> > > > themselves from
> > > > malicious traffic with spoofed
identites. As most IP
> > > protocols use IP
> > > > addresses as the identity, the
protection has involved source
> > > > IP address
> > > > verification using a cookie (TCP
cookies, [PHOTURIS], [IKE]).
> > > > SIP [RFC3261]
> > > > itself uses cookies, but only for its
Digest authentication.
> > > >
> > > >
> > > > Overview of Operation:
> > > >
> > > > Upon receipt of an INVITE where the
From: address contains a
> > > > SIP URI with an
> > > > E.164, a Verifier (as defined in RFC4474
and in
> > > > SIP-Identity-Media) needs to
> > > > verify if the signer is authorized to
sign for that domain.
> > > > This verification
> > > > is done by sending an out of dialogue
SIP message to that
> > > > E.164, using the
> > > > Verifier's default SIP routing rules for
routing an E.164
> > > > address. If this
> > > > routes to the same domain as the
originating Invite, the
> > > > cookie will be
> > > > returned.
> > > >
> > > > To do this, the Verifier sends an
out-of-dialogue SIP message
> > > > to the identity
> > > > in the From: address, using the
Verifier's normal SIP message
> > > > routing. This
> > > > out-of-diaglogue SIP message is a
SUBSCRIBE to an event that
> > > > causes the
> > > > calling UA to send one NOTIFY. The
SUBSCRIBE also contains a
> > > > cookie. The
> > > > calling UA's NOTIFY contains the
originating UA's DTLS
> > > > fingerprint and the
> > > > SUBSCRIBE's cookie. Upon receiving the
NOTIFY, the
> > Verifier ensures
> > > > fingerprints in the NOTIFY and INVITE
match, and then passes
> > > > the INVITE to the
> > > > called UA.
> > > >
> > > > Following SIP-Identity-Media, the called
UA performs a
> > > > DTLS-SRTP handshake
> > > > with the calling UA, and via the
DTLS-SRTP handshake the
> > > > called UA proves
> > > > possession of the private key associated
with its public key
> > > > (and certificate
> > > > fingerprint).
> > > >
> > > >
> > > > Message Flow:
> > > >
> > > > Calling Auth. SBCs and
Called
> > > > UA Service B2BUAs Verifier
UA
> > > > ------- ------- -------- --------
------
> > > > | | | |
|
> > > > | Invite | | |
|
> > > > |--------->| | |
|
> > > > | | | |
|
> > > > | (signs request) | |
|
> > > > | | | |
|
> > > > | | Invite | |
|
> > > > | |--------->| Invite |
|
> > > > |100 | |--------->|
|
> > > > |<---------|100 | |
|
> > > > | |<---------|100 |
|
> > > > | | |<---------|
|
> > > > | | | |
|
> > > > | | | (validates
|
> > > > | | | signature)
|
> > > > | | | |
|
> > > > | | |Subscribe |
|
> > > > | |Subscribe |<---------|
|
> > > > |Subscribe |<---------| |
|
> > > > |<---------| | |
|
> > > > | | | |
|
> > > > |200 Ok | | |
|
> > > > |--------->|200 Ok | |
|
> > > > | |--------->|200 Ok |
|
> > > > |Notify | |--------->|
|
> > > > |--------->| | |
|
> > > > | | | |
|
> > > > | (signs request) | |
|
> > > > | | | |
|
> > > > | |Notify | |
|
> > > > | |--------->|Notify |
|
> > > > | | |--------->|
|
> > > > | | | |
|
> > > > | | |200 Ok |
|
> > > > | |200 Ok |<---------|
|
> > > > |200 Ok |<---------| |
|
> > > > |<---------| | |
|
> > > > | | |
(a=fingerprint |
> > > > | | | matches)
|
> > > > | | | |
|
> > > > | | | |
Invite |
> > > > | | |
|--------->|
> > > > | | | |
|
> > > > | | DTLS-SRTP Handshake |
|
> > > >
|<=========...=======>|<==...==============>|
> > > > | | | |
|
> > > > | | | |
(handshake
> > > > | | | |
successful)
> > > > | | | |
|
> > > > | | | |
|display e.164
> > > > | | | |
|------------>
> > > >
> > > >
> > > > -d
> > > >
> > >
> > >
> > >
_______________________________________________
> > > Sip mailing list https://ww
w1.ietf.org/mailman/listinfo/sip
> > > This list is for NEW development of the core
SIP Protocol
> > > Use sip-implementorscs.columbia.edu for
questions on current sip
> > > Use sippingietf.org for new
developments on the
> application of sip
> >
_______________________________________________
Sip mailing list https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip
|
