Subject: minutes from the SECSH working group meeting at the 48th IETF

From: Bill Sommerfeld <[email-masked]>
Date: Fri, 01 Sep 2000 19:50:19 -0400

Minutes of the secsh working group
Wednesday, August 2, 2000
Notes taken by Jeremey Barrett <[email-masked]>, revised by
	Bill Sommerfeld <[email-masked]>

Bill apologized for arranging the secsh meeting on such short notice.
Note that the schedule in charter badly blown (all dates are in 1997).

Working group status:

Bill took over as chair shortly before this IETF meeting.  

The core set of 4 docs are all heavily inderdependent and need to
advance as a unit.  In Dec '97, a last call was put out on these
documents; a couple comments came in, but no action was taken in
response to the comments, and the documents were not submitted to the
IESG.

In theory we could do last call again now and just go, but we're
already aware of some issues which exist, so we may as well fix them
first, and advance the core documents onto the standards track, then
move on to new work.

Bill looked through archive for issues, though it was mind-numbing
work and may have missed a few.

Open issues/proposed resolutions:

draft-ietf-secsh-architecture-05.txt
	dangling reference to ssh-agent draft
		- rip out until agent draft exists.
	anti-dns language in section 4.1
		- rip out section 4.1; dead code.
	iana considerations section ok?
		- waiting for answer from AD

draft-ietf-secsh-transport-07.txt
	optimistic algorithm negotiation	- discuss on list.
	eliminating redundant length fields	- just do it.
	add ssh-rsa key type			- just do it.
	arcfour					- add cautionary text
	key stretching clamps entropy to hash size
		- ok as is given current threat models, but document as such
	packet size fuzz factor
		- document 35000 as arbitrary value larger than
		  uncompressed size
	secrecy of exchange hash
		- document that its best to keep it secret 
	Should concatenated string encoding specify length of each string?
		(transport, section 6)
		- [chair couldn't find context; will take to list]
	DH parameter selection clarification
		- [chair couldn't find context; will take to list]
	dangling references to pkix, spki 
		- both are now rfcs; correct references.

draft-ietf-secsh-userauth-07.txt
	any certificate implementation experience?
		- none yet, but that's ok for now.

draft-ietf-secsh-connect-07.txt		
	signal encoding
		- extend format, include optional string with 
		  signal name w/o SIG prefix.
		SIGBUS -> "BUS"
	need references to X11, POSIX drafts
		- just add them.
	ssh agent forwarding dangling references
		- remove for now until agent draft appears.
		
----

Kerberos Authentication (Tatu Ylonen)

Two new auth methods:
	kerberos - 			  Generate Kerberos AP_REQ

  Server must be able to parse and decrypt request in order to accept
    auth.

	kerberos-tgt
  Passes ticket-granting ticket to server in CREDS message from c->s

  Server MUST use the tgt to create a new ticket to validate it
  Server MAY store it in the credentials cache

First keeps server from getting access to tgt, second gives server tgt

Password method
  no protocol change
  SHOULD allow Kerb password and SHOULD store tgt in credentials cache

User names with realms
  In addition to basic user name, could be user@realm
  The user name MUST be mapped to local name by the server if it supports
      Kerb.
  Might need to change draft to allow @
  % might be used instead of @ on in client and then translated,
    since you can do ssh blah@foo

Folks familiar with kerberos picked a few nits with the proposal.

	- protocol needs to use mutual authentication.
	- credential forwarding needs to either happen after mutual
	  authentication or be protected with the ticket's key.
	- don't need a principal name outside the ticket; just leave
	  login name alone

questions: why not GSSAPI?  
	- misc implementation/portability issues.
	(can't do what ssh needs with current mechanism-independant gssapi)

action: tatu to write up an independant draft based on feedback and
publish.

Other new features:
	(MUST be independant drafts; don't want to hold up core drafts.)

Authentication agent

An old draft exists, but must be checked against implementations,
etc. Won't take long to write a draft, just matter of getting to it.

--------------------------------
File transfer

Current sftp draft is not in any state.  sftp protocol needs to be
documented, reviewed by the working group.  file listing format should
take a look at what the FTP WG did for directory listings.

---------------------------------
"How to write an auth method" 

Suggestion that since there is interest in new auth methods, there should be
some text on how to do this somewhere.

Bill: if someone wants to write one, please do

----------------------------------
DH param negotiation

Draft has boilerplate problems. Author couldn't make it this week
(Nils Provos).  No comments.

---------------------------------
Text file key exchange format info doc

For pubkeys and private keys to allow portability of keys between
       implementations.

Jeff van Dyke volunteered to put together a summary of the 4
variations out there for the list.

----------------------------------------------
Problems with SSHv1

There was a request to publish a spec for sshv1 as an IETF document
(probably going directly to Historic status).  

Tatu proposed, as an alternative, documenting "why not SSHv1" as an
Informational document.

------------------------------------------
Improvided password auth

EKE/SPEKE/SRP interest which ties the password a bit better into the
      crypto and less succeptible to dictionaries. A volunteer exists
      to write a draft on this.

Should look at these on the list.

------------------------------------------------
il8n of usernames

A comment to the list was made that multiple representations could happen, do
we need canonicalization.

Niels Moller suggested waiting for il8n strategy from the DNS people and using 
that.

Bill: other people are attacking this and what they do will probably work,
      the main problem with at least one draft is case sensitivity (especially
      with DNS stuff)
Tatu: If you want to make username something other than canonicalized binary
      crud, you will have to add something to identify which encoding it's
      in, might make sense to add it at this point. If we add it now, the
      installed base might be able to handle it when il8n is actually
      ready.
Bill: for compatibility we could add more magic strings for the tagged username
      format
Tatu: canonicalization could happen at client, and require NO changes to draft
Bill: anyone know of any mine fields here?
Comment: client would need unicode database
Comment: is there a reason UTF-8 wasn't used?
Tero: there are implementations that use "just binary data"

A bunch of UTF-8 discussion...

Comment: possible large sizes, etc
Ted: classic objection to UTF-8 is byte extension, but for usernames, not a
     big deal. The big deal is il8n hell.
Tero: I think canonicalization should be done at server, since it
      knows internal format it wants to use.

Bill: take this to the list

========================================================
Charter

no particular revisions appear to be needed until we decide on what
extensions we want to work on.

--------------------------------------
Schedule

Sep 00   Finalization of core drafts
Oct 00   Last calls
Oct 00   Submit core drafts to IESG
Oct 00   Determine schedule for extensions
Nov 00   Submit extension drafts for discussion
Dec 00   Meet in SD
Sep 01   Submit core drafts for publication as draft standard

Discussion on how long we need for extension drafts; we can discuss
that once the core drafts are finalized.

Authors interested in working on internet-drafts for extensions should
get in touch with the WG chair.

Extension drafts should be done at least a month before the next WG
meeting so that we have time to look at them and discuss them on the
list before the meeting.

					- Bill

---

From: "Jeff P. Van Dyke" <[email-masked]>
Date: Tue, 12 Sep 2000 20:05:57 -0600

> take a look at what the FTP WG did for directory listings.

I'd very much like to see some progress on getting sftp documented.

At the Pittsburg meeting, I believe the understanding was that SSH
Communications was going to prepare a draft.  Is there a time frame
for this?

Is there anything that others can do to help with this effort?

Jeff P. Van Dyke
[email-masked]

---

From: Markus Friedl <[email-masked]>
Date: Wed, 13 Sep 2000 13:01:49 +0200

> I'd very much like to see some progress on getting sftp documented.

here are my notes on the SFTP protocol. -m