RE: SIP E.164 Return Routability Test

> -----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

RE: SIP E.164 Return Routability Test

Thread: RE: SIP E.164 Return Routability Test