On Jul 31, 2008, at 9:56 AM, Uzelac, Adam wrote:
The point that I want to make is this - I think that end-to-end
identity is important. John and Hadriel have pointed out problems
with the methods available to attain end-to-end identity. This is
an important issue to address. Those intermediary devices are not
only there to address a SSP subscriber's policy for termination or
origination services, but also for just plain interoperability.
RFC 4474 provides quite strong assurances that the intermediaries have
acted appropriately.
Some of the things that RFC 4474 block some of the actions of SBCs and
some other intermediaries. Thus, we have a call to reduce the strength
of RFC 4474.
If we water-down RFC 4474 to the point that an evil intermediary
device could "gain advantage" in a way that RC 4474 would have
prevented, then we have ruined RFC 4474.
Thus the argument that any SBC that changes SDP, etc. forms a
transitive trust boundary, It MIGHT not have altered the identity, but
it also might have, and there really is no way for the end node to
tell. All it can really do is trust that it wasn't screwed over by the
SBC.
So here's an idea: an alternative to RFC-4474 that explicitly supports
transitive assertion identities by verifying an existing assertion and
then asserting the same identity with a new signature.
We might start with RFC 474 and sign the same things as IFC 4474 does,
but change a couple of points:
1) Instead of Identity and Identity-Info header fields, we'd use some
new header fields (names TBD) to the identity that was verified and
the signer. I propose "Reasserted-Identity" and "Reasserted-Identity-
info"
2) Relax the requirement that the subject of the signing cert match
the domain of the From. An SBC would still need a cert, but just the
one, not one for every possible domain.
3) Replace 4474's discussion of authentication with a discussion of
verification of an existing identity or Reasserted-Identity header
field.
4) Add some History-Info extensions to add information about the
reassertion into the history.
5) Add some flags somewhere to describe different levels of
verification, such as a) Valid Identity header, b) Learned from PSTN,
c) unverifiable Identity header, d) from P-Asserted-Identity, etc.
Here's an example:
1) [EMAIL PROTECTED] calls [EMAIL PROTECTED]
2) The example.com AS authenticates Alice using a mechanism such as
proxy-authenticate, then adds an appropriate Identity and Identity-
Info header field.
3) Bob's B2BUA verifies the Identity header field
4) Bob's B2BUA checks the Identity value value against Bob's whitelist
and chooses to allow the call.
5) But Bob is out, so the B2BUA wants to forward the call to Bob's
mobile phone. But Bob's administrative policy requires recording the
call.
Since Bob's administrative policy requires recording the call, Bob's
b2bua steers the media through a recorder. This requires either
"editing the SDP" or termination of media on the SBC. in either case,
it is not reasonable to send the existing Identity header on to Bob,
since it's going to be broken.
6) Bob's B2BUA elides the previous Identity and Identity-Info and adds
a new Reasserted-Identity and Reasserted-Identity-Info header field
to the new request, adds a flag saying that the identity being re-
asserted was learned from a verified Identity header, then sends it.
7) Bob's mobile sees the new request, knows that it trusts Bob's B2BUA
as a re-asserter, then checks its whitelist policy and finds that it
is willing to accept calls from [EMAIL PROTECTED] as long as the
assertion strength is either a direct Identity or a re-asserted
Identity based on verified Identity.
--
Dean
_______________________________________________
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
