Subject: Comments for draft-ietf-secsh-auth-kbdinteract-01.txt

From: Sami Lehtinen <[email-masked]>
Date: Tue, 12 Dec 2000 03:40:53 +0200

Couple of comments:

In section 3.1:

   The server SHOULD NOT reply with the SSH_MSG_USERAUTH_FAILURE
message
   if the failure is based on the user name or service name; instead
it
   SHOULD send SSH_MSG_USERAUTH_INFO_REQUEST message(s) which look
just
   like the one(s) which would have been sent in cases where
   authentication should proceed, and then send the failure message
   (after a suitable delay, as described below).  The goal is to make
it
   impossible to find valid user names by just comparing the results
   when authenticating as different users.

This is not good, as the server doesn't necessarily have a method to
get the possible messages from a device (library etc.). For example,
we don't know what PAM would query from the user if it existed. PAM
doesn't allow invalid users to continue the login after account
checkin. Point being, with PAM the server shouldn't take any stand on
what the PAM queries or tells the users; this depends on the PAM
configuration.

Section 3.2:

      byte    SSH_MSG_USERAUTH_INFO_REQUEST
      string  name (ISO-10646 UTF-8)
      string  instruction (ISO-10646 UTF-8)
      string  language tag (as defined in [RFC-1766])
      int     num-prompts
      string  prompt[1] (ISO-10646 UTF-8)
      boolean echo[1]
      ...
      string  prompt[num-prompts] (ISO-10646 UTF-8)
      boolean echo[num-prompts]

   The server SHOULD limit the length of the name and prompt fields to
   30 characters.  No restrictions are placed on the instruction
field.

30 characters could be too little.

  "[email-masked]'s passcode for SecurID auth:"

especially considering section 3.3 considerations

   --snip--
   request message.  Clients SHOULD NOT add any additional characters to
   the prompt such as ": "; the server is responsible for supplying all
   --snap--

-- 
[[email-masked]          --  Sami J. Lehtinen  --           [email-masked]]
[work:+358 9 85657425][gsm:+358 50 5170 258][http://www.iki.fi/~sjl]
[SSH Communications Security Corp               http://www.ssh.com/]

---

From: Martin Forssen <[email-masked]>
Date: Mon, 11 Dec 2000 18:59:07 -0800 (PST)

On 12 Dec, Sami Lehtinen wrote:
> Couple of comments:
> In section 3.1:
> 
>    The server SHOULD NOT reply with the SSH_MSG_USERAUTH_FAILURE message
>    if the failure is based on the user name or service name; instead it
>    SHOULD send SSH_MSG_USERAUTH_INFO_REQUEST message(s) which look just
>    (after a suitable delay, as described below).  The goal is to make it

Unfortunately I think this is an area where there is no good solution.
We would like the server to be able to make guessing valid usernames
impossible but this is not always possible. Perhaps the best we can do
here is to add some text to the draft where we note that we do not live
in a perfect world and although desirable authentication faking may not
always be possible. Something like this (to be added below the above
cited paragraph):

    The preceding paragraph describes how we would like things to work.
    Unfortunately it may sometimes not be possible for the server to
    predict the questions which would be sent as part of a valid
    authentication. In those cases it is not possible to fake
    authentication.

We could also change the beginning of the quoted paragraph to:

    The server SHOULD, if possible, NOT reply with the

IS tis enough or shoudl we do something more radical to the wording of
the draft?

>   "[email-masked]'s passcode for SecurID auth:"

In this case the server really ought to split it so for example the
instruction part reads

	"SecurID authentication for [email-masked]"

and the actual prompt is just "Passcode: "

	/MaF

PS If the example above was real I would also suggest applying large
   amount of physical force to the person who has designed your
   network:-)

PPS To add further noise here, back in the days when I worked as a
    sysadmin we actually used strange hostnames on machines we did not
    want people to log in to. Thus we had machine with names like
    gashplutzga, wazewski, rejewski, zorawski and so on.

---

From: Sami Lehtinen <[email-masked]>
Date: Tue, 12 Dec 2000 09:14:06 +0200

Martin Forssen, on December 11. 2000, wrote:
[faking authentication]
  : Unfortunately I think this is an area where there is no good solution.
  : We would like the server to be able to make guessing valid usernames
  : impossible but this is not always possible. Perhaps the best we can do
  : here is to add some text to the draft where we note that we do not live
  : in a perfect world and although desirable authentication faking may not
  : always be possible. Something like this (to be added below the above
  : cited paragraph):
  : 
  :     The preceding paragraph describes how we would like things to work.
  :     Unfortunately it may sometimes not be possible for the server to
  :     predict the questions which would be sent as part of a valid
  :     authentication. In those cases it is not possible to fake
  :     authentication.
  : 
  : We could also change the beginning of the quoted paragraph to:
  : 
  :     The server SHOULD, if possible, NOT reply with the
  : 
  : IS tis enough or shoudl we do something more radical to the wording of
  : the draft?

I think those will suffice. However, the whole concept of faking the
authentication is subject to debate. I, for one, don't have a strong
opinion about this. But, I think the decision on whether to fake or
not should probably be configurable by the adminkind.

  : > 30 characters could be too little.
  : > 
  : >   "[email-masked]'s passcode for SecurID auth:"
  : 
  : In this case the server really ought to split it so for example the
  : instruction part reads
  : 
  : 	"SecurID authentication for [email-masked]"
  : 
  : and the actual prompt is just "Passcode: "

Fair enough.

  : PS If the example above was real I would also suggest applying large
  :    amount of physical force to the person who has designed your
  :    network:-)

I'll forward your comments to our IT-department :)

---

From: Bill Sommerfeld <[email-masked]>
Date: Wed, 13 Dec 2000 22:51:50 -0800

i was about to ask [email-masked] to review the iana consideration
section, but it looks like the like the subheading for the IANA
Considerations section disappeared from the architecture draft..

   6.  Message Numbers   . . . . . . . . . . . . . . . . . . . . . . . .  8
     . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  9
   8.  Security Considerations   . . . . . . . . . . . . . . . . . . . .  9

					- Bill

---

From: Sami Lehtinen <[email-masked]>
Date: Thu, 14 Dec 2000 19:41:32 +0200

Bill Sommerfeld, on December 13. 2000, wrote:
  : i was about to ask [email-masked] to review the iana consideration
  : section, but it looks like the like the subheading for the IANA
  : Considerations section disappeared from the architecture draft..
  : 
  :    6.  Message Numbers   . . . . . . . . . . . . . . . . . . . . . . . .  8
  :      . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  9
  :    8.  Security Considerations   . . . . . . . . . . . . . . . . . . . .  9

Tero answered this already. The IANA considerations weren't changed
AFAIK from the last draft, so you can use that when asking.

Cheers,

---

From: Bill Sommerfeld <[email-masked]>
Date: Thu, 14 Dec 2000 10:27:09 -0800

I was pointed at RFC2434, "Guidelines on writing an 'IANA
Considerations' section".

It appears that we need just a little more detail in the architecture
draft; it also appears that the message numbers in section 6 of the
arch draft should also end up under the control of the IANA once the
documents are published as proposed standards.

Translating into the terminology in 2434, it looks like a reasonable
set of policies would be:

 - message numbers in the range of 0..191 should be allocated via IETF
consensus; message numbers in the 192..255 range (the "Local
extensions" set) are reserved for private use.

- protocol names are divided into three pieces:
  - names with @ signs in them are allocated by the owner of the DNS
name after the @ sign ("hierarchical allocation" in 2434 terms)
  - @-free names beginning with "ssh-" should be allocated using the IETF
consensus process.
  - @-free names not beginning with ssh- should be allocated using
2434's "specification required" policy.

Comments?

						- Bill

---

From: Martin Forssen <[email-masked]>
Date: Thu, 14 Dec 2000 13:41:59 -0800 (PST)

> extensions" set) are reserved for private use.

No problems.

> - protocol names are divided into three pieces:

What do you mean by protocol names? Does it for example include the
names of the encryption algorithms?

	/MaF

---

From: Bill Sommerfeld <[email-masked]>
Date: Thu, 14 Dec 2000 18:09:03 -0500

> names of the encryption algorithms?

Yes; see the five (I think) categories of names listed in the
architecture draft..

						- Bill

---

From: Martin Forssen <[email-masked]>
Date: Thu, 14 Dec 2000 18:12:13 -0800 (PST)

On 14 Dec, Bill Sommerfeld wrote:
>   - @-free names beginning with "ssh-" should be allocated using the
>     IETF consensus process.

It seems as if this does not require any names to be changed, so I have
no objections. But we should perhaps fix up the references to some of
the encryption algorithms. Just to refer to the AES submission feels a
bit vague. At least for twofish we could reference the book written
about it "The Twofish Encryption Algorithm: A 128-Bit Block Cipher" ISBN
0471353817.

	/MaF

---

From: [email-masked] (Niels M�ller)
Date: 15 Dec 2000 15:02:12 +0100

> extensions" set) are reserved for private use.

Would it make sense to subdivide the private use area into "local
extensions" (within an organization, site, regardless of
implementation) and "implementation extensions"?

> 2434's "specification required" policy.

To me, it seems odd that many of the names in the current spec (e.g.
channel types and requests, algoritms, signals, etc) are in your third
class, not the second. I would propose either

 * dropping the third class, having only "ietf consensus" and
   "hierachical", or

 * defining the third class as @-free names that begin with "x-".

I haven't read RFC2434 yet, though.

/Niels

---

From: Sami Lehtinen <[email-masked]>
Date: Fri, 15 Dec 2000 19:36:34 +0200

Martin Forssen, on December 14. 2000, wrote:
  : On 14 Dec, Bill Sommerfeld wrote:
  : > - protocol names are divided into three pieces:
  : >   - names with @ signs in them are allocated by the owner of the DNS
  : >     name after the @ sign ("hierarchical allocation" in 2434 terms)
  : >   - @-free names beginning with "ssh-" should be allocated using the
  : >     IETF consensus process.
  : >   - @-free names not beginning with ssh- should be allocated using
  : >     2434's "specification required" policy.
  : > 
  : > Comments?
  : 
  : It seems as if this does not require any names to be changed, so I have
  : no objections. But we should perhaps fix up the references to some of
  : the encryption algorithms. Just to refer to the AES submission feels a
  : bit vague. At least for twofish we could reference the book written
  : about it "The Twofish Encryption Algorithm: A 128-Bit Block Cipher" ISBN
  : 0471353817.

I'll fix that reference.

---

From: Bill Sommerfeld <[email-masked]>
Date: Fri, 15 Dec 2000 12:47:47 -0500

> implementation) and "implementation extensions"?

I'm not sure I like where that's going from an interoperability point
of view.. i.e., if you recognize what extensions to use based on the
version strings, you might wind up in the same mess as http, where
internet explorer claims to be a version of netscape because servers
sent different content based on the browser implementation/version
rather than the browser *capabilities*.

> class, not the second. 

Err, yes.  My mistake.  Some of the names are ssh-foo, some of them
aren't.

> I would propose either

ok, how about:

- protocol names are divided into three pieces:
  - names with @ signs in them are allocated by the owner of the DNS
name after the @ sign ("hierarchical allocation" in 2434 terms)
  - @-free names not beginning with "x-" should be allocated using the IETF
consensus process.
  - @-free names beginning with x- should be allocated using 2434's
"specification required" policy.

Or maybe we should just drop the third class entirely, given that
@-form names are most likely sufficient for experimental, private,
proprietary, etc., use..

comments?  (can we get closure on this quickly?)

						- Bill

---

From: Sami Lehtinen <[email-masked]>
Date: Fri, 15 Dec 2000 20:02:02 +0200

Bill Sommerfeld, on December 15. 2000, wrote:
  : - protocol names are divided into three pieces:
  :   - names with @ signs in them are allocated by the owner of the DNS
  : name after the @ sign ("hierarchical allocation" in 2434 terms)
  :   - @-free names not beginning with "x-" should be allocated using the IETF
  : consensus process.
  :   - @-free names beginning with x- should be allocated using 2434's
  : "specification required" policy.
  : 
  : Or maybe we should just drop the third class entirely, given that
  : @-form names are most likely sufficient for experimental, private,
  : proprietary, etc., use..

Drop the third class. The @-names are sufficient.
IMHO :)

---

From: [email-masked] (Niels M�ller)
Date: 16 Dec 2000 15:50:49 +0100

Bill Sommerfeld <[email-masked]> writes:

> version strings, you might wind up in the same mess as http,

That's not at all how I'm thinking. My scenario is as follows: I
choose a private use message number, say 217, for some special message
in the communication between lsh and lshg (the programs communicate by
means of the unencrypted transport protocol, over a local unix
socket).

Next, some site using lsh or some other secsh implementation chooses a
private use number for somthing else, and also happen to choose 217 =>
trouble when they use lshg.

It seems that using distinct classes for the two types of extensions
(those added by an implementation, and those of local configuration or
hacks) may be a good idea.

/Niels