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

From: [email-masked]
Date: Tue, 25 Apr 2000 10:14:58 -0500

RFC-1964 (Kerberos V5 GSS-API Mechanism) section 2.1.2 specifies how
to deal with hostbased service names:

Host-Based Service Name Form

   This name form has been incorporated at the mechanism-independent
   GSS-API level as of GSS-API, Version 2.  This subsection retains the
   Object Identifier and symbolic name assignments previously made at
   the Kerberos V5 GSS-API mechanism level, and adopts the definition as
   promoted to the mechanism-independent level.

   This name form shall be represented by the Object Identifier {iso(1)
   member-body(2) United States(840) mit(113554) infosys(1) gssapi(2)
   generic(1) service_name(4)}.  The previously recommended symbolic
   name for this type is "GSS_KRB5_NT_HOSTBASED_SERVICE_NAME".  The
   currently preferred symbolic name for this type is
   "GSS_C_NT_HOSTBASED_SERVICE".

   This name type is used to represent services associated with host
   computers.  This name form is constructed using two elements,
   "service" and "hostname", as follows:

      service@hostname

   When a reference to a name of this type is resolved, the "hostname"
   is canonicalized by attempting a DNS lookup and using the fully-
   qualified domain name which is returned, or by using the "hostname"
   as provided if the DNS lookup fails.  The canonicalization operation
   also maps the host's name into lower-case characters.

   The "hostname" element may be omitted. If no "@" separator is
   included, the entire name is interpreted as the service specifier,
   with the "hostname" defaulted to the canonicalized name of the local
   host.

   Values for the "service" element will be registered with the IANA.

---
Thomas Owusu
Java Security
[email-masked]

Martin Rex <[email-masked]>@lists.Stanford.EDU on 04/25/2000 08:56:52
AM

Please respond to [email-masked]

Sent by:  [email-masked]

To:   [email-masked]
cc:   [email-masked]
Subject:  Re: LIKPEY issues (was Re: host based principal names)

Mike Eisler wrote:
>
> Martin Rex has raised the following issues with LIPKEY
>
> 1. Misuse of GSS_S_NO_CRED to indicate failure to authenticate the user's
>    password.
>
> 2. Use of host-based service names.
>
> 3. No defined mapping between host-based service names to the
certificate.
>
> 4. No specification of mechanism specific forms for the generic name
types.
>
> ---------
>
> With respect to 1, I now agree with Martin. I think it should be changed
> to GSS_S_FAILURE. I propose that when the RFC editor provides me with the
48
> hour window to make editorial changes, that this change be made then. The
> number of characters in both error codes is the same, so this is easy to
do.
> If there is consensus to do this, I will ask the Aread Advisor, Jeff
Schiller,
> for his permission, or if he requires it, re-submit the i-d to make that
> change.
>
> With respect to 2, both John and Ted have made arguments in favor of
> host based service names. I don't see a consensus to change LIPKEY's
> bias from host based service names.

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?

Quoting rfc2228 "FTP security Extensions", Appendix I, 3rd paragraph:

   The client must begin the authentication exchange by calling
   GSS_Init_Sec_Context, passing in 0 for input_context_handle
   (initially), and a targ_name equal to output_name from
   GSS_Import_Name called with input_name_type of Host-Based Service and
   input_name_string of "ftp@hostname" where "hostname" is the fully
   qualified host name of the server with all letters in lower case.
   (Failing this, the client may try again using input_name_string of
   "host@hostname".)

The parenthesized suggestion seems to indicate that hostbased service names
may be broken in Kerberos GSS-API.  Personally, I consider it unacceptable
that "[email-masked]" may not work and I should try "host@hostname" instead.

As long as there is no official Kerberos spec that mandates how to map
gssapi hostbased service names into Kerberos principal names, their use
is non-portable and should be discouraged.

What Kerberos principal name is supposed to be used for nfs?
Your Email seems to suggest that a nfs/f.q.d.n principal is required
for that?

>
> 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.

-Martin
-++**==--++**==--++**==--++**==--++**==--++**==--++**==
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]

-++**==--++**==--++**==--++**==--++**==--++**==--++**==
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: Martin Rex <[email-masked]>
Date: Tue, 25 Apr 2000 19:23:45 +0200 (METDST)

> to deal with hostbased service names:

No, it doesn't.

This section is copied verbatim from rfc2078 and specifies only
transformations at the generic GSS-API level.  It doesn't specify
how to map these names into the mechanism-specific name form
Kerberos principal names.

What I'd like to see in the rfc1964 successor is either a definition
for this mapping or a clear reference of such a mapping in another RFC
(e.g. rfc1510bis).  In particular, I'd like to see whether any service
names must or must not be transformed into the "host" principal.

A requirement for independent principals for every service would be
sufficient for the spec, but it may require lots of additional
service keys to be generated when GSS-API variants of services
are installed.

-Martin