inline:
Hadriel Kaplan wrote:
>
>> Now Identity gives us a way to realize all of this
that protects
>> from attackers modifying things along the chain.
IBM signs and the
>> number as IBM and sends on to sprint. Sprint can
use this to decide
>> if they believe this OK or not along with their
policy information.
>> Now if sprint thinks it OK, they insert the
assertion they think it
>> OK and hand to AT&T. AT&T looks at it and
decides that it was OK
>> for sprint, then it is OK for them and inserts
their assertion that
>> it OK and hands down to Cisco. Cisco looks for the
AT&T assertion
>> and since it one of the carriers they trust,
decides it is OK.
>> <bold> As far as I can tell, anything other
than this won't work
>> for phone numbers </bold>. This means that
the PBX needs to require
>> that the identity it trusts to sign numbers is some
it trusts -
>> practically this means the one or more carriers
that it connects
>> to. These carriers need to have their SBC (or
proxies if they used
>> theses) insert an assertion about if the number is
OK or not.
>
> This already happens through P-Asserted. What you
describe is
> hop-by-hop trust of identity, so why would you believe
a 4474 signed
> request by your trusted previous-hop any less than a
P-Asserted claim
> from it? And what's more, why would each hop bother
with the
> overhead of 4474 if it can just use P-Asserted? If
Cisco was
> concerned with something between them and AT&T, or
AT&T concerned
> with something between them and Sprint, or Sprint
concerned with
> something between them and IBM, why wouldn't they just
use SIP/TLS
> for those peer connections? It's less overhead and
provides better
> security for those connections than 4474.
I agree with Hadriel here. There is no point in RFC 4474 if
anyway every
hop is going to resign. Cullen - what value do you see in it
over 3325?
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.
-Jonathan R.
--
Jonathan D. Rosenberg, Ph.D. 499 Thornall
St.
Cisco Fellow Edison, NJ
08837
Cisco, Voice Technology Group
jdrosen cisco.com
http://www.jdrosen.net
PHONE: (408) 902-3084
http://www.cisco.com
_______________________________________________
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
|