Re: Comments on the reviesed Security Section open issues.

[RJ Atkinson <rja%extremenetworks.com@localhost>]

On Monday, May 12, 2003, at 13:40 America/Montreal, 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.

Generic comment (applies to above and other places):
	I'd rather delete a claim that the WG can't clearly justify
	than have this document accidentally make a claim that later
	turns out to be inaccurate or misleading.

> > > 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.
>
> 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.
>
> Server also uses robust cryptographic PRNG,
> and correct implementations, forcing the Session
> Identifier for the MITM Client --> Server Session
> to be unpredictable, and most importantly,
> different from that of Client --> MITM Server.

Seems to me that we ought to note the criticality
of the quality of the PRNG implementation in the
Security Considerations section of the document.

> Now, client uses its private key to sign the
> Client -> MITM Server session id, and sends
> that signature as authentication data.
>
> Becasuse MITM Client can't use the signature it
> just received (MITM client --> Server has a different
> Session Id to be signed), and it doesn't have access to
> the private key, it cannot proceed forward with authentication.
>
> ---
>
> Now, of course MITM Client can simply defer completing
> authentication with Server, and wait for client to
> request Agent forwarding.  Then, using agent, obtain
> the signature it needs to complete the authentication
> with Server, and quickly bring MITM client --> Server
> state up to date with Client --> MITM Server state.
>
> Maybe the whole argument isn't worth including.

I'd go with that last sentence, particularly since the robustness
of the PRNG is very implementation-specific.  It is hard
to get PRNGs correct in actual code, so it is not unlikely
that one or more SSH implementations would not get it right.

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

Those proposed edits seem reasonable to me.

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

It turns out that the X11 cookie security has significant issues.

A good reference for folks here to read might be:
	Wietse Venema, "Murphy's Law and Computer Security", Proceedings
	of 6th USENIX Security Symposium, San Jose, CA, July 1996.

It is likely that the above paper can be downloaded from USENIX,
http://www.usenix.org.  I don't know the correct URL for that
paper, so one would have to browse to find it.

Also, if we reach back to 1997, there were other issues identified:
	http://lists.insecure.org/lists/bugtraq/1997/Sep/0062.html

I'm not comfortable with the current text on X11, though I'm
only one person...

Ran