From owner-ietf-ssh@clinet.fi  Fri May  2 23:19:17 1997
Return-Path: <owner-ietf-ssh@clinet.fi>
Received: from muuri.ssh.fi (muuri.ssh.fi [192.168.2.254])
	by pilari.ssh.fi (8.8.5/8.8.5/1.9) with ESMTP id XAA02654;
	Fri, 2 May 1997 23:19:11 +0300 (EET DST)
Received: from hauki.clinet.fi (root@hauki.clinet.fi [194.100.0.1])
	by muuri.ssh.fi (8.8.5/8.8.5/EPIPE-1.10) with ESMTP id XAA00998;
	Fri, 2 May 1997 23:19:11 +0300 (EET DST)
Received: (daemon@localhost) by hauki.clinet.fi (8.8.5/8.6.4) id XAA08678 for ietf-ssh-outgoing; Fri, 2 May 1997 23:12:07 +0300 (EET DST)
Received: from lox.sandelman.ottawa.on.ca (lox.sandelman.ottawa.on.ca [205.233.54.146]) by hauki.clinet.fi (8.8.5/8.6.4) with ESMTP id XAA08670 for <ietf-ssh@clinet.fi>; Fri, 2 May 1997 23:11:59 +0300 (EET DST)
Received: from amaterasu.sandelman.ottawa.on.ca (amaterasu.sandelman.ottawa.on.ca [205.233.54.134]) by lox.sandelman.ottawa.on.ca (8.7.5/8.7.3) with ESMTP id QAA28532 for <ietf-ssh@clinet.fi>; Fri, 2 May 1997 16:15:18 -0400 (EDT)
Received: from amaterasu.sandelman.ocunix.on.ca (LOCALHOST [127.0.0.1]) by amaterasu.sandelman.ottawa.on.ca (8.7.5/8.6.12) with ESMTP id QAA01079 for <ietf-ssh@clinet.fi>; Fri, 2 May 1997 16:10:53 -0400 (EDT)
Message-Id: <199705022010.QAA01079@amaterasu.sandelman.ottawa.on.ca>
To: ietf-ssh@clinet.fi
Subject: Re: Comments on draft-ietf-secsh-userauth-00.txt 
In-reply-to: Your message of "Mon, 21 Apr 1997 21:04:02 EDT."
             <199704220104.VAA15394@alcor.concordia.ca> 
Date: Fri, 02 May 1997 16:10:51 -0400
From: Michael Richardson <mcr@sandelman.ottawa.on.ca>
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 4202
Lines: 98

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


>>>>> "Anne" == Anne Bennett <anne@alcor.concordia.ca> writes:
    Anne> A more general question: I'm not sure I understand why you
    Anne> overload "failure" to mean both "more authentication
    Anne> required" and "authentication denied, go away".  My initial
    Anne> response was great puzzlement, since the two situations
    Anne> "feel" different to me, but when I thought it over, I could
    Anne> not easily come up with a situation where it would be
    Anne> important to differentiate between them.  It may not belong
    Anne> here in the draft, but I'd be interested in understanding
    Anne> your reasoning for this choice of approach.

  I do not like this overloading either.
  I have no idea when a client would stop trying to authenticate. I
suspect that most clients will give up too soon. In particular, they
may never try an authentication method that they have already tried. 

  The example that I give involves a proxy that talks SSH transport
layer, and requires password authentication. Once satisfied, it
negotiates a new transport layer session with the intended remote host
and communicates until the remote host gets to the
"SSH_MSG_USERAUTH_SUCCESS, continue with X,Y,Z" from the remote host. 

  At this time, the proxy becomes a circuit proxy. 
  
  Now, what does the client do? It previously authenticated using
"X". Should it try again? If so, how many times? Forever?

    Anne> I suspect that above you mean Unix "r-command"-style
    Anne> authentication; we should try to come up with a clearer
    Anne> one-line description to avoid keeping readers in suspense
    Anne> until they get to the relevant subsection.  :-) Nothing
    Anne> comes to mind offhand, unfortunately.

  Host identity could involve /etc/ssh_host_key style "RSARhost"
authentication.  I've never used this style myself...

    Anne> It's not clear what you mean by "service" here; I looked up
    Anne> "service request" in the transport draft, and am even more
    Anne> puzzled, since if we authenticated for a service, why should
    Anne> we then have to explicitly request a service?  I think the

  Maybe, some services may not require authentication ???

    Anne> So clearly the authentication sequence is stateful, and at
    Anne> least from the server's point of view, failure is not the

  I've rewritten this section.

    Anne> < While there is usually little point in clients sending
    Anne> requests that the < server does not list as acceptable,
    Anne> sending such requests is not an < error, and the server
    Anne> should simply reject requests that it does not < recognize.

    Anne> ... but not reset its state if the username and service have
    Anne> not changed?  And reset its state if they *have* changed?

  The motivation for this is not explained in the 00 document. It is
there to allow a server to lie about its authentication policy, and
for clients in the know (via preconfiguration) to do the right thing.

    Anne> This last sentence means that the server cannot require
    Anne> multiple authentications by the same method.  Is this what
    Anne> is intended?

  I hope not.

    Anne> I'd prefer to use the term "challenge-response"; for

  Point token.

    Anne> < 6.  Address of Author < < Tatu Ylonen < SSH Communications
    Anne> Security Ltd.  < Tekniikantie 12 < FIN-02150 ESPOO < Finland
    Anne> < < E-mail: ylo@ssh.fi

    Anne> Believe it or not, I have no comments on your address. :-)

  That's because you haven't seen the building. Or, the elevators that
who'se software crashes if you get in the wrong way.

   :!mcr!:            |  Network security consulting and 
   Michael Richardson |      contract programming
 WWW: <A HREF="http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html">mcr@sandelman.ottawa.on.ca</A>. PGP key available.



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

iQB1AwUBM2pJpaZpLyXYhL+BAQGeCAL/UEIkkWms/r4ZGeMugJmii6c41X7igezS
/fbgjCkGMiIBma0J9lZ/WR2Bwz8t23GcD2GDg73X0dggdePLdaKN7bzsYdYhKMgy
JFsX0gDIh5qQ9RKxejrL4VBzLuqRvgii
=ow46
-----END PGP SIGNATURE-----
From owner-ietf-ssh@clinet.fi  Sat May  3 00:10:59 1997
Return-Path: <owner-ietf-ssh@clinet.fi>
Received: from muuri.ssh.fi (muuri.ssh.fi [192.168.2.254])
	by pilari.ssh.fi (8.8.5/8.8.5/1.9) with ESMTP id AAA02960;
	Sat, 3 May 1997 00:10:59 +0300 (EET DST)
Received: from hauki.clinet.fi (root@hauki.clinet.fi [194.100.0.1])
	by muuri.ssh.fi (8.8.5/8.8.5/EPIPE-1.10) with ESMTP id AAA01096;
	Sat, 3 May 1997 00:10:58 +0300 (EET DST)
Received: (daemon@localhost) by hauki.clinet.fi (8.8.5/8.6.4) id AAA14919 for ietf-ssh-outgoing; Sat, 3 May 1997 00:10:30 +0300 (EET DST)
Received: from lox.sandelman.ottawa.on.ca (lox.sandelman.ottawa.on.ca [205.233.54.146]) by hauki.clinet.fi (8.8.5/8.6.4) with ESMTP id AAA14867 for <ietf-ssh@clinet.fi>; Sat, 3 May 1997 00:10:20 +0300 (EET DST)
Received: from amaterasu.sandelman.ottawa.on.ca (amaterasu.sandelman.ottawa.on.ca [205.233.54.134]) by lox.sandelman.ottawa.on.ca (8.7.5/8.7.3) with ESMTP id RAA28925 for <ietf-ssh@clinet.fi>; Fri, 2 May 1997 17:13:40 -0400 (EDT)
Received: from amaterasu.sandelman.ocunix.on.ca (LOCALHOST [127.0.0.1]) by amaterasu.sandelman.ottawa.on.ca (8.7.5/8.6.12) with ESMTP id RAA01211 for <ietf-ssh@clinet.fi>; Fri, 2 May 1997 17:09:13 -0400 (EDT)
Message-Id: <199705022109.RAA01211@amaterasu.sandelman.ottawa.on.ca>
To: ietf-ssh@clinet.fi
Subject: draft-ietf-secsh-userauth-00.txt: Rewritten text about one time tokens
In-reply-to: Your message of "Mon, 21 Apr 1997 21:04:02 EDT."
             <199704220104.VAA15394@alcor.concordia.ca> 
Date: Fri, 02 May 1997 17:09:09 -0400
From: Michael Richardson <mcr@sandelman.ottawa.on.ca>
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 1734
Lines: 50

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


  Tatu volunteered me to rewrite the one time token and user
authentication method negotiation parts of the draft.

  I had hoped to provide some text prior to now, and will be posting
some today.

  I have a question:

  I had originally intended to distinguish between software and
hardware tokens. The argument is that software tokens are something
that requires particular support in the SSH client, while hardware
tokens are something that require interaction with a human. 

  Perhaps the name "hardware" is wrong: a software token that requires
that the human do some cut&paste operations is a "human intervention token"
while, an OPIE otp, which can be understood by the client itself
doesn't require any cut&paste operations. (How do you get the
passphrase!)
  
  The other way to distinguish things is tokens that require a human
to be there, and those that do not. Are there any examples where a
human is not in some way required? 
  (RSA authentication via the agent is an example, but it isn't 
a OTP example)

  So, I'm inclined to drop my distinction between hardware and
software tokens.

  What do you think?

   :!mcr!:            |  Network security consulting and 
   Michael Richardson |      contract programming
 WWW: <A HREF="http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html">mcr@sandelman.ottawa.on.ca</A>. PGP key available.


	

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

iQB1AwUBM2pE2KZpLyXYhL+BAQFqXgMAotrqIxloKiF2HjRJiNn724mcuMiVSHQH
vVqxfAcedAizKgu3wU5pHEdVFPFJd9IjhVC9sXRb30oAlF/eWOCdZWLpLjJhVJ3K
Y9y03Lz7XTwhKFscItixnKbAnzHIEAt/
=tXlG
-----END PGP SIGNATURE-----
From owner-ietf-ssh@clinet.fi  Sat May  3 17:16:50 1997
Return-Path: <owner-ietf-ssh@clinet.fi>
Received: from muuri.ssh.fi (muuri.ssh.fi [192.168.2.254])
	by pilari.ssh.fi (8.8.5/8.8.5/1.9) with ESMTP id RAA11241;
	Sat, 3 May 1997 17:16:48 +0300 (EET DST)
Received: from hauki.clinet.fi (root@hauki.clinet.fi [194.100.0.1])
	by muuri.ssh.fi (8.8.5/8.8.5/EPIPE-1.10) with ESMTP id RAA04029;
	Sat, 3 May 1997 17:16:48 +0300 (EET DST)
Received: (daemon@localhost) by hauki.clinet.fi (8.8.5/8.6.4) id RAA04219 for ietf-ssh-outgoing; Sat, 3 May 1997 17:15:37 +0300 (EET DST)
Received: from lox.sandelman.ottawa.on.ca (lox.sandelman.ottawa.on.ca [205.233.54.146]) by hauki.clinet.fi (8.8.5/8.6.4) with ESMTP id RAA04196 for <ietf-ssh@clinet.fi>; Sat, 3 May 1997 17:15:26 +0300 (EET DST)
Received: from amaterasu.sandelman.ottawa.on.ca (amaterasu.sandelman.ottawa.on.ca [205.233.54.134]) by lox.sandelman.ottawa.on.ca (8.7.5/8.7.3) with ESMTP id KAA01584 for <ietf-ssh@clinet.fi>; Sat, 3 May 1997 10:19:25 -0400 (EDT)
Received: from amaterasu.sandelman.ocunix.on.ca (LOCALHOST [127.0.0.1]) by amaterasu.sandelman.ottawa.on.ca (8.7.5/8.6.12) with ESMTP id KAA01795 for <ietf-ssh@clinet.fi>; Sat, 3 May 1997 10:14:36 -0400 (EDT)
Message-Id: <199705031414.KAA01795@amaterasu.sandelman.ottawa.on.ca>
To: ietf-ssh@clinet.fi
Subject: Re: draft-ietf-secsh-userauth-00.txt: Rewritten text about one time tokens 
In-reply-to: Your message of "Sat, 03 May 1997 08:24:07 EDT."
             <Pine.SOL.3.95.970503081622.28449g-100000@lukyduk.ifs.umich.edu> 
Date: Sat, 03 May 1997 10:14:34 -0400
From: Michael Richardson <mcr@sandelman.ottawa.on.ca>
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 1961
Lines: 50

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


>>>>> "Douglas" == Douglas Song <dugsong@umich.edu> writes:
    Douglas> a Kerberos service ticket/authenticator could be
    Douglas> considered a time-expired token, since it changes for
    Douglas> each session, and doesn't require any human intervention
    Douglas> (ie. typing of passphrases, etc.).

  My questions related only to one time passwords. While I agree with
you, this type of thing isn't appropriate for Kerberos.

    Douglas> i think a good thing to look at is the GSSAPI work that's
    Douglas> already been done, since this is largely what the point
    Douglas> of GSS was. good luck!

  GSSAPI even less so.
  We are talking about allowing things like SecurID (with all its
NextPIN, etc... modes), CryptoCard, SNK, ActiveCard, S/Key, OPIE, and
new things that might be supported indirectly via things like PAM.
  Some of these things might desire to have in-client support. 

  The major problem with any kind of negotiation between the client
and the server about what "method" to use is that the client software
would need to be configured to know what tokens the user has in their
pocket. 
  I would favour the client offering to the server to enter into a
"one time password" negotiation. A client in batch mode would never do
this. 
  The server then gets to decide whether to ask for the OPIE or the
SecurID card first.

   :!mcr!:            |  Network security consulting and 
   Michael Richardson |      contract programming
 WWW: <A HREF="http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html">mcr@sandelman.ottawa.on.ca</A>. PGP key available.





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

iQB1AwUBM2tH4aZpLyXYhL+BAQGFQgL+OQFxawF/4rpWbfFfAGEKGQxGegA+b2uX
yIS4V7fEIhMAVd2zFqqvzEu+TezoyRusYQwipDjbHGoT2Qz2aqKCMMmLCBLkHCDn
wMm7dR70IvjBx62TTOWE61k6zi3YffU1
=xlWp
-----END PGP SIGNATURE-----
From owner-ietf-ssh@clinet.fi  Fri May 16 02:00:13 1997
Return-Path: <owner-ietf-ssh@clinet.fi>
Received: from muuri.ssh.fi (muuri.ssh.fi [192.168.2.254])
	by pilari.ssh.fi (8.8.5/8.8.5/1.9) with ESMTP id CAA09591;
	Fri, 16 May 1997 02:00:11 +0300 (EET DST)
Received: from hauki.clinet.fi (root@hauki.clinet.fi [194.100.0.1])
	by muuri.ssh.fi (8.8.5/8.8.5/EPIPE-1.10) with ESMTP id CAA09771;
	Fri, 16 May 1997 02:00:07 +0300 (EET DST)
Received: (majordom@localhost) by hauki.clinet.fi (8.8.5/8.6.4) id BAA09480 for ietf-ssh-outgoing; Fri, 16 May 1997 01:53:49 +0300 (EET DST)
X-Authentication-Warning: hauki.clinet.fi: majordom set sender to owner-ietf-ssh@clinet.fi using -f
Received: from muuri.ssh.fi (ssh.fi [194.100.44.97]) by hauki.clinet.fi (8.8.5/8.6.4) with ESMTP id BAA09466 for <ietf-ssh@clinet.fi>; Fri, 16 May 1997 01:53:41 +0300 (EET DST)
Received: from pilari.ssh.fi (pilari.ssh.fi [192.168.2.1])
	by muuri.ssh.fi (8.8.5/8.8.5/EPIPE-1.10) with ESMTP id BAA09688;
	Fri, 16 May 1997 01:53:41 +0300 (EET DST)
Received: (from ylo@localhost)
	by pilari.ssh.fi (8.8.5/8.8.5/1.9) id BAA09092;
	Fri, 16 May 1997 01:53:39 +0300 (EET DST)
Date: Fri, 16 May 1997 01:53:39 +0300 (EET DST)
Message-Id: <199705152253.BAA09092@pilari.ssh.fi>
From: Tatu Ylonen <ylo@ssh.fi>
To: Anne Bennett <anne@alcor.concordia.ca>
Cc: ietf-ssh@clinet.fi
Subject: Comments on draft-ietf-secsh-userauth-00.txt
In-Reply-To: <199704220104.VAA15394@alcor.concordia.ca>
References: <199704220104.VAA15394@alcor.concordia.ca>
Organization: SSH Communications Security, Finland
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 1582
Lines: 35

> Appended are my comments on the userauth-00 draft, which is the one I
> picked up a few days before the IETF.  I noticed some comments that
> purported to be about userauth-01, but if 01 is out, I missed the
> announcement.  I hope the appended is useful anyway.

Sorry about my late response.  I haven't edited the draft for a few
weeks, but I'm now finally merging a set of changes into it.

Thank you very much for your excellent comments.  I merged almost all
of your proposed changes into the document.

> A more general question: I'm not sure I understand why you overload
> "failure" to mean both "more authentication required" and
> "authentication denied, go away".  My initial response was great
> puzzlement, since the two situations "feel" different to me, but when
> I thought it over, I could not easily come up with a situation where
> it would be important to differentiate between them.  It may not
> belong here in the draft, but I'd be interested in understanding your
> reasoning for this choice of approach.

I have now changed the specification to say that the server
should not list those requests it has already accepted, unless it
really wants the client to authenticate again with the same method.

I've added a boolean field "partial success" to
SSH_MSG_USERAUTH_FAILURE.  It is TRUE if the particular method was
accepted, but authentication still failed because more authentication
is needed.

I'll send the updated draft to the ietf-ssh list later (I still have
some more changes to merge).

Again, thanks for your comments and suggestions!

    Tatu
From owner-ietf-ssh@clinet.fi  Fri May 16 02:07:39 1997
Return-Path: <owner-ietf-ssh@clinet.fi>
Received: from muuri.ssh.fi (muuri.ssh.fi [192.168.2.254])
	by pilari.ssh.fi (8.8.5/8.8.5/1.9) with ESMTP id CAA09821;
	Fri, 16 May 1997 02:07:38 +0300 (EET DST)
Received: from hauki.clinet.fi (root@hauki.clinet.fi [194.100.0.1])
	by muuri.ssh.fi (8.8.5/8.8.5/EPIPE-1.10) with ESMTP id CAA09878;
	Fri, 16 May 1997 02:07:37 +0300 (EET DST)
Received: (majordom@localhost) by hauki.clinet.fi (8.8.5/8.6.4) id CAA10958 for ietf-ssh-outgoing; Fri, 16 May 1997 02:06:06 +0300 (EET DST)
X-Authentication-Warning: hauki.clinet.fi: majordom set sender to owner-ietf-ssh@clinet.fi using -f
Received: from muuri.ssh.fi (ssh.fi [194.100.44.97]) by hauki.clinet.fi (8.8.5/8.6.4) with ESMTP id CAA10953 for <ietf-ssh@clinet.fi>; Fri, 16 May 1997 02:06:00 +0300 (EET DST)
Received: from pilari.ssh.fi (pilari.ssh.fi [192.168.2.1])
	by muuri.ssh.fi (8.8.5/8.8.5/EPIPE-1.10) with ESMTP id CAA09874;
	Fri, 16 May 1997 02:06:00 +0300 (EET DST)
Received: (from ylo@localhost)
	by pilari.ssh.fi (8.8.5/8.8.5/1.9) id CAA09817;
	Fri, 16 May 1997 02:05:58 +0300 (EET DST)
Date: Fri, 16 May 1997 02:05:58 +0300 (EET DST)
Message-Id: <199705152305.CAA09817@pilari.ssh.fi>
From: Tatu Ylonen <ylo@ssh.fi>
To: Michael Richardson <mcr@sandelman.ottawa.on.ca>
CC: ietf-ssh@clinet.fi
Subject: Re: Comments on draft-ietf-secsh-userauth-00.txt 
In-Reply-To: <199705022010.QAA01079@amaterasu.sandelman.ottawa.on.ca>
References: <199704220104.VAA15394@alcor.concordia.ca>
	<199705022010.QAA01079@amaterasu.sandelman.ottawa.on.ca>
Organization: SSH Communications Security, Finland
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 2466
Lines: 51

>     Anne> A more general question: I'm not sure I understand why you
>     Anne> overload "failure" to mean both "more authentication
>     Anne> required" and "authentication denied, go away".  My initial
>     Anne> response was great puzzlement, since the two situations
>     Anne> "feel" different to me, but when I thought it over, I could
>     Anne> not easily come up with a situation where it would be
>     Anne> important to differentiate between them.  It may not belong
>     Anne> here in the draft, but I'd be interested in understanding
>     Anne> your reasoning for this choice of approach.
> 
>   I do not like this overloading either.
>   I have no idea when a client would stop trying to authenticate. I
> suspect that most clients will give up too soon. In particular, they
> may never try an authentication method that they have already tried. 

I just responded to Anne's original message.  Essentially
  - it now specifies that the server only lists an already successful
    method if using it again would be benefical
  - SSH_MSG_USERAUTH_FAILURE includes a "partial success" flag which
    indicates that the particular method was accepted, but it alone is
    not sufficient.

>   Now, what does the client do? It previously authenticated using
> "X". Should it try again? If so, how many times? Forever?

This is driven by the server.  The client just obeys the server's
requests.  It should be tried again if the server still lists it.

>     Anne> I suspect that above you mean Unix "r-command"-style
>     Anne> authentication; we should try to come up with a clearer
>     Anne> one-line description to avoid keeping readers in suspense
>     Anne> until they get to the relevant subsection.  :-) Nothing
>     Anne> comes to mind offhand, unfortunately.
> 
>   Host identity could involve /etc/ssh_host_key style "RSARhost"
> authentication.  I've never used this style myself...

Lots of people do use it...

>     Anne> It's not clear what you mean by "service" here; I looked up
>     Anne> "service request" in the transport draft, and am even more
>     Anne> puzzled, since if we authenticated for a service, why should
>     Anne> we then have to explicitly request a service?  I think the
> 
>   Maybe, some services may not require authentication ???

I've clarified this in the draft.  There is a separate service request
after authentication, so you can have different services that require
authentication.

    Tatu
From owner-ietf-ssh@clinet.fi  Wed May 21 00:02:30 1997
Return-Path: <owner-ietf-ssh@clinet.fi>
Received: from muuri.ssh.fi (muuri.ssh.fi [192.168.2.254])
	by pilari.ssh.fi (8.8.5/8.8.5/1.9) with ESMTP id AAA11452;
	Wed, 21 May 1997 00:02:23 +0300 (EET DST)
Received: from hauki.clinet.fi (root@hauki.clinet.fi [194.100.0.1])
	by muuri.ssh.fi (8.8.5/8.8.5/EPIPE-1.10) with ESMTP id AAA23601;
	Wed, 21 May 1997 00:02:22 +0300 (EET DST)
Received: (majordom@localhost) by hauki.clinet.fi (8.8.5/8.6.4) id XAA12094 for ietf-ssh-outgoing; Tue, 20 May 1997 23:55:29 +0300 (EET DST)
X-Authentication-Warning: hauki.clinet.fi: majordom set sender to owner-ietf-ssh@clinet.fi using -f
Received: from lox.sandelman.ottawa.on.ca (lox.sandelman.ottawa.on.ca [205.233.54.146]) by hauki.clinet.fi (8.8.5/8.6.4) with ESMTP id XAA12081 for <ietf-ssh@clinet.fi>; Tue, 20 May 1997 23:55:15 +0300 (EET DST)
Received: from morden.sandelman.ottawa.on.ca (morden.sandelman.ottawa.on.ca [205.233.54.157]) by lox.sandelman.ottawa.on.ca (8.7.5/8.7.3) with ESMTP id RAA12583; Tue, 20 May 1997 17:07:25 -0400 (EDT)
Received: from morden.sandelman.ottawa.on.ca (localhost [127.0.0.1]) by morden.sandelman.ottawa.on.ca (8.7.5/8.7.3) with ESMTP id JAA00122; Tue, 20 May 1997 09:14:15 -0400 (EDT)
Message-Id: <199705201314.JAA00122@morden.sandelman.ottawa.on.ca>
To: ietf-ssh@clinet.fi
CC: spki@c2.org
Subject: firewall traversal certificates for SSH
In-reply-to: Your message of "Fri, 28 Mar 1997 03:19:19 +0200."
             <199703280119.DAA26506@pilari.ssh.fi> 
Date: Tue, 20 May 1997 09:14:12 -0400
From: Michael Richardson <mcr@sandelman.ottawa.on.ca>
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 5030
Lines: 129

-----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-----
From owner-ietf-ssh@clinet.fi  Wed May 21 00:02:38 1997
Return-Path: <owner-ietf-ssh@clinet.fi>
Received: from muuri.ssh.fi (muuri.ssh.fi [192.168.2.254])
	by pilari.ssh.fi (8.8.5/8.8.5/1.9) with ESMTP id AAA11454;
	Wed, 21 May 1997 00:02:27 +0300 (EET DST)
Received: from hauki.clinet.fi (root@hauki.clinet.fi [194.100.0.1])
	by muuri.ssh.fi (8.8.5/8.8.5/EPIPE-1.10) with ESMTP id AAA23605;
	Wed, 21 May 1997 00:02:26 +0300 (EET DST)
Received: (majordom@localhost) by hauki.clinet.fi (8.8.5/8.6.4) id XAA12031 for ietf-ssh-outgoing; Tue, 20 May 1997 23:54:50 +0300 (EET DST)
X-Authentication-Warning: hauki.clinet.fi: majordom set sender to owner-ietf-ssh@clinet.fi using -f
Received: from lox.sandelman.ottawa.on.ca (lox.sandelman.ottawa.on.ca [205.233.54.146]) by hauki.clinet.fi (8.8.5/8.6.4) with ESMTP id XAA11999 for <ietf-ssh@clinet.fi>; Tue, 20 May 1997 23:54:18 +0300 (EET DST)
Received: from morden.sandelman.ottawa.on.ca (morden.sandelman.ottawa.on.ca [205.233.54.157]) by lox.sandelman.ottawa.on.ca (8.7.5/8.7.3) with ESMTP id RAA12582 for <ietf-ssh@clinet.fi>; Tue, 20 May 1997 17:07:23 -0400 (EDT)
Received: from morden.sandelman.ottawa.on.ca (localhost [127.0.0.1]) by morden.sandelman.ottawa.on.ca (8.7.5/8.7.3) with ESMTP id JAA00150 for <ietf-ssh@clinet.fi>; Tue, 20 May 1997 09:43:45 -0400 (EDT)
Message-Id: <199705201343.JAA00150@morden.sandelman.ottawa.on.ca>
To: ietf-ssh@clinet.fi
Subject: Re: draft-ietf-secsh-userauth-00.txt (fwd) 
In-reply-to: Your message of "Fri, 28 Mar 1997 03:19:19 +0200."
             <199703280119.DAA26506@pilari.ssh.fi> 
Date: Tue, 20 May 1997 09:43:44 -0400
From: Michael Richardson <mcr@sandelman.ottawa.on.ca>
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 3860
Lines: 92

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


  Tatu writes 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 that Tatu wrote about more recently,
satisfies me that a proxy can be built. I would prefer that rather
than have a modifier 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.

  Issues #1 and #2 are dealt with in my ID. #4 is protocol
specific.

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

  Question number #4 restated: 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. 

  I think this should be done after the key exchange, but before
authentication and service requests. This allows the authentication
that the proxy does to be dependant on the application layer target
address.
  (Correct me if I'm wrong, that the authentication protocol fits into
the the transport protocol sequence between section 7 and 8. Could
there be a document added that just has sample exchanges? Perhaps with
the actual bytes listed, and the sample host keys, etc..)

	vlint32		SSH_MSG_TARGET_HOST
	string		host

  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 data also allows for protocol gateways, including v4/v6
gateways.

]  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");  [

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

iQB1AwUBM4GqgcmxxiPyUBAxAQF0FwMAmd9d21kVTx7M3LHF8xU8hun0igYbnJXn
Z67GcE6cswFzJmYwtkLoBPPE0E2Lvny7TcAYIvfCYj4I9n1tT6Q9kjlTf1NLbJN3
SOFcsSbztKKcrmv41AK+wPX/Mtq1MR1f
=iNU0
-----END PGP SIGNATURE-----
