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

From: "Peterson, Jon" <[email-masked]>
Date: Fri, 22 Apr 2005 18:26:00 -0400

Well, I think we are actually homing in on a bit of common ground.

More 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",
> 
> No. The CA vendors merely issue the cert to a properly authorized
> entity for a given *name* which they are authorized to assert.

Of course. But here I think we're splitting hairs a bit. You say "a properly authorized entity for a given name", I say, "owners of the domain names in question". I'm not sure there's a material distinction, or least, for the purposes of my argument I wouldn't distinguish between the two. I think the entity meeting either of those descriptions would have authority over how the DNS is populated for the name in question, and that's all that matters to me.

> This says nothing about the *role* that cert plays within the
> organization. It is Out Of Scope from the CA vendor's standpoint.

True. Unless it's some kind of attribute cert, or something, neither the cert itself, nor the circumstances under which it is issued, should have any bearing on how it is used by the organization.

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

Of course. A cert just authenticates the entity to whom it is issued. The way the cert is used, the information the cert is used to sign, is what gives its usage semantics in the context of any interaction, including SIP. Using a particular cert to sign a particular piece of information is said, for SIP, to have a particular semantic that can be verified by recipients of messages. Nothing about that "role" is inherent in the cert. It just so happens that the cert authenticates an entity that is the proper entity to provide a certain judgment for the purpose of the SIP identity mechanism.

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

I've tried to clean up this language a bit for -05, and hopefully it will be an improvement. In the first place, I now talk about domains appearing in the CN field of the subject of the cert as well as the subjectAltName. Our aim here is to correspond exactly with the conventions for identifying web servers in the existing e-commerce field, so, using the CN field of the subject is actually more accurate (though I understand subjectAltName is used as well when multiple hosts are subjects of the same certificate, as is the case in some web hosting architectures).

Of course, that really doesn't so much answer the implied questions above. I do not want to invent anything about the certificate business for sip-identity, nor change existing practices, if I can help it, for issuing certificates. I agree that the implication that the subjectAltName is special, and that if there's a domain name in it, that domain name is reserved for SIP, or something, would be totally inappropriate and self-defeating. We're not trying to do anything like that, here. Hopefully, as the new text it written, we won't be.

> > - 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),
> 
> No, that's not what you said: 
> 
> > > 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 
> 
> That is, you are saying that it implies role and/or authorization.
> It does not. 

Well, if there's a distinction here, it is very fine. A certificate authenticates some entity. That entity is the one to whom the certificate was issued. In the case of a certificate whose subject is a domain name, that entity is, you said above, the "properly authorized entity for a given name". You may mean something different by that than "administrator of the namespace", but that's a very fine distinction. Does "administrator of the namespace" imply some role or authorization that "properly auhthorized entity for a given name" doesn't imply? Can you flush this out a bit?

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

I think I heard Mr. Kyzviat say this was specifically a non-requirement, something we should require the system to avoid, but...

> Otherwise your SIP proxy will be authorized to trade my Prized Roosters again.

I know that you cringe when I tranpose talk of delegation to name subordination, but I really think it is unavoidable.

When Amazon runs a web service, they don't run it on 'amazon.com', they run it on 'www.amazon.com'. When you acquire a TLS certificate from Amazon, you don't get a cert from 'amazon.com', you get one from 'www.amazon.com'. The one service that uses certs right now uses them in this fashion. So Amazon, it would appear, didn't fall into any trap about this. They needed to delegate to a service, and they decided to do so using the DNS. Of course 'www.amazon.com' could run a mail server, or PRTS, but that wouldn't be 'amazon.com' running those services, it would be 'www.amazon.com'. Amazon can create a mail.example.com with very different users than www.amazon.com, and one that uses a different certificate.

Now, this is not to say that every service needs its own host, or more importantly, it's own domain name - that is a just a human convention that evolved for the web. However, these human conventions have security implications, because it is that domain, 'www.amazon.com', that a user types into their browser, and which they expect to reach. If they get back some other domain in a certificate, that should be a problem.

Email is, of course, very different. We use identifiers of the form @example.com, rather than @mail.example.com, when we send people mail (usually - there are still some holdouts). But we all know that behind the scenes, there are subordinate hosts that run these mail functions, and that they have their own domain names (NeuStar has a bunch, all named after trees). From an interface perspective, it is desirable to hide the existence of these hosts from users. Thus the MX record was born. Without the MX record, we would not be hiding the existence of all the mail.example.com's. Once again, it is what the entity that controls the DNS for 'example.com' populates in their node in the hierarchy that makes email work this way.

SIP has chosen a path similar to email. There are procedures in RFC3263 that define ways to hide these proxy servers from end users so that they only have to remember @example.com, not @sip.example.com. You can even use RFC3263 to send tell users that for SIP services in 'example.com', you need to contact a SIP server over at 'example.org'. The big security problem with these sorts of practices is that the orginator of a connection to 'example.org' need to have some assurance they are connecting to the right guy, especially in the face of the insecurity of the DNS.

So I do think that name delegation and subordination is the key issue here. But I'm not sure I agree with, or perhaps even understand, the conflation you're describing above. It seems me that the way the web uses certs doesn't rule out other services in the same domain using certs at all.

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

Well, sure. I might drop that in Amazon's suggestion box, actually.

But I do understand that nothing about having a cert for a domain name links that cert to any particular service, sure. It is how the cert is used that provides that linkage. The holder of the cert, after all, gets to choose when and how to use it. Using it to sign particular pieces of information is an act that can have meaning to a protocol. As in HTTP, so in SIP.

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

I think we have to go there a little bit, at least so far to say that thwarting the kinds of trivial From-header forgeries we're targetting with SIP identity is a function that I am very comfortable having about as much security as e-commerce security does. Cert enrollment ain't perfect, client handling of certs and so on ain't perfect, but for our purposes, it looks like a fine level of security to me.

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

It is a requirement for the identity system to instantiate the quality in question - for it to be possible for users to have identities of the form 'sip:[email-masked]' even if their identity services are provided by a different host, i.e., for us not to require shunting. For some deployments, it is possible to do this with sip-identity as written. I agree that it does not work for Jon if some other domain, like 'example.org' or 'prizeroosters.trading.example.com', uses their certificate to sign the Identity header.

Cullen and I had a good talk about this requirement today, and a number of important points emerged (from him).

Let's flip this around for a moment. If I am sending a request to 'sip:[email-masked]' over TLS, regardless of where the RFC3263 procedures tell me go (including discovering SRV records for 'example.org' or 'prizerooster.trading.example.com'), I expect the entity on the other end of the TLS connection to provide me with a certificate for 'example.com'. Why is that? Once again, we're following the model of HTTP in order to overcome the inherent insecurity of the DNS. It is the string in the user interface, the URI the human that is attempting to contact, that needs to have reference integrity with the certificate provided by TLS, regardless of what any intermediate (insecure) system like the DNS tells you.

One could argue that because this doesn't allow for certain kinds of hosting cases, it is broken. But it is the security architecture on record for SIP.

So that's the way inbound requests to a domain work. What does this have to do with have requests outbound from 'sip:[email-masked]' work? Everything. sip-identity makes a number of strong assumptions about the relationship between registration (how you express that you are eligible to receive a request for a given AoR) and identity. In fact, it suggests that if you are eligible to register under an AoR, you are eligible to claim that AoR as an identity - that the credentials that allow you to prove the first should also be presented to prove the second. This assumption is based on the usage of the From header field to provide a 'return address', an AoR for the request's originator. Consequently, I really feel strongly that the entity that has authority over validating >From header fields for identity is in fact the same entity that manages the location service. If there were separate entities for these functions who, say, disagreed about whether or not I was 'sip:[email-masked]', that would be extremely problematic. And, of course, the entity that manages the location service is the guy who provides the credential for 'example.com' when you send an inbound request. 

[As an aside, note that the above does not entail that every URI that can appear in a From header field is an AoR, or even routable. Anonymous URIs (sip:[email-masked]) would be an example of a URI that isn't necessarily an AoR. But But that certainly doesn't argue that the system should work for normal 'AoR' URIs]

I think there are a few strong conclusions that fall out of this. I think it would be unwise to revisit a decision about what certificate should be used by an authentication service if we do not revisit the certificates expected for inbound requests going to a domain. If we changed this unilaterally for sip-identity, the sorts of architectures that would be enabled by letting the cert 'sip.example.com' sign for users of the form 'sip:[email-masked]' would not work for inbound calls (the host 'sip.example.com' would still need to have the 'example.com' cert for that).

Is it possible to revisit how inbound call routing works? Sure. But we're not going to do it in passing in sip-identity. It is also conceivable that there is some really clever solution to all of this that we don't know today. Whichever it is, it is future work.

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

Understandable.

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

No, it is an important question. My answer to it is this:

http://www.ietf.org/internet-drafts/draft-peterson-message-identity-00.txt

For those that would prefer the short answer (well, at least shorter than that draft), this is a design space with a number of trade-offs. Some of those trade-offs weigh differently for a real-time messaging system like SIP than they do for a non-real-time system like email. They weigh differently if you can expect, as you can with SIP, that intermediaries are required to support certificates. They weigh differently if you can have different expectations about what intermediaries are allowed to change in a message. They weigh differently if you don't need to worry about distinctions like Sender v. From. They weigh differently if you have a different architecture for exploders. They weigh differently if you can agree on a fixed set of pieces of a message that need to be protected by the signed hash, as opposed to selecting a set on a per-message on per-implementation basis.

In the lingo of message-identity, I would describe IIM as a identity mechanism that uses uncertified assymetric user-based keys, variable replicated reference indicators (including content), intermediary identity providers and verifiers (including verification assertions), user-based assertions placed in the envelope, and which distributes keys by-value (with a network lookup to authorize those uncertified keys). This is, ironically enough, very similar to sip-identity-00, which allowed uncertified user-based keys which are shared by-value and used variable replicated reference indicators (though admittedly, it also put assertions in the body, not the envelope). sip-identity-04, by way of contrast, distributes keys only by-reference, uses only certified keys, has static reference indicators, and employs only domain-based keys. Since it hasn't really been relevant to this thread, I'll skip the bit about reference indicators.

The use of certified vs. uncertified keys has, really, been the substance of our thread up until now. You've been questioning whether the certified keys described in sip-identity-04 really do the job that we think they do. Section 6 of peterson-message-identity (in particular 6.1.1 and 6.1.2) represents my thinking about the overall trade-off. I think it is a lot easier to assume certificates for auth services when you envision those auth services MUST support TLS and will have certificates anyway. If you are interested in user-based keying, clearly, getting certified keys is laughable; sip-identity is only concerned with domain-based keying, where certification is reasonable.

As for user-based keys, clearly there are some security problems that cannot be solved with domain-based keys. However, I feel that the particular threat of impersonation is not one of those. Clearly, sip-identity doesn't help you at all with, say, confidentiality - it just helps with impersonation. We've evolved a related mechanism in SIP (sipping-certs) that is all about user-based keying and specifically targets confidentiality, and so on. We just felt that sip-identity and sipping-certs had different applicability, and that you might want to prevent impersonation even if you didn't care about confidentiality, and so on. The cert stores in sipping-certs have a lot in common with a KRS.

As I understand it, the difference between the key distribution systems of IIM and sip-identity is as follows: sip-identity provides an HTTP URL to a place where a copy of the certified key can be found, and IIM provides uncertified keys by-value, but allows a network lookup to authorize the key which, ultimately, relies on the DNS. Clearly, dereferencing an HTTP URL involves a DNS lookup, so it isn't that sip-identity doesn't rely on the DNS. However, it doesn't -trust- the DNS, because the key acquired via HTTP is a certified key, not an uncertified key. The exact level of trust one is willing to have in the DNS is, of course, proportional to the threats against the DNS, and must be weighed against the likely powers and perseverance of impersonators.

So in summary, I think these are all points on which intelligent people can disagree, and that comparatively subtle differences between SIP and email can lead you in very different design directions. While you might not be comfortable with our use of certificates, I note that the MASS security review asked some pointed questions about why IIM doesn't use certificates, and about reliance on the DNS.

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: Cullen Jennings <[email-masked]>
Date: Fri, 22 Apr 2005 16:01:14 -0700

On 4/22/05 3:26 PM, "Peterson, Jon" <[email-masked]> wrote:

> I've tried to clean up this language a bit for -05, and hopefully it will be
> an improvement. In the first place, I now talk about domains appearing in the
> CN field of the subject of the cert as well as the subjectAltName. Our aim
> here is to correspond exactly with the conventions for identifying web servers
> in the existing e-commerce field, so, using the CN field of the subject is
> actually more accurate (though I understand subjectAltName is used as well
> when multiple hosts are subjects of the same certificate, as is the case in
> some web hosting architectures).

Not sure I agree here. SN was horribly underspecified and caused all sort of
complicated problems. SubjectAlntName (SAN) corrects these and we don't have
a backwards compatibility problem here. 3261 is very clear that the certs
used for SIP have to have a SAN - this allows SIP to avoid a ton of problems
is is not really a big deal for implementers or CA. I think we should
continue using the same sort of certificates for SIP identity that we use
for 3261.

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 22 Apr 2005 19:04:44 -0400

> Well, I think we are actually homing in on a bit of common ground.

Great discussion! But I'm going to snip it all away to comment on one 
trivial point.

> I think I heard Mr. Kyzviat say this was specifically a
> non-requirement, something we should require the system
 > to avoid, but...

If I understand all the nuances then that isn't quite what I meant to say.

You may indeed need to delegate that name to some entities for service X 
and others for service Y: namely [email-masked] may be delegated to 
both the cisco mail server and the cisco sip proxy. Whats important is 
that they were both delegated for purposes of use by the single entity me.

	Paul