Subject: RE: low-infrastructure GSS mechanisms?

From: Paul Leach <[email-masked]>
Date: Fri, 8 Jan 1999 13:47:57 -0800

> -----Original Message-----
> From: David Jablon [mailto:[email-masked]]
> Sent: Friday, January 08, 1999 1:21 PM
> To: Paul Leach
> Cc: [email-masked]'; [email-masked]; [email-masked];
> [email-masked]
> Subject: RE: low-infrastructure GSS mechanisms?
> 
> 
> At 10:41 AM 1/8/99 -0800, Paul Leach wrote:
> > Please note that the last Digest SASL draft also included 
> integrity and
> > confidentiality services.
> >
> > Also, it seems to me that creation of a DH tunnel ought to 
> be able to be
> > done in a way that is orthogonal to the protocol (authentication or
> > otherwise) being tunneled. [...]
> 
> Unfortunately this advice is contrary to a basic sound
> design principle for secure authentication protocols:
> namely, that authentication should be integrated with
> key exchange.

I don't disagree. I think that such a design principle violation is implicit
in the concept of a DH "tunnel". At least, that's the implication if we use
the common definition of tunnel from the network layer, which is that it's
transparent to the next layer up.

If Ted meant something different in his use of "tunnel", then we just had a
terminology mismatch. I think you are objecting to a DH tunnel, too, and
advocating a tighter integration of DH into Digest.

I'd be interested in seeing a proposal for how it might work.

BTW: if one exchanged a key with DH, then tunneled Digest, which
authenticates and exchanges a key in an integrated way, then all tarffic
would be double encrypted. The main purpose of the DH tunnel would be to
protect the Digest exchange from passive attacks, which would otherwise be
able to get the name fo the user, and the challenge/response pair, which are
sent in the clear.

==========================================================================
This message was posted through the Stanford campus mailing list
server.  If you wish to unsubscribe from this mailing list, send the
message body of "unsubscribe ietf-cat-wg" to [email-masked]

---

From: David Jablon <[email-masked]>
Date: Fri, 08 Jan 1999 19:55:34 -0500

At 01:47 PM 1/8/99 -0800, Paul Leach wrote:
>> design principle [...]
>the common definition of tunnel [...]

Ok.  I think we seem to agree on the definition and
limitations of a DH tunnel.

My main point was that is seemed wrong to separate the
DH tunnel, as a distict step, to be applied to an arbitrary
set of hash-based methods.

> [...] I think you are objecting to a DH tunnel, too, and

Not exactly, and yes.  I object to a separate DH tunnel as a
*generic* solution for bolstering weaker protocols.
I have no problem with Ted's suggestion of it for a
specific protocol alternative.  But at the very least,
I think we must not *discourage* tighter integration of DH
or other tricks into the protocol.

So, I think we're generally on the same page.

Perhaps, rather than focusing on whether DH can be broken
out as a separate step, it would be fruitful to focus
on how a stored verifier format can vary within
the same essential protocol.

Imagine two different systems, where one
stores a clear-text password and the other stores a
verifier V = hash(password).  Let's make them use
the same auth protocol.  The only difference
is that the second system uses V as a shared secret.
This seems workable.

But I can also imagine systems where the client
has built-in knowledge of the construction of V,
and uses it in the protocol.  This is where it may be
important to make the protocol modular, so the function
used to compute V can be replaced depending on the
environment.

Also, before getting into real specifics, I think it
might be good to verify that we have some general
agreement on what "low infrastructure" means.
For starters, I've been taking it to mean:

  "using pre-shared secrets,
   without using a PKI,
   without using stored secrets on the client, and
   where the host's secret verifier wasn't built
     using public-key encryption."

Here I'm trying to generalize a basic password-based
infrastructure.  The last part suggests, for example,
that we have no control over the /etc/passwd format.
Clearly, one can improve certain systems by improving
the stored verifier format, but I've presumed this
to be out of our scope.  Any disagreement?

-------------------------
David P. Jablon
Integrity Sciences, Inc.
[email-masked]
<http://world.std.com/~dpj/>
+1 508 898 9024