Subject: Question on transport protocol

From: Derek Fawcus <[email-masked]>
Date: Tue, 15 Jan 2002 03:30:31 +0000

In the transport protocol,  section 8 (Service Request),  the last paragraph
states:

   Note that after a key exchange with implicit server authentication,
   the client MUST wait for response to its service request message
   before sending any further data.

I'd like to ask why is the above contraint there?  I assume it's for some
security reason,  but looking at the packet flow,  I can't see a reason
for it.

i.e. it would appear that no additional information is leaked by allowing
say a USERAUTH_REQUEST to immediatly follow the SERVICE_REQUEST even when
the server has been implicity authenticated.

Mind it's a bit of a pointless optimisation given that the user should
be prompted about the implicit authentication,  but it could make an
implementation fractionally simpler.

What am I missing?

DF

---

From: Derek Fawcus <[email-masked]>
Date: Tue, 15 Jan 2002 04:06:42 +0000

[  I'm adding the list back into this reply ]

On Mon, Jan 14, 2002 at 10:36:37PM -0500, Richard E. Silverman wrote:
> On Tue, 15 Jan 2002, Derek Fawcus wrote:
> 
> > In the transport protocol,  section 8 (Service Request),  the last
> > paragraph states:
> > 
> With implicit authentication, the client verifies server authentication by
> checking that it can decode traffic from the server using the
> just-negotiated shared encryption key.

That's the bit I don't get.

> So it must wait for the next
> message from the server; if it doesn't, then it may be sending (possibly
> sensitive) data to a bogus server.

Surely after the DH exchange,  both ends have the same shared secret,
thus the above authentication will always succeed?  The fact that the
KEX_DH_REPLY had a signed hash seems to provide as good an authentication
as one is going to get.  Thus the client should always be able to decode
the first packet.

Or is the intention that if a non DH exchange is used,  then this delay
is required (i.e in the more general case).

I'll admit that I'm discussing this from a position of ignorance wrt
the key exchange protocol,  it may well be that it's required and
the method of attack it would fall to is just not obvious to me.

DF

---

From: Derek Fawcus <[email-masked]>
Date: Tue, 15 Jan 2002 04:39:28 +0000

> security reason,  but looking at the packet flow,  I can't see a reason

A bit more about what I'm thinking...

The obvious problem with implicit server authentication is that it leaves
one open to a MITM attack.  However I don't see how the above constraint
helps here.  You'd have just done a sucessful DH exchange with the MITM,
and he can then fake all responses,  delaying till you get the SERVICE_ACCEPT
doesn't appear to gain any advantage in this case.

I there must assume it's for some other scenario,  if so then what?

DF

---

From: "Richard E. Silverman" <[email-masked]>
Date: Tue, 15 Jan 2002 07:39:57 -0500 (EST)

Exactly.  In your next post, you write:

> The obvious problem with implicit server authentication is that it
> leaves one open to a MITM attack...

This doesn't make sense, as a big objective of anything called "server
authentication" is exactly to *prevent* MITM.  Perhaps you have some model
of implicit authentication in mind, but the spec does not specify a
mechanism for "implicit server authentication."  The idea is merely that
it might happen as an integral part of some future key-exchange method,
which could then do without explicit server auth mechanism described here.
For examples, see the server auth method of SSH-1, as well as the
proprosed GSSAPI/Kerberos method for SSH-2.

-- 
  Richard Silverman
  [email-masked]

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 16 Jan 2002 01:02:24 -0500 (EST)

> proprosed GSSAPI/Kerberos method for SSH-2.

FWIW, the GSSAPI key exchange doesn't rely on this -- during key exchange,
a GSSAPI security context is established and then used to sign a DH
exchange, similarly to the way the host key is used during the normal
signed DH exchange described in the transport draft.  Once GSSAPI keyex is
complete, you know the server's identity and that there is no MITM. 

However, there's something in the back of my mind saying that removing
this requirement would be a bad idea.

-- Jeffrey T. Hutzelman (N3NHS) <[email-masked]>
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA