Subject: RE: [Sip] sip-identity-05: display-name woes

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 19 Apr 2005 04:45:55 -0400

Mike,

I'm not sure why you think sip-identity suffers from the same problem. The presence of an Identity header signifies that the owner of a namespace (the signer of the hash) authorizes the use of the name populating the From header field. The Identity header exists for no other purpose. So what exactly is the problem?

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Michael Thomas [mailto:[email-masked]]
> Sent: Monday, April 18, 2005 3:02 PM
> To: Francois Audet
> Cc: Peterson, Jon; 'Paul Kyzivat'; 'Brian Rosen'; [email-masked]'
> Subject: RE: [Sip] sip-identity-05: display-name woes
> 
[snip]
> 
> Much better would be for a way for the name space owner
> to assert whether something using its name space is
> authorized or not to be sending on its behalf. And DNSsec
> alone for ENUM doesn't provide this since DNSsec is a 
> source authentication scheme, not a source authorization 
> service.
> 
> Of course, I think that sip-identity suffers from the
> same problem...
> 
> 		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: Tue, 19 Apr 2005 08:13:53 -0700

> I'm not sure why you think sip-identity suffers from the same problem. The presence of an Identity header signifies that the owner of a namespace (the signer of the hash) authorizes the use of the…

I'm not talking about the header here, I'm talking about
about the credential being asserted. As always, authentication
!= authorization: my merely having a credential in a namespace
does not mean that I am authorized to perform every service
that namespace offers, for example. In this particular case,
if example.com gave me a cert for [email-masked] which is
how I identify myself for, oh say, ssh access that does
*not* mean that I likewise then get the ability to assert
sip-identities for the whole domain. Example.com must be
able to delegate whether I'm allowed to do that or not. 

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

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.

		Mike