> -----Original Message----- > From: Cullen Jennings [mailto:[email protected]] > Sent: Saturday, April 04, 2009 4:58 AM > To: Francois Audet > Cc: Dan Wing; Jonathan Rosenberg; Jiri Kuthan; Jon Peterson; > SIP IETF; Uzelac, Adam; Dean Willis > Subject: Re: [Sip] francois' comments and why RFC4474 not > used in the field > > > I can't remember which people thought this did not solve > their problem > but I remember the characteristics of the discussion were similar of > being unclear where this would or would not work and unclear on what > the problem was this did not solve. > > Cullen <in my individual contributor role>
Here are the minutes regarding draft-wing-sip-identity-media, identity problem, and identity requirements from the last 6 consecutive IETF meetings: Minutes from SIP meeting at IETF69, Chicago, July 22-27, 2007, http://www.ietf.org/proceedings/07jul/minutes/sip.html Media Identity Led by Dan Wing. Slides presented. Dan Wing reports that Cisco has made IPR claims related to this material. Discussion centered on difficulties with applying RFC 4474 techniques through session border controllers and other B2BUA. Some participants in the discussion questioned the use case or wondered whether the problem posed by the use case needs to be solved. Conclusion: There was no consensus to pursue the work at this time, but the WG might be willing to reconsider if more convincing use cases can be provided. Minutes from SIP meeting at IETF70, Vancouver, December 2-7, 2007, http://www.ietf.org/proceedings/07dec/minutes/sip.txt Topic: Media Identity led by Dan Wing Slides presented and included in proceedings Issue: SBCs break 4474 because SDP signed by Identity is rewritten by SBC Francois observed that this problem may only occur when it is an SBC outside the domain of the Identity server that is doing the rewriting. Hannes suggested extending IDENTITY to be like DKIM, which can selectively sign pieces. General discussion revealed that most of the material in the signaling is problematic from a signature perspective. IP Addresses are essentially meaningless, especially across domain boundaries. Phone numbers are little better, with end-nodes having no real way to test assertions about them (and perhaps a service provided signature is the best we can do here). RFC 4474 already documents limitations with respect to telephone numbers. There seems to be an emerging thread of consensus here that what we need is some way to bind media to signaling -- that is, to by inspection of the media and the signaling be able to say with some level of certainty that they are related -- and specifically, to say "this media is a result of that signaling". Chairs noted that there is additional work required her to be able to frame this into the sort of requirement that could be added to a charter. Minutes from SIP meeting at IETF71, Philadelphia, March 9-14, 2008, https://www3.ietf.org/proceedings/08mar/minutes/sip.txt Topic: SIP-Identity Issues by John Elwell Slides presented Issue: E.164 and RFC 4474 and DTLS-SRTP We have known issues with RFC 4474 handling of phone numbers, especially given the inconsistent processing of phone numbers and mixed URI encoding methods. The critical manifestation here is that if RFC 4474 is used to assert an identity derived from the PSTN (specifically, through a gateway via Caller-ID services) then there may be no basis to trust that assertion. This is problematic in that DTLS-SRTP requires and RFC 4474 Identity header to provide the fingerprint that correlates media with signaling. We would like to be able to use DTLS-SRTP with calls to/from PSTN gateways. However, this could result in teh insertion of misleading Identity headers. Discussion focused on defining the problem and the three "problem" use cases. There was a conclusion that this is definitely a problem that needs to be fixed. There seems to be a possibility that it could be fixed by guidance in the DTLS-SRTP framework, which we would like to conclude as soon as possible. However, there is at this time no consensus on a solution. For the record, an extended conversation took off on the mailing list following the in-meeting discussion, and that conversation has brought forward at least one proposal (a From: header URI parameter that would be inserted by gateways) that might meet the requirements. Issue: Impact of SBCs on RFC 4474 and SRTP-DTLS SBCs may make changes to requests that alter the RFC 4474 Identity header in such a way that it can not meet the requirements of SRTP-DTLS. Several fixes have been proposed and were discussed briefly. Further discussion is required. Minutes from SIP meeting at IETF72, Dublin, July 27 - August 1, 2008, http://www.ietf.org/proceedings/08jul/minutes/sip.txt Topic: Identity Issues Led by John Elwell Slides presented and included in proceedings John discussed the problem background and discussed a significant use case involving SBCs that perform media steering, with which RFC 4474 may not be effectively used. Discussion followed as to whether this "failure" is actually a feature and design goal of RFC 4474, with no consensus developing. This discussion included a lengthy review of the rationale of RFC 4474 by Jon Peterson. Further use cases, such as preservation of identity across multiple service provider SBC boundaries, were raised. Discussion on what to do next continued without final conclusions. Minutes from SIP meeting, IETF 73, November 16-21, 2008, http://www.ietf.org/proceedings/08nov/index.html Topic: Path forward on Identity Issues Led by Jon Peterson Slides Presented No draft Issue: Desirable Properties Desirable properties: - Generality ? one universal mechanism is a good thing. - Avoids bid-downs. - Authentication - enables media security - useful to decide whether or not to accept a request Hadriel noted that these are all good, but we can't have them. What are we willing to settle for tha twe can actually deliver? Several others voiced similar positions on the "noble but futile" theme. Issue: Configurability Proposed that some level of flexibility on what headers get signed might be acceptable. Hadriel suggested that we come up with a set of rules that intermediaries could comply with. Sam Hartman suggested that we further need a compromise about what we need to sign to get secure media that shows up as secure on the other end, with a spec that provides it. If we can't get it in this working group, we may need work that spans the entire IETF to get it. Further discussion ensued. No conclusions were noted. And Hadriel did a presentation at IETF74 but minutes haven't yet been posted. -d > > On Apr 1, 2009, at 10:15 AM, Francois Audet wrote: > > > So, having re-read all these drafts... > > > > Cullen/Jon, > > > > Why is something like draft-wing-sip-identity-media (let's > focus just > > on the DTLS-SRTP version for now) not a proper solution to the > > problem we > > are trying to solve? > > > > The problem being (I think): > > Identity Assertion of both the Signalling and the > Media, BUT allowing > > for relays? > > > > This has the advantage of being end-to-end. I guess the > alternative is > > to not have end-to-end media identity assertion, and instead have > > Alice-to- > > her-service-provider's relay, and > Bob-to-his-service-provider's-relay > > instead. > > > >> -----Original Message----- > >> From: Dan Wing [mailto:[email protected]] > >> Sent: Monday, March 30, 2009 21:16 > >> To: Audet, Francois (SC100:3055); 'Jonathan Rosenberg'; > 'Jiri Kuthan' > >> Cc: 'SIP IETF'; 'Uzelac, Adam'; 'Dean Willis' > >> Subject: RE: [Sip] francois' comments and why RFC4474 not > >> used in the field > >> > >> > >> > >> > >>> -----Original Message----- > >>> From: Francois Audet [mailto:[email protected]] > >>> Sent: Monday, March 30, 2009 7:53 PM > >>> To: Jonathan Rosenberg; Jiri Kuthan; Dan WING > >>> Cc: SIP IETF; Uzelac, Adam; Dean Willis > >>> Subject: Re: [Sip] francois' comments and why RFC4474 not > >> used in the > >>> field > >>> > >>> For everybody's reference, can you point to Dan's draft? > >> > >> It is > >> http://tools.ietf.org/html/draft-wing-sip-identity-media-02 > >> > >> other proposals in the same sphere, > >> http://tools.ietf.org/html/draft-fischer-sip-e2e-sec-media-00 > >> http://tools.ietf.org/html/draft-kaplan-sip-asserter-identity-01 > >> > >> -d > >> > >> > >>> On Mar30 2009 19:12 , "Jonathan Rosenberg" > >> <[email protected]> wrote: > >>> > >>>> inline: > >>>> > >>>> Jiri Kuthan wrote: > >>>> > >>>> > >>>>>> From an end user perspective, I would assert that the > >>> most important > >>>>>> thing is probably the media. If the callerID says, "this > >>> is bob", what > >>>>>> is important to the user, is that when I pick up the > >>> phone and start > >>>>>> talking, it will be Bob who hears me, and Bob that I hear. > >>>>>> > >>>>>> Consider this litmus test: > >>>>>> > >>>>>> If the signaling actually came from Mary (perhaps as a > >>> third party), > >>>>>> but the media goes/comes to/from Bob, who should appear > >>> on the caller > >>>>>> ID? I say - Bob. > >>>>> > >>>>> There is a timing aspect in favor of placing identity in > >>> signaling -- > >>>>> I would like to know whose call is ringing before I answer > >>> (if I do). > >>>> > >>>> You can still have that. Just don't ring the phone until > >>> early media has > >>>> been exchanged and verified. Indeed if you were doing an > >>> ICE-style thing > >>>> per Dan's draft, you'd get that for free. > >>>> > >>>> -Jonathan R. > >>>> > >>>> > >>> > >> > >> > > _______________________________________________ > > 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
