Subject: RE: What do we want from sshv2?

From: Joe Salowey <[email-masked]>
Date: Mon, 30 Oct 2000 11:03:09 -0800

I wasn't sure what to do with the naming so I based it on 2712.  I think
leaving the realm determination up to the implementation would be
acceptable.

> One thing jumped out at me when reading this draft.  In section 3
> ("Naming Conventions"), the description of the Realm field is Just
> Wrong.  The realm of a server is often a trailing substring of the
> FQDN of the server hostname, but not always.  The description you give
> (and the matching description in RFC 2712) would not work for
> dcl.mit.edu (correct realm name is ATHENA.MIT.EDU) or
> r93aag001418.sbo-smr.ma.cable.rcn.com (realm RAEBURN.ORG).
> 
> Determining the realm(s) for a given host is one of the weak points of
> Kerberos at the moment.  (No, the Microsoft additions to the protocol
> don't fix the problem, they just move it from all the clients in the
> world to all the KDCs in the world.)  But from the point of view of
> the ssh protocol, I'd say you should just leave that determination to
> the Kerberos implementation (which may use config files, or name
> canonicalization, or something entirely different).  Or the GSSAPI
> mechanism, if you want to switch to that, and just specify
> "host@<hostname>".  The Kerberos GSSAPI mechanism already needs to be
> able to figure out the realm name from the host name for host-based
> services, though this is not addressed in RFC 1964.
> 
> In section 1, is there any reason not to permit and use a subkey in
> the AP_REQ?

No, I just wanted to simplify things.  It would be okay to allow a subkey as
long as we explicitly define that if it is present it is used instead of the
session key in the ticket.

> Ken

---

From: Joe Salowey <[email-masked]>
Date: Mon, 30 Oct 2000 11:18:41 -0800

> > -----Original Message-----
> > From: Jeffrey Hutzelman [mailto:[email-masked]]
> > Sent: Monday, October 23, 2000 1:41 PM
> > To: Joe Salowey
> > Cc: [email-masked]; [email-masked]
> > Subject: RE: What do we want from sshv2? 
> > 
> > Hm.  We seem to have a case of parallel invention.  The key exchange
> > method you describe in section 1 
> > (kerberos-diffie-hellman-group1-sha1)  is
> > pretty much exactly what Sam Hartman and I discussed the week of the
> > August IETF meeting.  The only significant problem I see with 
> > that section
> > is that it does not clearly require the AP_REQ generated in 
> > the first step
> > to have the mutual-required flag set.  It should be obvious 
> > that such a
> > requirement is necessary in order to authenticate the host. 
> >
> 
>True, this is an omission that needs to be corrected.
 
On second thought (after looking at the draft and Ken's message) the mutual
authentication is achieved through the use of veifiaction of the hash which
requires correct decryption of the AP_REQ.

Joe