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 16:29:43 -0400

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

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', and consequently that I am empowered to create subordinate names per (1) and (2) above. In more detail, this means that I have administrative authority over the domain. I may of course delegate authority over subordinate names to someone else within my organization, or a subcontractor, or what have you. But I administratively choose the host that 'example.com' points to. If the people operating that host issue subordinate names (per (2)) in ways that I don't like, I am empowered to change the host for 'example.com' to one that behaves as I like, as a matter of last recourse. When I get a certificate for 'example.com', the enrollment process establishes that I have administrative authority for 'example.com'. I may then give the cert and the associated private keying material to someone else to use in an application, and if they use it in ways I don't like, I have administrative recourse to give it to someone more responsible. This is what it means to have administrative control over a domain - you control how names are allocated, and you have administrative control over the certficate of that domain. This authority is not specific to any application - it is authority over the name. However, authority over the name entails administrative authority over applications; if you don't like the way hosts are running, you can change the DNS for your name such that it no longer points to misbehaving hosts. 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 (or their delegate). This is significant for sip-identity because the assurance sip-identity provides is about the administration of names within a domain - it must come from someone with authority over how subordinate names are delegated for the domain in question. That is the authority that matters here.

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'. 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...

> [*] no you cannot use a different root to separate them out because
>     the receiver doesn't know which roots represent which service.

... in that case, I think it would be very clear to the receiver that a request from [email-masked]' needs to be signed by 'sip.example.com', nor 'prst.example.com' or what have you. If that's what you mean by a 'different root', it seems totally feasible to me.

But isn't it, well, lame to use names of the form [email-masked]' rather than [email-masked]'? Yes, it is somewhat lame. But it is neither broken from a security perspective nor infeasible from an administrative perspective. Moreover, I believe that there will be administrative domains in which people do trust the "telephony guys" with the private key for their domain, and/or there will be domains created specifically for SIP as a service where this lameness will not arise.

Thinking to the future, MX records were created to palliate this sort of lameness in mail deployments. SRV and NAPTR records for SIP serve a similar purpose. Is it possible these records, or some similar tool in the DNS, could be checked by verifiers to identify the canonical auth service for a particular domain? Definitely. Then a verifier could fetch the DNS record and say, "Ah, for all users in 'example.com', SIP requests should be signed by a cert from 'sip.example.com', not 'prst.example.com' or any other host." This could make the lameness go away - provided you trust the DNS, of course. sip-identity has hinted at this as a direction for future work for a long time (at least since the -02 version). 

However, I have not felt it is worth articulating that proposal further until we get the fundamentals of sip-identity down pat. I think sip-identity is useful enough without this capability that we can put the specification forward and worry that (and a few other matters) later. 

> > It does not assume that if you hold the cert 
> sip.example.com. or sip:[email-masked], that you are the 
> authority for example.com. How does one get a cert for 
> example.com? That is matter of CA policy, to a large extent, 
> but there is typically a validation process. The validation 
> process consists of the CA determining whether or not the 
> requestor of a certificate has authority over that particular 
> name in the DNS
> 
> I don't understand the DNS part, and don't recall seeing
> anything about DNS in the draft. 

I am talking about the procedures of certificate enrollment, here, not about any sip-identity procedures.

[snip]
> Right now, there typically exists zero PKI namespaces
> (with the lone exception of http server certs) within
> most organizations. I don't think that bodes well for
> handwaving.
 
True, but, we have gone to some trouble to make sure that the same PKI used for HTTP server certs can be used for SIP. That doesn't mean that the same -certs- are used for both, necessarily, but that the same CAs, and CA enrollment procedures, and so on, are used. A new PKI would be a fruitless approach to this.

> > > Worse is that a naive
> > > cross domain receiver has *no* way to know which of example.com's
> > > namespaces ought to be considered valid. So it doesn't even
> > > work in this case.
> > 
> > Well, no, I'm not sure that is true. If cisco.com uses a 
> cert with a subject of 'cisco.com' in their auth service, 
> then SIP users would have names of the form 
> 'sip:[email-masked]'. If it uses, say, sip.cisco.com in their 
> auth service, then SIP users would have need to have names of 
> the form 'sip:[email-masked]'. So, saying that it doesn't 
> work isn't fair. It will be clear to a cross domain user 
> whether or not the domain in the From header field matches 
> the domain the subjectAltName of the cert.
> > 
> 
[snip]
> So is the idea to segregate out the name space with the
> sip: preceding the subject alt name? 

No... as it says above, the proposal is that there is a -domain- in the subjectAltName. I'm not sure how you could have derived that inference from the text above. The names of SIP users (which have a 'sip:' in them) have a domain portion, and that domain portion must correspond with the domain in the subject of a cert.

> This is getting 
> weirder and weirder, because that implies that I'm going
> have a pile of different purpose built certs per/user 
> which is really awful because enrollment is the actual
> Really Hard Problem of PKI. If you're going to go down
> this cert route at all, you really ought to look into 
> attribute certs instead of overloading namespace with
> authz semantics.
 
Yeah, that would suck.

> > 
> > > NB: this is a common conflation with would-be cert users.
> > > What you get with certs is authentication and nothing more.
> > > Authorization is necessary to bind identity with role. That's
> > > missing in the sip-identity draft.
> > 
> > Yes, the cert authenticates the owner of the namespace. The 
> act of creating the Identity header makes an authorization 
> assertion about the use of the From header field in a 
> particular message. 
> 
> It can assert all it likes. If I can't verify the authority
> of that assertion it's worthless. That's the problem here. 

The manner in which you (the recipient) verify the authority of the assertion is by comparing the domain in the URI in the From header field to the domain in the subject of the cert. If they match, there is authority; if they don't match, there is no authority. What's the big deal?

Jon Peterson
NeuStar, Inc.

> 		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: Wed, 20 Apr 2005 16:51:42 -0700

On Wed, 2005-04-20 at 13:29, Peterson, Jon wrote:
> 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:
> 

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…

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

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

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 21 Apr 2005 09:02:25 -0400

Mike & Jon,

I don't know much about the mechanics of this, but I'm learning a lot 
and having fun watching the two of you go at it. If the two of you don't 
kill each other then I think we may get a good outcome. I want to 
comment on one point from a requirements point of view:

> *requirement* to me. As in, a first principle.

I think this is really important. Its not sufficient that the email 
service at example.com may have a user [email-masked] and the sip 
service may have a user [email-masked]. Its important that those two be 
assigned to the same "entity".

I don't want to get into a situation where, after having talked with

	"Miles Anderson Thomas" <sip:[email-masked]>

I send email to [email-masked] only to discover that it goes to

	"Mary Alice Taylor" <mailto:[email-masked]>

Paul

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 21 Apr 2005 09:46:19 -0400

You may not want to find that situation.
But preventing a mistake in that regard is up to the domain.  A domain can 
choose to use separate assignment policies and practices to assign SIP and 
Email addresses.  I agree that this would be a foolish practice, but it is 
not a violation of the standards, and our authentication work can not 
assume a specific practice in this regard.

yours,
Joel M. Halpern

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 21 Apr 2005 12:11:23 -0400

Joel M. Halpern wrote:
> But preventing a mistake in that regard is up to the domain.  A domain 
> can choose to use separate assignment policies and practices to assign 
> SIP and Email addresses.  I agree that this would be a foolish practice, 
> but it is not a violation of the standards, and our authentication work 
> can not assume a specific practice in this regard.

It may be out of scope of any particular group. But it would be nice to 
find a way to make this some kind of best practice if nothing else.

	Paul

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 22 Apr 2005 15:12:04 -0700

The best practices around handling namespaces are pretty ugly. For example,
if you left your current employer, people sending you email might suddenly
find that their personal email to you was being delivered to HR. We have a
change in the person receiving the message over the same protocol for the
same name - this is nasty but more or less a requirement of enterprise
email. Trying to enforce how domains manage the names is pretty hard.

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 22 Apr 2005 18:32:35 -0400

Cullen Jennings wrote:
> find that their personal email to you was being delivered to HR.

I don't have a huge problem with that. (I shouldn't have been getting my 
personal mail at my business address.)

"[email-masked]" is me the cisco lacky.

"[email-masked]" is me the human with a private life. (Well, it 
would be if I *had* a private life.)

> We have a

*Enforce* is probably to much to expect. But that doesn't mean there 
can't be best practices. Both the sip and mailto can be attached to the 
"same" destination, whether that is an employee or the HR department.

	Paul

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 22 Apr 2005 16:03:01 -0700

Fair enough, I understand that enterprises using different address for the
same person for email, voip, and IM would be pretty weird and confusing but
I don't think it is really an issue we have to tackle.