|
I'm likely tainting this with my own views , but it feels like what most people want is a protocol definition which at some level is transport independent. On top of that, bindings to HTTP would be defined. The HTTP bindings would be seen as the easiest route to interoperability. Bindings to other transports may be defined, but don't have to be within the charter of the DIX WG. Depending on how much work is involved in writing a binding spec, some kind of guidelines document for doing so might be necessary.
How tightly coupled the transport-independent parts and HTTP-specific are defined to be is debatable. The more loosely coupled, the more re-work to dmd-01.
Is this a fair general read?
Jim
>>> [EMAIL PROTECTED] 1/24/06 10:33:43 am >>> >> 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. > > Which is true. SIP (without mechanisms such as SIP-identity) suffer the > same authentication problems email does. Specifically, the ability for the > UAC to forge the 'From' header. SIP does not necessarily suffer from those problems, and the spec acknowledges this. Existing challenge/response mechanisms using digest could solve this problem given a well known SIP server for the UAC (SRV perhaps) w/ Certs. The spec acknowledges that other mechanisms exist but goes on to state lack of support from user-agents. IMO, lack of support is not a good reason to create another way of doing the same thing. >From the Spec: RFC3261 specifies a number of security mechanisms that can be employed by SIP UAs, including Digest, TLS and S/MIME (implementations may support other security schemes as well). However, few SIP user agents today support the end-user certificates necessary to authenticate themselves > I am not suggesting a new scheme for SIP, others were suggesting SIP as > another target transport. SIP-identity/SIP-SAML are there now. As I > stated, it would be up to the SIP WG to determine if adding a 'dix' > mechanism is a 'Good Thing' or not. The same can be said of any chosen transport protocol including HTTP. Are you suggesting that every protocol binding should be done by the existing working group? IMO, unless the DIX transport binding extends the particular transport protocol, it should be done by this group. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Peter Davis Sent: Tuesday, January 24, 2006 6:38 AM To: Digital Identity Exchange <[email protected]> Subject: Re: [dix] draft of proposed charter (#2) On 1/20/2006 7:45 PM, "Suresh Venkatraman" <[EMAIL PROTECTED]> wrote: >> 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. Which is true. SIP (without mechanisms such as SIP-identity) suffer the same authentication problems email does. Specifically, the ability for the UAC to forge the 'From' header. > > 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". I am not suggesting a new scheme for SIP, others were suggesting SIP as another target transport. SIP-identity/SIP-SAML are there now. As I stated, it would be up to the SIP WG to determine if adding a 'dix' mechanism is a 'Good Thing' or not. > > Some future DIX binding for SIP will help add to the confusion. Yep. So we leave it up to them. > > <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> ;-) =peterd _______________________________________________ dix mailing list [email protected] https://www1.ietf.org/mailman/listinfo/dix _______________________________________________ dix mailing list [email protected] https://www1.ietf.org/mailman/listinfo/dix |
_______________________________________________ dix mailing list [email protected] https://www1.ietf.org/mailman/listinfo/dix
