Subject: Re: hostbased service names (or not)

From: Jeffrey Altman <[email-masked]>
Date: Thu, 27 Apr 2000 10:15:36 EDT

> Wow - Great!  You seem to be a mighty wizard.

And now you are just being condescending.  

> Please share the wisdom with us how to map between hostbased service names
> and X.509 certificates, because none of us has been able to come up
> with a solution so far.

It is the same problem that exists with regards to mapping userid's to
X.509 certificates.  Given the current lack of an infrastructure of
trust and real standards for what goes into a certificate it is not
possible to receive a certificate issued by a semi-trusted third party
and really accept the data inside the certificate.

Because of this fundamental problem which I have seen handled in
different ways at different organizations, all of my applications 
provide either callbacks or other user defined implementations to
perform the mappings from certificates to entities.  Many sites issue
certificates without any identifying information and simply perform
database comparisions from the cert to the entity. 

In someways this illustrates my point.  I understand that GSSAPI is
supposed to give an application designer the appropriate credentials
for a given "hostbased service name".  If I make a connection to a 
host on port 3000 what service am I using?  

Is there a mapping from port number to service?

Some might say 'yes'.  Simply call getservbyport() and use the service
name that is returned.  But I know of plenty of sites that run
services on non-standard ports.  

If I have established a connection on a port that implements a custom
application protocol and I decide to use GSSAPI to authenticate; and 
I call my service "frisbee".   Since "frisbee" is not a IANA
registered service name what is GSSAPI (in your opinion) supposed to
do?

Shouldn't it attempt to find a matching credential for that hostbased
service name  "[email-masked]" and fail if it can't?

Is it up to the application designer to determine which credentials 
s/he wants?

If I as the application request the credentials for "[email-masked]"
and GSSAPI can't get them; or the negotiation fails; doesn't it make 
sense that I might want to try an alternate route to getting my job
done?

Maybe my rules say 

 . first attempt to use the really efficient "frisbee" service

 . but if the service is not accessible use "rsh" and do things
   some other way

In that case, I would (according to you) as for "[email-masked]"
and then "[email-masked]".  This is not any different by an application
first attempting to use "[email-masked]" and then using "[email-masked]" 
as a fallback.

Depending on the model, it may be that the "[email-masked]"
credential is very specific to the service that it can be used for
and provides higher levels of access whereas "[email-masked]" is
more general purpose and provides a lower level of access that might
happen to be sufficient for the application.  It doesn't matter 
whether these credentials are Kerberos principals, X.509 certificates,
or anything else.  

    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: Martin Rex <[email-masked]>
Date: Fri, 28 Apr 2000 20:08:38 +0200 (METDST)

> database comparisions from the cert to the entity. 

I think it is just fine to map an opaque certificate directly to
a user via a database/directory.  I don't know the details, but isn't
this actually how certificate-based logons work in W2K with the
Active Directory?  The drawback is, that one needs to get hold of
each certificate to put it into the database and verify the
association of a human being with a user account oneself.

Keep the opaque certificate in your mapping table.  Basically
you map from the contained public key and ignore everything else.

   - PROs:  - it is independent of the CAs naming convention and policies,
            - you don't need to trust the CA
            - you don't need a particular(ly expensive) CA
	    - when the keypair was not created by the CA, only the
              public key is signed by it, then this mapping is even
              secure when the CA is corrupted
            - you don't need a PKI
	    - you can yourself control the quality of the association
              between a user (account) and a certificate, independent
              of the policies and qualities of the CAs whose certs
              your users are using.

   - CONs:  - certificate rollover (expiration/loss/replacement)
              in your mapping table requires administrative action
            - if you're operating PKI-less, you may have to implement
              manual access revocation procedures.
            - you have to check the association of a user (account)
              with a certificate yourself, because there is no common
	      pool of (trusted) information that you can use.

> services on non-standard ports.  

We run services on >600 non-standard ports  :-)

The TCP port that you use shouldn't really matter, the application
protocol that you use is the one that should count.

On Unix machines it is quite easy to run sshd (or telnetd/rlogind/...)
on an arbitrary port, just by adding an extra line to /etc/inetd.conf.
One might be doing it to get around access list on some routers...

> registered service name what is GSSAPI (in your opinion) supposed to

The gssapi mechanism spec of the mechanism that you're using should
tell you how/whether this can be mapped to a principal at all.

If you were going to use one of the existing SPKM gssapi mechanisms,
it wouldn't really matter, since every conceivable hostbased service
name would fail equally.

Having the user or administrator supply the names of targets and
credentials in full-length mechanism-specific syntax will work
in all cases, all environments and with all mechanisms.

> Is it up to the application designer to determine which credentials 

I think it should be up to the human being that installs the
application to create, install and configure the credentials.
This is what our application requires and it has since worked with
every gssapi mechanism that popped up.  Being able to plug an
arbitrary never-having-seen-before gssapi mechanism into an
application and getting it run without having to recompile the
application is what I consider application "portability" in the
GSS-API sense.

The devil is in the details, because the GSS-API spec is extremely
flexible in some areas.  If for example a programmer of a non-trivial
application only had exposure to a SPKM gssapi mechanism, he may be
surprized when tries to use the product with the Kerberos gssapi
mechanism and it doesn't work because the executables started by
the user find themselves unable to accept security contexts.
In a distributed environment, this limitation of rfc1964 might
be a showstopper.  Btw. the Microsoft W2K Kerberos SSP doesn't
have this limitation. ;-)

> sense that I might want to try an alternate route to getting my job

Our application guys even circumvent or disable security to get
their job done when they run into "access denied" problems.
"Don't force it, use a bigger hammer!"

Security-wise it's a bad idea to promote trial-and-error approaches.
Every time when access of a remote file on Windows NT via UNC-syntax
fails with a logon failure, it will increase the logon failure counter
by 3, because under the hood it performs some retries (I don't know
the exact details).  Our domain admin has set a lockout count at 12,
and some components of our distributed build environment access remote
files via shares.  I don't know why exactly it happens, but in
the past few month my account was locked out 5 times because of
some strange bugs in Microsofts networking that sometimes cause
network logon failures.  And since the make environment requests
files via UNC from 5 different servers, using the build process once
during such a strange network confusion will lock out my account. :-((

> first attempting to use "[email-masked]" and then using "[email-masked]" 

... the shotgun approach: Kill 'em all, let's God sort them out.
It is a bad idea to specify an try-and-error approach when it can
easily be avoided.

> whether these credentials are Kerberos principals, X.509 certificates,

Which credentials can be our should be shared is extremely dependent
on the capabilities of the gssapi mechanism as well as the habits
and policies of the system administration.  The application should
neither make assumptions nor set requirements in this area, because
that will definitely reduce the portability across gssapi mechanisms
and computing environments.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Fri, 28 Apr 2000 21:34:31 +0200 (METDST)

> 	      pool of (trusted) information that you can use.

Oooops, what I totally forgot to mention:

This mapping of opaque certificates into users is not an option
for GSS-API mechanisms.  GSS-API is modeled to perform name-based
authentication.  One could define a nametype that used base64-encoded
X.509 certificates, but no human would want to type these in. ;-)

One could reduce it to simply the base64-encoded public key within
the certificate, but those would still be hard to recognize and relate
by humans.  Maybe the concatentation of the subject_dn with the
base-64 encoded public key?

When not including the public key in the cert, then you suddenly
have to carefully review and rely on all policies of all CA (trees)
that you accept.  Better run your own CA, trust only that, and issue
certificates for everbody who needs one.  Then you may get along
with only mapping the subject DN or even only a particular attribute
of the alt_subject name.

-Martin