o provides strong security against cryptanalysis and protocol attacks,
o can work reasonably well without a global key management or certificate infrastructure,
o can utilize existing certificate infrastructures (e.g., DNSSEC, SPKI, X.509) when available,
o can be made easy to deploy and take into use,
o requires minimum or no manual interaction from users,
o is reasonably clean and simple to implement.
The resulting protocol will operate over TCP/IP or other reliable but insecure transport. It is intended to be implemented at the application level.
| Done | Submit Internet-Draft on SSH-2.0 protocol | |
| Done | Decide on Transport Layer protocol at Memphis IETF. | |
| Done | Post revised core secsh drafts | |
| Feb 01 | Submit core drafts to IESG for publication as proposed standard | |
| Feb 01 | Post extensions drafts for review | |
| Feb 01 | Start sending extensions drafts to Last Call |
Current Meeting Report
Minutes of IETF52 Secure Shell (secsh) meeting.
[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
Slides
None received.