Subject: Comments on the reviesed Security Section open issues.

From: "Joseph Galbraith" <[email-masked]>
Date: Mon, 12 May 2003 11:40:53 -0600

> > 11.1.2 Data Integrity
> >
> >    This protocol does allow the Data Integrity mechanism to
> >    be disabled.  Implementors SHOULD be wary of exposing this
> >    feature for any purpose other than debugging.  Users and
> >    administrators SHOULD be explicitly warned anytime the
> >    "none" mac is enabled.
> >
> >    So long as the "none" mac is not used, this protocol
> >    provides data integrity.
> >
> >    Because MACs use a 32 bit sequence number, they might
> >    start to leak information after 2**32 packets have
> >    been sent.  However, following the rekeying
> >    recommendations should prevent this attack.
> >    The transport protocol [1] recommends rekeying after
> >    one gigabyte of data, and the smallest possible
> >    packet is 16 bytes. Therefore, rekeying SHOULD happen
> >    after 2**28 packets at the very most.
> >
> > 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.  If the random data here (e.g., DH parameters)
> >    are 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.  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.  RFC 1750
> >    [1750] contains more discussion on this.
> >
> > [1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness
> >        Recommendations for Security", RFC 1750, December 1994.
> >
> >
> >    The use of a MAC other than 'none' provides integrity and
> >    authentication.  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.  Because
> >    public key authentication exchanges are cryptographically bound to
the
> >    session (i.e., to the initial key exchange) they cannot be
successfully
> >    replayed in other sessions.  Note that the session ID can be made
> >    public without harming the security of the protocol.
> >
> >    If two session happen to have the same session ID [hash of key
> >    exchanges] then packets from one can be replayed against the other.
It
> >    must be stressed that the chances of such an occurrence are, needless
> >    to say, minimal when using modern cryptographic methods.  This is all
> >    the more so true when specifying larger hash function outputs and DH
> >    parameters.
> >
> > [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.

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

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.

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

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

- Joseph

---

From: RJ Atkinson <[email-masked]>
Date: Mon, 12 May 2003 14:45:44 -0400

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

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

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

> and sprinkle a few 'if any' around judiciously.

Those proposed edits seem reasonable to me.

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

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 13 May 2003 09:37:57 -0700

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

> of whether the server's public key has been securely

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.

> Identifier for the Client --> MITM Server

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.

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

> and sprinkle a few 'if any' around judiciously.

Sure.

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

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