Subject: RE: authority for a domain (was RE: [Sip]sip-identity-05:display-name woes)

From: "Peterson, Jon" <[email-masked]>
Date: Wed, 20 Apr 2005 21:36:10 -0400

Mike,

This is likely to continue to be a conversation in which we talk past one another. Below, you've taken my attempt to establish some common ground about name subordination and submitted that instead, each bullet should be about the requirements of an identity system. I'm talking about one thing, you're talking about something else entirely. As an aside, I don't disagree substantially with any of the requirements you outlined, and I think they are largely met by sip-identity.

Clearly, if you disagree so vehemently with the fundamental assumptions underlying sip-identity, then no solutions in this space will make you happy. It is true that I believe the DNS and its associated hierarchical structure and concepts of authority are integral to how we understand authority over SIP identities, because SIP identities are names rooted in the DNS. I think that disregarding the delegation of authority in the DNS would result in a design for SIP identities that does not correspond to the way SIP users are enrolled nor the manner in which SIP requests are routed. That much said, aside from concerns about the assumptions and how the problem has been cast, you seem to have three concrete points of discomfiture below:

- You don't believe that existing CAs which issue certificates for web sites (i.e., for domain names) have enrollment policies that restrict the issuance of certificates to the owners of the domain names in question; instead, you believe these CAs issue you a certificate "for whatever reason they wanted to",
- You don't believe that a signature generated with the private key corresponding to a certificate serves to authenticate the entity to which the certificate was issued ("Sorry this is just fundamentally wrong", you say),
- You assert that sip-identity is not useful unless it has a mechanism that will prevent any need for namespace "shunting"; that is, being forced to take users with AoRs of form 'sip:[email-masked]' and move them to the namespace 'sip:[email-masked]', in order to accommodate the architecture of sip-identity ("the rest of your argument falls apart if that requirement is accepted", you say, apparently neglecting that the "argument" of the paragraphs after the one you are commenting on accept and discuss the solution for this requirement).

To which I will reply, in order:

- I believe that existing CAs which offer certs to web sites have an enrollment process which verifies ownership of the requested domain name. If you disagree, please go to Verisign, GoDaddy or GeoTrust and procure a certificate for 'www.amazon.com' and post it to this list. I'll pay you back for the certificate later.
- I believe that when I form a TLS connection to www.amazon.com, I download a certificate which allows me to verify that integrity-protected content sent over the TLS connection actually comes from the organization authoritative for the name 'www.amazon.com'. I believe that if we don't understand certificates this way, e-commerce security is nonsensical.
- In my previous mail, and in the draft, I acknowledged that this is a limitation of sip-identity, though I don't share your apocalyptic feelings about it. I agree it is a requirement, and it is, as I said, a subject for future work. I outlined the form I believed that future work would take, and I think it is a reasonable approach to the problem. Perhaps the reason why I don't feel so apocalyptic about this one is that I can envision reasonable deployment environments in which SIP identity could be deployed without shunting. Shunting happens when administrations have pre-existing SIP namespaces and in which they are unwilling to allow a SIP auth service to have access to the private key of a cert corresponding to the domain portion of that namespace. There are no doubt administrations that meet that description and those that do not. We could, of course, block sip-identity from a standardization perspective until we complete work on an MX-like way for verifiers to determine what auth service is  authoritative for a domain... but I continue to believe it is worth publishing sip-identity without this capability and defining it after the fact.

Incidentally, I have been aware of the various MASS drafts for some time, and I continue to believe that there are far more similarities than differences between sip-identity and the MASS efforts. However, SIP and email are slightly different problem spaces for identity , and I don't think that there is a lot to be gained from importing from IIM or DK into sip-identity. I did make the check, at one point, though, to see if there was anything we could glean there. One major distinction is that SIP has not yet enjoyed the universal deployment of email, and accordingly, we have a bit of wiggle-room still in making surgical changes to the protocol and deployment environment.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Michael Thomas [mailto:[email-masked]]
> Sent: Wednesday, April 20, 2005 4:52 PM
> To: Peterson, Jon
> Cc: [email-masked]; Francois Audet; Paul Kyzivat
> Subject: RE: authority for a domain (was RE:
> [Sip]sip-identity-05:display-name woes)
> 
> 
> On Wed, 2005-04-20 at 13:29, Peterson, Jon wrote:
> > I fear that we're talking way past one another, Mike, but 
> I'll try to go a little farther with this to see if we can 
> find any common ground...
> >  
> > > > The draft does assume that if you hold a cert for 
> > > example.com (i.e., a CA-signed cert with the subjectAltName 
> > > 'example.com'), then you are the legitimate authority for 
> > > example.com. 
> > > 
> > > Authority for _what_? SIP? Prize Rooster trading? All of the
> > > above? If not all of the above, what if I want to use the
> > > same technique for the Prize Rooster Trading Protocol... but
> > > it seems that I can't because SIP got there first[*]. If it is
> > > all of the above, then that's a real problem in the delegation
> > > arena since I don't want my telephony guys having any authority
> > > over who's allowed to trade my Prize Roosters.
> > 
> > To answer the question "Authority for what?", let's go back 
> to first principles, here. 
> 
> Going back to first principles is fine -- in fact that's what 
> I've been
> trying to accomplish. The problem I see is that you have a solution in
> mind already and are arguing backward from there. That is, 
> you're taking
> PKI namespaces and DNS as being primaries. They are not. It would help
> a lot if you understood what we've done with IIM for email (as well as
> Yahoo's Domain Keys), because they approach a very similar 
> problem space
> making different tradeoffs. It also helps greatly because there
> are existence proofs of both of these protocols which are 
> deployed today
> which as far as I can tell is not the case for sip-identity 
> (in the case
> of DK, dozens of large ISP signing 100's of millions of email a day).
> Also: as one of the implementors of IIM, I have a very good feel for
> what is implementable; sip-identity is no where close to ready for 
> prime time. Harsh yes, but I just wanted to set straight that I'm
> not here just to be argumentative.
> 
> > If I own a name in the DNS, I am empowered to create 
> subordinate names. There are four administrative procedures 
> relating to subordinate names which are salient to this discussion:
> > 
> > 1) If I own the name 'example.com', I can create a 
> subordinate name called 'mail.example.com'. 
> 
> This is not a first principle. The first principle is that I 
> have names
> that I'd like to assert as being legitimately from my domain for
> particular services. A second principle is that I'd like to be able
> to delegate namespace/service pairs to entities within my organization
> to whom I authorize to use my namespace for a particular purpose. DNS
> delegation may or may not be an ends to those principles.
> 
> > 2) I can also run services on the host 'example.com' which 
> have different accounts, users, or whatever, and for the 
> purposes of those services, names like [email-masked]' 
> might be created.
> 
> This is confused: the first principle here is that services 
> want to use
> nodes within a namespace. It's not helping here because example.com
> can be a host, but I sense that you mean example.com the domain.
> 
> >  
> > 3) I can furthermore run services on a host with a 
> subordinate name, and the users of that service might be 
> issued names like [email-masked]'
> 
> Or I can run service SIP on host1.example.com and SMTP on
> host2.example.com for the name [email-masked]. The first
> principle here is that I'd like to be able to authorize
> host1 to assert names in SIP messages for some or all of 
> example.com's namespace. DNS delegation isn't the primary 
> property here: it seems to be an artifact of a particular 
> model you are using to achieve the this authorization.
> 
> > 4) Finally, I can mark up the DNS to link services 
> associated with the name 'example.com' to particular services 
> running on subordinate hosts; e.g., the MX record linking 
> mail services for 'example.com' to 'mail.example.com', or the 
> comparable procedures for SIP using NAPTR and SRV.
> 
> Again, this isn't the first principle: I'd say that it is: 
> domains would
> like to send messages to domains with which there can be no assumption
> of prior knowledge. Further, we want the receiving domain to be able
> to detect authorized from unauthorized use of a purported sending
> domain's namespace/service pair. This doesn't *necessarily* entail
> the use of DNS though it may.
> 
> 
> > If I am the owner of 'example.com', I can go get a cert 
> from a CA for 'example.com'. 
> > What that cert signifies, ultimately, is that I am the 
> administrator of the name 'example.com', 
> 
> No. Not at all. It means only that the operator of the CA delegated 
> you the name example.com for whatever reason they wanted to 
> delegate you
> that name. It most certainly doesn't imply any sort of role. 
> A protocol
> might want to define such roles, but it is *not* inherent in the 
> credential itself.
> 
> > and consequently that I am empowered to create subordinate 
> names per (1) and (2) above. 
> 
> A CA or DNS administrator is empowered do this, but that doesn't
> directly address my version of (4). Again, you have a particular
> model in mind here which is what I'm questioning.
> 
> > Consequently, when a certificate is used to secure 
> communications, it signifies to you (the recipient) that you 
> are receiving this information from the administrator of the 
> namespace 
> 
> No it doesn't. Sorry this is just fundamentally wrong. There 
> is nothing 
> inherent in a subjectAltName that says that. You might devise a 
> protocol which forces a receiver to make that assumption, but
> that's the protocol's doing, not the credential itself. Again, you've
> got a particular design in mind here, and the problems that I'm having
> is with the implications of your assumptions.
> 
> > Your point above seems to be that a certificate for 
> 'example.com' is too broad a tool for a SIP authentication 
> service to use, because SIP is just one service, and domain 
> administrators would not want to empower a SIP auth service 
> to speak for any and all services of 'example.com'.
> 
> Yes.
> 
> >  After all, if the private key for 'example.com' is 
> resident on a host running a SIP auth service, that host 
> could create signatures over messages or documents for all 
> kinds of non-SIP applications. Accordingly, using a cert with 
> a subject(AltName) of 'example.com' to sign SIP requests is 
> not feasible.
> > 
> > But of course, any domain that doesn't trust its "telephony 
> guys" could have a subordinate name for telephony; e.g., 
> 'sip.example.com' and 'prtp.example.com' could be run on 
> separate hosts. Separate certificates could be acquired for 
> those hostnames. Subordinate usernames under those hosts like 
> [email-masked]' and [email-masked]' could 
> be created. So...
> 
> The point here is that you're forcing a particular shape of the
> namespace to accommodate the ability to delegate authorization. What
> disturbs me is that you're not doing this by shunting the 
> authorization
> information into a backwater of the namespace (which is what both
> IIM and DK do), but instead forcing the real life *users* of the 
> namespace to be shunted over there too. That is, I'd have to be known
> as [email-masked] and [email-masked], and so forth. That
> strikes me as really, really ugly and mostly likely administratively
> infeasible for large existing domains. Preserving a single name for 
> end identities across different services seems like it should be a
> *requirement* to me. As in, a first principle.
> 
> I'm afraid that the rest of your argument falls apart if that
> requirement is accepted.
> 
> 		Mike
> 

_______________________________________________
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

---

From: Michael Thomas <[email-masked]>
Date: Thu, 21 Apr 2005 16:56:48 -0700

> - You don't believe that existing CAs which issue certificates for web sites (i.e., for domain names) have enrollment policies that restrict the issuance of certificates to the owners of the domain…

No. The CA vendors merely issue the cert to a properly authorized
entity for a given *name* which they are authorized to assert.
This says nothing about the *role* that cert plays within the
organization. It is Out Of Scope from the CA vendor's standpoint.
If you want to bind authz/role information to an identity which
is provable via a cert, that is up to the users/protocols not
the CA vendors. 

What I specifically have a lot of problem with is saying as
you do that there is something inherently significant about
a cert that doesn't have a xxx@ in the subjectAltName. That
is an invention/expectation of sip-identity. And since it is
not, we need to be careful about overloading those semantics
for SIP onto a more general purpose name binding system.

> are receiving this information from the administrator of the 
                                      ^^^^^^^^^^^^^^^^^
> namespace 

That is, you are saying that it implies role and/or authorization.
It does not. People *conflate* this all the time, but that is
because there is exactly one service that uses certs right now:
the web. But that conflation all falls apart when you need to
delegate that name to some entities for service X and other
entities for service Y. Otherwise your SIP proxy will be 
authorized to trade my Prized Roosters again.

> - I believe that existing CAs which offer certs to web sites have an enrollment process which verifies ownership of the requested domain name. If you disagree, please go to Verisign, GoDaddy or Geo…

That's not what is at issue. It's whether there's any implied
connection of www.amazon.com to the https service. There isn't.
You can use a www.amazon.com cert for the Prized Rooster Trading
Protocol just as well.

> - I believe that when I form a TLS connection to www.amazon.com, I download a certificate which allows me to verify that integrity-protected content sent over the TLS connection actually comes from…

Suffice it to say that there is much less to web server based
authentication than meets the eye. The little lock icon is,
uh, not a complete fiction, but it's not really as much as
a safety net as people might think. Let's not go here though.

> - In my previous mail, and in the draft, I acknowledged that this is a limitation of sip-identity, though I don't share your apocalyptic feelings about it. I agree it is a requirement, and it is, as I said, a subject for future work []. 

I'm sorry, but how can something be a requirement and a subject
for future work at the same time? Doesn't the Pauli exclusion
principle apply?

And fwiw, I don't feel apocalyptic about it, I just don't
want you to have the accidental authority to trade my 
prized roosters in the mean time.

> Incidentally, I have been aware of the various MASS drafts for some time, and I continue to believe that there are far more similarities than differences between sip-identity and the MASS efforts.…

I've been trying very hard to stay on the fence about that
subject. But I do have to ask: do you think there are things
that dk/iim can't do for sip that sip-identity can? I've been
struggling to come up with any differences in the problem
spaces they are attempting to address. This isn't a rhetorical
question.

		Mike