RE: a draft on messaging, impersonation and identity

["Peterson, Jon" <jon.peterson@xxxxxxxxxxx>]

Mike,

> I think that out of the exercise of my part of the IIM
> draft, I've finally come to an understanding of where I
> think that "traditional" views of PKI, etc, go off track.
> I've viewed this problem from very early on from the
> standpoint of authorization; in this case, who's allowed to
> use/assert names from a given domain. That's really what the
> domain holder wants: control over the use of their good
> name. As such, *authentication* is not a primary virtue, but
> instead a means to the end of asserting that control. 

Agreed, basically. The same critical insight into the limitations of
"traditional" PKI obviously motivated the SIP identity work, with which I
believe you are familiar. An identity assertion, in my terminology, is an
assurance of your authorization decision about "who's allowed to use/assert
names" which can be carried in a message or somehow made available to other
parties in the messaging architecture.

Hence language in my draft like Section 3.1:

"...the identity provider must furthermore determine whether or not the
originator is authorized to send the message in question... this
authorization decision may be based on a number of factors; for our
purposes, the most important is the identity claimed by the originator of
the message. An originator may be authorized to claim one identity, or any
of a number of identities, in accordance with the policy of the controller
of the namespace containing the identity."

If you assume that the assertion is domain-based (which I think is a
reasonable scope, and obviously is the one we chose for SIP identity), then
for the paragraph above, the identity provider would be the domain. This
seems to capture the philosophy you espouse above.

I agree that authentication of the originator is not material, and is
outside the scope of my document (it's a matter that is at the sole
discretion of the identity provider). However, I'm not sure that a different
variety of authentication is not a primary virtue - someone who relies on an
identity assurance must have some way to authenticate the provider of that
assurance, or they have no way of knowing if it was created by someone who
is actually entitled to make that authorization decision. This is where the
trade-off you mention next becomes very material:

> Whether you use certified, uncertified, etc, etc identites
> is primarly a risk tradeoff assessment of what degree of
> control is actually needed/useful for a given set of
> threats. For example, I care greatly that the powers that be
> (such as they are) exercise extreme control over who is
> authorized to launch nukes. On the other end of the
> spectrum, we've until very recently gotten by with an email
> system that gave domain holders have *no* control whatsoever
> over who uses their namespace. I think that many agree that
> this lack of control needs to change for email.
> 

Also agreed. My draft expends much of its effort in assessing precisely that
risk trade-off.

> I believe that the entire MASS effort -- and ones that are
> likely to follow if it is sucessful -- is an effort to find
> a happy medium between the desire to control the use of some
> resource by a resource holder (eg, authorization) and the
> difficult tradeoffs between various identity schemes and the
> threats and deployment characteristics they themselves bring
> to the table (as PKI's surely do as well). Once that
> tradeoff is made, we have just one (albeit important) piece
> in the overall puzzle.
> 

Also agreed. 

> Thus, I fundamentally think that starting from identity and
> working out from there is a good way to lose sight of what
> the original problem was. Afterall, the original problem
> wasn't "can I name something", but instead, "who's allowed
> to do this/use this/assert this and how can I enforce
> that in a way that affords me more control in reality
> than I have today?".
> 

Well, if there's any difference between our perspectives here, I suspect
it's merely terminological. For me, an identity is a name in a namespace,
specifically the return address claimed by the originator of a message. An
identity provider is someone is who has the authority to determine who is
allowed to use an identity. An identity assertion is a reflection of that
authorization decision which is carried in the message.

So, I do think that it is necessary to start from identity is the sense that
we need to understand what identity is before we can determine who has the
authority to to assert that someone can use it. The namespace itself, and
the manner in which it is allocated, delegated, and so on, must teach us who
is authoritative over names. Without any significant analysis of the
namespace itself, it would be impossible to define 'domain-based' assertions
in any reasonable way, solve problems related to name subordination, and so
on.

Jon Peterson
NeuStar, Inc.

> 		Mike
> 
>