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

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 19 Apr 2005 14:37:39 -0400

Mike,

> As far as I can tell, there's an implicit assumption in
> sip-identity that the way that example.com would prevent 
> me from signing sip-identites for the whole domain  is 
> to... just not give me that cert. 

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

So, "[the domain] just not giving [a random user] the cert" is not the issue. The domain is not the CA, and it is not the domain's business to distribute certs. The authority for the domain is eligible to receive a cert from a CA, and a random user of that domain is not.

While one could argue that CA processes for issuing certs are flawed, or what have you, a draft about SIP identity is hardly going to rectify that.

> That's not a very 
> good assumption as credentials can be used for a wide
> variety of things, and having to run parallel namespaces
> which each gate a particular authorization domain would
> be a horrible management nightmare. 

Your point that a domain uses credentials for a wide variety of things is relevant, and it is a limitation of the sip-identity mechanism. It is, as you say, an operational limitation. It's hard for me to see how impactful this will ultimately be. If cisco.com, say, doesn't want some SIP authentication service to store and use the private key associated with its 'cisco.com' cert, then cisco.com would be forced to create a parallel namespace, like sip.cisco.com, for its SIP users.

While either or both alternatives could be awkward for particular administrative domains, I would submit I have hard time looking at this as a "horrible management nightmare".

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

There is some treatment of name subordination issues in the -04 version of the draft, and I am beefing up that language a bit in the -05 to make this more clear. -05 also leaves a few doors open for future work to improve on the name subordination story. However, I believe that the current story is practicable, and that we can go forward with it for this initial iteration.

> 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. Whatever else one may think a cert means, it means that the holder of the cert was verified by the CA to have authority over that domain name in the DNS. That is the only 'role' we are concerned with here.

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 07:50:00 -0700

On Tue, 2005-04-19 at 11:37, Peterson, Jon wrote:
> 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.

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

> 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. 
.
> Your point that a domain uses credentials for a wide variety of things is relevant, and it is a limitation of the sip-identity mechanism. It is, as you say, an operational limitation. It's hard for…

As I said, you cannot create a parallel namespace unless the
receiver has a way to know which namespace is appropriate
for which service. Consider the actual fact that I'm completely
ignorant about example.com's namespace(s). Which one do I
consider to be valid when I get an incoming INVITE?

> While either or both alternatives could be awkward for particular administrative domains, I would submit I have hard time looking at this as a "horrible management nightmare".

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.

> There is some treatment of name subordination issues in the -04 version of the draft, and I am beefing up that language a bit in the -05 to make this more clear. -05 also leaves a few doors open fo…

So is the idea to segregate out the name space with the
sip: preceding the subject alt name? 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.

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

		Mike

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 22 Apr 2005 14:46:07 -0700

It sounds like a possible solution to this problem  would be to defined some
Key Usage Extensions (see RFC 3280) in the certificate that said it was
allowed to be used for SIP, SSH, Prize Rooster Protocol, or whatever. This
would allow a certificate to be generated for example.com that could only be
used by the SIP server and not the Rooster Roaster.

On 4/20/05 7:50 AM, "Michael Thomas" <[email-masked]> wrote:

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