At Mon, 14 Apr 2008 14:04:03 -0500,
Alan Johnston wrote:
> Your analysis really misses the point others are making here.

If you say so.


> This isn't a call between Alice and Bob - it is a call between 
> +12125551212 and +19725551313.  If the identities of the two parties are 
> telephony ones, then RFC 4474 does not provide the same integrity 
> protection available to non-telephony SIP URIs, no matter how you spin 
> it.  This is because without some new mechanism and protocol, there is 
> no difference between an identity assertion of:
> 
>     sip:[EMAIL PROTECTED]
> 
> or
> 
>     sip:[EMAIL PROTECTED]
>
> However, there may be a small MitM  difference.  And this is a DTLS-SRTP 
> issue since it relies on integrity protection of RFC 4474 to prevent 
> MitM attacks, and most VoIP endpoints in the world today use telephony 
> identities.

Yes, I'm quite aware of the technical facts, I just believe you're
misinterpreting their import.

To reiterate what I said in PHL, the problem is *not* RFC 4474, but
rather the attempt to infer from a SIP URI with a numeric LHS that
you're in fact talking to someone with an E.164 number which matches
that LHS. Which is to say, that the relevant identity is not
+12125551212 but rather [EMAIL PROTECTED] If you work
in that space (and this of course can be hidden under UI in many
cases), then you in fact do get the appropriate security 
properties.

For calls which are coming from the PSTN, trying to go from the
SIP identity back to an E.164 number is basically meaningless.
No matter how strong we make our authentication infrastructure
on the VoIP side, the PSTN CNID information is untrustworthy.
We can't solve this problem by being extra-sure we only trust
some GWs to vouch for that information, since that GW has no
reasonable basis on which to base its assertion.

Now, if what you're concerned with is pure VoIP calls which
use E.164 numbers but don't transit the PSTN, then, yes, it's
potentially meaningful to talk about going from fully qualified
numeric LHS URIs to E.164 numbers. What you'd need is some
mechanism for determining whether a given domain should be
vouching for a given E.164 number. I've heard at least three
suggestions for this:

 - Manual lists of E.164 -> domain mappings
 - Enum
 - draft-wing style return routability checks.

I certainly think this is potentially worth pursuing, but as far
as I can tell, Dean was talking about calls transiting the PSTN,
where none of this stuff applies.

-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

Reply via email to