Subject: Re: [Sip] SIP Identity WG name

From: "James M. Polk" <[email-masked]>
Date: Tue, 01 Jul 2008 12:33:33 -0500

At 09:42 AM 6/27/2008, Hadriel Kaplan wrote:
>I don't know if people care, but since email is free: it would be 
>nice to decide on a name for this potential group, and RETIRE is 
>kinda a downer.
>
>Potential names:
>RETIRE - "REal Time Identity and Role Expression"

sounds like we're deprecating functions

>SIGNED - "Sip Identity for Generic Name and E.164 Deployments"

doesn't do roles/saml justice

>SIGN - "Sip Identity for Global Names"

roles/saml isn't about global names, it's about asserted 
categorization of identities

>RISE - "Roles and Identities in SIP Environments"

this one gets my vote, since it clearly discusses most of what this 
WG is being proposed to charter work for (roles and identity)

>Or if you prefer a tounge-in-cheek approach:
>RESIGN - "Roles and Establishment for SIP Identities of Generic 
>Nature" (which would be pronounced either as the act of signing 
>again as in "re-sign", or of retiring as in "resign")

this is a possibility

>INSIPID - "INternet SIP IDentities" (which could be pronounced 
>either as "in SIP-ID", or the word insipid)

I don't mind this

>So far we have 3 votes for INSIPID and 1 vote for SIGNED.
>
>_______________________________________________
>Sip mailing list  https://www1.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

_______________________________________________
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: Jonathan Rosenberg <[email-masked]>
Date: Tue, 01 Jul 2008 14:41:08 -0400

Before going to deep on charter names and all, I think it'd be good to 
discuss whether it makes sense to have a WG do this work.

The first deliverable is a revision of 4474. There are differing 
opinions on the table about whats included in that revision. If all 
we're going to do is update it so that its clearer that it really 
doesn't work with numbers, we don't need a WG to do that. If we're going 
to 'fix' it to work with numbers - I'd prefer to start with a plausible 
proposal, and frankly I don't think there is one (an enum-based solution 
is pure science fiction...).

We're also pretty far from consensus so far on how/if the SBC problems 
can be fixed. Along the same lines, I think we need some agreement that 
this is a fixable problem, before chartering a group.

Guidelines for usage of e164 numbers for identifiers - well that is a 
REAL problem and a constant source of interop issues (tel vs. sip? + or 
not-+?). Worth addressing I think.

Unanticipated respondent problem - we haven't solved this problem yet, 
and frankly I'm not convinced we really need to. Given the size of the 
gulf between real usage of SIP security and identity mechanisms, and the 
specs we've produced, I am reluctant to start new work here without 
clear expectation that folks are lining up to actually USE it.

So, net/net is that I am unconvinced there is enough content here to 
propose a new WG.

-Jonathan R.

Dean Willis wrote:
> I've revised the proposed charter fora RETIRE working group based on 
> list comments. This is still a very early concept, and the formation of 
> such a working group is contingent on a great many things that are 
> outside of my control.
> 
> 
> --------
> 
> 
> 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 E.164 numbers, 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 Bob. 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 E.164 numbers, 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. It may also be necessary to document the impact of such 
> changes, if any, on the DTLS-SRTP framework.
> 
> 2) Specify a solution (or set of solutions)  for the Unanticipated 
> Respondent Problem in SIP.
> 
> 3) Guidelines for the use of E.164 numbers as SIP identifiers.
> 
> 4) Guidelines for the use of SAML with SIP for the purposes of 
> expressing identity and role, specifically in the contexts of #1, #2 and 
> #3 above.
> 
> 

-- 
Jonathan D. Rosenberg, Ph.D.                   499 Thornall St.
Cisco Fellow                                   Edison, NJ 08837
Cisco, Voice Technology Group
[email-masked]
http://www.jdrosen.net                         PHONE: (408) 902-3084
http://www.cisco.com
_______________________________________________
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: Dean Willis <[email-masked]>
Date: Tue, 1 Jul 2008 18:02:13 -0500

On Jul 1, 2008, at 1:41 PM, Jonathan Rosenberg wrote:

> Before going to deep on charter names and all, I think it'd be good  
> to discuss whether it makes sense to have a WG do this work.
>
> doesn't work with numbers, we don't need a WG to do that. If we're  
> going to 'fix' it to work with numbers - I'd prefer to start with a  
> plausible proposal, and frankly I don't think there is one (an enum- 
> based solution is pure science fiction...).

It works with numbers (numeric identities) at a domain now. It can be  
made to work with numbers from a gateway, IF there's some way to  
convey the limitation of the identity server's knowledge about the  
source of the number (and we have proposals for that). We had a rather  
long thread on the topic that seemed to indicate acceptable solutions  
for that whole problem space. I know, not everybody read it. And since  
SIP isn't entertaining the work, nobody is going to write a draft on  
it for us.

>
> We're also pretty far from consensus so far on how/if the SBC  
> problems can be fixed. Along the same lines, I think we need some  
> agreement that this is a fixable problem, before chartering a group.
>

Did you read the existing solution drafts from Dan and Kai? They  
seemed workable, and fairly easy to reconcile.

--
Dean