Re: Newer Rev of Section 11 - was: Re: IESG feedback on core drafts.

[Nicolas Williams <Nicolas.Williams%sun.com@localhost>]

On Thu, Apr 10, 2003 at 02:09:58PM -0400, RJ Atkinson wrote:
> 
> On Thursday, Apr 10, 2003, at 13:32 America/Montreal, Joseph Galbraith
> wrote:
> >> 11.1.3 Replay
> >>
> >>    This protocol binds each session key to the session
> >>    by including random data that is specific to the
> >>    session in the hash used to produce session keys.
> >>
> >> [RJA:  Is it random or pseudo-random ?
> >> [RJA:  Does the difference matter in this case ?
> >
> > It is probably pseudo-random?  I'm not sure if
> > it matters.  If no one else can say, I'll just
> > change it to pseudo-random.
> 
> It would be good if we could find a cryptographer
> who could tell us whether it matters.

IANAC, but what matters is that if the data in question (e.g., DH
parameters) be pseudo-random then the PRNG should be cryptographically
secure (i.e., its next output not easily guessed, even when knowing all
previous outputs) and, furthermore, the PRNG should be seeded with some
truly random inputs (or as random as can be available - not all
implementations will have suitable sources of entropy).

In any case, the amount of entropy available to a given client or server
sometimes may be less than what is needed to run the protocol, in which
case either one must resort to PRNGs anyways or refuse to run the
protocol.  In practice implementors will generally rely on some PRNG.

[...]

> >    In addition, the transport protocol provides a
> >    unique session identifier (bound in part to pseudo-random
> >    data that is part of the algorithm and key exchange process)
> >    that can be used by higher level protocols to
> >    bind data to a given session and prevent replay of
> >    data from prior sessions.
> >
> >    For example, the authentication protocol uses this to
> >    prevent replay of signatures from previous sessions.
> >
> >
> >>    This vulnerability to man-in-the-middle attacks can
> >>    be mitigated in several fashions:
> >>
> >>    1. Narrow the window.  If the client ensures that the
> >>       host key for a given server remains consistant, an
> >>       attacker must execute the man-in-the-middle attack
> >>       on the _first_ connection to a given server.
> >>
> >> [RJA:  Narrow *which* window ?
> >> [RJA:  Intended meaning is not crystal clear above.
> >
> > How about this?
> >    1. Narrow the window during which the client is vulnerable
> >       to such a man-in-the-middle attack..  If the client ensures
> >       that the...
> 
> OK with me.
> 
> >>    2. Use an authentication method that is not vulnerable
> >>       to man-in-the-middle.  For example, public-key
> >>       authentication is not vulnerable to man-in-the-middle
> >>       attack, because the signature is made across data
> >>       that is session specific.  The attack can not use
> >>       the signature he receives because the session specific
> >>       data between the attacker and server is different, and
> >>       can not create a valid signature because he does not
> >>       have the private key.
> >>
> >> [RJA:  Is this really true and sufficient ?
> >
> > Hmm... I'm not sure if I missed something here or
> > what?  If the man-in-the-middle doesn't have the
> > private key, he can't complete the authentication
> > right?  It seems that this is true and sufficient
> > to prevent an attack, but maybe I'm missing something?
> 
> Maybe you didn't miss anything.  It really was a
> question on my part.  Maybe massage the above new
> paragraph to include your sentence:
> 
> 		"[Because] the man-in-the-middle does not have
> 		the private key [of whom ?], the he cannot
> 		correctly complete the authentication with
> 		[whom ?]."
> 
> My main goal here is clarity, so avoiding pronouns
> and making the identities clear is appreciated. :-)

Because public key authentication exchanges are cryptographically bound
to the SSHv2 session (i.e., to the initial key exchange) they cannot be
successfully replayed in other sessions.

(Of course, if two session happen to have the same session ID [hash of
kex exchanges] then packets from one can be replayed against the other;
the chances of such an occurrence are, needless to say, minimal, all the
more so the larger the hash function's output and DH parameters used.)

Also note that the session ID can be made public without harming the
security of the protocol.

> >>    Use of this protocol without reliable association
> >>
> >> [RJA:  association of what/whom ?
> >
> > How about:
> >
> >    Use of this protocol without reliable association
> >    of hosts and host keys is inherently insecure, but
> >    but may be necessary in non-security critical
> >    environments, and still provides protection against
> >    passive attacks.  However, implementors of applications
> >    running on top of this protocol should keep this
> >    possibility in mind.
> 
> Proposed slight edit to first clause:
> 
> 	Use of this protocol without reliable authentication
> 	of the binding between a host and its host keys is
> 	inherently insecure, but ...

Add "and NOT RECOMMENDED?"

> >> 11.2 Authentication Protocol
> >>
> >>    The purpose of this protocol is to perform client user
> >>    authentication.  It assumed that this runs over a secure transport
> >>    layer protocol, which has already authenticated the server machine,
> >>    established an encrypted communications channel, and computed a
> >>    unique session identifier for this session.  The transport layer
> >>    provides forward secrecy for password authentication and other
> >>    methods that rely on secret data.
> >>
> >> [RJA:  "perfect forward secrecy" or "forward secrecy" ?
> >
> > I'm not sure; this paragraph is quoted from the previous
> > security considerations section.  Would any one else care
> > to comment?
> 
> I'm also not sure, but it would be nice if we could find
> someone who is sure -- preferably someone who can supply
> a citation or a more detailed rationale to support the claim.

"Perfect forward secrecy" - see Google search:

http://www.google.com/search?hl=en&ie=ISO-8859-1&q=Perfect+forward+secrecy

and first link that comes up:

http://www.itsecurity.com/asktecs/may201.htm

A very simple difinition:

http://www.atis.org/tg2k/_perfect_forward_secrecy.html

"perfect forward secrecy: In cryptography, of a key-establishment
protocol, the condition in which the compromise of a session key or
long-term private key after a given session does not cause the
compromise of any earlier session."

...

> >> 11.2.3 Local security policy
> >>
> >>    Implementer MUST ensure that the credentials provided
> >>    validate the professed user and also MUST ensure that
> >>    the local policy of the server permits the user the
> >>    access requested.
> >>
> >>    In particular, because of the flexible nature of the
> >>    SSH connection protocol, it may not be possible to determine
> >>    this completely at the time of authentication, because
> >>    the kind of service being requested is not yet clear.
> >>
> >> [RJA:  Unclear antecedent "this".
> >
> > How about:
> >
> >    In particular, because of the flexible nature of the
> >    SSH connection protocol, it may not be possible to determine
> >    the local security policy that should apply at the time
> >    of authentication, because the kind of service being
> >    requested is not yet clear.
> 
> Fine with me.

What if no policy is available?

[...]

Cheers,

Nico
--