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

From: [email-masked]
Date: Tue, 25 Apr 2000 14:36:00 -0500

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

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

Jeffrey Altman <[email-masked]>@lists.Stanford.EDU on 04/25/2000
02:00:41 PM

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)

> If you insist on using a "portable" hostbased service name for
applications,
> then I insist on using A SINGLE one.
>
> I.e. I want to require that
>     telnet via GSS-API always use exactly "[email-masked]",
>     rlogin via GSS-API always use exactly "[email-masked]",
>     ftp via GSS-API always use exactly "[email-masked]",
>     nfs via GSS-API always use exactly "[email-masked]"
>
> No alternate trying of "[email-masked]" permitted for the application
> (because this is a Kerberos mechanism-specific thingy).

This is not a Kerberos mechansim specific thingy.  This is a FTP
GSSAPI-KERBEROS_V5 specific thingy.

> If Kerberos wants to share the host/f.q.d.n for several services,
> then it is up to the Kerberos GSS-API mechanism spec to define
> exactly how an when "[email-masked]", "[email-masked]", "[email-masked]",
> etc. are internally transformed into "host/f.q.d.n".

Read my words:

  Your GSSAPI mechanism is NOT to perform any transformations of the
  service name as specified by the application.

> This is exactly broken application behaviour to work around defects
> in the Kerberos GSS-API spec.  Yuck!

There are no defects in the GSS-API spec.  There are no mapping of
service names in the GSS-API specification.  You are creating
something that does not exist.

    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]

-++**==--++**==--++**==--++**==--++**==--++**==--++**==
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: "Douglas E. Engert" <[email-masked]>
Date: Tue, 25 Apr 2000 16:23:53 -0500

> the mech type is Kerberos?

Not clear. What you are really looking for is:

  gss_import_name(&ms, "service@host", GSS_C_NT_HOSTBASED_SERVICE, &name_one);
  gss_canconicalize_name(&ms, name_one, mech_type, &name_two);

  gss_export_name(&ms,name_two, &buffer); 
   -or-
  gss_display_name(&ms,name_two, &buffer, &oid);

Would buffer then have "service/fqdn@realm" with oid = GSS_C_NO_OID
or                     "service/host@realm" with oid = GSS_C_NO_OID 
or                     "service@host"       with OID=GSS_C_NT_HOSTBASED_SERVICE
or                     "service@fqdn"       with OID=GSS_C_NT_HOSTBASED_SERVICE 

Since it is a host based service, the GSSAPI could be using DNS internally to
convert host to fqdn too. 

What one would like to get is the first. 

-- 

 Douglas E. Engert  <[email-masked]>
 Argonne National Laboratory
 9700 South Cass Avenue
 Argonne, Illinois  60439 
 (630) 252-5444
-++**==--++**==--++**==--++**==--++**==--++**==--++**==
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: "Douglas E. Engert" <[email-masked]>
Date: Wed, 26 Apr 2000 15:24:53 -0500

I don't think you understood the point I was trying to make. 

Is there any way to pass in a hostbased service name, and get back
from gssapi what is the actual name that would be used? 

In Kerberos it would be the principal of service/fqdn@realm.
This would allow an application to see how the gss converted the name,
which would include the canoniclization of the hostname and the 
selection of the realm. 

In other words will gss_export_name return the derived principal name,
or will/should it return service@host with the OID of the hostbased service? 

Then what about gss_inquire_context? There I assume it would return 
the principal name, as the contexti had been established.  

Martin Rex wrote:
> Douglas E. Engert wrote:
> BEWARE!  There are some implicit requirements set by the GSS-API spec
> and the definition of some gss_*_name() calls that you don't seem
> to know.
>

OK, the above was an example, the question was what name (and what OID) would
be returned?  

> GSS_C_NO_OID was not allowed as output from gss_display_name() before
> rfc2743.  To allow lazy name evaluation, something that I needed
> in my generic gssapi mechanism layer, a very specific exception was
> added (quoting rfc2743, section 2.4.4 GSS_Display_Name):
> 
>    The GSS_C_NO_OID name type is to be returned only when the
>    corresponding internal name was created through import with
>    GSS_C_NO_OID. It is acceptable for mechanisms to normalize names
>    imported with GSS_C_NO_OID into other supported types and, therefore,
>    to display them with types other than GSS_C_NO_OID.
> 
> In your above example, the first two names would have
> to be accompanied by the nametype OID for a Kerberos Principal name.

But which of the 4 would it be expected to return?

> -Martin

--

---

From: Martin Rex <[email-masked]>
Date: Wed, 26 Apr 2000 21:39:26 +0200 (METDST)

-Martin

---

From: Martin Rex <[email-masked]>
Date: Thu, 27 Apr 2000 09:54:24 +0200 (METDST)

> from gssapi what is the actual name that would be used? 

Yes and no.

After a long and hard battle, gss_export_name() was added which
requires the ability to create a canonical name *binary* blob to
populate ACLs.

Although the GSS-API spec itself does not require a printable canonical name,
most gssapi mechanism implementations will provide you with one anyhow
when you perform the following function calls:

gss_import_name( "service@host", GSS_C_NT_HOSTBASED_SERVICE, &name );
gss_canonicalize_name( name, mech_oid, &cname )
gss_display_name( cname, &buffer &nametype_oid )

For some mechanisms it will work without calling gss_canonicalize_name(),
however portable applications shouldn't rely on this feature.

MIT Kerberos will always return Kerberos principal names from
gss_display_name() accompanied by the GSS_KRB5_NT_PRINCIPAL_NAME nametype
oid, i.e. one can see the result of the transformation that was applied
to a hostbased service name, and this transformation is a performed
mostly locally (don't forget the DNS lookup).  I therefore find it hard
to mimic this exact behaviour with the service name resolution that
Microsoft Kerberos offers.  I don't want to imply that Microsoft's
approach is wrong.  My perception is rather that it was wrong trying
to push the service name resolution down into GSS-API, because this
will not work for host-independent service names, where one needs to
lookup the pair of the transport endpoint and a particular service
instance from a secure naming service.

Why are the printable names not guaranteed to be canonical?
Quoting historic CAT discussion:

>   From: "Theodore Ts'o" <[email-masked]>
>   Date: Fri, 28 Jul 1995 14:14:58 -0400
>   Subject: Re: errata
>
> [...]
>
> I don't know about other implementations, though --- do they make this
> guarantee today?  And is it acceptable to make gss_display_name() always
> return a canonical form that doesn't change no matter what your locale
> is?  Remember, gss_display_name() is supposed to return something that's
> suitable for human consumption.
>
> To take an example, if your X.500 name is:
>
> /Country=United States of America/Organizational Unit=Massachusetts
> Institute of Technology/Organizational Unit=Information Systems/
> Organizational Unit=Distributed Computing and Network Services/
> Common Name=Theodore Y. Ts'o
>
> ...and the locale is set to Spain, wouldn't you want gss_display_name()
> to return something started with: "/Pais=Los Estados Unidos...."?  And
> if you were in France (or your environment variable indicated you wanted
> the French locale), would gss_display_name() would return something like
> "/Pays=...."?

> the principal name, as the contexti had been established.  

Yes and no, see above.
gss_inquire_context() returns a gss_name_t, not a printable.
Use either gss_display_name() or gss_export_name() with mentioned
characteristics.  gss_inquire_context() must return a mechanism-specific
name, so one doesn't need to call gss_canonicalize_name() for it.

> which would include the canoniclization of the hostname and the 

I remember when we installed our application at the MIT in sprint 1996
and Ted Ts'o configured a hostbased service name, but security context
establishment always failed.  Looking at the KDC syslog info we saw that
a service ticket was requested, but for the wrong f.q.d.n.
I suggested checking the hosts file on the Sun workstation we were using
and that turned out to be the culprit.  (It was not the first problem
that we encountered, that's why it took us ~5 minutes to spot this problem.)
It is one of the reasons why I decided to avoid hostbased service names.

I consider Ted a Kerberos wizard, and I really don't want to offend him
by disclosing that even wizards can occasionally get confused by their
own magic for a few seconds. ;-)

In fact, during the past couple of year I found Ted to be an extremely
valuable advisor on many GSS-API and security issues.  In particular I am
very grateful that he always explained to me, exactly and carefully,
when and how I was breaching the GSS-API abstraction when I entered the
discussion of the GSS-API v2 spec during 1995.  And I think I since
have learned a lot about GSS-API and I know precisely what I'm talking
about.

-Martin