Subject: Re: Section 3.2 of secsh-auth-kbdinteract-01

From: Frank Cusack <[email-masked]>
Date: Thu, 17 Jan 2002 17:18:25 -0800

On Tue, Dec 19, 2000 at 11:19:32AM +0100, Martin Forssen wrote:
> On 18 Dec, Darren Moffat wrote:
> >>Section 3.2:
> > 
> >>   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
> > 
> > Agreed where did 30 come from ? (I'll take a wild guess here and
> > assume it is the number of chars that can be displayed on the screen
> > of a PalmPilot using the default font? (I checked ;-))
> 
> I think I already have countered this example, ut I just wanted to
> comment on the number 30. The number 30 is just an arbitrary number and
> I am not aware of any systems which actually enforces those limits.

30 does seem an odd number[1].  I don't recall the exact device (probably
Palm) but I do believe it was in fact based on some minimal screen width
limitation.  The reason the name and prompt fields were limited is b/c
they are expected to be printed on a single line.

In your example, is it feasible that instead of a single long prompt,
it could be broken up as:

name: "SecurID auth"
instruction: "SecurID auth for [email-masked]"
prompt: "Enter passcode: "

This might be difficult for PAM (sshd might have to know what text to
expect from the underlying PAM module), but would be feasible for "native"
securID auth.

Perhaps a good compromise is to just say that the server should expect
that the client may truncate these fields.

/fc
[1] ha!

---

From: RJ Atkinson <[email-masked]>
Date: Fri, 18 Jan 2002 08:01:35 -0500

> they are expected to be printed on a single line.

IMHO, either the advice "SHOULD be limited to 30 characters" ought to be
deleted xor that should be edited to a much more reasonable value than 30.
Given that most systems, even a Palm, can wrap lines, it isn't clear to me
that any limit is needed.  And "user@domain" strings can be VERY long.
I regularly see long strings (not least since the domain at my office is:
va.extremenetworks.com, with a hostname and username being prepended to 
that
for SSH purposes :-)

Ran

---

From: Frank Cusack <[email-masked]>
Date: Fri, 18 Jan 2002 10:14:42 -0800

> that any limit is needed.  And "user@domain" strings can be VERY long.

The 'name' field is intended to be the window title on GUI clients.
The window title has a limited number of characters that can usefully
be displayed.  If the name is important (eg, tells the user what device
to use out of several he has) and is 256 characters but the client
is forced to truncate (or the window toolkit just truncates) that
important info is lost.

A similar argument exists for the prompt fields.

So I do not agree with you that no limit is needed, however at the same
time it is clear that strings can be very long.

/fc

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 22 Jan 2002 13:34:03 -0500

> is forced to truncate (or the window toolkit just truncates) that

Why should the "name" be the dialog title? Why can't the dialog title be
"SSH Prompt" and let the prompt name be given in full in the dialog
window.

Bear in mind, I have filed a bug report with Sun about CDE's
dtlogin/dtgreet not displaying multi-line PAM prompts correctly, and I
would consider the same behaviour a bug in any other GUI.

> time it is clear that strings can be very long.

There should be no limit. If kbd-interactive seeks to be a carrier of
PAM prompts and responses and PAM places no limit on those, then neither
should kbd-interactive.

> /fc

Cheers,

Nico
--
-DISCLAIMER: an automatically appended disclaimer may follow. By posting-
-to a public e-mail mailing list I hereby grant permission to distribute-
-and copy this message.-

Visit our website at http://www.ubswarburg.com

This message contains confidential information and is intended only 
for the individual named.  If you are not the named addressee you 
should not disseminate, distribute or copy this e-mail.  Please 
notify the sender immediately by e-mail if you have received this 
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free 
as information could be intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain viruses.  The sender therefore 
does not accept liability for any errors or omissions in the contents 
of this message which arise as a result of e-mail transmission.  If 
verification is required please request a hard-copy version.  This 
message is provided for informational purposes and should not be 
construed as a solicitation or offer to buy or sell any securities or 
related financial instruments.