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.
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.
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.
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?".
Mike
Peterson, Jon writes:
Hi George,
Glad you found some value in the document.
I do have some experience with identity-based cryptography, though mostly
for encryption rather than signing. I agree that the pieces of the puzzle
are moved around in potentially interesting ways by these systems.
In the parlance of my document, IBS would create a user-based assertion, in
which the identity provider (probably the originator) obtains its private
key from a key-store (the PKG - essentially, this is a by-reference key
distribution to identity providers), and the verifier can validate the
signature over the assertion provided that it holds the public key of the
key-store. The chief problem is distributing the public key of the store to
verifiers in such a way that it is clear that the key store (rather than the
identity provider) has authority over the namespace of the originator.
Practically, this is accomplished by providing a secure, certified manner of
downloading the public key of the key store (like HTTPS); a URI with this
property would probably be enclosed in the message, since the originator
cannot anticipate whether or not a given verifier already possesses the key.
Since the key store's public key is probably uncertified, it would not be
safe to include the message by-value (since its authority would not be
determinant in that case).
What this buys you is end-to-end cryptography between the identity provider
and the verifier in which it is easy for the originator to act as the
identity provider. It doesn't immediate seem to provide any useful
properties for intermediaries that instantiate the identity provider role.
It also enables to verifier to persist only the public keys of the store -
it doesn't need to persist any keying material on a per-user basis, which is
very unusual for a user-based assertion system, and a definite advantage.
Moreover, recipients instantiating the identity provide role are able to
encrypt messages sent in the backwards direction to the identity provider
(who in useful architectures is probably the originator); this is a neat
side-effect, though not strictly in the scope of preventing impersonation.
Is this a decided improvement on, say, the domain-based assertions described
in my document? I think that has to depend on how strongly you value the
end-to-end properties of this mechanism. If user-based assertions and
originators acting as identity providers are very attractive, this provides
a better approach than most to achieving those goals. The fact that a
trusted third-party knows the keys really isn't any different, from a
security perspective, from the assumptions of domain-based assertions.
Were I to include something in the document about IBS, my starting text
anyway would be along the lines of the above. Given that there are material
differences and advantages, it probably should be included.
Jon Peterson
NeuStar, Inc.
-----Original Message-----
From: George Gross [mailto:gmgross(_at_)nac(_dot_)net]
Sent: Saturday, October 16, 2004 3:58 AM
To: Peterson, Jon
Cc: ietf-mailsig(_at_)imc(_dot_)org
Subject: Re: a draft on messaging, impersonation and identity
Hi Jon,
a very good read, thank you for producing this survey. Very
through assessment.
I noticed that you didn't mention and analyze the Identity-Based
Signature public key crytosystems. While these systems are relatively new
(none are standardized AFAIK) they do possess properties that may work
well in this problem area. Notably, the ability to algorithmically map an
asserted identity to its public key. Recent advances in the crypto allow
hierarchical namespaces in the IBS public key systems. The main IBS
drawback is the key escrow problem. The TTP knows the signature private
keys, although there are techniques to distribute the secret across
multiple trusted parties.
do you think IBS merits a mention in your document?
br,
George
On Sat, 16 Oct 2004, Peterson, Jon wrote:
Hello,
Long time listener, first time caller.
Once or twice, it has been mentioned on this list that
identity work has
been underway in the SIP WG of the IETF, and that there are
some high-level
similarities between that work and the work here. As I was
writing up an
overview of the design decisions and trade-offs we
perceived in the SIP
identity work over the past couple years, I decided to try
to make these
remarks less specific to SIP, and more applicable to
Internet messaging
systems that share a certain set of qualities.
The result is the following draft (which you can fetch here
until it appears
in the repository, or if you just like HTML versions):
http://www.unreason.com/jfp/ietf/draft-peterson-message-identi
ty-00.html
To be clear, this draft is not a proposal for an identity scheme for email
or indeed any other protocol. Instead, it tries to define the threat of
impersonation and the concept of identity for messaging, delineate some
roles in an identity architecture that meet might that threat, and discuss
the structure and distribution of both identity assertions and the
cryptographic keys which might be used to secure them.
In terms of applicability to this group: while this document does not
argue
for any particular proposal, it might provide some useful vocabulary and
architectural concepts, show the trade-offs associated with various design
decisions, and perhaps most importantly show how these design decisions
interrelate. If the analysis seems valid to the group, this document could
be used to classify and compare the various solutions being considered
here.
Being a -00 draft, it is undoubtedly not perfect, but perhaps it's a
reasonable start.
Jon Peterson
NeuStar, Inc.