> SIP presently has means to 'prove' the identity of the calling party sip > identity [1] which supplies a new header (and some hash/signing). While it > is presently in ID, it is header to RFC editor queue. > > It would be for the SIP WG to draft a binding of 'dix' with sip-identity, > IMHO. At least for the purposes laid out in the above use case.
It's in the draft "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)". It assumes identity is defined for SIP, but is not cryptographically secure. From the draft: "The existing security mechanisms in the Session Initiation Protocol are inadequate for cryptographically assuring the identity of the end users that originate SIP requests, especially in an interdomain context." "An identity, for the purposes of this document, is defined as a SIP URI, commonly a canonical address-of-record (AoR) employed to reach a user (such as 'sip:[EMAIL PROTECTED]')." "This document defines a new role for SIP entities called an authentication service." The draft is of course motivated by a need for authenticating identity but I worry about yet another separate but incompatible scheme for SIP. There is also a proposal to bind SAML to SIP titled "Using SAML for SIP". And from the SIP charter (http://www.ietf.org/html.charters/sip-charter.html): In addition to extending SIP as required to address these externally- derived requirements, the deliverables of the group include assuring capable security and privacy mechanisms within SIP and increasing the stability of the SIP specification. Specific deliverables toward these goals include: 1. Mechanisms for secure expression of identity in requests and responses. 3. Guidelines for use of existing security mechanisms such as TLS, IPsec, and certificates. 4. Guidelines for the use of descriptive techniques such as SAML (Security Association Markup Language) with SIP. Some future DIX binding for SIP will help add to the confusion. <sarcasm> Of course it's par for the course to throw everything under the sun into SIP. And the charter actually states simplicity as its goal... I can't wait until every application or network WG has its own version of identity, none of which will interoperate. </sarcasm> -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Peter Davis Sent: Friday, January 20, 2006 6:47 AM To: Digital Identity Exchange; [EMAIL PROTECTED] Subject: Re: [dix] draft of proposed charter (#2) On 1/19/2006 9:38 PM, "John Merrells" <[EMAIL PROTECTED]> wrote: > ... but I might be on a call to a call center and they ask me to > prove something about me... right now they ask a bunch of > questions... SSN, MMN, DOB... with DIX over SIP they might > be able to send the request to my client and assuming it > had the appropriate interface (ie capabilities) it could ask > me if i wanted to reveal that identity information... i'd click > yes and it'd be revealed. Which sounds quite nice to me. SIP presently has means to 'prove' the identity of the calling party sip-identity [1] which supplies a new header (and some hash/signing). While it is presently in ID, it is header to RFC editor queue. It would be for the SIP WG to draft a binding of 'dix' with sip-identity, IMHO. At least for the purposes laid out in the above use case. =peterd (http://public.xdi.org/=peterd) [1] http://www.ietf.org/internet-drafts/draft-ietf-sip-identity-06.txt _______________________________________________ dix mailing list [email protected] https://www1.ietf.org/mailman/listinfo/dix _______________________________________________ dix mailing list [email protected] https://www1.ietf.org/mailman/listinfo/dix
