Subject: San Diego secsh meeting minutes (draft)

From: Bill Sommerfeld <[email-masked]>
Date: Sat, 20 Jan 2001 16:08:29 -0500

Send corrections to me..

Minutes of the secsh working group
Monday December 11, 2000
Notes taken by "RL 'Bob' Morgan" <[email-masked]>
revised by Bill Sommerfeld <[email-masked]>

We first discussed the core protocol drafts, with a quick review of
the open issues and changes from last time.

A.  Core SECSH protocol drafts.

1. Authentication

	User certificates: we don't have any implementation experience yet.

2. Transport

 - optimistic algorithm negotiation
	  Sami will reverse-engineer from ssh implementation and write it down

 - public key algorithms vs certificates
Need to be able to specify PK algorithms and cert formats independently.

 Joseph Galbraith[?] made a proposal: extend names to multi-part eg
x509v3-sign-rsa, x509v3-sign-dss; is that enough? Tero says yes.

Requirement for client to ask for cert from specific CA? No.

Negotiate cert exchange after key exchange?  this adds more round
trips ...

 - AES key sizes

  256 is required, 128 optional, is this overkill?
  only 80 bits of key material from DH anyway ...
  Lisa Yin:  256 is more secure due to larger number of rounds

 - Twofish also needs variable key size

Key size should be in all new alg names; this helps with
interoperability.  We're not going to bother renaming existing fixed
size ciphers, even though we can have aliases: twofish and twofish256
as same.

3. Connection

 - signals:  Is current draft language OK? yes

 - forwarding to multiple X11 displays

An attendee brought up an issue with X11 forwarding to multiple
displays through a single ssh connection; the demultiplexing info gets
lost. Maybe some language is needed on how to fix this in the client,
maybe a and new draft is needed to specify an extension to really fix
it.

4. Architecture

Comment from Jeff Hutzelman <[email-masked]>:
the architecture draft requires "every host must have a host key";
this is unnecessary, and is not needed for kerberos.  Change to SHOULD?

Comment from Jeff Hutzelman <[email-masked]>: Documents are unclear on
why the DH exchange involves the host key..  is it to detect a
man-in-the-middle attack?  What should go there for a key exchange
which doesn't use the host key?

IANA considerations:

Jeff Schiller (Security AD): We have to do pass over all docs for IANA
considerations.

The IANA considerations section still needs review and work [This was
discusssed offline and on the list after the meeting]

B. Extensions

1.  Use of GSSAPI/Kerberos for SECSH authentication and key exchange.

we had impromptu presentations from the authors of several different
individual submissions on tying together SECSH with kerberos and/or GSSAPI.

a. Kerberos/GSS, Joe Salowey, now [email-masked]

  Protocol: 

Two variants:

 o Ties Kerberos into key exchange, by using kerberos to
authenticate the DH exchange (uses kerberos session key to encrypt the
DH hash)

 o pure Kerberos: just use the Kerberos session key, which is faster
than doing DH, but loses PFS.

Possible change to GSS? adds more round trips.  is GSS delegation too
limited?  it's what people use

Is this a secsh WG thing or a krbwg thing? it's a ssh change, not a
Kerb or GSS change, hence secsh.

b. GSS key exchange, Jeff Hutzelman <[email-masked]>

Draft not yet sent to list.

Propose a "null host key" algorithm to deal with host that has no host
key but can do GSSAPI authentication.

Kerberos key type?  no, not for GSS case; there's no need to
distinguish various types of secret keys

add "external" user authentication via
key exchange so a separate user authentication step is not needed.

Consensus at the meeting to make this a WG draft.

c. Joseph Galbraith, vandyke.com

Using GSS for user authentication.

Disallows use of GSSAPI algorithm negotiation (ie SPNEGO), since ssh
already protects negotiation.  Need to express GSS mechs as OIDs, in
capability list; some clarification needed on userauth failure.

Tying them together:

Why two proposals?  Are they complementary?  yes

 - If a client knows host's DSS key, might want to use that and not do
GSS key exchange
 - a GSS mechanism might not support integrity, and therefore not be useful
for key exchange.
 - Might want to do GSS key exchange to avoid the usual MITM problem,
but authenticate user via public key or some other means.

 Text explaining all this will be added to the documents.

Kerberos/GSS issues
  Kerberos vs GSS?  Consensus seems to be for using GSS now.  

However: we should prohibit use of SPNEGO (GSSAPI's algorithm
negotiation mechanism) as secsh negotiation already covers that;
collapsing two levels of negotiation to one prevents certain kinds of
negotiation failures.

What happened to the prior proposal from Tatu?  had too many problems.
The use of Kerberos for password checking on the server is not a
protocol issue and is out of scope for this WG.

2. Keyboard-interactive 

It's  "back from the dead"; Martin has resurrected it and released a new rev.

keyboard-interactive, Martin Forssen

For authentication methods that don't need/want specific support
  just "interact with user" via prompts/responses?
All this happens (as userauth always does) after transport encryption
for Securid, challenge-response tokens, forced password changing
  OTP
Client request includes language tag, device name(s)
  service name, etc
server sends text to be displayed
client responds, etc
this idea tried and rejected before in ssh,
  but this had larger scope, to cover biometric, binary, etc
  so learn from past excesses
Maybe "device" is confusing since could just be "method"?
Need multiple questions in a single round trip?
  PAM could use that, but doesn't require it
Can there be multiple roundtrips?  Yes, like any userauth method
Does this work with WAP phones? (SIM cards?) no.
Biometrics should be done as a separate authentication method
PAM is easy to add ... ?

3. Public-key channel, Joseph Galbraith

ssh public key channel
  replaces public-key file format?

Intent is to solve problem of users getting PKs to servers.
Current draft has problems, will be rewritten
New one should use "subsystem" rather than "channel"?
  yes, subsystem, because adding subsystem is easier (in some implementations?)

Some subsystems give "shell" output where it isn't wanted, which
causes whole thing to fail; is this a broken subsystem implementation?)

Bill:  proposed keyfile format to establish access to new machines; PK channel proposal  only handles managing keys after you authenticate.

The keyfile thing still needs to be done, as standards track.
(many non-protocol things are stds)

Jeff Vandyke will write that draft.

Possibly a separate doc for handling Kerberos/GSS config.