On Tue, Sep 02, 2003 at 12:10:32PM -0400, Jeffrey Hutzelman wrote:- Maintaining backward compatibility for the existing deployed base, so that people can transition without a flag day.that's easy if you use a different name for the method.
True. I didn't think that was what you meant by "negotiating within the method".
- Maintaining support for GSSAPI mechanisms which are unable to support GSS_GetMIC() - Not making gratuitous changes to work that's already been done.i don't see why this is necessary.
Well, the key word is "gratuitous". If a change is necessary, of course we'll do it. But I don't like to do the same work multiple times, and I imagine the people implementing this feel the same way. If it looks like the spec is going to keep changing every day, then no one will bother implementing it. I guess part of the source of my concern over this is that several people have indicated they want to take care of this quickly; it's frustrating to think you have concensus, write up a specification, have people starting to implement it, and then discover that the concensus is not as strong as you thought. I know that's not your fault, but perhaps it helps explain where I'm coming from.
- Getting this done in a timely manner. I know there are implementors who are planning on doing releases in the near future which include GSSAPI userauth (you know who you are). I'd like to see those releases include support for the more secure variant, inOpenSSH 3.7 cannot ship a 'more secure variant'. It was even considered replacing "gssapi" userauth with "kerberos-2%ssh.com@localhost".
Just so I understand... Regardless of what approach we choose to solving this problem, you're not planning on making any changes before 3.7 ships?
-- Jeff