Subject: draft-ietf-secsh-dns-04 comments

From: Pekka Savola <[email-masked]>
Date: Mon, 12 May 2003 22:21:11 +0300 (EEST)

Hi,

A few layman's (to SSH specs & DNS details) comments to the secsh-dns 
draft.

Most of the comments should be easy to understand.  In 2.4, I think the 
language must be much more specific what's required.  "MUST .. unless" is 
not good, IMO.  

(looking back, you could also add a reference to RFC2434 in the IANA 
considerations section)

--- draft-ietf-secsh-dns-04.txt	Wed Apr  2 19:54:58 2003
+++ draft-ietf-secsh-dns-04.txt.new	Mon May 12 22:12:30 2003
@@ -8,7 +8,7 @@
                                                            April 2, 2003

-           Using DNS to securely publish SSH key fingerprints
+           Using DNS to Securely Publish SSH Key Fingerprints
                       draft-ietf-secsh-dns-04.txt
 
 Status of this Memo
@@ -125,14 +125,14 @@
    saved locally and used for verification for all following
    connections.  While some security-conscious users verify the
    fingerprint out-of-band before accepting the key, many users blindly
-   accepts the presented key.
+   accept the presented key.
 
    The method described here can provide out-of-band verification by
    looking up a fingerprint of the server public key in the DNS [1][2]
    and using DNSSEC [4] to verify the lookup.
 
    In order to distribute the fingerprint using DNS, this document
-   defines a new DNS resource record to carry the fingerprint.
+   defines a new DNS resource record, "SSHFP", to carry the fingerprint.
 
    Basic understanding of the DNS system [1][2] and the DNS security
    extensions [4] is assumed by this document.
@@ -196,8 +196,8 @@
 
 2.4 Authentication
 
-   A public key verified using this method MUST only be trusted if the
-   SSHFP resource record (RR) used for verification was authenticated by
+   A public key verified using this method MUST NOT be trusted if the
+   SSHFP resource record (RR) used for verification was not authenticated by
    a trusted SIG RR.
 
    Clients that do not validate the DNSSEC signatures themselves MUST
@@ -234,7 +234,9 @@
          /                          fingerprint                          /
          /                                                               /
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
+==> please use the more common textual representation, seems much more
+natural
+==> the picture is 74 chars wide --- not good!
 
 3.1.1 Algorithm Number Specification
 
@@ -319,7 +321,7 @@
       replacing the corresponding SSHFP in DNS.
 
       If SSH host key verification can be configured to require SSHFP,
-      we can implement SSH host key revocation by removing the
+      SSH host key revocation by can be implemented by removing the
       corresponding SSHFP from DNS.
 
    As stated in Section 2.2, we recommend that SSH implementors provide

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Jakob Schlyter <[email-masked]>
Date: Mon, 12 May 2003 23:03:40 +0200 (CEST)

> language must be much more specific what's required.  "MUST .. unless" is

thanks, I've integrated your changes. since this is only editoral changes,
I assume we do not need another last call.

> (looking back, you could also add a reference to RFC2434 in the IANA

why?

textual representation? please elaborate.

	jakob

---

From: Pekka Savola <[email-masked]>
Date: Tue, 13 May 2003 08:20:18 +0300 (EEST)

> I assume we do not need another last call.

Oh, that's why I got around to see the draft.  Yes, I agree this doesn't 
necessitate another IETF LC.

> > (looking back, you could also add a reference to RFC2434 in the IANA

To get a reference to what "IETF Consensus" by the definition of RFC2434 
means.

> textual representation? please elaborate.

please look at e.g. RFC2460 and many other RFC's on how they have 
represented it there:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Version| Traffic Class |           Flow Label                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Payload Length        |  Next Header  |   Hop Limit   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                                                               |
   +                         Source Address                        +
   |                                                               |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                                                               |
   +                      Destination Address                      +
   |                                                               |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

.. this is the de-facto way of representing bits, I think -- and should be 
used.

---

From: Chris Lonvick <[email-masked]>
Date: Wed, 14 May 2003 13:27:01 -0700 (PDT)

Hi Folks,

I'm trying to work in all of the suggestions for improvements in the text.
It's a bit ungainly to put all of that in a single note so I'm separating
it into subsections.  Here's a rewrite of 11.3.3.  Below that is a
grouping of comments I've seen on this thread.  Please make comments on
this text.  Specific textual contributions will be especially appreciated.

Thanks,
Chris

==========================================================================

11.3.3 X11 Forwarding

   Another form of proxy forwarding provided by the ssh connection
   protocol is the forwarding of the X11 protocol.  If end-point security
   has been compromised, X11 forwarding may allow attacks against the X11
   server.  Users and administrators should, as a matter of course, use
   all available X11 security mechanisms to prevent unauthorized use of
   the X11 server.  Implementors, administrators and users who wish to
   further explore the security mechanisms of X11 are invited to read
   [SCHEIFLER] and analyze previously reported problems with the
   interactions between SSH forwarding and X11 in CERT vulnerabilities
   VU#363181 and VU#118892 [CERT].  Additionally, they are advised to
   review the problems found and the lessons learned in a paper by Wietse
   Venema [Venema] presented to the 6th USENIX Security Symposium.

   Implementors of the X11 forwarding protocol SHOULD implement the magic
   cookie access checking spoofing mechanism as described in [ssh-connect]
   as an additional mechanism to prevent unauthorized use of the proxy.

[SCHEIFLER]     Scheifler, R., "X Window System : The Complete
                Reference to Xlib, X Protocol, Icccm, Xlfd, 3rd
                edition.", Digital Press ISBN 1555580882, February
                1992.

[CERT]     The CERT Coordination Center
           Software Engineering Institute
           Carnegie Mellon University
           Pittsburgh, PA 15213-3890
           U.S.A.
           ( http://www.cert.org/nav/index_red.html )

[ssh-connect]     ssh-connect ID to be replaced with the RFC information
                  when available

[Venema]     Wietse Venema, "Murphy's Law and Computer Security",
             Proceedings of 6th USENIX Security Symposium, San Jose, CA,
             July 1996.
http://www.usenix.org/publications/library/proceedings/sec96/venema.html

---Notes---

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

---Nico---vv
Well, the MIT magic cookie approach is about the only one truly in use
and, IMO, it is sufficient for the purposes of SSHv2.
---Nico---^^

---Joseph---vv
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---^^

---Nico---vv
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
---Nico---^^

---Ran---vv
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: Wed, 14 May 2003 21:20:37 -0700

I take issue with this comment.  X11 forwarding helps fix exactly those
problems that Wietse Venema describes, particularly if:

a) the X11 server does not accept connections except over local IPC
   mechanisms that are protected by ACLs or file permissions (e.g., Unix
   domain sockets),

and

b) (a) applies to the SSHv2 server pseudo-X11 server used in X11
   forwarding.

Given (a) and (b) those magic cookies add no value and their weakness is
irrelevant.  Xsun, for example, can be configured not to listen for
display opens over TCP.

Cheers,

Nico

---

From: RJ Atkinson <[email-masked]>
Date: Thu, 15 May 2003 09:56:16 -0400

On Thursday, May 15, 2003, at 00:20 America/Montreal, Nicolas Williams 
wrote:
> Given (a) and (b) those magic cookies add no value ...

This is consistent with my stated unhappiness with the text that
was implying that those cookies did have security value.

We need text that is clear and accurate.  I'm not exactly sure
what that text looks like, unfortunately, or I'd propose a block
of new text.

Ran

---

From: Chris Lonvick <[email-masked]>
Date: Thu, 15 May 2003 07:08:59 -0700 (PDT)

Hi,

The section on MITM for your review.

Thanks,
Chris

========================================================================

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.

   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.

   Insecure distribution of server public keys allows a different sort of
   man-in-the-middle: one with suitable but incorrect host keys.  If the
   server public keys are not securely distributed then the client cannot
   know if it is talking to the intended 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.

   Attackers may attempt to manipulate packets in transit between peers.
   As described in the Replay part of this section, a successful attack
   of this nature is very improbable.  As in the Replay section, this
   reasoning does assume that the MAC is secure and that it is infeasible
   to construct inputs to a MAC algorithm to give a known output.  This
   is discussed in much greater detail in Section 6 of RFC 2104.  If the
   MAC algorithm has a vulnerability or is weak enough, then the attacker
   may be able to specify certain inputs to yeild a known MAC.  With that
   they may be able to alter the contents of a packet in transit.
   Alternatively the attacker may be able to exploit the algorithm
   vulnerability or weakness to find the shared secret by reviewing
   the MACs from captured packets.  With either of those cases, an
   attacker could construct a packet that could be inserted into an SSH
   stream.  To prevent that, implementors are encouraged to utilize
   commonly accepted MAC algorithms and administrators are encouraged to
   watch current literature and discussions of cryptography to ensure
   that they are not using a MAC algorithm that has a recently found
   vulnerability or weakness.

---Notes---[Chris: These notes revolve around (2) above.]

[RJA:  Is this really true and sufficient ?

--Joseph--vv
Public key authentication is not vulnerable regardless
of whether the server's public key has been securely
distrubuted.

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

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

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

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.

   ---Ran---vv
   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.
   ---Ran---^^

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

   ---Ran---vv
   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.
   ---Ran---^^

   ---Heikki---vv
   I second that.
   ---Heikki---^^

---Heikki---vv
In my opinion, this belongs into the agent spec, not here. [Don't do
agent forwarding for the servers you don't trust.]
---Heikki---^^

   ---Ran---vv
   That would be OK with me.
   ---Ran---^^

---

From: Simon Tatham <[email-masked]>
Date: Thu, 15 May 2003 15:27:41 +0100

Chris Lonvick  <[email-masked]> wrote:
>       clients before the first SSH connection is made.

Surely the other way round?

If the server's key has already been securely distributed to the
client, then _no_ authentication method is vulnerable to MITM -
that's precisely what the server's host key is for! I don't see how
public-key authentication is any better than other methods in this
respect.

If the _user's_ public key has been securely distributed to the
_server_ before the first SSH connection is made, then public-key
authentication might be able to verify the server's host key which
was previously unknown.

However, this is conditional on the user being sure they really have
connected to the right server! I grant that an MITM seeing a
public-key authentication request wouldn't be able to use it to gain
access to the real server; but they could simply return Yes, and
_pretend_ to be the real server for as long as they could get away
with it in the absence of a genuine login there, in the hope that
the user might try to (for example) connect through to some other
system and type a password in. The user would have to verify the
connection by requesting some other piece of information from the
server which they already knew but which the MITM would be unlikely
to guess right.

Cheers,
Simon
-- 
Simon Tatham         "The distinction between the enlightened and the
<[email-masked]>    terminally confused is only apparent to the latter."

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 15 May 2003 07:31:03 -0700

> was implying that those cookies did have security value.

Ah, sorry I misread your comment.

> what that text looks like, unfortunately, or I'd propose a block

How about this?:

   X11 display forwarding, by itself, is not sufficient to correct well
   known problems with X11 security [Venema].  However, X11 display
   forwarding in SSHv2 (or other, secure protocols), combined with
   actual and pseudo-displays which accept connections only over local
   IPC mechanisms authorized by permissions or ACLs, does correct most
   X11 security problems.

   It is RECOMMENDED that X11 display implementations default to
   allowing display opens only over local IPC.  It is RECOMMENDED that
   SSHv2 server implementations that support X11 forwarding default to
   allowing display opens only over local IPC.  On single-user systems
   it is reasonable to default to allowing local display opens over
   TCP/IP.

Cheers,

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 15 May 2003 08:06:37 -0700

Than you Simon, your comment makes the point I tried to make the other
day, but more clearly and eloquently than my poor attempt.

Nico

---

From: RJ Atkinson <[email-masked]>
Date: Thu, 15 May 2003 11:18:22 -0400

On Thursday, May 15, 2003, at 10:31 America/Montreal, Nicolas Williams 
>    X11 display forwarding, by itself, is not sufficient to correct well

s/X11 display forwarding/X11 display forwarding with SSH/

>    IPC mechanisms authorized by permissions or ACLs, does correct most

Proposed edits:

s/most X11/many X11/

>    it is reasonable to default to allowing local display opens over

s/it is reasonable/it might be reasonable/

Otherwise looks OK to me.

Ran
[email-masked]

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 15 May 2003 08:22:23 -0700

> s/X11 display forwarding/X11 display forwarding with SSH/

I intended that the first sentence reference X11 display forwarding in
general - the point being that "X11 display forwarding," whatever
protocol is used for the purpose, by itself does not solve the X11
display security problems.  The next sentence references X11 display
forwarding with SSHv2 specifically.

Perhaps we should mention non-use of the "none" encryption and MAC algs...

> >    IPC mechanisms authorized by permissions or ACLs, does correct most

Yes, thank you.

> s/it is reasonable/it might be reasonable/

Good one.

Thanks,

Nico
--

---

From: RJ Atkinson <[email-masked]>
Date: Thu, 15 May 2003 11:26:15 -0400

On Thursday, May 15, 2003, at 11:22 America/Montreal, Nicolas Williams 
> forwarding with SSHv2 specifically.

OK.

> Perhaps we should mention non-use of the "none" encryption and MAC 

Yes.  My oversight, terribly sorry.

Thanks,

Ran

---

From: Chris Lonvick <[email-masked]>
Date: Thu, 15 May 2003 08:42:33 -0700 (PDT)

Hi Nico and Ran,

Should this proposal entirely replace the prior proposal or are there
parts of the prior proposal that should be kept with this?  I appreciate
the suggestions you've made here.

Thanks,
Chris

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 15 May 2003 08:59:04 -0700

> the suggestions you've made here.

How about this (my proposed text added between the first and second
paragraphs you proposed):

11.3.3 X11 Forwarding

   Another form of proxy forwarding provided by the ssh connection
   protocol is the forwarding of the X11 protocol.  If end-point
   security server.  Users and administrators should, as a matter of
   course, use all available X11 security mechanisms to prevent
   unauthorized use of the X11 server.  Implementors, administrators and
   users who wish to further explore the security mechanisms of X11 are
   invited to read [SCHEIFLER] and analyze previously reported problems
   with the interactions between SSH forwarding and X11 in CERT
   vulnerabilities VU#363181 and VU#118892 [CERT].  Additionally, they
   are advised to review the problems found and the lessons learned in a
   paper by Wietse Venema [Venema] presented to the 6th USENIX Security
   Symposium.

   X11 display forwarding, by itself, is not sufficient to correct well
   known problems with X11 security [Venema].  However, X11 display
   forwarding in SSHv2 (or other, secure protocols), combined with
   X11 actual and pseudo-displays which accept connections only over
   local IPC mechanisms authorized by file permissions or other ACLs,
   does correct many X11 security problems.  It is RECOMMENDED that X11
   display implementations default to allowing display opens only over
   local IPC.  It is RECOMMENDED that SSHv2 server implementations that
   support X11 forwarding default to allowing display opens only over
   local IPC.  On single-user systems it may be reasonable to default to
   allowing local display opens over.

   Implementors of the X11 forwarding protocol SHOULD implement the
   magic cookie access checking spoofing mechanism as described in
   [ssh-connect] as an additional mechanism to prevent unauthorized use
   of the proxy.

   [references]

Cheers,

Nico
--

---

From: RJ Atkinson <[email-masked]>
Date: Thu, 15 May 2003 13:33:18 -0400

On Thursday, May 15, 2003, at 11:59 America/Montreal, Nicolas Williams 
>    security server.  Users and administrators should, as a matter of

There is a typo just above ("If end-point security server.").

>    course, use all available X11 security mechanisms to prevent

s/all available/appropriate/

- some X11 security mechanisms are mutually exclusive
- some X11 security mechanisms might not make sense in some environments

>    [ssh-connect] as an additional mechanism to prevent unauthorized use

Other than the proposed edits, the above looks OK to me.

Ran

---

From: "Joseph Galbraith" <[email-masked]>
Date: Thu, 15 May 2003 12:13:46 -0600

> server which they already knew but which the MITM would be unlikely

Right... this is what the origal claim was;
man in the middle is not feasable with public
key.

However, as you point out, a spoofing attack
is-- which really makes this protection quite
useless.

I think we should remove #2.

Thanks,

Joseph

---

From: Chris Lonvick <[email-masked]>
Date: Thu, 15 May 2003 12:32:23 -0700 (PDT)

Hi,

Latest revision incorporating the suggestions.  I've removed the duplicate
reference to Venema's work and make the recommended substitutions.  Please
comment.

Thanks,
Chris

=======================================================================

11.3.3 X11 forwarding

   Another form of proxy forwarding provided by the ssh connection
   protocol is the forwarding of the X11 protocol.  If end-point security
   has been compromised, X11 forwarding may allow attacks against the X11
   server.  Users and administrators should, as a matter of course, use
   appropriate X11 security mechanisms to prevent unauthorized use of the
   X11 server.  Implementors, administrators and users who wish to
   further explore the security mechanisms of X11 are invited to read
   [SCHEIFLER] and analyze previously reported problems with the
   interactions between SSH forwarding and X11 in CERT vulnerabilities
   VU#363181 and VU#118892 [CERT].

   X11 display forwarding with SSH, by itself, is not sufficient to
   correct well known problems with X11 security [VENEMA].  However, X11
   display forwarding in SSHv2 (or other, secure protocols), combined
   with actual and pseudo-displays which accept connections only over
   local IPC mechanisms authorized by permissions or ACLs, does correct
   many X11 security problems as long as the "none" MAC is not used.  It
   is RECOMMENDED that X11 display implementations default to allowing
   display opens only over local IPC.  It is RECOMMENDED that SSHv2
   server implementations that support X11 forwarding default to allowing
   display opens only over local IPC.  On single-user systems it might be
   reasonable to default to allowing local display opens over TCP/IP.

[VENEMA]     Wietse Venema, "Murphy's Law and Computer Security",
             Proceedings of 6th USENIX Security Symposium, San Jose, CA,
             July 1996.
http://www.usenix.org/publications/library/proceedings/sec96/venema.html

---

From: Chris Lonvick <[email-masked]>
Date: Thu, 15 May 2003 12:47:28 -0700 (PDT)

Hi Everyone,

I'd like to suggest the following as a new section to call out the
importance of the PRNG to this effort.  Essentially the first paragraph of
the Replay section was removed from there to form this new section.  I'm
thinking it should just be a new Section 11.1 and then everything that had
been 11.1 (Transport) and below just move downwards.  Your comments on
this are requested.

Thanks,
Chris

===========================================================================

11.1 PRNG

   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.  RFC 1750
   [1750] contains more discussion on this and suggestions for
   randomness.  Implementors should note well the importance of truly
   random values where needed in this document.  They should also heed
   the well-meant, anecdotal warning that implementing PRNG functions are
   difficult to get right.

   The amount of entropy available to a given client or server sometimes
   may be less than what is needed to run the protocol.  In this case
   one must either resort to PRNGs anyways or refuse to run the protocol.
   In practice implementors will generally rely on some PRNG.

[1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness
       Recommendations for Security", RFC 1750, December 1994.

---

From: Russ Housley <[email-masked]>
Date: Thu, 15 May 2003 17:02:26 -0400

Chris:

>    ... and, furthermore, the PRNG should be seeded with

I think that the term "truly random" ought to be avoided.  In the 
subsequent paragraph. the term "entropy" is used.  I think that is a better 
way to go.  I propose:

    ... and, furthermore, entropy needs to be added to the PRNG.
    RFC 1750 [1750] offers suggestions for sources of entropy.
    Implementors should note the importance of entropy and the
    well-meant, anecdotal warning about the difficulty in
    properly implementing PRNG functions.

Russ

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 15 May 2003 14:29:15 -0700

> man in the middle is not feasable with public

Yes, and I screwed up in my comment.  What I meant to say was that
pubkey userauth with server host keys that are not securely distributed
is subject to spoofing - but I said instead that it's subject to MITM
attack.  My apologies for the confusion.

> is-- which really makes this protection quite

Right.

Nico
--

---

From: Chris Lonvick <[email-masked]>
Date: Fri, 16 May 2003 05:33:45 -0700 (PDT)

Hi,

Integrating Russ' suggestion.

Thanks,
Chris

============================================================

11.1 PRNG

   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, entropy needs to be added to the
   PRNG.  RFC 1750 [1750] offers suggestions for sources of entropy.
   Implementors should note the importance of entropy and the well-meant,
   anecdotal warning about the difficulty in properly implementing PRNG
   functions.

---

From: Chris Lonvick <[email-masked]>
Date: Fri, 16 May 2003 05:42:02 -0700 (PDT)

Hi Folks,

From a note from Fyodor on the [email-masked] mailing list:
  http://lists.insecure.org/lists/nmap-hackers/2003/Apr-Jun/0010.html

-snip-
> Like almost any self-respecting geek, I bought tickets to 'Matrix:
> Reloaded' several weeks back (no spoilers, I promise). After all, who
> can resist the combination of philosophical mind games and Trinity
> (Carrie-Anne Moss) in that tight leather bodysuit?
>
> So after waiting an hour in a line snaking out of the theatre to the
> parking lot, I finally got in to my 10pm Wednesday showing. All was
> going well until Trinity needed to do some hacking. Oh, no! I was
> sure we'd see a silly "Hackers"-esque 3D animated "hacking scene".
> Not so! Trinity is as smart as she is seductive! She whips out
> Nmap (!!!), scans her target, finds 22/tcp open, and proceeds with an
> Uber ssh technique! I was so surprised, I almost jumped out of my
> seat and did the "r00t dance" right there in the theatre!
-/snip-

While this may be good news for Fyodor and the Nmap crew, this is
definitely bad news for our effort.  I suspect that some future/
alternate-reality implementor will not have heeded the warnings about the
correct implementation of the PRNG.  I think it best that my employer
should send me to see the movie (and pay for the popcorn, soft drink,
maybe some Milk Duds and a bottle of water as well) so I can do some
_research_ on this future/alternate-reality problem with SSH.

Thanks,
Chris

Special note to the humor impaired:  This is it.  :-)

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 16 May 2003 09:12:13 -0700

> _research_ on this future/alternate-reality problem with SSH.

Even in the heady `90s such a business expense might be too much -
certainly it could be enough to bankrupt a typical, small dot-bomb.

Cheers,

Nico
--

---

From: "David M. Williams" <[email-masked]>
Date: Fri, 16 May 2003 11:28:33 -0600

Chrris,
    I hope that my signal-to-noise ratio on comments hasn't gotten too 
low that I can't make a few comments on the PRNG section.

the acronym PRNG lacks a parenthetical reference at it's first occurance 
in the draft.

s/PRNG/Pseudo-Random Number Generation/
with the parenthetical reference in the following paragraphs or

s/PRNG/Pseudo-Random Number Generator (PRNG)/
This is probably not correct per the style RFC.

also we seem to be using the acronym for both "generator" and 
"generation".  Do we care about the gramatical agreement?

>   random data that is specific to the session in the hash used to
maybe this is clearer,
s/random data that is specific to the session/random, session specific data/

>   anecdotal warning about the difficulty in properly implementing PRNG
s/PRNG functions/PRNGs/
fixes the usage issue, now all uses reflect the implied "generator" usage.

>   may be less than what is needed to run the protocol.  In this case
s/sometimes may/may sometimes/

s/to run the protocol/to provide

>   one must either resort to PRNGs anyways or refuse to run the protocol.
s/anyways/regardless of insufficient entropy/

>   In practice implementors will generally rely on some PRNG.
I'd like to suggest we drop this sentence.

-- 
David M. Williams, CISSP		Phone: 505-665-8062
Systems Engineer, CCN-2			Fax:   505-667-7942
Los Alamos National Laboratory		Email: d_wllmsATlanlDOTgov

"Nel mezzo del cammin di nostra vita / mi ritrouvai per una selva oscura /
che la diritta via era smarrita" -Dante Aligheri

---

From: Chris Lonvick <[email-masked]>
Date: Fri, 16 May 2003 10:37:12 -0700 (PDT)

Hi Simon and Nico,

I believe that the point you're trying to make would come under the
Authentication Protocol section rather than being left in the Transport
section on MITM.  That section starts with the following:
===
11.3 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.
===
Is that sufficient for your concerns or should this section also contain a
warning about trying to run _any_ authentication mechanism over an SSH
session that has not already been authenticated (at the device level)?

Thanks,
Chris

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 16 May 2003 10:44:36 -0700

Ah, yes, that is good.

Thank you,

Nico

---

From: Chris Lonvick <[email-masked]>
Date: Fri, 16 May 2003 11:19:27 -0700 (PDT)

Hi,

I've pulled out #2 from the prior version and didn't like it until I
reformatted it.  I've kept a lot of the verbiage and hopefully the
thoughts.  Please comment.

Thanks,
Chris

11.1 Transport

11.1.4 Man-in-the-middle

   This protocol makes no assumptions nor provisions for an
   infrastructure or means for distributing the public keys of hosts.  It
   is expected that this protocol will sometimes be used without first
   verifying the association between the server host key and the server
   host name.  Such usage is vulnerable to man-in-the-middle attacks.
   This section describes this and encourages administrators and users to
   understand the importance of verifying this association before any
   session is initiated.

   There are two cases of man-in-the-middle attacks to consider.  The
   first is where an attacker places a device between the client and the
   server before the session is initiated.  In this case, the attack
   device is trying to mimic the legitimate server and will offer its
   public key to the client when the client initiates a session.  If it
   were to offer the public key of the server, then it would not be able
   to decrypt or sign the transmissions between the legitimate server and
   the client unless it also had access to the private-key of the host.
   The attack device will also, simultaneously to this, initiate a
   session to the legitimate server masquerading itself as the client.
   If the public key of the server had been securely distributed to the
   client prior to that session initiation, the key offered to the client
   by the attack device will not match the key stored on the client.  In
   that case, the user SHOULD be given a warning that the offered host
   key does not match the host key cached on the client.  As described in
   Section 3.1 of [ARCH], the user may be free to accept the new key and
   continue the session.  It is RECOMMENDED that the warning provide
   sufficient information to the user of the client device so they may
   make an informed decision.  If the user chooses to continue the
   session with the stored public-key of the server (not the public-key
   offered at the start of the session), then 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.

   Insecure distribution of server public keys allows a second type of
   man-in-the-middle attack that should also be considered in this case;
   one with suitable but incorrect host keys.  If the server public keys
   are not securely distributed then the client cannot know if it is
   talking to the intended server.  An attacker may use social
   engineering techniques to pass off server keys to unsuspecting users
   and may then place a man-in-the-middle attack device between the
   legitimate server and the clients.  If this is allowed to happen then
   the clients will form client-to-attacker sessions and the attacker
   will form attacker-to-server sessions and will be able to monitor and
   manipulate all of the traffic between the clients and the legitimate
   servers.  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 are discussed in Section 3.1 of [SSH-ARCH] and may also
   include secured Web pages, physical pieces of paper, etc.
   Implementors SHOULD provide recommendations on how best to do this
   with their implementation.  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, making the host key fingerprint available through a secure
   DNS lookup, or using kerberos over gssapi during key exchange to
   authenticate the server are possibilities.

   As a second man-in-the-middle case, attackers may attempt to
   manipulate packets in transit between peers after the session has been
   established.  As described in the Replay part of this section, a
   successful attack of this nature is very improbable.  As in the Replay
   section, this reasoning does assume that the MAC is secure and that it
   is infeasible to construct inputs to a MAC algorithm to give a known
   output.  This is discussed in much greater detail in Section 6 of RFC
   2104.  If the MAC algorithm has a vulnerability or is weak enough,
   then the attacker may be able to specify certain inputs to yield a
   known MAC.  With that they may be able to alter the contents of a
   packet in transit.  Alternatively the attacker may be able to exploit
   the algorithm vulnerability or weakness to find the shared secret by
   reviewing the MACs from captured packets.  In either of those cases,
   an attacker could construct a packet or packets that could be inserted
   into an SSH stream.  To prevent that, implementors are encouraged to
   utilize commonly accepted MAC algorithms and administrators are
   encouraged to watch current literature and discussions of cryptography
   to ensure that they are not using a MAC algorithm that has a recently
   found vulnerability or weakness.

   In summary, the 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.

-end

---

From: Chris Lonvick <[email-masked]>
Date: Fri, 16 May 2003 11:53:07 -0700 (PDT)

Hi,

How's this?  I punted on the PRNG and just replaced it with the proper
words as grammar dictates.  I worked in a sentence that originally appears
in Section 8 of [SSH-ARCH] and replaced the last sentence as that seems to
be consistent with the intent of that Section 8.

Thanks,
Chris

=========================================================================

11.1 Pseudo-Random Number Generation

   This protocol binds each session key to the session by including
   random, session specific data in the hash used to produce session
   keys.  Special care should be taken to ensure that all of the random
   numbers are of good quality.  If the random data here (e.g., DH
   parameters) are pseudo-random then the pseudo-random number generator
   should be cryptographically secure (i.e., its next output not easily
   guessed even when knowing all previous outputs) and, furthermore,
   proper entropy needs to be added to the pseudo-random number
   generator.  RFC 1750 [1750] offers suggestions for sources of random
   numbers and entropy.  Implementors should note the importance of
   entropy and the well-meant, anecdotal warning about the difficulty in
   properly implementing pseudo-random number generating functions.

   The amount of entropy available to a given client or server may
   sometimes be less than what is required.  In this case one must either
   resort to pseudo-random number generation regardless of insufficient
   entropy or refuse to run the protocol.  The latter is preferable.