Re: Even Newer Section 11 for Your Comments

[Chris Lonvick <clonvick%cisco.com@localhost>]

Hi Everyone,

My watchdog timer has gone off so I'm re-sending.  There are comments
below that SHOULD be addressed.  Please take the time to look them over
and comment upon them.

Thanks,
Chris

On Wed, 16 Apr 2003, Chris Lonvick wrote:

> Hi Folks,
>
> My thanks to everyone who's been discussing and making comments upon the
> proposed Section 11.  Below is a revision based upon the recent email
> thread.  Please look that over and provide your further comments.  To make
> the task of looking at the revisions easier, I've attached a file with
> some html in it.  (Your indulgences, please.)  When viewed in a browser it
> displays redline striking to indicate deleted passages and green text to
> indicate insertions.  It's not exact but it has markups at or near the
> places that have changed which will hopefully allow everyone to review
> these changes without having to hunt them down manually.
>
> I've edited some significant changes into Section 11.1.3 "Replay" and have
> added a new Section 11.1.7  "Forward Secrecy".  Please look those over
> carefully.  I've also tried very hard to keep outstanding questions in
> this which still need to be addressed.  These should be findable by
> looking for "[xxx: " at the start of lines below.
>
> One comment that was raised was about adding a new section on the security
> of the key exchange.  I have not attempted to address that and it is not
> noted below.  If that is needed in this section, would someone
> (Joseph? :-) please propose text?
>
> Thanks,
> Chris
>
> ===vvv===  New Proposal for Section 11  ===vvv===
>
> 11. Security Considerations
>
>    In order to make the entire body of Security Considerations more
>    accessible, Security Considerations for the transport, authentication,
>    and connection documents have been gathered here.
>
>    The transport protocol [1] provides a confidential channel over an
>    insecure network.  It performs server host authentication, key
>    exchange, encryption, and integrity protection.  It also derives a
>    unique session id that may be used by higher-level protocols.
>
>    The authentication protocol [2] provides a suite of mechanism which
>    can be used to authenticating the client user to the server.
>    Individual mechanisms specified in the in authentication protocol use
>    the session id provided by the transport protocol and/or depend on the
>    security and integrity guarantees of the transport protocol.
>
>    The connection protocol [3] specifies a mechanism to multiplex
>    multiple streams [channels] of data over the confidential and
>    authenticated transport. It also specifies channels for accessing an
>    interactive shell, for 'proxy-forwarding' various external protocols
>    over the secure transport (including arbitrary TCP/IP protocols), and
>    for accessing secure 'subsystems' on the server host.
>
> 11.1 Transport
>
>
> 11.1.1 Confidentiality
>
>    It is beyond the scope of this document and the Secure Shell Working
>    Group to analyze or recommend specific ciphers other than the ones
>    which have been established and accepted within the industry.  At the
>    time of this writing, ciphers commonly in use include 3DES, ARCFOUR,
>    twofish, serpent and blowfish.  AES has been accepted by The US Federal
>    Information Processing Standards [FIPS-197] and the cryptographic
>    community as being acceptable for this purpose as well.  As always,
>    implementors and users should check current literature to ensure that
>    no recent vulnerabilities have been found in ciphers used within
>    products.  Implementors should also check to see which ciphers are
>    considered to be relatively stronger than others and should recommend
>    their use to users over relatively weaker ciphers.  It would be
>    considered good form for an implementation to politely and
>    unobtrusively notify a user that a stronger cipher is available and
>    should be used when a weaker one is actively chosen.
>
>    The "none" cipher is provided for debugging and SHOULD NOT be used
>    except for that purpose.  It's cryptographic properties are
>    sufficiently described in RFC 2410, which will show that its use does
>    not meet the intent of this protocol.
>
>    The relative merits of these and other ciphers may also be found in
>    current literature.  Two references that may provide information on the
>    subject are [SCHNEIER] and [KAUFMAN,PERLMAN,SPECINER].  Both of these
>    describe the CBC mode of operation of certain ciphers and the weakness
>    of this scheme.  Essentially, this mode is theoretically vulnerable to
>    chosen cipher-text attacks because of the high predictability of the
>    start of packet sequence.  However, this attack is still deemed
>    difficult and not considered fully practicable especially if relatively
>    longer block sizes are used.
>
> [SCHNEIER] Applied Cryptography, Second Edition, Bruce Schneier, Wiley
> and Sons Publisher, 1996
>
> [KAUFMAN,PERLMAN,SPECINER] Network Security; PRIVATE Communication in
> a PUBLIC World, Charlie Kaufman, Radia Perlman, Mike Speciner, Prentice
> Hall Publisher, 1995
>
>    Additionally, another CBC mode attack may be mitigated through the
>    insertion of packets containing SSH_MSG_IGNORE.  Without this
>    technique, a specific attack may be successful.  For this attack
>    (commonly known as the Rogaway attack) to work, the attacker would
>    need to know the IV of the next block that is going to be encrypted.
>    In CBC mode that is the output of the encryption of the previous
>    block. If the attacker does not have any way to see the packet yet
>    (i.e it is in the internal buffers of the ssh implementation or even
>    in the kernel) then this attack will not work. If the last packet has
>    been sent out to the network (i.e the attacker has access to it) then
>    he can use the attack.
>
>    In the optimal case an implementor would need to add an extra packet
>    only if the packet has been sent out onto the network and there are no
>    other packets waiting for transmission. Implementors may wish to check
>    to see if there are any unsent packets awaiting transmission, but
>    unfortunately it is not normally easy to obtain this information from
>    the kernel or buffers.  If there are not, then a packet containing
>    SSH_MSG_IGNORE SHOULD be sent.  If a new packet is added to the stream
>    every time the attacker knows the IV that is supposed to be used for
>    the next packet, then the attacker will not be able to guess the
>    correct IV, thus the attack will never be successfull.
>
>    As an example, consider the following case:
>
>       Client                                                  Server
>       ------                                                  ------
>       TCP(seq=x, len=500)            ->
>          contains Record 1
>
>                           [500 ms passes, no ACK]
>
>       TCP(seq=x, len=1000)           ->
>          contains Records 1,2
>
>                                      <-                        ACK
>
>
>       (1) The Nagle algorithm + TCP retransmits mean that the two
>           records get coalesced into a single TCP segment
>       (2) Record 2 is *not* at the beginning of the TCP segment
>           and never will be, since it gets ACKed.
>       (3) Yet, the attack is possible because Record 1 has already
>           been seen.
>
>    As this example indicates, it's totally unsafe to use the existence
>    of unflushed data in the TCP buffers proper as a guide to whether
>    you need an empty packet, since when you do the second write(),
>    the buffers will contain the un-ACKed Record 1.
>
>    On the other hand, it's perfectly safe to have the following
>    situation:
>
>       Client                                                  Server
>       ------                                                  ------
>       TCP(seq=x, len=500)           ->
>          contains SSH_MSG_IGNORE
>
>       TCP(seq=y, len=500)           ->
>          contains Data
>
>    Provided that the IV for second SSH Record is fixed after the data for
>    the Data packet is determined -i.e. you do:
>         read from user
>         encrypt null packet
>         encrypt data packet
>
>
> 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.
>
>
> 11.1.4 Man-in-the-middle
>
>    This protocol makes no assumptions nor provisions for
>    an infrastructure for distributing public keys.  It is
>    expected that this protocol will sometimes be used without
>    insisting on reliable association between the server host
>    key and the server host name.  Such usage is vulnerable
>    to man-in-the-middle attacks.
>
>    This vulnerability to man-in-the-middle attacks can
>    be mitigated in several fashions:
>
>    1. Narrow the window during which the client is vulnerable to such a
>       man-in-the-middle attack.  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.
>
>    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
>       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 ?
>
>    3. Because the protocol is extensible, future extensions
>       to the protocol may provide better mechanisms for dealing
>       with the need to know the server's host key before
>       connecting.  For example, storing the hostkey fingerprint
>       in a secure dns database, or using kerberos over gssapi
>       during keyexchange to authenticate the server.
>
>    Server administrators are encouraged to make host key
>    fingerprints available for checking by some means whose
>    security does not rely on the integrity of the actual host
>    keys.  Possible mechanisms include secured Web pages, the DNS
>    [draft-ietf-secsh-dns], physical pieces of paper, etc.
>    Implementors SHOULD provide recommendations on how best to do
>    this with their implementation.
>
>    Use of this protocol without a reliable association of the binding
>    between a host and its host keys is inherently insecure and is NOT
>    RECOMMENDED.  It may however be necessary in non-security critical
>    environments, and will still provide protection against passive
>    attacks.  Implementors of protocols and applications running on top of
>    this protocol should keep this possibility in mind.
>
> 11.1.5 Denial-of-service
>
>    This protocol is designed to be used over a reliable transport.  If
>    transmission errors or message manipulation occur, the connection is
>    closed.  The connection SHOULD be re-established if this occurs.
>    Denial of service attacks of this type ("wire cutter") are almost
>    impossible to avoid.
>
>    In addition, this protocol is vulnerable to Denial of Service
>    attacks because an attacker can force the server to go through
>    the CPU and memory intensive tasks of connection setup and
>    key exchange without authenticating.  Implementors SHOULD provide
>    features that make this more difficult.  For example, only allowing
>    connections from a subset of IPs known to have valid users.
>
> 11.1.6 Covert Channels
>
>    The protocol was not designed to eliminate covert channels.  For
>    example, the padding, SSH_MSG_IGNORE messages, and several other
>    places in the protocol can be used to pass covert information, and
>    the recipient has no reliable way to verify whether such information
>    is being sent.
>
> 11.1.7  Forward Secrecy
>
>    It should be noted that the Diffie-Hellman key exchanges may provide
>    perfect forward secrecy (PFS).  PFS is essentially defined as the
>    cryptographic property of a key-establishment protocol in which the
>    compromise of a session key or long-term private key after a given
>    session does not cause the compromise of any earlier session.
>    [ANSI T1.523-2001]  SSHv2 sessions resulting from a key exchange using
>    diffie-hellman-group1-sha1 are secure even if private
>    keying/authentication material is later revealed, but not if the
>    session keys are revealed. So, given this definition of PFS, SSHv2
>    does have PFS.  It is hoped that all other key exchange mechanisms
>    proposed and used in the future will also provide PFS.  This property
>    is not commuted to any of the applications or protocols using SSH as a
>    transport however.  The transport layer of SSH provides
>    confidentiality for password authentication and other methods that
>    rely on secret data.
>
>    Of course, if the DH private parameters for the client and server and
>    revealed then the session key is revealed, but these items can be
>    thrown away after the key exchange completes.  It's worth pointing out
>    that these items should not be allowed to end up on swap space and
>    that they should be erased from memory as soon as the key exchange
>    completes.
>
>
> [ANSI T1.523-2001] American National Standard T1.523-2001, "Telecom
> Glossary 2000", American National Standards Institute, Inc., Approved
> February 28, 2001.
>
>
> 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 server may go into a "sleep" period after repeated unsuccessful
>    authentications to make key search harder.
>
>    Several authentication methods with different security
>    characteristics are allowed.  It is up to the server's local policy
>    to decide which methods (or combinations of methods) it is willing to
>    accept for each user.  Authentication is no stronger than the weakest
>    combination allowed.
>
> 11.2.1 Weak Transport
>
>    If the transport layer does not provide confidentiality, authentication
>    methods that rely on secret data SHOULD be disabled.  If it does not
>    provide MAC protection, requests to change authentication data (e.g.
>    password change) SHOULD be disabled to avoid an attacker from
>    modifying the ciphertext without being noticed, rendering the new
>    authentication data unusable (denial of service).
>
> 11.2.2 Debug messages
>
>    Special care should be taken when designing debug messages.  These
>    messages may reveal surprising amounts of information about the host
>    if not properly designed.  Debug messages can be disabled (during
>    user authentication phase) if high security is required.
>
> 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?
>
>
> 11.2.4 Public key authentication
>
>    The use of public-key authentication assumes that the
>    client host has not been compromised.
>
>    This risk can be mitigated by the use of passphrases
>    on private keys; however, this is not an enforceable
>    policy.  The use of smartcards, or other technology
>    to make passphrases an enforceable policy is suggested.
>
>    The server could require both password and public-key
>    authentication, however, this requires the client
>    to expose its password to the server (see section on
>    password authentication below.)
>
> 11.2.5 Password authentication
>
>    The password mechanism of specified in the authentication
>    protocol assumes that the server has not been compromised.
>    If the server has been compromised, using password
>    authentication will reveal a valid username / password
>    combination to the attacker, which may lead to further
>    compromises.
>
>    This vulnerability can be mitigated by using an alternative
>    form of authentication.  For example, public-key authentication
>    makes no assumptions about security on the server.
>
> 11.2.6 Host based authentication
>
>    Host based authentication assumes that the client
>    has not been compromised.  There are no mitigating
>    strategies, other than to use host based authentication
>    in combination with another authentication method.
>
> 11.3 Connection protocol
>
> 11.3.1 End point security
>
>    End point security is assumed by the connection protocol.
>    If the server has been compromised, any terminal sessions,
>    port forwarding, or systems accessed on the host are compromised.
>    There are no mitigating factors for this.
>
>    If the client end point has been compromised, and the server
>    fails to stop the attacker at the authentication protocol,
>    all services exposed (either as subsystems or through forwarding)
>    will be vulnerable to attack.  Implementors SHOULD provide
>    mechanisms for administrators to control which services
>    are exposed to limit the vulnerability of other services.
>
>    These controls might include controlling which machines and
>    ports can be target in 'port-forwarding' operations, which
>    users are allowed to use interactive shell facilities, or
>    which users are allowed to use exposed subsystems.
>
> 11.3.2 Proxy forwarding
>
>    The SSH connection protocol allows for proxy forwarding of other
>    protocols such as SNMP, POP3, and HTTP.  This may be a concern for
>    network administrators who wish to control the access of certain
>    applications by users located outside of their physical location.
>    Essentially, the forwarding of these protocols may violate site
>    specific security policies as they may be undetectably tunneled
>    through a firewall.  Implementors SHOULD provide an administrative
>    mechanism to control the proxy forwarding functionality so that
>    site specific security policies may be upheld.
>
>    In addition, a reverse proxy forwarding functionality
>    is available, which again can be used to bypass firewall
>    controls.
>
>    As indicated above, end-point security is assumed during
>    proxy forwarding operations.  Failure of end-point security
>    will compromise all data passed over proxy forwarding.
>
> 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.
>
>
> ===^^^===  New Proposal for Section 11  ===^^^===
>