Subject: Re: LIKPEY issues (was Re: host based principal names)

From: Jeffrey Altman <[email-masked]>
Date: Tue, 25 Apr 2000 11:06:05 EDT

> OK, I want to add hostbased service names to my W2K Kerberos SSP wrapper.
> Where is the spec for Kerberos that tells me how to map the hostbased
> service name into full Kerberos principal name.
> (i.e. "telnet", "ftp", "rcmd", "rlogin", "pop3", ...)
> 
> My understanding is that many of the traditionally kerberized Unix services
> share the "host/f.q.d.n" key.  What are the rules when using GSS-API?

There is no GSSAPI authentication method for "telnet".  But if there
was it would use "host/f.q.d.n" since that is what the KERBEROS_V5
AUTH method uses.

> > With respect to 3 and 4, the specification is perhaps underspecified in these
> > areas. However, the TLS RFC is similarly underspecified in the corresponding
> > areas. The intent of LIPKEY is to operate in environments that are
> > accustomed to using TLS. It isn't clear how specify LIPKEY to address
> > issues 3 and 3, and not avoid inconsistency with TLS. It would be clearer
> > with implementation experience, right now, I've none to offer. Because
> > LIPKEY is mandatory to implement for NFSv4, I believe that implementation
> > experience will occur. At which time, we could re-visit these issues,
> > and if it possible to drill down on issues 3 and 4, do so, by 
> > issuing an RFC to replace the previous LIPKEY RFC.
> 
> 
> The lack of names in TLS is not a valid reason,
> TLS is a wire protocol, not an API.

I am fairly sure that the comment regarding hostnames and TLS has to
do with the rather confusing ways that hostnames are used in X.509 
certificates.  The rules for verifying a host certificate basicly say 
do (1) but if (1) fails, look for (2) and if (2) fails, you can try
(3) but we do not recommend it.

    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]

-++**==--++**==--++**==--++**==--++**==--++**==--++**==
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: Jeffrey Altman <[email-masked]>
Date: Tue, 25 Apr 2000 14:36:32 EDT

> What I'd like to know is whether I can blindly create a Kerberos
> principal name from a hostbased service name in my wrapper any
> rely on the Service-specific principals to exist whenever a GSS-API
> variant of a kerberized service is built, or whether there is
> a subset of services that should be mapped to the common "host" key.

You should blindly create a Kerberos principal from a host based
service name.

You cannot count on the service specific principals existing.  If I
don't want a specific service to be authenticated I don't create 
keys for that service/host combination.  

You do not perform service name translations within the GSSAPI
implementation.  

> So many documents to read, so little time.
> 
> I hope that this is the first and the last document that permits trial
> and error administration.  

Why?  There are a lot of benefits associated by being able to specify
either a global key for all services or individual keys for each
service.  Obviously, it is an either/or situation.

> TLS still shows its SSL heritage in that authentication is not provided
> in a uniform fashion, they primarily wanted to provide an encrypted channel
> and ignore authentication issues at the application level.
> TLS-based applications often don't care about authentication at the
> TLS level.

Authentication is REQUIRED at the TLS level.  That is why the IESG 
mandated that the anonymous ciphers be deprecated.  TLS without
authentication of the server is insecure and susceptible to man in the
middle attacks.

End user authentication may either be performed during the TLS
negotiations or as a subsequent negotiation after TLS is established.
Telnet and FTP are both examples of services which allow end user 
authentication to be performed either as part of the TLS negotiation
or as a subsequent authentication protocol.  Whichever is used, TLS
provides privacy and integrity protection for the channel but only if 

(1) the server was authenticated during TLS initialization; or

(2) the TLS negotiations are later verified during the subsequent
    authentication

The second method is not described in any Internet-Drafts and is not 
formally implemented.  As soon as the current set of Telnet
Internet-Drafts are approved by the IESG I will publish the I-D
describing how to authenticate an anonymous or unverified TLS 
connection.

---

From: Jeffrey Altman <[email-masked]>
Date: Tue, 25 Apr 2000 15:44:51 EDT

> What about GSS_Canonicalize_name? Is that supposed to perform
> transformation from "service@fqdn" to "service/fqdn@realm" when
> the mech type is Kerberos?

Exactly.  That is the conversion from host based service name to 
Kerberos principal name.  There are no mapping of the service name
from one value to another.

---

From: Jeffrey Altman <[email-masked]>
Date: Tue, 25 Apr 2000 16:08:07 EDT

> On what authority do you say this?  It doesn't make sense for the
> application to be worrying about the service namespace of the
> mechanism, since the whole point of GSSAPI is to abstract away the
> details of the mechanisms.
> 

Whether the application uses "[email-masked]" or "[email-masked]" is not
part of the GSSAPI mechanism.

By saying that the GSSAPI mechanism is supposed to perform this
translation would require that everytime someone decides to implement
GSSAPI in a new application (for instance, "telnet"), every GSSAPI 
implementation would have to be updated to support the new entry.
This is what makes no sense.

The service name to be used is defined by the application protocol 
not by the GSSAPI.  The exact same problem exists in applications that
use Kerberos without the GSSAPI.  You need to know what service name
is used on the host.

I know of several organizations which use alternate service names for
Kerberos authentication instead of "host" because they want to be able
to authorize access to some services and not all services on a given
host.  That is why my applications allows the end user to specify the
service name to be used when authenticating to a host.  It would be 
completely inappropriate for the GSSAPI to decide that it does not
recognize "foo" as a service name and therefore translate it to
"host".