Subject: RE: comments on kerberos-revisions-05.txt

From: "Linn, John" <[email-masked]>
Date: Fri, 14 Apr 2000 13:43:58 -0400

Ted writes:

>    From: Martin Rex <[email-masked]>
>    Date: Tue, 11 Apr 2000 20:15:52 +0200 (METDST)
> 
>    IMHO this is exactly wrong.  hostbased service names are 
> mech-specific,
>    so your code is very mechanism dependent.  It may be 
> unfortunate, but
>    there are no "portable" names at all, so portable 
> applications must not
>    attempt to derive gssapi names algorithmically from transport
>    endpoints.
> 
> From the start, hostbased service names were designed to be mechanism
> independent.  That's why they're in the generic GSSAPI draft.  It just
> so happens that for Kerberos there's a simple algorithmic 
> tranformation
> between the hostbased service name and the Kerberos principal 
> name, but
> I believe the original vision was one where some database might be
> consulted to translate the hostbased service name into a X.509
> Distinguished Name, for example.

Agreed.  The fundamental idea is that each mechanism supporting HBSNs
defines how they map into the naming structures that it uses.  I think
they're an important step towards cross-mechanism portability, and think it
would be a Useful Thing in this regard if more mechanisms take up RFC-2743's
recommendation to support them. 

> 
> I think you're making the argument that the way implementations have
> turned out haven't matched with the vision, but that's different from
> saying that the whole concept of host-based service names was wrong.
> 
> It's true that specifying all three parameters (IP-Addr, Port#, and
> Target-name) is the most general, but I think it's important to have
> defaults whenever possible.  Most people don't specify the telnet port
> when they telnet to a host, and I think most would rebel if we asked
> them to specify the target-name as well!  Especially if it were an
> X.509 Distinguished name.  Can you imagine people typing:
> 
> telnet bitsy.mit.edu 23 
> /C=US/SP=Massachusetts/OU=Massachusetts Institute of 
> Technology/CN=bitsy.mit.edu
> 
> when they want to telnet to the machine bitsy.mit.edu?  I think not!
> (Thus the old joke whose punchline was: "... and when two X.400 users
> meet in a conference, and want to reach each other afterwards 
> ---- they
> use the telephone.)  

Agreed again; for most users, it's highly desirable to defer this
mechanism-specific name processing and knowledge (including, if mutual
authentication is active, the determination of whether the target's
authenticated name appropriately corresponds to the HBSN requested by the
initiator) to be handled within the mechanism. 

--jl
-++**==--++**==--++**==--++**==--++**==--++**==--++**==
This message was posted through the Stanford campus mailing list
server.  If you wish to unsubscribe from this mailing list, send the
message body of "unsubscribe ietf-cat-wg" to [email-masked]

---

From: John Brezak <[email-masked]>
Date: Tue, 18 Apr 2000 08:34:06 -0700

below

> -----Original Message-----
> From: Jeffrey Altman [mailto:[email-masked]]
> Sent: Tuesday, April 18, 2000 5:52 AM
> To: Ken Raeburn
> Cc: [email-masked]; [email-masked]
> Subject: Re: comments on kerberos-revisions-05.txt
> 
> 
> Ken Raeburn wrote:
> > 
> > Doing away with all canonicalization of FQDNs means that 
> either (a) a
> > service would have to be aware of and have keys for every 
> convenience
> > alias the host has, even in other domains outside the control of the
> > maintainers of the host or service, (b) we have to change names
> > somewhere else, such as through canonicalizing principal names or
> > using secure DNS, or (c) the user of such aliases just loses.
> 
> Isn't (a) what Win2000 requires now?

No.

Name-canonicalization provides a mechanism that allows a principal to be
known by many identities, but translated to a single name. The client knows
the principal by many names, but the server is aware of only its canonical
name. The server would only need one key because it has only one real name.
This is documented in the Kerberos referrals I-D -
http://www.ietf.org/internet-drafts/draft-swift-win2k-krb-referrals-00.txt

> 
> Isn't (b) what the Microsoft folk are proposing be done by the KDC?

The Microsoft proposal doesn't use DNS. It requires a database that provides
this information to the KDC. In the Windows 2000 implementation this is
provided by Active Directory.

> 
> Now I am beginning to understand and appreciate why Microsoft would
> like these translations to be done by the KDC.
> 
> 
> 
> 
>     Jeffrey Altman * Sr.Software Designer * Kermit-95 for 
> Win32 and OS/2
>                  The Kermit Project * Columbia University
>               612 West 115th St #716 * New York, NY * 10025
>   http://www.kermit-project.org/k95.html * 
> [email-masked]
> 
>