[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

firewall traversal certificates for SSH

-----BEGIN PGP SIGNED MESSAGE-----


  I started writing a response to <199703280119.DAA26506@pilari.ssh.fi>,
which, if the ietf-ssh archives aren't available yet, I'll put up
at http://www.sandelman.ottawa.on.ca/SSW/ietf/secsh/ylo-proxy when
I get home.
  I then realized that my response had gotten to ID length, so I'll
post that to
http://www.sandelman.ottawa.on.ca/SSW/ietf/draft-richardson-aft-cert-ipsec-secsh.txt
  and to the ID editor after some revision.
 
]  sleep lab: Help! I woke up with wires attached to my head!   | one borg    [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    | two borg    [
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ | red b blue b[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy");  [
  

  Tatu writes in  of a way that 
SSH 2.0 could use a proxy. What he describes, along with the 
partial success flag for the SSH_MSG_USERAUTH_FAILURE message
satisfies me that a proxy can be built. I would prefer that rather
than have a modifyer for SSH_MSG_USERAUTH_FAILURE, that we call this
message SSH_MSG_USERAUTH_REQUEST. 
  Success/failure of an chosen authentication method should be
indicated by distinct success/failure notices. Successful conclusion
of the authentication should be indicated by an overall success
condition. 
  
>I assume you mean like a firewall proxy, and the user first
>authenticates to the firewall and only then gets connected to the real
>host where he needs to autenticate again?

  Yes, precisely.

1>  - how does the client know whether it can know the proxy server (the
>    man in the middle)?
2>  - how does the server know that it can trust the proxy server (the
>    man in the middle)?
3>  - how to tell the real server who the real client is?

  And, as you say later:
4.  - how to tell the proxy where the real server is.

  Some terminology:
	C <---> {G1} <---> {G2} <---> S
  C is the client.
  G1/G1 are gateways.
  S is the server.

  C is the application layer originator.
  S is the application layer target.
  C/G1  is a transport layer originator/target. 
  G1/G2 is a transport layer originator/target.
  G2/S  is a transport layer originator/target.

  Last issue first:
  #4

>This does not completely solve the problem for the case that the
>client needs to directly connect to the proxy (is that case
>relevant?).  For that to work, we need to pass the name of the real
  
  Yes, it happens when an external node tries to connect to an
internal node, but the internal node is behind a first generation
application layer gateway (e.g. SOCKS, FWTK, etc.) that does NAT.
  As you identify, the problem is relaying the intended application
layer target to the proxy.

  #3: how does a non-transparent or NAT proxy determine the
application layer target given only the transport layer target?

>target host somewhere, either on the transport layer or on the user
>authentication layer.  One possibility would be to have a new
>fake authentication mehthod "connect-to-real-host" that could look
>like the following:

  I'd prefer that the transport layer ALWAYS pass on an application
layer target hostname to the server. This should be the thing that the
user typed in. I.e. "foo.bar.com" rather than an IP address or the
result of getnamebyaddr(3)'ing an IP address. Think of this as being
like the Host: field for HTTP 1.1. 
  Normal servers may just log this, but otherwise ignore it. The
presence of this data does make large scale make man-in-the-middle 
attacks easier (e.g. ones done by a bad ISP), but we have #1/#2 to
address this issue. 
  NOTE: this field also allows for protocol gateways, including v4/v6
gateways.

  #1: how does the client trust the proxy?
  #2: how does the server trust the proxy?

  Yes, a certificate is used. Firewalls are issued with [SPKC]
certificates with an auth field like:
	(ip-gateway ..<list of networks/hosts>..)
  e.g:
	(ip-gateway (v4-network 205.233.54.128 28)
		    (v4-private 192.168.32.0   24)
		    (host       foo.bar)
		    (v6-network 00:c0:ff:ee:04:ba:be:: 56))

  This cert would be signed by a host within 205.233.54.128/28 wishing
to initiate or receive a connection, or by a host's organizational
CA. (In the SPKI model, one would have a certificate, or a local
policy statement delegating naming authority to one's CA chain, so
these statements are equivalent, except that this chain needs to be
passed to other verifiers)
  Note: we need the host type to deal with NAT situations, since those
machines do not have meaningful network addresses.  Thus the presence 
of v4-private types. 
  The above certificate is used both by client and by server.

  For the above example there are 
  
  
    


  
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: latin1
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface

iQB1AwUBM4Gjm8mxxiPyUBAxAQH5fQL/T3VFA2W7K41T2ipVZvtgnJAGr7QYCC+C
83LQ1xL1GdEtNpTCn198VGksn2AADrnJQGzO0PrUMHSfbm8T+wYuYGZSp9hpbyXB
WddrTaPk+i6FZl7owFeXF2qJvxCencYL
=tDzN
-----END PGP SIGNATURE-----