RE: a draft on messaging, impersonation and identity

[Michael Thomas <mike@xxxxxxxx>]

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@xxxxxxx]
 > > Sent: Saturday, October 16, 2004 3:58 AM
 > > To: Peterson, Jon
 > > Cc: ietf-mailsig@xxxxxxx
 > > 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.
 > >