Comments on the reviesed Security Section open issues.

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

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