Subject: [Sip] First draft, RETIRE Charter

From: Dean Willis <[email-masked]>
Date: Tue, 24 Jun 2008 18:20:13 -0500

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.

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-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Theo Zourzouvillys" <[email-masked]>
Date: Wed, 25 Jun 2008 00:29:43 +0100

On Wed, Jun 25, 2008 at 12:20 AM, Dean Willis <[email-masked]> wrote:

> For example, Alice might delegate her calls to Alice.

resulting in a horrible loop.

 ~ Theo

---

From: Dean Willis <[email-masked]>
Date: Tue, 24 Jun 2008 21:49:45 -0500

On Jun 24, 2008, at 6:29 PM, Theo Zourzouvillys wrote:

> On Wed, Jun 25, 2008 at 12:20 AM, Dean Willis <[email-masked] 
> > wrote:
>

Well, that would be unanticipated! Same name, different person . . .

Thanks, Theo. I actually did mean "Alice might delegate her calls to  
Bob".

You win the actually-reading-what-I-wrote prize for the day.

--
Dean

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 25 Jun 2008 08:24:17 +0100

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: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Dean Willis
> Sent: 25 June 2008 00:20
> To: [email-masked]
> Subject: [Sip] First draft, RETIRE Charter
> 
[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."

> Authenticated Identity Management in conjunction with SIP response  
[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.

---

From: "Fischer, Kai" <[email-masked]>
Date: Wed, 25 Jun 2008 15:03:36 +0200

Hi Dean,
this looks good for me - see one comment below.
Kai

> Sent: Mittwoch, 25. Juni 2008 01:20
> To: [email-masked]
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.

---

From: Dean Willis <[email-masked]>
Date: Wed, 25 Jun 2008 11:01:14 -0500

On Jun 25, 2008, at 2:24 AM, Elwell, John wrote:

> numbers and with gateways, session border controllers, and back-to- 

Does it really have issues with E,164 numbers, or only when they are  
used through gateways? For example, I thought we had agreed  that if  
the ENUM entry for an E.164 points to a domain including an  
authentication service, then that AS could reasonably issue Identity  
headers on that phone number.

> BCP to do with E.164 numbers in SIP URIs.

That is indeed one of the proposals for alerting an RFC4474 consumer  
to the fact that the identity assertion is "weak" because it came from  
the PSTN.

General guidance on E.164s in URIs might be a reasonable thing to do.

--
Dean

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 25 Jun 2008 21:29:32 +0100

Dean, 

> From: Dean Willis [mailto:[email-masked]] 
> Sent: 25 June 2008 17:01
> To: Elwell, John
> Cc: [email-masked]
> Subject: Re: [Sip] First draft, RETIRE Charter
> 
> 
> > "RFC 4474 suffers additional limitations relating to its 
> use with E. 
> > 164
[JRE] That was suggested - I am not sure there was an agreement, and
even that would need documenting.

John