Hi Dean, this looks good for me - see one comment below. Kai > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Dean Willis > Sent: Mittwoch, 25. Juni 2008 01:20 > To: [email protected] > Subject: [Sip] First draft, RETIRE Charter > > This is a first-pass at what I think we might do with a > RETIRE working > group > > --------------- > > > The "REal Time Identity and Role Expression" (RETIRE) > Working Group's > purpose is to standardize the expression and assertion of > identity and > roles needed for real-time communications with the IETF's Realtime > Applications Infrastructure (RAI) area protocols, primarily the > Session Initiation Protocol (SIP) and others used in > conjunction with > SIP. > > By "Identity", we mean authenticated addresses of record (as defined > in RFC 4474 "Enhancements for Authenticated Identity > Management in the > Session Initiation Protocol". RFC 4474 provides a means by > which a SIP > server may vouch for the "From" address of a request transiting that > server. It further provides a cryptographic mechanism for > testing the > source of the assertion. In the typical case, this mechanism is > dependent on the same Public Key Infrastructure that supports secure > HTTP services. Since RFC 4474 provides only authentication of the > source of SIP request messages and it is also important to determine > the identity of the sender of responses, RFC 4916 "Connected > Identity > in the Session Initiation Protocol" provides authenticated > identity in > an ongoing SIP dialog by applying RFC 4474 to requests in the > reverse > direction. While adequate for some scenarios, this mechanism is not > useful for SIP interactions having a single non-dialog transaction, > such as MESSAGE requests. RFC 4474 suffers additional limitations > relating to its use with gateways, session border controllers, and > back-to-back user agents. The whole discussion of the limitations with RFC 4474 came up in the context of DTLS-SRTP and end-to-end security and the limited binding of the identity and certificate fingerprint. From my point of view, this should be added explicitly here.
> > By "Role", we mean aspects of a a system user that are related > identity, but more dynamic in nature. For example, Alice might > delegate her calls to Alice. A calling party, expecting to > reach Alice > but reaching Bob, needs to know that this is a reasonable thing and > what Bob's role in relation to Alice is. This problem is in general > referred to as the "unanticipated respondent problem", and it has > impacts both at the level of user expectations and key management. > Proposals for fixing it have included deprecation of proxy > retargeting > and the use of a new SIP provisional response to inform the calling > party about the retargeting operation. > > Security Assertion Markup Language (SAML) is an XML-based > standard for > exchanging authentication and authorization data between security > domains, that is, between an identity provider (a producer of > assertions) and a service provider (a consumer of > assertions). SAML is > a product of the OASIS Security Services Technical Committee. > The SIP > working group worked for several years on applying SAML to SIP with > mixed results, but the technique appears to have great promise. > > > The initial deliverables of the RETIRE working group are: > > 1) A standards-track revision of RFC 4474 that resolves its > limitations with respect to gateways, session border > controllers, and > back-to-back user agents. This revision will also address the use of > Authenticated Identity Management in conjunction with SIP response > messages. > > 2) Specify a solution for the Unanticipated Respondent Problem in SIP. > > 3) Guidelines for the use of SAML with SIP for the purposes of > expressing identity and role, specifically in the contexts of #1 and > #2 above. > > > _______________________________________________ > 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 > _______________________________________________ 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
