RE: a draft on messaging, impersonation and identity

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

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