> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Dean Willis > Sent: 31 July 2008 13:50 > To: Adam Uzelac; SIP IETF > Subject: [Sip] Alternative SIP Identity Approach (was re: > Thoughts on SIPIdentity) > > > 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. [JRE] But it is still transitive trust, but with the improvement (compared to PAI) that at least you see the chain of transitive trust. In that respect, isn't it similar to Hadriel's proposal?
Maybe one situation where this might have some utility is the case where the intermediary intervenes in the media in a way that involves decryption, e.g., change of codecs, conference mixing, recording of the clear media. In this situation we cannot do better than transitive trust. But for the case where media is encrypted e2e, identity authentication needs to be e2e. I am uncomfortable with transitive trust, at least for cases where one of the signers in the chain is an entity not known to me or not trusted by me. John _______________________________________________ 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
