Subject: Re: [Enum] [Sip] New I-D on RFC4474 and phone numbers

From: "Richard Shockey" <[email-masked]>
Date: Mon, 18 Feb 2008 17:17:02 -0500

FYI from the SIP list...

>  -----Original Message-----
>  From: [email-masked] [mailto:[email-masked]] On Behalf Of
>  Tschofenig, Hannes (NSN - FI/Espoo)
>  Sent: Monday, February 18, 2008 2:55 PM
>  To: ext Jonathan Rosenberg; Paul Kyzivat
>  Cc: IETF SIP List
>  Subject: Re: [Sip] New I-D on RFC4474 and phone numbers
>  
>  Hi Jonathan,
>  Hi Paul,
>  
>  thanks for raising the aspect of E.164 and ENUM usage. There was an
>  offline discussion between Dan Wing, Klaus Darilion, Kai Fischer,
>  David Schwartz, Hadriel Kaplan, John Elwell, and myself about E.164
>  and SIP Identity. As part of the discussion Klaus and I polished a
>  former document of Alexander Mayrhofer on the usage of ENUM for E.164
>  numbers (see draft-mayrhofer-enum-domainkeys-00). As we moved along
>  with the work we obviously came across a couple of problems (as one
>  can easily imagine) and the document triggered a long discussion among
>  us. Dispite a couple of challenges, we published the document today
>  (see http://www.ietf.org/internet-drafts/draft-darilion-sip-e164-enum-
>  00.txt). I learned a lot while working on that document.
>  
>  In addition to publishing the document a few of us have also worked on
>  a document that captures some of our discussion on E.164 number
>  ownership. I will publish it very soon -- just a bit more proof-
>  reading.
>  
>  Ciao
>  Hannes
>  
>  > -----Ursprüngliche Nachricht-----
>  > Von: [email-masked] [mailto:[email-masked]] Im
>  > Auftrag von ext Jonathan Rosenberg
>  > Gesendet: Montag, 18. Februar 2008 21:36
>  > An: Paul Kyzivat
>  > Cc: IETF SIP List
>  > Betreff: Re: [Sip] New I-D on RFC4474 and phone numbers
>  >
>  > I agree that something along the lines of enum could solve
>  > this problem,
>  > and I believe there was a draft that proposed such a thing. This has
>  > been discussed since the start of rfc4474.
>  >
>  > However, I fear that saying, 'use enum' is kind of like saying,
>  we'll
>  > just use an All-Knowing Oracle, so lets figure out the interface
>  > protocol to the Oracle. The easy part is the interface (the enum
>  > mechanism). The actual hard problem is how to get those entries
>  > populated. The deployment of public enum has been - shall we
>  > say - less
>  > than spectacular. I'd hate for that to be our only solution. Not
>  that
>  > its obvious what else to do; though I do suggest in my draft
>  > how domain
>  > based authentication, when combined with whitelists and
>  > blacklists, can
>  > help.
>  >
>  > -Jonathan R.
>  >
>  > Paul Kyzivat wrote:
>  > > Jonathan,
>  > >
>  > > I guess the time has come for this discussion, since John
>  > Ewell has also
>  > > submitted a draft on this subject.
>  > >
>  > > I thought the problem was already well known, but perhaps
>  > not. IMO the
>  > > main thing now is to figure out the *solution* to the problem!
>  > > IMO a solution is to use a 4474-style approach, but where the
>  > > certificate is tied to just the phone number, not to some
>  arbitrary
>  > > domain name. That of course would depend on a model where
>  > the "owner" of
>  > > the phone number is the one who may obtain the certificate
>  > for that number.
>  > >
>  > > My thought is that we already have an algorithmic mapping
>  > from an E.164
>  > > phone number to a domain name, defined by enum. If the
>  > sender puts an
>  > > E.164 number in From, and can sign it with a cert for the
>  > enum mapped
>  > > domain name corresponding to that number, then that ought
>  > to be valid
>  > > proof of the validity of the sender.
>  > >
>  > > In those places where public enum is in operation, I think there
>  is
>  > > already a legal mechanism in place to give the owner of record of
>  a
>  > > particular phone number control over the contents of the
>  > corresponding
>  > > DNS entry. That should also be sufficient to allow a certificate
>  > > authority to assign a cert to that same owner.
>  > >
>  > > Combine all that and you have a complete e2e identity model
>  > for phone
>  > > numbers, based on public enum. And that can be true even if
>  > public enum
>  > > isn't used to *route* the calls to that number. So it could
>  > be used for
>  > > "unlisted" numbers.
>  > >
>  > > To use this approach the From header should contain either
>  > a TEL URI, or
>  > > a sip/sips URI containing the enum-mapped domain name
>  > corresponding to
>  > > the phone number. (I would rather see the TEL used for this
>  > - it is more
>  > > user friendly.)
>  > >
>  > >     Thanks,
>  > >     Paul
>  > >
>  > > Jonathan Rosenberg wrote:
>  > >> I just submitted:
>  > >>
>  > http://www.ietf.org/internet-drafts/draft-rosenberg-sip-rfc447
>  > 4-concerns-00.txt
>  > >>
>  > >>
>  > >> This is basically a discussion on the security properties
>  > of rfc4474
>  > >> with phone numbers, and a comparison to rfc3325 in this
>  > case. Also a
>  > >> discussion on what happens to dtls-srtp.
>  > >>
>  > >> Comments welcome.
>  > >>
>  > >> -Jonathan R.
>  > >
>  >
>  > --
>  > 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  http://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
>  >
>  _______________________________________________
>  Sip mailing list  http://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

_______________________________________________
enum mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/enum

---

From: "Richard Shockey" <[email-masked]>
Date: Tue, 19 Feb 2008 10:00:52 -0500

Well ENUM is on a short leash in Philadelphia with only 1 hour, we are
trying to slowly but deliberately wind things down. It might not be the best
time, but we certainly have large body of expertise in dealing with E.164
numbers and the history of trying to deal with number mappings in globally
distributed databases. :-) 

It's certainly something worth discussing the ENUM WG list from time to time
but the real issues are all layer 8 and above.

>  Hannes Tschofenig
>  Sent: Tuesday, February 19, 2008 2:24 AM
>  To: Richard Shockey
>  Cc: 'IETF SIP List'; 'Paul Kyzivat'
>  Hi Richard
>  I have thought about that. When I spoke to a couple of people about
>  requesting a slot in ENUM they told me that ENUM is not the right
>  place
>  to discuss this.
>  Feedback from the ENUM WG would certainly be helpful. ;
>  
>  Ciao
>  Hannes
>  
>  Richard Shockey wrote:
>  > So did you guys want a slot during the ENUM WG?
>  >
>  >

---

From: "PFAUTZ, PENN L, ATTCORP" <[email-masked]>
Date: Tue, 19 Feb 2008 10:43:29 -0500

Section 3.2 suggests there is no definition for Infrastructure ENUM. At least reference RFC 5067!

Section 3.3  wallet garden model? I like that :-)
 
Is there a reason why a carrier can't use infrastructure ENUM to certify a given populated caller ID using a general rather than a specific key? (If they were willing to)

Penn Pfautz
AT&T National Access Management
+1-732-420-4962