[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sip] First draft, RETIRE Charter
Dean,
Thanks for preparing this. I like what I see. This seems to be an ample
scope for a WG, and it could probably be addressed during a 1 to 1.5
hour slot at each IETF. A couple of comments below.
John
> -----Original Message-----
> From: sip-bounces at ietf.org [mailto:sip-bounces at ietf.org] On
> Behalf Of Dean Willis
> Sent: 25 June 2008 00:20
> To: sip at ietf.org
> 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.
[JRE] It also suffers an additional limitation to do with E.164 numbers.
So I would prefer to say:
"RFC 4474 suffers additional limitations relating to its use with E.164
numbers and with gateways, session border controllers, and back-to-back
user agents."
>
> 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.
[JRE] One thing we have talked about in the past has been an additional
parameter in a SIP URI. I am not saying we definitely need to do this,
but I would not want to close the door on this if the group concludes it
would be a good thing. Another possible deliverable might a some sort of
BCP to do with E.164 numbers in SIP URIs.
>
> 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 sip-implementors at cs.columbia.edu for questions on current sip
> Use sipping at ietf.org 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 sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip