Subject: Re: IESG feedback on core drafts.

From: Frank Cusack <[email-masked]>
Date: Thu, 3 Apr 2003 00:52:37 -0800

On Mon, Mar 31, 2003 at 08:08:59AM -0800, Chris Lonvick wrote:
>    The "none" cipher is provided for debugging and should never be used
>    except for that purpose.  It's cryptographic properties are
>    sufficiently described in RFC 2410.

I believe the "none" cipher has legitimate uses besides debugging.  You
may want the authentication mechanisms provided by SSH, but not the data
confidentiality.  EG: you are copying already encrypted data between
machines that have such low CPU power that encryption is a significant
overhead.  Even if you disagree, *it goes without saying* that you
wouldn't use the "none" cipher where integrity/privacy matters.

If you /were/ to keep this text, shouldn't 'should' be in caps?

RFC 2410 seems too humorous to be referenced in a security considerations
section.  Maybe I'm just in a bad mood though.

/fc

---

From: [email-masked] (David Wagner)
Date: 3 Apr 2003 09:04:04 GMT

Frank Cusack  wrote:
>overhead.

Do you really think there is any real-world case where this will come up?
Remember, to use SSH you have to be able to do a public-key operation.
I'm hard-pressed to imagine any scenario where the public-key operation
is feasible but there is no symmetric-key encryption that will be.

Allowing people to use the none cipher is asking for trouble.  Many people
expect the (symmetric-key) crypto to be much more expensive than it really
is.  The ``SHOULD NOT use "none" cipher'' language seems reasonable.

---

From: Frank Cusack <[email-masked]>
Date: Thu, 3 Apr 2003 02:14:20 -0800

Some more comments.  BTW, thanks for taking the time to collect and
compose this text.

On Mon, Mar 31, 2003 at 08:08:59AM -0800, Chris Lonvick wrote:
>    twofish, serpent and blowfish.  AES has been accepted by cryptographic
>    experts as being stronger than most of the other ciphers in use today

It has?  I don't think DES had that property and I'm not sure (ie, I don't
know either way) that AES has that property.  eg, one of the considerations
for selection was a design that allows for efficient implementation in
software (unlike DES).
http://csrc.nist.gov/CryptoToolkit/aes/pre-round1/aes_9709.html#sec4

Certainly, AES is strong.  Is it stronger than MOST of the other ciphers
in use today?  What ciphers are in use today?

I might just be being too picky.

>    and it is being implemented in other security protocols as it is within
                                                             ^^^^^^^^

"as well as", maybe?

>    SSH.  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.  Implementors may

cool.

>    wish to offer relatively weaker ciphers in their products for
>    interoperability but should strive to depricate them as soon as

"deprecate", and why would implementors deprecate, say 3DES which may
be weaker than AES?  3DES is required by SSH, AES is not.  (Although,
I believe that AES *should* be required and the 3DES req. dropped, but
that's not the point.)  I would just lose this sentence.

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

"practical" might be better.

/fc

---

From: Frank Cusack <[email-masked]>
Date: Thu, 3 Apr 2003 02:43:11 -0800

> Do you really think there is any real-world case where this will come up?

Sure, I regularly copy terabytes of data around, data that is not
encrypted but also not worth protecting.  The time cost of encryption
is visible to me, partly for billing reasons.

/fc

---

From: Frank Cusack <[email-masked]>
Date: Thu, 3 Apr 2003 02:51:11 -0800

> is visible to me, partly for billing reasons.

Then again, anyone who is going to use 'none' is going to have really
good reasons for it.  There's no harm in discouraging it.  Part of my
argument was that it seems damn obvious that you shouldn't use "none".

/fc

---

From: Markus Friedl <[email-masked]>
Date: Thu, 3 Apr 2003 13:28:09 +0200

On Thu, Apr 03, 2003 at 12:52:37AM -0800, Frank Cusack wrote:
> confidentiality. 

in this case you can use arcfour, i think.

-m

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 3 Apr 2003 16:48:43 +0300

> > >    In addition, the CBC mode attack can be mitigated by
> > >    ensuring the an SSH_MSG_IGNORE packet preceeds any real
> > >    data at the start of a TCP packet.
> > A TCP packet? How is the TCP mapping relevant?

To the attack to work, the attacker needs to know the IV of the next
block that is going to be encrypted. In CBC 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 he cannot use this
attack. If the last packet has been sent out to the network (i.e
attacker will know it) then he can use the attack.

In optimal case we would need to add extra packet only if the packet
has been sent out to network, and there is no other packets waiting in
any buffers. Unfortunately it is not normally easy to see if there are
unsent packets in the kernel, thus for example ssh's secsh checks if
there is any data in its own buffers, and if not then it will add
extra packet. 

If we add new packet to stream every time the attacker knows the IV
that is supposed to be used for next packet, we will always cause the
attacker to guess wrong IV, thus his attack will never be successfull.

>    Additionally, the CBC mode attack may be mitigated through the
>    insertion of packets containing SSH_MSG_IGNORE.  This technique may be
>    used to obfuscate the relative positions of the enciphered message and
>    its use is encouraged.

It is not to obfuscate the relative positions, it is to change the IV
known by the attacker to something else, i.e something that is not
known by the attacker. The contents of the packet actually does not
matter, as long as attacker cannot affect its contents.

As far as I can understand the attack (and remember about it, this was
more than year ago when I last time checked this attack) this should
make the attack impossible.
-- 
[email-masked]
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/

---

From: Eric Rescorla <[email-masked]>
Date: 03 Apr 2003 07:01:25 -0800

> there is any data in its own buffers, and if not then it will add
Yes, I'm familiar with the Rogaway attack, but it's a mistake to
get fixated on TCP mapping.

For instance, 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

The point is that you can't safely talk about TCP packets. If you want
to talk about conditional empty packet insertion you should talk about
the data being "written" "delivered to the network"

-Ekr

-- 
[Eric Rescorla                                   [email-masked]]
                http://www.rtfm.com/

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 3 Apr 2003 22:43:53 +0300

> get fixated on TCP mapping.
... 
> (3) Yet, the attack is possible because Record 1 has already

Yes, as I say above the important thing is if it has been ever sent
out to network.

> the buffers will contain the un-ACKed Record 1.

It is safe, if and only if you get the information from the TCP stack
if that data at the end of the TCP buffers have ever been sent out to
network. If it has never ever been sent out to network, then we do not
need the extra packet, if it has already been sent out, then you do
need extra packet. 

> the data being "written" "delivered to the network"

I think I have been using term "seen on the network" all the time, I
didn't talk about TCP packet. 
-- 
[email-masked]
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/

---

From: Eric Rescorla <[email-masked]>
Date: 03 Apr 2003 13:46:29 -0800

> need the extra packet, if it has already been sent out, then you do
Yes, but since essentially no stack will tell you this, it's not
really an optimization worth making.

> didn't talk about TCP packet. 
But that's the language that appeared in the text I was criticizing.

-Ekr

---

From: Chris Lonvick <[email-masked]>
Date: Thu, 3 Apr 2003 14:37:51 -0800 (PST)

Hi,

I've tried to revise Section 11 per all of the comments and came up with
the following.  There are some questions asked by Ran that still need to
be addressed which are noted.

I've corrected some typo's and will gladly pass this back to Joseph.  :-)

Thanks,
Chris

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

[Chris:  While it may be obvious to everyone on this list that "none"
[Chris:  should not be used, it may not be obvious to all readers.  I'd
[Chris:  like to keep this in for completeness.

   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.

   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

      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.

[RJA:  Is it random or pseudo-random ?
[RJA:  Does the difference matter in this case ?

   This session id is used by higher level protocols
   to prevent replay of packets form previous sessions.

   In addition, the use of cipher chaining prevents
   replay of packets within the session.  Cipher chaining
   also prevents the insertion or deletion of packets.

[RJA:  Citations would be pleasant for these claims.

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

[RJA:  Narrow *which* window ?
[RJA:  Intended meaning is not crystal clear above.

   2. Use an authentication method that is not vulnerable
      to man-in-the-middle.  For example, public-key
      authentication is not vulnerable to man-in-the-middle
      attack, because the signature is made across data
      that is session specific.  The attack can not use
      the signature he receives because the session specific
      data between the attacker and server is different, and
      can not create a valid signature because he does not
      have the private key.

[RJA:  Is this really true and sufficient ?

   However, this does assume that the public-key has
   been distributed to the server host in some secure
   fashion before the first SSH connection can be made.

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

[RJA:  association of what/whom ?

   is inherently insecure, but may be necessary in
   non-security critical environments, and still
   provides protection against passive attacks.  However,
   implementors of protocols running on top of this
   protocol should keep this possibility in mind.

[RJA:  ???  s/protocols running/applications running/ ???

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.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 transport layer
   provides forward secrecy for password authentication and other
   methods that rely on secret data.

[RJA:  "perfect forward secrecy" or "forward secrecy" ?

   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
   this completely at the time of authentication, because
   the kind of service being requested is not yet clear.

[RJA:  Unclear antecedent "this".

   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.

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.

[RJA:  Add citation for "magic cookie spoofing".

   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.

References:

[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

===end===

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 4 Apr 2003 13:29:16 -0800

Another legit use of "none" would be with GSS keyex and a channel
bindings that cryptographically bind the GSS context to some underlying
secure channel (e.g., IPsec).

Don't laugh.  Exactly this sort of thing is being discussed on the NFSv4
list.  The current approach is to define a new, trivial GSS
pseudo-mechanism for the purpose of negotiating channel bindings - if you
use this mechanism then channel bindings[*] must be used[**].

So, SSHv2 w/ GSS key exchange + this new GSS pseudo-mechanism + channel
bindings to IPsec + SSH "none" crypto alg == SSH w/ crypto at IPsec
layer only.

This is much more useful in the context of NFSv4 than in the context of
SSHv2, but it sure seems applicable to SSHv2.

Cheers,

Nico

[*] GSS-API supports two kinds of channel bindings: network address,
    which are useless in this context, and "transformations of
    encryption keys" [rfc2743].

[**] GSS channel bindings are opitonal and generally not used, therefore
     a way to force their use is needed and by making it a
     pseudo-mechanism any protocols that can negotiate GSS mechanisms
     can negotiate the use of this pseudo-mech and so the use of channel
     bindings.

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 4 Apr 2003 15:38:29 -0600

Note: this was merely an attempt to illustrate a possible future use of
the SSHv2 "none" crypto alg.

Perhaps there should be text explicitly allowing the use of "none" when
the key exchange and/or userauth cryptographically binds authentication
at the SSHv2 layer to integrity/confidentiality services at a lower
layer:

   "
   The "none" encryption algorithm MAY be used where authentication at
   the SSHv2 layer is cryptographically bound to the cryptographic
   integrity and/or confidentiality services provided by a lower layer,
   such as IPsec.  Other uses of the "none" encryption algorithm are NOT
   RECOMMENDED.
   "

For more details on this proposed GSS pseudo-mechanism look at the NFSv4
WG list archives.  And note that it's a trivial wrapper around an
underlying non-pseudo mechanism (almost like an OID prefix, if you
wish).

Cheers,

Nico

---

From: Bill Sommerfeld <[email-masked]>
Date: Mon, 07 Apr 2003 20:50:04 -0400

Thanks for your edits.

This thread seems to have died down.  Are we done yet?

						- Bill

---

From: RJ Atkinson <[email-masked]>
Date: Tue, 8 Apr 2003 07:12:04 -0400

On Monday, Apr 7, 2003, at 20:50 America/Montreal, Bill Sommerfeld 
> This thread seems to have died down.  Are we done yet?

No.

	Chris's text ignored a bunch of my questions/inputs.  I'd
really like to see those addressed.

	In some cases, it is a matter of editing the text to be more
clear/precise.  In other cases, it might be a matter of either deleting
a poorly justified claim or justifying the claim more clearly (ideally
via a citation to some paper in the published literature that supports
the claim).  I'm open to hearing about some other proposed resolution
of those items, if such exists.

	The open issues need to be resolved in some deliberate manner,
IMHO.

Ran
[email-masked]

---

From: Chris Lonvick <[email-masked]>
Date: Tue, 8 Apr 2003 06:23:09 -0700 (PDT)

Hi,

> > This thread seems to have died down.  Are we done yet?

Agreed.

> really like to see those addressed.

Ran's questions and comments are appropriate and do need to be addressed.
I didn't make an attempt as the plane was landing, but instead incorported
his comments into the revision before sending it out.

> 	The open issues need to be resolved in some deliberate manner,

For the convenience of everyone who's now fired-up to complete this, I'm
attaching the revision of Section 11 that I sent out a few days ago.
Ran's comments may be found by looking for "[RJA :" at the start of lines.

Thanks,
Chris

=======

11.1 Transport

11.1.1 Confidentiality

      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

      Client                                                  Server
      ------                                                  ------
      TCP(seq=x, len=500)           ->
         contains SSH_MSG_IGNORE

      TCP(seq=y, len=500)           ->
         contains Data

11.1.2 Data Integrity

11.1.3 Replay

11.1.4 Man-in-the-middle

11.1.5 Denial-of-service

11.1.6 Covert Channels

11.2.1 Weak Transport

11.2.2 Debug messages

11.3 Connection protocol

11.3.2 Proxy forwarding

11.3.3 X11 forwarding

References:

===end===

---

From: RJ Atkinson <[email-masked]>
Date: Tue, 8 Apr 2003 09:49:00 -0400

> his comments into the revision before sending it out.

What was entirely reasonable, IMHO, as it resolved a bunch
of the issues and let everyone review the update...

Ran

---

From: "Joseph Galbraith" <[email-masked]>
Date: Thu, 10 Apr 2003 11:32:28 -0600

(Thanks Chris for gathering edits together.  I've
tried to respond to Ran's comments below,
with revised text where appropriate.)

> [RJA:  Does the difference matter in this case ?

It is probably pseudo-random?  I'm not sure if
it matters.  If no one else can say, I'll just
change it to pseudo-random.

> [RJA:  Citations would be pleasant for these claims.

All right, I think I was just having a major incident
of drain bamage.

This section should be rewritten:

   The use of a MAC other than 'none' provides rigorerous
   protection agains replay attacks at the protocol
   level.
   
   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.

> [RJA:  Intended meaning is not crystal clear above.

How about this?
   1. Narrow the window during which the client is vulnerable
      to such a man-in-the-middle attack..  If the client ensures
      that the...

> [RJA:  Is this really true and sufficient ?

Hmm... I'm not sure if I missed something here or
what?  If the man-in-the-middle doesn't have the
private key, he can't complete the authentication
right?  It seems that this is true and sufficient
to prevent an attack, but maybe I'm missing something?

> [RJA:  association of what/whom ?

How about:

   Use of this protocol without reliable association
   of hosts and host keys is inherently insecure, but
   but may be necessary in non-security critical
   environments, and still provides protection against
   passive attacks.  However, implementors of applications
   running on top of this protocol should keep this
   possibility in mind.

> [RJA:  "perfect forward secrecy" or "forward secrecy" ?

I'm not sure; this paragraph is quoted from the previous
security considerations section.  Would any one else care
to comment?

> [RJA:  Unclear antecedent "this".

How about:

   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.

> [RJA:  Add citation for "magic cookie spoofing".

How about: see "SSH Connection Protocol", Section 4.3.1, page 9. 

Well, I didn't have a particular one in mind.  The
advice is to use any X11 security mechanism.  I'd
be willing to remove the paragraph.

- Joseph

---

From: RJ Atkinson <[email-masked]>
Date: Thu, 10 Apr 2003 14:09:58 -0400

On Thursday, Apr 10, 2003, at 13:32 America/Montreal, Joseph Galbraith 
> change it to pseudo-random.

It would be good if we could find a cryptographer
who could tell us whether it matters.

>    protection agains replay attacks at the protocol

I think of a MAC (by itself) as only providing integrity/authentication.

I imagine that a sequence number does help preclude replay
attacks, but I was hoping that someone else had actually
done some analysis that we could cite to justify the claim
that this MAC combined with this kind of sequence numbering
would actually provide replay attack prevention.

>       to such a man-in-the-middle attack..  If the client ensures

OK with me.

> to prevent an attack, but maybe I'm missing something?

Maybe you didn't miss anything.  It really was a
question on my part.  Maybe massage the above new
paragraph to include your sentence:

		"[Because] the man-in-the-middle does not have
		the private key [of whom ?], the he cannot
		correctly complete the authentication with
		[whom ?]."

My main goal here is clarity, so avoiding pronouns
and making the identities clear is appreciated. :-)

>    running on top of this protocol should keep this

Proposed slight edit to first clause:

	Use of this protocol without reliable authentication
	of the binding between a host and its host keys is
	inherently insecure, but ...

> security considerations section.  Would any one else care

I'm also not sure, but it would be nice if we could find
someone who is sure -- preferably someone who can supply
a citation or a more detailed rationale to support the claim.

>    requested is not yet clear.

Fine with me.

> How about: see "SSH Connection Protocol", Section 4.3.1, page 9.

Maybe.  Once upon a time there was a component of X11 called
"MIT-magic-cookie" that was used to provide (very very weak)
security.  My original thought was that the original text
was referring to that, hence some reference to the X11 protocol
specification or to some relevant published paper on X11 would
be the right one.  With your new text, I'm now wondering whether
the intended reference was to the "MIT-magic-cookie" part of
the X11 protocol or to something else.

I'm confused.

> be willing to remove the paragraph.

I'd like to keep text encouraging folks to use as much
security as they can.  I'm not an expert on the security
properties of X11.  I was thinking that there probably were
some specific security mechanisms (e.g. my vague recollection
of the MIT-magic-cookie hack noted above) that we ought
to mention and cite.

Cheers,

Ran

---

From: Jon Bright <[email-masked]>
Date: Fri, 11 Apr 2003 08:23:20 +0200

>    The use of a MAC other than 'none' provides rigorerous

rigorous

--
Jon Bright
Lead Programmer, Silicon Circus Ltd.
http://www.siliconcircus.com

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 11 Apr 2003 09:21:33 -0700

> who could tell us whether it matters.

IANAC, but what matters is that if the data in question (e.g., DH
parameters) be 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 - not all
implementations will have suitable sources of entropy).

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.

[...]

> and making the identities clear is appreciated. :-)

Because public key authentication exchanges are cryptographically bound
to the SSHv2 session (i.e., to the initial key exchange) they cannot be
successfully replayed in other sessions.

(Of course, if two session happen to have the same session ID [hash of
kex exchanges] then packets from one can be replayed against the other;
the chances of such an occurrence are, needless to say, minimal, all the
more so the larger the hash function's output and DH parameters used.)

Also note that the session ID can be made public without harming the
security of the protocol.

> 	inherently insecure, but ...

Add "and NOT RECOMMENDED?"

> a citation or a more detailed rationale to support the claim.

"Perfect forward secrecy" - see Google search:

http://www.google.com/search?hl=en&ie=ISO-8859-1&q=Perfect+forward+secrecy

and first link that comes up:

http://www.itsecurity.com/asktecs/may201.htm

A very simple difinition:

http://www.atis.org/tg2k/_perfect_forward_secrecy.html

"perfect forward secrecy: In cryptography, of a key-establishment
protocol, the condition 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."

...

> >    requested is not yet clear.

What if no policy is available?

[...]

Cheers,

Nico
--