Minutes of IETF52 Secure Shell (secsh) meeting.

[Bill Sommerfeld <sommerfeld%east.sun.com@localhost>]

[Notes taken by Michael Richardson and Jun-ichiro "itojun" Hagino ]

Minutes from Secure Shell (secsh) meeting of IETF 52 in Salt Lake City:

- Agenda bashing/WG status
- last call, core drafts

WG Status
	Last call started on core drafts.
	One issue remaining, which is a typo.

draft-ietf-secsh-architecture-11
transport-11
userauth-13
connect-14

Core issue
     - formatting errors in transport draft.
     - some references have been added.
     - no need to repeat last-call for this.
     - more text for @domain extensions.
     - clarification for advice for setting environment variables.
     - client to bind to port 0 to let server decide on port #.

New issue - multiple outstanding userauth requests.

    - problem with multiple outstanding userauth requests.
      - comes from GSSAPI, where successful authentication requires multiple
	round trips.
      - if a client has started more than one userauth requests, how does
        one know which request the response applies to?

    Joe: if the client sends only first round responses, the ordering is
	 maintained, but if there are multiple rounds, then the ordering
	 can not be determined.

    Bill: ambiguity when there are multiple rounds required.
    Bill: can we insist that client send in order as well?
    Joe: that kills multiple requests.
    - the server interprets new userauth's as aborts of previous requests.
    
    If one asserts the rule that every reply gets only one response, then
    we can fix this, but this breaks GSSAPI, but GSSAPI can work around it.
    
    Eliminating multiple userauth's requests would solve this.

    Bill: Anyone object to this? 
    Joe: Neils Mueller (absent) may be using this.   

    Discussion about different methods and whether or not different methods
    of operation are in fact using multiple userauths.

    Markus: what is the gain in having multiple outstanding requests?

    Bill: the rational is to cut down the number of round trips.
    
Documenting historic identifiers
    - historic algorithm use (des-cbc).
    - other identifiers in deployed implementations?
    Marked as historic.
    RFC2026: specs can be historic, and applicability statements can
	      be "Not Recommended"; one document can be both.

    No comments - issue is resolved this way.

Extension drafts
	  - Generic Message Exchange Authentication for SSH
		    (auth-kbdinteract-02.txt)
		    believed to be ready for last call.
		    
          - GSSAPI Authentication and Key Exchange
		   (gsskeyex-02.txt)

		   concern about errors on the server be returned properly
		   to the client.
		   Clarification about what happens after the last client
		   message has been sent, and it needs an ACK, but there
		   isn't space for one.

		   If the userauth multiple-outsanding-requests issue is 
		   not resolved in the core draft, then GSSAPI may have 
		   to resolve it.

	  - SECSH Public key File Format
		  (publickeyfile-02.txt)

		  ready for last call? taken to list.

	  - Diffie Hellman Group Exchange
		   (dh-group-exchange-01)

		   ready for last call? Think so. 	  	   
		   two implementations out there.

          - Storing SSH Host Keys in DNS
		    (dns-key-format-00.txt)
		    Using DNSSEC extensions to store SSH host keys.
		    Current KEY RR is not sufficient to do what we need
		    to do. APPKEY is a proposed solution.

		    Want to approach this from a different point of view,
		    what do application need in the way of key distribution?

		    Concern was raised about security of DNSSEC server.

	  - File Transfer Protocol
		 (filexfer-02.txt)
		 
		 more work need.
		 - string vs numeric user ids?
		 - how many reinvented wheels?

		 Much Unix centric pieces in the draft. 
		 Even under Unix systems, it is used between disparit
		 spheres of control, so that numbers are meaningless.

		 Conclusion get rid of long names.

		 MCR asked for attribute to say whether or not the 
		 file/directories are writable.

Future directions		 
       - an agent forwarding would be nice.
	    Darren has volunteered to write this draft.

	    It was in v1, but was omitted from v2. If there are other vendors
	    who want to have interoperable versions, contact Darren.

       - review milestones
    
------- End of Forwarded Message