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

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

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

---

From: Greg Hudson <[email-masked]>
Date: Tue, 25 Apr 2000 15:53:33 -0400

> service name as specified by the application.

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