Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field

From: "Francois Audet" <[email-masked]>
Date: Wed, 1 Apr 2009 11:15:45 -0500

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-masked]] 
> 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-masked]]
> > 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-masked]> 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.
> > > 
> > > 
> > 
> 
>

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 4 Apr 2009 05:57:44 -0600

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>

On Apr 1, 2009, at 10:15 AM, Francois Audet wrote:

> _______________________________________________
> 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: "Dan Wing" <[email-masked]>
Date: Sat, 4 Apr 2009 17:23:51 -0700

> From: Cullen Jennings [mailto:[email-masked]] 
> 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

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

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 6 Apr 2009 11:04:31 -0500

Right,

So now that we have progressed, let's try to figure out what the problems
with this approach are (if any).

> Sent: Saturday, April 04, 2009 04:58
> To: Audet, Francois (SC100:3055)
> 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.
> 
> > on the DTLS-SRTP version for now) not a proper solution to 
> the problem 
> > we are trying to solve?
> >
> > 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
> 
>