Re: Comments on the reviesed Security Section open issues.

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

On Mon, May 12, 2003 at 11:40:53AM -0600, Joseph Galbraith wrote:
> > > [RJA:  I imagine that a sequence number does help preclude replay
> attacks,
> > > [RJA:  but I was hoping that someone else had actually done some
> analysis
> > > [RJA:  that we could cite to justify the claim that this MAC combined
> with
> > > [RJA:  this kind of sequence numbering would actually provide replay
> > > [RJA:  attack prevention.
> 
> If no one knows of something to cite here, I'm
> not sure what to do at this point?
> 
> Baring someone stepping forward witht the requested
> citation, what should we do?  I'd like to move forward.

Er, this is a time-honored technique.  Examples of protocols that
support the use of sequence numbers as a replay detection technique are:

 - GSS-API (generally) [RFC2743]
    - The KerberosV GSS-API mechanism (specifically) [RFC1964]
    - The Simple Public-Key GSS-API Mechanism (SPKM) (specifically) [RFC2025]

 - Kerberos V [RFC1510]
 
 - TLS 1.0 [RFC2246]

Need I go on?  Probably not.  Each of those documents makes reference to
the use of sequence numbers for replay and out-of-sequence detection.


> > > 11.1.4 Man-in-the-middle
> 
> > >    2. Use an authentication method that is not vulnerable to
> > >       man-in-the-middle attacks.  For example, public-key authentication
> > >       is not vulnerable to man-in-the-middle attack as long as the
> > >       public-key of the server has been securely distributed to the
> > >       clients before the first SSH connection is made.  This is because
> 
> *** see below ***
> 
> > >       the signature is made across data that is session specific.  The
> > >       session specific data between the attacker and server will be
> > >       different between the client-to-attacker session and the
> > >       attacker-to-server sessions due to the randomness discussed above.
> > >       From this, the attacker will not be able to make this attack work
> > >       since the attacker will not be able to correctly sign packets
> > >       containing this session specific data from the server since he
> does
> > >       not have the private key of that server.
> > >
> > > [RJA:  Is this really true and sufficient ?
> 
> Public key authentication is not vulnerable regardless
> of whether the server's public key has been securely
> distrubuted.

Insecure distribution of server public keys allows a different sort of
MITM: one with suitable host keys.  If the server public keys are not
securely distributed then the client cannot know if it is talking to a
legitimate server.

> Client --> MITM server / MITM client --> Server
> 
> Client uses robust cryptographic PRNG, and
> correct implemenations, forcing the Session
> Identifier for the Client --> MITM Server
> to be unpredicatable.

This applies only to a MITM who does not posses host keys.  Obiously,
any MITM can generate host keys.  The questions is: can a MITM fool a
client into thinking that it (the MITM) is the server that the client
intended to connect to.


> > > 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 the local security
> > >    policy that should apply at the time of authentication, because the
> > >    kind of service being requested is not yet clear. For example, local
> > >    policy might allow a user to access files on the server, but not
> start
> > >    an interactive shell. However, during the authentication protocol, it
> > >    is not known whether the user will be accessing files or attempting
> to
> > >    use an interactive shell, or even both. In any event, local security
> > >    policy for the server host MUST be applied and enforced correctly.
> > >
> > > [Nico:  What if no policy is available?
> 
> Then there is nothing to enforce?

The implementation MUST provide a default policy, either the "null"
policy (anything goes) or a highly restrictive policy (the client can
establish an SSHv2 connection but do nothing with it other than close it
:).

> Perhaps we should say,
>   In any event, where local security policy for the server host exists,
>   it MUST be applied and enforced correctly.
> 
> and sprinkle a few 'if any' around judiciously.

Sure.


> > > 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.  More information
> > >    about the use of the X11 magic cookie may be found in many of the
> > >    available manual references and implementation guides for X11.  For
> > >    example, viewing the manual page for "xauth" in BSD systems may be
> one
> > >    place to start.
> > >
> > >    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.
> > >
> > > [JG:  Well, I didn't have a particular one in mind.  The
> > > [JG:  advice is to use any X11 security mechanism.  I'd
> > > [JG:  be willing to remove the paragraph.
> > > [RJA:  I'd like to keep text encouraging folks to use as much
> > > [RJA:  security as they can.  I'm not an expert on the security
> > > [RJA:  properties of X11.  I was thinking that there probably were
> > > [RJA:  some specific security mechanisms (e.g. my vague recollection
> > > [RJA:  of the MIT-magic-cookie hack noted above) that we ought
> > > [RJA:  to mention and cite.

Well, the MIT magic cookie approach is about the only one truly in use
and, IMO, it is sufficient for the purposes of SSHv2.

> 
> I would suggest the following two citations for this
> section:
> 
>    [SCHEIFLER]     Scheifler, R., "X Window System : The Complete
>                    Reference to Xlib, X Protocol, Icccm, Xlfd, 3rd
>                    edition.", Digital Press ISBN 1555580882, Feburary
>                    1992.
> 
> and
> 
>   draft-ietf-secsh-connect-16.txt, section 4.3.1.,
>   "Requesting X11 Forwarding"

Er, sure.  I'm not very familiar with the X11 standards, so I'm not sure
what would be a good reference.  Apparently X.ORG and the Open Group own
the X11 standards now.  A quick search through X.org and XFree86.org
yielded little conclusive information, but a further search finally
yielded:

http://www.xfree86.org/4.3.0/XStandards.7.html

Likely the best reference is:

X Window System Protocol
X Version 11, Release 6.4
Robert W. Scheifler

Cheers,

Nico
--