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

["Joseph Galbraith" <galb-list%vandyke.com@localhost>]

(Thanks Chris for gathering edits together.  I've
tried to respond to Ran's comments below,
with revised text where appropriate.)

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

>    This session id is used by higher level protocols
>    to prevent replay of packets form previous sessions.
> 
>    In addition, the use of cipher chaining prevents
>    replay of packets within the session.  Cipher chaining
>    also prevents the insertion or deletion of packets.
> 
> [RJA:  Citations would be pleasant for these claims.

All right, I think I was just having a major incident
of drain bamage.

This section should be rewritten:

   The use of a MAC other than 'none' provides rigorerous
   protection agains replay attacks at the protocol
   level.
   
   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...

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


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

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

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

> 11.3.3 X11 forwarding
> 
>    Another form of proxy forwarding provided by the ssh
>    connection protocol is the forwarding of the X11 protocol.
> 
>    Implementors of the X11 protocol SHOULD implement the
>    magic cookie spoofing, to prevent unauthorized use of
>    the proxy.
> 
> [RJA:  Add citation for "magic cookie spoofing".

How about: see "SSH Connection Protocol", Section 4.3.1, page 9. 

>    X11 forwarding relies on end-point security.  If end-point
>    security has been compromised, X11 forwarding will allow
>    any attack against the X11 server possible locally.
> 
>    Users and administrators should, as a matter of course, use
>    X11 security mechanism to prevent unauthorized use of
>    the X11 server.

[RJA:  Which "X11 security mechanism" is meant ?
[RJA:  Also, please add a citation for that mechanism.

Well, I didn't have a particular one in mind.  The
advice is to use any X11 security mechanism.  I'd
be willing to remove the paragraph.

- Joseph