Subject: kdbinteract-03

From: Frank Cusack <[email-masked]>
Date: Fri, 15 Feb 2002 16:39:56 -0800

Attached is an updated keyboard-interactive draft.  I think the only
contentious point might be the client truncation of name and prompt
fields.  Rather than list the changes side-by-side, I'll just give
a summary of them.  I apologize for the inconvenience.

  - [3.1] Language tag deprecated in SSH_MSG_USERAUTH_REQUEST.

    When originally written, ssh had no provision for language choice
    (and didn't need it -- all protocol exchanges were byte codes).
    However, the better place for this is in the transport, which
    is where it is now.  So I want to deprecate use of it in kbdint.
    The doc says it may be removed in the future, but I don't think
    this is easily done if compatibility with existing implementations
    is desired.  Can someone comment on that?

  - [3.2] Server no longer should limit name/prompt fields.

    Instead, the server should just consider that the client may truncate
    these fields, and choose its prompts appropriately, if possible.

  - [3.3] Client now MUST prompt the user "as follows".

    The end of 3.2 said the client MUST display the name and instruction
    as indicated in 3.3, but in 3.3 it only said SHOULD.  This is a
    disconnect which I didn't like.  So the 3.3 section is now MUST, but
    the description is a little more flexible.

  - [3.3] GUI instructions more flexible.

  - [3.3] More explicit description of echo field handling.

  - [4] Added a second example

    Should I remove "CRYPTOCard" and replace with "Challenge/Response"?
    CRYPTOCard might not like the reference without an attribution.

  - [6] Refs updated

/fc

---

From: [email-masked]
Date: Sun, 17 Feb 2002 22:40:59 +0100 (CET)

>     is desired.  Can someone comment on that?

I do not think it is worth changing this from the current draft since
this is already widely deployed.

>     Instead, the server should just consider that the client may
>     truncate these fields, and choose its prompts appropriately, if
>     possible.

This is  a difference in degree only, but I can live with it.

>     The end of 3.2 said the client MUST display the name and
>     instruction as indicated in 3.3, but in 3.3 it only said SHOULD. 
>     This is a disconnect which I didn't like.  So the 3.3 section is
>     now MUST, but the description is a little more flexible.

I would prefer to have SHOULD at both places as to not limit the client
more than absolutely needed. Somebody might want to build a client which
recognizes some prompts from the server and which knows how to answer,
the MUST forbids that.

	/MaF