ietf-mailsig
[Top] [All Lists]

RE: a draft on messaging, impersonation and identity

2004-10-17 00:39:23

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




<Prev in Thread] Current Thread [Next in Thread>