1 / 9

Identity Coexistence

Identity Coexistence. Jonathan Rosenberg Cisco Systems. Problem Statement. We have two mechanisms defined for a form of “secure Identity” P-Asserted-Identity (RFC 3325) SIP Identity (RFC 4479) It is entirely unclear how these mechanisms work together (or not)

rae-bolton
Download Presentation

Identity Coexistence

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Identity Coexistence Jonathan Rosenberg Cisco Systems

  2. Problem Statement • We have two mechanisms defined for a form of “secure Identity” • P-Asserted-Identity (RFC 3325) • SIP Identity (RFC 4479) • It is entirely unclear how these mechanisms work together (or not) • It is entirely unclear how we migrate from P-Asserted-ID to SIP Identity

  3. Requirements • Clear algorithm for a UA to render caller ID • Continued ability to support call trace and anonymous calling • Reduce barriers to deployment of SIP Identity • Retain key properties of SIP Identity • Clear guidance to implementors and designers on relative roles of From and P-A-ID

  4. Basic Idea • Use P-A-ID as an “Intra-Domain” identity • Use From with Identity as Inter-Domain identity

  5. Architecture Remove PAID Add Identity Verify Identity Add PAID Originating Network uses PAID Terminating Network Uses PAID Authenticate (digest) And insert PAID Use PAID or From UAC UAS

  6. Anonymity • From would be constructed as anonymous within the domain (sip:gunk@example.com;user=anonymous) • UA obtains this from provider – contains traceable identity for malicious trace • Could be anonymous gruu…. • Originating domain authenticates and puts in PAID with actual identity • PAID stripped at egress of originating domain • Terminating domain inserts anonymous URI from From into PAID (since From verifies)

  7. Lots of Issues • Do PAID and From really convey the same identity? • Disagrees with elwell draft which asserts that they are different • How does this work through transit providers which modify SDP? • Should they resign? If they do that, is there any value to Identity? • Does a domain need to signal support for this specification?

  8. Option Tag Use Case PAID still there Originating Network Doesn’t support PAID Terminating Network Doesn’t support PAID Authenticate (digest) UA inserts PAID With false identity UAS supports PAID and renders UAC UAS

  9. Questions • Interest in pursuing as a work item? • Really predicated on belief that PAID and From have same identity

More Related