Subject: Re: comments on kerberos-revisions-05.txt

From: Jeffrey Altman <[email-masked]>
Date: Mon, 3 Apr 2000 19:43:54 EDT

> It seems clear to me that the desired end state is having realm names be
> case-preserving in use and case-insensitive in matching, which is to say,
> *exactly* like host names in DNS.  I think the dns-locate functionality
> serves to further justify this approach.  Can someone explain in detail
> (or point to existing explanations) why requiring all-upper-case realms is
> a better end state?

Requiring all upper case realms hurts the fewest number of people.
The number of realms that are all upper case significantly surpass the
number of realms which use lower or mixed case.  Upper case realm
names have been recommended practice since K4 days.  Making them
required is an easy solution to the case sensitivity issues of realm
names. 

The reason that Realm names are case sensitive is due to its use as
a seed to ciphers to ensure that the password "password" has a
different hash for MY.REALM than for YOUR.REALM.

For realm names to be entered in a case insensitive manner it must be
possible for the client to determine which case rules are to be
applied to the specified realm.  This information is not available 
via dns-locate.  The reason the client must be able to know the case
of the realm prior to contacting the KDC is so that it can properly 
generate pre-auth data and/or be able to decode KDC responses.  

If you have suggestions on how the case rules for a specific realm 
can be determined, please propose them.

    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: "RL 'Bob' Morgan" <[email-masked]>
Date: Mon, 3 Apr 2000 17:41:22 -0700 (PDT)

> can be determined, please propose them.

How about this:

In the case of a client using dns-locate methods to do the host->realm
mapping, the correct capitalization of the realm name is already found in
the value of the TXT record that the client looks up to do this mapping:

    _kerberos.foo.example.com.        IN      TXT     "Example.Com"

If the client has obtained a realm name in some other fashion (eg a user
has typed in "kinit [email-masked]"), and is going to use SRV records to
find the KDCs (or kpasswd servers, etc), it can look up the TXT record
corresponding to the realm name:

   _kerberos.example.com.             IN      TXT     "Example.Com"

and obtain the correct capitalization in just the same way.  (This does
overload the entry containing the realm mapping for the host
"example.com"; presumably in practice it would just about always be the
case that if there is a host "example.com" and a Kerberos realm
"example.com" that the host services would be in that realm.  But if
separation is desired, there could be an additional record, eg:

   _kerberos_realm_name.example.com.   IN      TXT     "Example.Com"

to supply precisely this bit of info.)

If the client is using a standard config file, it can use case-insensitive
matching to search that config file for realm names.

The only lose (that I can see) from current practice in all these cases is
that "example.com", "Example.Com", and "EXAMPLE.COM" can't be separate
realms.  I hope we can agree that this occurs very little in nature; and
the upper-case-only rule eliminates this too, so it isn't any better.

I don't see any additional security issues in looking up case-info via
DNS, vs looking anything else up in DNS.

Any reason why this wouldn't work?  Is that really all it takes?

 - RL "Bob"

---

From: Ken Raeburn <[email-masked]>
Date: 04 Apr 2000 17:50:45 -0400

> DNS, vs looking anything else up in DNS.

I think it yields the same exposures as mapping host->realm via DNS,
but only if you don't verify that it's the same string (aside from
case conversions) as the original.  If that check is done, only DoS
attacks should be left.

I would suggest a different name than _kerberos since there's a chance
that realm FOO.BLAH.ORG exists but host foo.blah.org isn't in it.

> Any reason why this wouldn't work?  Is that really all it takes?

Sounds good to me....

---

From: "Douglas E. Engert" <[email-masked]>
Date: Sun, 09 Apr 2000 18:55:35 -0500

With all the discussion this week on the case of the realm name, and how
to add case sensitive names to DNS, I would like to ask what it would 
take to say realm names are case insensitive? 

I agree with Bob that lower case realm names are widely used, and can
not be dismissed easily. (We have a lower case realm name.)

As I understand it, the main problem comes from using the realm 
name as a salt where the case of the salt is significant, and the
realm name is needed by preauth.  But don't all preauths have the 
ability to return the correct salt in an error message if it was not
correct on the first try? In any case, the only time the client
needs to know the salt is when using a password to get a ticket, 
or to change a password. In these cases the user is talking to 
his local realm, and could even specify the case sensitive realm
for the salt as part of the principal name as input to kinit or 
kpasswd.  

So in other words, the salt would not strictly be the realm name,
but a case sensitive string derived from the case insensitive realm name.
By default it would be determined by the principal name. 

Having case insensitive realm names, would simplify any DNS issues,
and eliminate the proposals to add a DNS function to get the case of the
realm. It should also address any problems of the realm in an ACL. 

I would also not expect there are two production realms which differ
only by case. Does anyone know of any? Are there any realms with mixed case
realm names? 

-- 

 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: Ken Raeburn <[email-masked]>
Date: 10 Apr 2000 01:36:50 -0400

> By default it would be determined by the principal name. 

Yes, I think that could probably work.  Though unless we specify some
case conversion as part of generating the salt for a given realm,
we'll *always* have to return the salt info.

> realm. It should also address any problems of the realm in an ACL. 

That's not the only instance in which the case matters.  Currently,
the non-realm part of the principal name is also case sensitive, and a
realm name is used in the non-realm part of a ticket-granting ticket's
service name.  Unless we make the entire principal name
case-insensitive, we still need to be able to determine the correct
case.

So, can we make principal names case-insensitive?  Certainly email
addresses are case-insensitive.  But in other contexts, OS user names
are often considered case sensitive.  Are IANA-assigned service names
considered case-insensitive?  How else are principal names chosen in
various deployments?
-++**==--++**==--++**==--++**==--++**==--++**==--++**==
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: Clifford Neuman <[email-masked]>
Date: Sun, 9 Apr 2000 23:04:01 -0700 (PDT)

Before this discussion gets out of hand, let me make it clear that
changing names in Kerberos to be case insensitive is a mistake.  The
reasons for case sensitivity in principal and realm names were
described in my message of April 3rd, which I repeat below for easy
reference.

It is acceptable to provide external means to appropriately choose a
default case for particular principals, and to map case when entered
by the user at login.  Such changes could be implementation specific
and would not involve a change to the protocol, nor the interpretation
of the protocol.

Clifford Neuman

  Date: Mon, 3 Apr 2000 16:20:42 -0700 (PDT)
  From: Clifford Neuman <[email-masked]>
  To: [email-masked]
  CC: [email-masked], [email-masked]
  Subject: Re: comments on kerberos-revisions-05.txt

  Using upper case DNS realm names is not a change, but instead the way
  things have been all along.  Early on it was decided that names in
  Kerberos needed to be case sensitive because we did not have control
  over the environments within which Kerberos would be used.  

  If names were not case sensitive, then use of Kerberos in an
  environment that had case sensitive names would be difficult.
  However, case sensitive names in Kerberos were easily used in
  environments where names were not case sensitive, simply by adopting
  the convention on which case would be used in the Kerberos encoding.

  Choosing case preservation, but insensitive matching was not an
  acceptable solution, because in such environments where case
  sensitivity mattered, the consequence for the security of the system
  could be significant.

  As to whether the convention chosen was for DNS realm names to be
  upper case or lower case, that was decided a LONG time ago.  The chose
  was upper case - I do not recall the reason offhand - but
  unfortunately it wasn't a significant reason and it might have even
  been arbitrary.  

  Now, their might have been a failure to communicate this choice, but
  it was the choice and it is not an issue that can be revisited at this
  time.  Though it doesn't constitute communications of the convention,
  all DNS based realm name examples in RFC1510 were upper case.  That
  would strongly argue against an imposition of lower case as the
  convention.   

  Clifford Neuman

---

From: "Douglas E. Engert" <[email-masked]>
Date: Mon, 10 Apr 2000 10:06:28 -0500

> described in my message of April 3rd, which I repeat below for easy

I was bringing this up, as we seam to be bending over backwards, with trying
to use a case insensitive service, DNS, when it is still not clear to me
why Kerberos has to have case sensitive names, and adding more DNS lookups
to get the case of the realm may be counter productive. 

I have some more questions about that below. 

> and would not involve a change to the protocol, nor the interpretation

I would argue that changing the case at login, is stretching it, 
to abide by the "convention". The user my have wanted the lower case name. 
As a convenence you may determing that the closest match to an existing realm 
is uppercase and change it for the user, but you should first check if the user
typed a valid case sensitive realm name. (The only place we ever found 
this to be a problem in the MIT code was in an older Windows cns.rc where we 
removed the ES_UPPERCASE flag of the edit box dialog box.)

>   environment that had case sensitive names would be difficult.

But this is the same situation DNS and email names have,
i.e. they are case insensitive and they don't seam to have these problems. 

>   the convention on which case would be used in the Kerberos encoding.

But it was a "convention" and names are still case sensitive, so therefore you 
could use lower or mixed case realm names and still be with in the specifications. 
We now have a large community using lower case realm names. 
 
>   sensitivity mattered, the consequence for the security of the system

Could you give some example here? What if we are only talking about the
realm name being case insensitive. 

>   would strongly argue against an imposition of lower case as the

I am just asking the question. It there some time when it might be revisited?
Is there any thing we could do now to make it easiter to reviit this in the 
future? Users have become accustomed to using lower case with any network names,
like host, e-mail and URLs, which are case insensitive. 

I would also not expect there to be two production realms where the names
differed by only case. So if the specifications were changed, this should
not be a problem. There could be others, that is why I was just asking.  

--

---

From: Clifford Neuman <[email-masked]>
Date: Mon, 10 Apr 2000 08:25:52 -0700 (PDT)

Date: Mon, 10 Apr 2000 10:06:28 -0500
   From: "Douglas E. Engert" <[email-masked]>

   I would argue that changing the case at login, is stretching it, 
   to abide by the "convention". The user my have wanted the lower case name. 
   As a convenence you may determing that the closest match to an
   existing realm is uppercase and change it for the user, but you
   should first check if the user typed a valid case sensitive realm
   name. (The only place we ever found this to be a problem in the MIT
   code was in an older Windows cns.rc where we removed the
   ES_UPPERCASE flag of the edit box dialog box.) 

I am not arguing that realm names must be upper case, simply that the
matching of realm names to determine equivalence of a principal
(e.g. when checking an access control list) must be case sensitive.  I
still feel that the convention should remain as upper case realm names
when the realm name is based on a domain name.  However, mapping case
at login to the "best" match seems a completely reasonable thing to do.  

The only other place where mapping to other than the conventional case
might occur would be when looking up the realm of a server principal.
So long as you have a secure means to do that mapping, I don't see a
problem.  This mapping operation is the same one needed when the
hierarchy of domain names does not precisely match the hierarchy of
realm names - and unfortunately there are weaknesses in the some of
the ways this mapping is done presently.

DNS was able to define it's own name space (in fact, it did define a
new name space, and all the existing hosts on the Internet had to
change their names).  As to e-mail names, you are welcome to argue
that issue with Jerry Saltzer.

If an access control list were set up and entries matched in a case
insensitive manner when a realm name was generated by systems with
case sensitive names, and where two realms shared the same name except
for case differences, then access would be granted even though the
principal was not the one intended.

   >   time. 

   I am just asking the question. Is there some time when it might be
   revisited? Is there any thing we could do now to make it easier to
   revisit this in the future? Users have become accustomed to using
   lower case with any network names, like host, e-mail and URLs,
   which are case insensitive.  

I don't think that revisiting the specific convention makes sense.
However, as long as the mechanisms to securely map to the appropriate
realm name exists when looking up server principals, as well as when
initially logging in to the system, then the convention becomes less
relevant.  Some of the name referrals proposals out of Microsoft would
in fact provide such mapping in a secure manner (i.e. the KDC can
refer you to the correct realm regardless of the case).

Clifford Neuman

---

From: Russ Allbery <[email-masked]>
Date: 10 Apr 2000 14:48:28 -0700

> considered case-insensitive?  How else are principal names chosen in

E-mail addresses are not case-insensitive on the LHS except for the
special case of "postmaster".  Local systems are permitted to treat them
as such, and most of the major MDAs do so, but RFC 822 is quite explicit
about the fact that the LHS is case-sensitive and [email-masked] and
[email-masked] may be completely different mailboxes.

I do know that some people use this, although not very many.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

---

From: Mike Eisler <[email-masked]>
Date: Mon, 10 Apr 2000 15:27:12 -0700 (PDT)

> I do know that some people use this, although not very many.

Why can't the parts of the principal name that refer neither to a realm nor a
host or sub-domain of realm be case sensitive, and the other parts case
insensitive. E.g.

	[email-masked] [email-masked]

are distinct, but

	[email-masked] [email-masked]

are not. For instance specific examples:

	host/[email-masked] HOST/[email-masked]

are distinct, but

	host/[email-masked] host/[email-masked]

are not.

---

From: [email-masked] (Johan Danielsson)
Date: 11 Apr 2000 01:11:52 +0200

Mike Eisler <[email-masked]> writes:

> Why can't the parts of the principal name that refer neither to a
> realm nor a host or sub-domain of realm be case sensitive, and the
> other parts case insensitive.

Why bother? Having some parts case sensitive, and some insensitive is
just going to cause a whole lot of confusion.

Realms are *not* mail domains, and principals are *not* email
addresses. The fact that you in some, perhaps even most, cases can
convert from one to the other by changing case is irrelevant.

I think that it's perfectly ok to have some piece of user interface
that converts from a mail address to a principal, and that the KDC
might assist in this conversion. Infact this is exactly what the
`local realm' is for -- so you can enter your username (which is also
not a principal), and have the system expand it into a principal.

Please don't try to make it mandatory that every part of the already
complex protocol should be able to handle arbitrarly composed
principals that might look like some address.

/Johan

---

From: Ken Raeburn <[email-masked]>
Date: 10 Apr 2000 21:07:01 -0400

> [email-masked] may be completely different mailboxes.

Well, you learn something new every day... :-)

Certainly I expect most people's experiences to suggest to them that
they are "always" case-insensitive though.
-++**==--++**==--++**==--++**==--++**==--++**==--++**==
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, 11 Apr 2000 10:44:21 +0200 (METDST)

> 	host/[email-masked] host/[email-masked]

Beware!  MIT Kerberos will distinguish the latter two names -- they're
not equivalent at all.  Don't confuse the hostname canonicalization
that is applied to hostbased service names (i.e. [email-masked])
with the case sensitivity of Kerberos principal names.  You can add
the principal "host/SERVER.widget.com", however it will probably never
get used by the majority of native Kerberos applications that specify
hostbased service names as target names.  When using a Kerberos
principal name as target, no transformations are applied to the
hostname that is part of the name, AFAIK.

-Martin

---

From: Mike Eisler <[email-masked]>
Date: Tue, 11 Apr 2000 02:38:21 -0700 (PDT)

> Beware!  MIT Kerberos will distinguish the latter two names -- they're

Believe me, I know.

> hostbased service names as target names.  When using a Kerberos

Yes, that's what I thought too.

> hostname that is part of the name, AFAIK.

Which I think is broken. Consider a real world application, like
NFS. The NFS client does:

	mount -o sec=krb5 server:/export /mnt

This NFS client uses GSS-API, and so needs to establish a GSS-API security
context between itself and the target, "nfs@server" via the Kerberos V5
mechanism. "nfs@server" is merely the canonical RFC 2078 name. The RFC 1964
name is "nfs/server.<dns_domain>@<REALM>", which the initiator has
to expand "server" to in the following steps:

	1. prefix "nfs/"
	2. append the fully qualified domain name (FQDN) of "server"
	3. append the "@<REALM>" as defined by the rules in krb5.conf.

Depending on how resolv.conf is configured, the FQDN of "server" can take on
different forms of case. The work-around is in step 2 to always convert of
FQDN of "server" to lower case. However, if that's what one must do (and both
RFC 1510 and draft-ietf-cat-kerberos-revisions-05.txt say that's what one must
do, see section 7.2.1), that seems rather silly. Kerberos V5 is relying on a
case insensitive, case preserving directory called DNS; Kerberos V5 should
simply follow the conventions of DNS rather make up its own which lead to
implementation bugs in step 2. This is what my suggestion 

And by the way, telling the user that the he MUST when invoking the mount
command, specify a lower case, FQDN for "server" is a non-starter. 

Johan Danielsson writes:

> > insensitive.

> Why bother? Having some parts case sensitive, and some insensitive is

Because as is clear from the discussion, some people want to preserve the case
of realm names, host names, and domain names, and some people want one or more
of these names to be case insensitive.

> just going to cause a whole lot of confusion.

As opposed to what current implementation practice is? My approach eliminates
all the confusion by adhering to the case preserving, case insensitive
semantics of the underlying directory, while still adhering to the
case sensitive semantics of RFC 822.

	-mre

---

From: Martin Rex <[email-masked]>
Date: Tue, 11 Apr 2000 16:33:57 +0200 (METDST)

Hi Mike,

Mike Eisler wrote:
> mechanism. "nfs@server" is merely the canonical RFC 2078 name.

"nfs@server" is a so-called "hostbased service name", as described
in section 4.1 of RFC-2743.  Although defined in the generic GSS-API
spec, this nametype is understood only by a few gssapi mechanisms
and therefore non-portable.  

The procedure how to canonicalize the hostname part of a hostbased
service names is specified in section 4.1 of RFC-2743. It explicitly
says that the fqdn must be mapped to lowercase by the canonicalization
(i.e. after DNS lookup).  It does not define, how the two parts
of the hostbased service name (after canonicalization) are being
used to derive the real name of the target in a form that is
acceptable to the GSS-API mechanism.  For Kerberos 5 there is
a convention to derive a principal name like this:

    <service>/<lowercased fqdn>@<REALM>

How to derive the <REALM> is not actually specified in rfc1964,
I think.

> The RFC 1964

Could it be that they forgot to put the "lowercasing after DNS lookup"
into rfc1964?  It is in rfc2078 and rfc2743, and because Kerberos is
using the same OIDs as in rfc2744, the definition of rfc-2743, section 4.1
should apply (as well).

-Martin

---

From: Mike Eisler <[email-masked]>
Date: Tue, 11 Apr 2000 09:32:40 -0700 (PDT)

> and therefore non-portable.  

Given that there are but a few gssapi mechanisms, I'm not sure I understand
the non-portability comment. In any case, portable or not, host-based service
names give one the best opportunity to build security mechanism independent
applications, so nfs uses them.

> says that the fqdn must be mapped to lowercase by the canonicalization

OK, but when the lower-cased fqdn is passed to the implementation of rfc1964,
that opens a window for fqdn to become upper case, which is what I've observed
in at least one implementation. The point being that DNS is case-insensitive,
and so such programming "errors" are likely. Nonetheless, I concede that RFC
2743 and RFC 1510 are pretty clear on the issue (even if I find the
specifications on the issue disagreeable), so treating the fqdn in host-based
principals is not needed. Still, Kerberos principals of form:

	<lhs>@<realm>

could treat the <realm> as case insensitive, and <lhs> as case sensitive,
which would satisfy the various concerns raised on this topic, and has
the virtue of being consistent with conventions for mailboxes.

	-mre

---

From: Martin Rex <[email-masked]>
Date: Tue, 11 Apr 2000 20:15:52 +0200 (METDST)

> applications, so nfs uses them.

IMHO this is exactly wrong.  hostbased service names are mech-specific,
so your code is very mechanism dependent.  It may be unfortunate, but
there are no "portable" names at all, so portable applications must not
attempt to derive gssapi names algorithmically from transport endpoints.

When using GSS-API, a TCP transport endpoint is securely identified by
three parameters:  IP-Addr, Port#, Target-Name, and none of the three
is redundant.  Previously insecure applications that want to use
GSS-API to secure their communications must add an additional
parameter for the target that a user/adminstrator will have to provide.

I personally dislike hostbased service names for many reasons:
- they don't easily work for plain IP-Addrs/Port#
- they don't easily work for non-standard apps or apps on non-standard ports
- they use INsecure DNS for canonicalization and are therefore vulnerable
- they're available only in the minority of gssapi mechanisms
- even with Kerberos, they don't universally work for target names,
  e.g. when the target is a user

I know there are a lot of kerberized apps that have been or are being
shifted to use GSS-API instead of native Kerberos, but no provisions
are made to make them portable gssapi applications by allowing the
user and/or administrator to supply a target name.

-Martin

---

From: Mike Eisler <[email-masked]>
Date: Tue, 11 Apr 2000 11:35:05 -0700 (PDT)

> attempt to derive gssapi names algorithmically from transport endpoints.

[email-masked] is a very portable name. It happens to get translated to
mechanism specific names, which is a bit of an implementation inconvenience,
but it simply means that for every mechanism the application supports, there
has to be another corresponding mech specific name. It serves the desired
purpose, no less than [email-masked] does for ftp servers.

> user and/or administrator to supply a target name.

The NFS implementation I worked on is a portable gssapi application.
It works over Kerberos V5 today, and will someday work over SPKM/LIPKEY,
simultaneously.

	-mre

---

From: Martin Rex <[email-masked]>
Date: Tue, 11 Apr 2000 21:21:17 +0200 (METDST)

> purpose, no less than [email-masked] does for ftp servers.

Where does this portable name "[email-masked]" get translated?
Most gssapi mechanisms will simply return "GSS_S_BAD_NAMETYPE" when
they are given an hostbased service name.  If you do the translation
within your code, then it is a different name than the one I was
talking of.

It is the same with FTP, and it is really unfortunate that the
use of a hostbased service name is actually recommended in the
FTP spec, simply because it is non-portable across the majority
of the gssapi mechanisms.

> It works over Kerberos V5 today, and will someday work over SPKM/LIPKEY,

The three(four) different SPKMs that I've seen all do not understand
hostbased service names.  And unfortunately, because rfc2025(SPKM)
fails to specify any nametype at all -- provide completely independent
nametypes which are interoperating only in a limited way.  :-((

-Martin

---

From: "Douglas E. Engert" <[email-masked]>
Date: Tue, 11 Apr 2000 14:32:51 -0500

> attempt to derive gssapi names algorithmically from transport endpoints.

I disagree. They don't have to be mech-specific, and with our GSSAPI
based on SSL, we use the host@FQDN just like Kerberos. Sometimes all you
have to work with is the hostname, so you have to derive a target name from it. 

If you have a target_name from some other source, fine, but is then not hostbased. 

Portable names are another issue, there are not hostbased, as you point out,
so why does should this stop one from using hostbased services for services
on a host? 

> parameter for the target that a user/adminstrator will have to provide.

But for the target to authenticate to the client, the target still needs 
credentials, which are usually issued or signed be some trusted third
party, like a KDC or a CA. So deriving the target name from the hostname
when the application is host based and then authenticating it are not completely 
independent. The target is still proving its identity.  

>   e.g. when the target is a user

But for a user, it is not a hostbased target. The application can still provide 
a non hostbased target name if it chooses, so many of these arguments
don't realy apply.   

So maybe we are arguing the same point: If you have a target name, great, use
it, if not, and all you have is a FQDN, then you have to use hostbased services. 

--

---

From: Mike Eisler <[email-masked]>
Date: Tue, 11 Apr 2000 12:49:11 -0700 (PDT)

> Where does this portable name "[email-masked]" get translated?

In the mechanism.

> Most gssapi mechanisms will simply return "GSS_S_BAD_NAMETYPE" when

What's the alternative way to achieve portability if we can't count on
the generic gss-api name types being supported?

> nametypes which are interoperating only in a limited way.  :-((

SPKM-3 (part of the pending LIPKEY RFC) mandates all of the
name forms of RFC 2078.

If a mechanism doesn't support the host based nametyope, then its usefulness
is going to be limited, because ftp, ldap, nfs, etc. will expect it.

	-mre

---

From: Martin Rex <[email-masked]>
Date: Thu, 13 Apr 2000 21:08:55 +0200 (METDST)

> the generic gss-api name types being supported?

Let users/administrators provide the names, just as they provide
their gssapi implementation.  Don't hardcode names or nametypes into
your application, because this will definitely make it non-portable,
even if it works with all the mechanisms that you're using yourself
right now.

> SPKM-3 (part of the pending LIPKEY RFC) mandates all of the

Uh-oh! ...

I have just browsed through the lipkey-03 document quickly and
I'm not amused.  The spec is sufficiently vague to prevent interoperability
of any two independent implementations (i.e. before they meet for the
first time).  Somehow I get the feeling that this proposed mechanism
bends the gssapi framework over its limits, i.e. the only thing that
works like gssapi is the context token handshake and the message
protection calls.  There is so much more to GSS-API than that.

Some things that I noticed:

- section 4.1 repeats section 2.1
  section 4.2 repeats section 2.2

- Requiring "all generic nametypes of rfc2078" is inappropriate.

  A real gssapi mechanism spec (which rfc2025(spkm) is not quite)
  needs to define a mechanism-specific name format first.   Then
  it may define how generic nametypes of rfc2743 are to be transformed
  into this mechanism-specific format.  rfc1964 (the Kerberos5 gssapi
  mechanism spec), section 2.1 is much better in this respect, although
  it is missing the definition how to map the mandatory hostbased
  service name into a kerberos principal name in section 2.1.2,
  and also missing such guidance for the optional name forms in 2.2
  Although lacking the guidance, all Kerberos5 gssapi mechanisms
  that I've seen are fortunately doing it in the same way.
  
  Note in particular the header of section 2.2 in rfc1964 and you'll
  notice why sections 2.2/4.2 of lipkey are inappropriate as they are.

  Among the nametypes defined in rfc2743(rfc2078) is also an exported
  name type.  A generic framing is given in section 3.2 of rfc2743.
  If a mechanism wants to support exported names, it will need to
  define how its own mechanism-specific names are put into the
  payload of the generic exported-names framing.

quoting rfc2743, section 3.2: "mechanism-independent exported name format"
   "The format of names encapsulated via this representation shall be
    defined within individual mechanism drafts."

  rfc2025 (SPKM) is seriously incomplete because it fails to define
  a clear mechanism specific nametype and how to map generic nametypes
  into the mechanism-specific ones.  All the (4) SPKM implementations that
  I've seen so far implemented their own mechanism-specific nametypes
  and they basically do not interoperate on names.

  The libkey-03 draft is just as incomplete in this respect.

- in 3.3.3 gss_accept_sec_context() should return GSS_S_NO_CRED
  when the users credentials are invalid.  This is a bad abuse of this
  error code, because for gss_accept_sec_context() it is meant to
  apply to the acceptor credentials, NOT the initiator credentials.
  You should be defining a new major status code for your purpose.

- although the spec talks of unilateral authentication in several
  locations (which would not require a target name at all for GSS-API v2)
  it makes use of the target name all over the place with fuzzy
  purpose.  It suggest some sort of target name to Server certificate
  mapping, however doesn't say how.
  There is the GSS_C_MUTUAL_FLAG as input to and output from
  gss_init_sec_context(), which really should get used if any
  target name validation (I doubt it will be a real authentication)
  for this mechanism is performed at all.  Otherwise the whole
  target name stuff should be dropped all together.

> 
> If a mechanism doesn't support the host based nametype, then its usefulness

The applicability of applications that hardcode names and nametypes
is going to be limited, because they didn't understand the gssapi spec.
Applications must have provisions to pass a gssapi name and nametype opaque
from the user/administrator to the gssapi mechanism, or they're broken.

-Martin

---

From: Mike Eisler <[email-masked]>
Date: Thu, 13 Apr 2000 13:35:28 -0700 (PDT)

> even if it works with all the mechanisms that you're using yourself

Please elaborate, perhaps with a simple example.

>   section 4.2 repeats section 2.2

There's no repetition since 2.1 and 2.2 refer to SPKM-3, and
4.1 and 4.2 refer to LIPKEY.

>   that I've seen are fortunately doing it in the same way.

Which would prevent LIPKEY/SPKM-3 from reaching Draft, at which point
this will have to nailed down. My mistake for overlooking it.
I suspect implementors will follow the Kerberos V5 approaches.

>   You should be defining a new major status code for your purpose.

I don't really care for new major status code's since it impacts
portability. GSS_S_NO_CRED is closest one to matching the
requirement.

>   locations (which would not require a target name at all for GSS-API v2)

SPKM supports two types of unilateral authentication. One form
authenticates just the target. Another form authenticates
just the initiator. LIPKEY is layered over the former form.

>   mapping, however doesn't say how.

My, possibly naive, notion was that the target name, service[@host] would be
compared with the SubjectAltName in the certificate. service@host has an
obvious 1-1  mapping with the rfc822Name field.

> from the user/administrator to the gssapi mechanism, or they're broken.

I admit to not understanding the issue above. However, it seems to be
that given ftp, ldap, nfs, etc. can be made to work over Kerberos V5, and
goiven SPKM is underspecifying in the areas of principal name management,
the experiences of Kerberos V5 can be be applied to SPKM, and SPKM can
then be better specified.

	-mre

---

From: [email-masked]
Date: Thu, 13 Apr 2000 21:47:55 -0400

From: Martin Rex <[email-masked]>
   Date: Tue, 11 Apr 2000 20:15:52 +0200 (METDST)

   IMHO this is exactly wrong.  hostbased service names are mech-specific,
   so your code is very mechanism dependent.  It may be unfortunate, but
   there are no "portable" names at all, so portable applications must not
   attempt to derive gssapi names algorithmically from transport
   endpoints.

From the start, hostbased service names were designed to be mechanism
independent.  That's why they're in the generic GSSAPI draft.  It just
so happens that for Kerberos there's a simple algorithmic tranformation
between the hostbased service name and the Kerberos principal name, but
I believe the original vision was one where some database might be
consulted to translate the hostbased service name into a X.509
Distinguished Name, for example.

I think you're making the argument that the way implementations have
turned out haven't matched with the vision, but that's different from
saying that the whole concept of host-based service names was wrong.

It's true that specifying all three parameters (IP-Addr, Port#, and
Target-name) is the most general, but I think it's important to have
defaults whenever possible.  Most people don't specify the telnet port
when they telnet to a host, and I think most would rebel if we asked
them to specify the target-name as well!  Especially if it were an
X.509 Distinguished name.  Can you imagine people typing:

telnet bitsy.mit.edu 23 /C=US/SP=Massachusetts/OU=Massachusetts Institute of Technology/CN=bitsy.mit.edu

when they want to telnet to the machine bitsy.mit.edu?  I think not!
(Thus the old joke whose punchline was: "... and when two X.400 users
meet in a conference, and want to reach each other afterwards ---- they
use the telephone.)  

Details about whether an insecure means is used for canonicalizing them
is really an implementation issue.  We could devise a secure means of
canonicalizing the name (including deploying SecureDNS :-), if we really
wanted to deal with that issue.  

More of an issue is your observation that many gssapi mechanisms
apparently aren't implementing the host-based service name.  This is
unfortunate, but basically, this is a hard problem that I don't think we
can just define away.  For certain applications it may be OK to
hard-code the target name in the command-line associated with an icon
which the user double-clicks (which is the case with the SAPGUI, for
example), but I don't think that's a general solution to the problem.

						- Ted

---

From: Martin Rex <[email-masked]>
Date: Fri, 14 Apr 2000 17:41:35 +0200 (METDST)

> saying that the whole concept of host-based service names was wrong.

My oberservations of hostbased service names are:
- they are INSECURE how rfc2743 defines them and the way they have
  been implemented in MIT Kerberos 5.
- they are not available in many of gssapi mechanisms that
  I have seen, in particular the public key based mechanisms
- they don't scale for distributed services where the end system
  decides which machine is going to serve the request.
- they don't work for proxy-traversal, i.e. environments where the
  service is located behind a single or even a chain of firewalls

> when they want to telnet to the machine bitsy.mit.edu?  I think not!

Yes, sort of!  To ease the user interface, you can make it work backwards.

There is a popular telnet replacement called SSH which does just that.
It eases the use by caching the identities (which are public keys in SSH)
under the alias of the hostname.  You know that if you don't verify
"authenticate" a host key (by transfering them out-of-band or comparing
fingerprints), then you're taking a risk.
I think it would be a good idea for apps such as telnet to use a similar
scheme when adding security.  SSH's use of the hostname as the lookup
key doesn't scale with firewall traversal, however.  Re-use of the
host key in a server farm should work, however.

Your example CN is acutally quite short.  There are CAs that put a policy
and other junk into the DN as well...  Because of that I think it's
a bad idea to use the full or parts of the subject DN for authentication.

The important point is not to force them typing lengthy names, but
to require a SECURE transformation from the target name that the user
supplies into the name that is compared against the target's real
identity.

As long as ALL transformations on the target name are secure,
 - it will be ok to resolve the transport endpoint through
   insecure naming services.
 - it won't matter if the transport endpoint resolves round-robin
   to a particular instance of a server farm / cluster.
 - it won't matter if the transport endpoint is actually
   a proxy that will decide by it's own to which machine of
   a server farm you will be connected/routed.
 - it is possible to share a single server credential across
   all servers of a server farm / cluster.

hostbased service names are a very Kerberos-centric view of the situation.
Because of the way the Kerberos authentication works (authenticator
and replay cache), sharing server credentials across several hosts of a
cluster would result in a replay vulerability.  

Hostbased service names scale badly in server farms / clustered environments.
Here, servers are not only acceptors, they're often initiators, so a server
farm with 100 servers need not only 100 server credentials, but also
Access Control lists with 100 entries on each of the server to allow
internal delegation, cross-connects and load-balancing.  Using a single
service name and a single credential eases the adminstration significantly,
and changes in the exact procedure how to connect a client to a particular
service instance will not interfere with a secure name resolution of
the client.

> wanted to deal with that issue.  

Even zillion-bit secure DNS will not prevent the transfer of a DNS-domain
from one company to another by a court order resulting from a trademark
dispute.  And this is becoming more and more common nowadays.

The remaining security problem with DNS is that the allocation of
DNS domains is not secure, but a first-come first-serve service with
legal battles over the domain ownerships.  And I don't think this
will change soon.  No, *I* don't want to root my trust in DNS,
even if they switch to secure DNS.

Now if I accidentally connect to "www.openssl.de" instead of
"www.openssl.org", then it is exactly the insecure hostname and
domain allocation of DNS that could fool me to believe everything
is just fine if they showed me a VeriSign Server Certificate for
www.openssl.de (which they rightfully could obtain).

> example), but I don't think that's a general solution to the problem.

It may depend on the application how it caches the target names,
however I think the full names should always be used and cached,
and when the user starts the game with a short name (or without
any name just like in SSH), the user should at most once have
to take a risk of an insecure target identity transformation.
When using public key based technology and preconfigured trusted
roots, the risk of the initial insecure name transformation
could be further reduced.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Fri, 14 Apr 2000 19:44:10 +0200 (METDST)

> Please elaborate, perhaps with a simple example.

Look at the CN=f.q.d.n check that Web-Browsers perform.
This is a hardcoded and stupid target name validation, which
doesn't add real security, it only verifies the association
of a public key with a hostname that is allocated from a
first-come first-served namespace (the DNS).

We are going to add HTTPS accessibility to our application servers,
but because of this silly browser habit, we will have to torment the
administrators with getting Server Cert's signed for each and
every server seperately and to maintain ACLs whenever any of the
servers accesses another server by HTTPS client authentication
(within the same server farm of from a different server farm).

In a simple Web-Server scenario it is possible to cheat the clients
about the transport endpoint, either by using a TCP-Proxy (or a
NAT) and using a Certificate with the address of the proxy machine
(or the NAT).  This has an added benefit that "bookmarks" will
have the correct entry point.  However this also provides a single
point of failure and network traffic hotspots.  And why do we have
to cheat the client at all -- it would be much better if the client
was so short-sighted in the first place.

> 4.1 and 4.2 refer to LIPKEY.

OK, I'm sorry.  So much for my speed-reading capabilities at night.
I searched for certain keywords only and only read the near vicinity
around them.

> I suspect implementors will follow the Kerberos V5 approaches.

This didn't work at all with SPKM, how are you so optimitic that it
will work with an SPKM-derived mechanism?

> portability. GSS_S_NO_CRED is closest one to matching the

Semantically it is the wrong status code.
Quoting rfc2743, section 2.2.2, GSS_Accept_sec_context

   o  GSS_S_NO_CRED indicates that no context was established, either
   because the input cred_handle was invalid, because the referenced
   credentials are valid for context initiator use only, because the
   caller lacks authorization to access the referenced credentials, or
   because the procedure for default credential resolution failed.

When returned by gss_accept_sec_context(), this status code is
reserved for failures related to the explicit or implicit acceptor
credentials.  It is wrong to use it for indicating that client
credentials in the context token are invalid for logon.

I don't by the portability argument: existing full-blown gssapi mechanisms,
(if they ever let you this far) will have to return GSS_S_FAILURE.

Again, if you want to indicate the particular failure that the
client credentials transferred by LIPKEY are invalid for logon,
then invent a new major status code, *please*.

> obvious 1-1  mapping with the rfc822Name field.

Don't count on the obvious.  History with SPKM shows that implementors
get things wrong ... terribly wrong, simply because they will have to
deliver a product long before they have a chance to look closely at other
implementations.

I would really appreciate if the LIPKEY spec would *mandate* a
particular mapping.  Keeping in mind the drawbacks of strict
hostbased service names, such a mapping should offer more flexibility.

The ID draft-ietf-tls-https-04.txt, section 3.1, makes at least some
provisions for supporting server farms with a single credential.
This draft mentions transport-independent target authentication,
but doesn't realize their huge potential benefits.

> given SPKM is underspecifying in the areas of principal name management,

Updating the SPKM spec to define a mechanism-specific nametype
and in particular the exact mapping of hostbased service names into
this namespace would be a great benefit in my opinion.

However it would require backwards-incompatible code updates for all
existing SPKM implementations and provide clear guidelines for
CAs how to issue Certificates for server instances.  One of the reasons
why the SPKM spec is lacking such definitions is probably that they
didn't want to force certificate content constraints onto CAs.
Up to now, CAs were the ones to set rules for the contents of
their certificates.

-Martin

---

From: Mike Eisler <[email-masked]>
Date: Thu, 20 Apr 2000 09:43:13 -0700 (PDT)

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.

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.

	-mre

---

From: Martin Rex <[email-masked]>
Date: Tue, 25 Apr 2000 15:56:52 +0200 (MET DST)

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

> 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

---

From: "Douglas E. Engert" <[email-masked]>
Date: Tue, 25 Apr 2000 10:05:23 -0500

> share the "host/f.q.d.n" key.  What are the rules when using GSS-API?

The choice of the service name is up to the application,
so your W2K Kerberos SSP wrapper GSS should not care.

 RFC 2743 says it is:

   This name type is used to represent services associated with host
   computers.  Support for this name form is recommended to mechanism
   designers in the interests of portability, but is not mandated by
   this specification. This name form is constructed using two elements,
   "service" and "hostname", as follows:

   service@hostname

Then Kerberos goes on to convert this to the principal service/fqdn@realm 
after canonicalization of the hostname via DNS. (Which as you have pointed out may 
be a security risk.) 

> that "[email-masked]" may not work and I should try "host@hostname" instead.

Yes that is to bad that that was not resolved earlier, but that is an FTP problem
not a GSSAPI problem. 

> Your Email seems to suggest that a nfs/f.q.d.n principal is required

That would be up to the application writer (NFS developer) to define the service
which could be "nfs". This would then map to nfs/fqdn@realm as a principal. 
They might even want to use "host". But the GSSAPI should not care what the service
is. 

Using a single "host" service for all root-login type operations simplifies the
sysadmin life as he does not need a dozen principals and keys. 

--

---

From: Ken Hornstein <[email-masked]>
Date: Tue, 25 Apr 2000 11:22:26 -0400

>share the "host/f.q.d.n" key.  What are the rules when using GSS-API?

Martin, I was under the impression your complaint was with the use of
the hostname-based service name, not with the rules used to map service
names to Kerberos principals.  As I understand it, the mapping between
the GSSAPI service name and Kerberos principal is very simple:
[email-masked] maps to service/f.q.d.n@REALM.

All of the traditional Kerberized Unix remote access utilities (with the
exception of ftp) don't use GSS-API.  "host" in the Kerberos sense
traditionally is a key readable only by the root user on Unix, and all
of the services that require root level access (such as telnetd, rlogind)
share this key.  If they did use the GSSAPI, I think all of their service
names would be "[email-masked]".

>that "[email-masked]" may not work and I should try "host@hostname" instead.

I have never really understood why the RFC2228 authors choose two possible
service names, but this isn't really related to Kerberos from my point
of view.  The ftp client that comes with MIT Kerberos tries both
[email-masked] and [email-masked] (which maps to the Kerberos principals
ftp/f.q.d.n@REALM and host/f.q.d.n@REALM respectively).

>is non-portable and should be discouraged.

Section 2.1.2 of RFC 1964 isn't exactly unambiguous, but:

   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

I think most people who are knowledgable about Kerberos would agree that
this means "service" should be the first label, and hostname would be
the instance.  I think if 1964 gets revised, this should be made more
clear.

>Your Email seems to suggest that a nfs/f.q.d.n principal is required

Seems relatively clear to me; what's the problem?  (I would have personally
chosen "host", though).

Let's ask a different question: is there an IETF protocol that
specifies the use of GSSAPI and _doesn't_ use the host-based service
name form?  Certainly the largest consumer of GSSAPI that I'm aware of
(SASL) mandates the use of host-based service names.

--Ken

---

From: Mike Eisler <[email-masked]>
Date: Tue, 25 Apr 2000 08:50:05 -0700 (PDT)

> > [...]

The topic is LIPKEY and SPKM-3, but, in RFC 1510, it
says in section 7.2.1 "Name of server principals"

   The principal identifier for a server on a host will generally be
   composed of two parts: (1) the realm of the KDC with which the server
   is registered, and (2) a two-component name of type NT-SRV-HST if the
   host name is an Internet domain name or a multi-component name of
   type NT-SRV-XHST if the name of the host is of a form such as X.500
   that allows slash (/) separators.  The first component of the two- or
   multi-component name will identify the service and the latter
   components will identify the host.  Where the name of the host is not
   case sensitive (for example, with Internet domain names) the name of
   the host must be lower case.  For services such as telnet and the
   Berkeley R commands which run with system privileges, the first
   component will be the string "host" instead of a service specific
   identifier.

I agree that the above is somewhat underspecified.
 
> share the "host/f.q.d.n" key.  What are the rules when using GSS-API?

I've presumed that when GSS-APU gets a target name like
	host@<f.q.d.n>
then when using a Kerberos V5 target, this becomes
	host/<f.q.d.n>@<realm>
 
> that "[email-masked]" may not work and I should try "host@hostname" instead.

Perhaps you should have objected when the ftp i-id was being considered
by the WG several years ago.

> is non-portable and should be discouraged.

This isn't a new point in the discussion. We'll have to agree to disagree.
Since RFC 1510 is being re-worked in this WG, you might want raised this point
to the authors of the i-d that is to replace RFC 1510.

> Your Email seems to suggest that a nfs/f.q.d.n principal is required

Yes it is.

> The lack of names in TLS is not a valid reason,

Considering that LIPKEY is intended to work in environments
that TLS does, it is valid.

> TLS is a wire protocol, not an API.

But GSS-API is a wire protocol.

	-mre

---

From: Mike Eisler <[email-masked]>
Date: Tue, 25 Apr 2000 09:00:29 -0700 (PDT)

> Seems relatively clear to me; what's the problem?  (I would have personally

Getting way off topic here, but one reason I opted for "nfs" and not "host" 
was that NFS servers often operate in a kernel environment and not a 
user level environment, and I wanted to accommodate implementations that
might chose to keep the keytab information completely in the kernel. If
"host" were used, and the same machine supported a telnet service and an
nfs service, this would not be possible for such implementations.

	-mre

---

From: Martin Rex <[email-masked]>
Date: Tue, 25 Apr 2000 19:12:51 +0200 (METDST)

> I agree that the above is somewhat underspecified.

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.

> by the WG several years ago.

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.  

> > Your Email seems to suggest that a nfs/f.q.d.n principal is required

What I wanted to ask: Do you require "[email-masked]", or do you allow
"[email-masked]" fallback as in the Secure FTP extensions? 

> But GSS-API is a wire protocol.

GSS-API is both, a wire protocol *and* an API.

GSS-API has primitives for doing name-based access control, and
the minimum "service" provided by GSS-API is authentication.
GSS-API is made for authentication-aware applications.

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.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Tue, 25 Apr 2000 19:38:16 +0200 (METDST)

Ok, this is a Kerberos and not a LIPKEY issue...

> names would be "[email-masked]".

Do I need to map "[email-masked]" into "host/f.q.d.n@REALM",
or should I always map it into "telnet/f.q.d.n@REALM".
Telnet SHOULD NEVER have to try both "[email-masked]" and "[email-masked]"
in way that the current Secure FTP extensions suggest.

I need a formal specification for any such mapping (if there should
be one for Kerberos 5) because I want to ship code!  ;-)

If an application tries "[email-masked]" as target name, then there
are two failure possibilities:

 1. (one network roundtrip to the KDC):
    the principal for "telnet" doesn't exist
    gss_init_sec_context() fails with GSS_S_FAILURE

 2. (one network roundtrip to the KDC, one to the target):
    the principal for "telnet" exists, but the target is using
    "host" credentials for accepting,
    gss_init_sec_context() succeeds for the initiator,
    but gss_accept_sec_context() fails for the acceptor.

I don't like either one, because both failures have network
roundtrip and crypto overhead. 

-Martin

---

From: Ken Hornstein <[email-masked]>
Date: Tue, 25 Apr 2000 14:09:09 -0400

>in way that the current Secure FTP extensions suggest.

I agree, and _if_ we had a GSS-API authentication mechanism for telnet,
I would say that the only target name that should be tried would be
"[email-masked]".

>be one for Kerberos 5) because I want to ship code!  ;-)

I think ftp is the exception in this regard (the fact that there are
two possible target names that may work).  I believe that everyone
agrees that there is a one-to-one mapping between Kerberos principals
and GSSAPI host-based service names, so I don't think this is an issue.

Even in the ftp case, this isn't a Kerberos issue; the issue is that
two different _GSSAPI_ service names are specified.

>[... From another note ...]

I believe everyone would agree that you don't need to do any special
mapping between GSS-API service names and Kerberos principals; whatever
the protocol specifies as the service name will be the correct principal.
Of course, some protocols may specify more than one service name (like
ftp), but IMHO that's a protocol-specific issue.

(If there was going to be GSSAPI versions of telnet and rlogin, I
think everyone would agree they would all use "[email-masked]" as a
service name).

--Ken

---

From: Ken Hornstein <[email-masked]>
Date: Tue, 25 Apr 2000 15:35:00 -0400

Okay, this is a bit of an old message, but I was digging out of some
old email, and I figured it was relevant ...

>  I have seen, in particular the public key based mechanisms

Are there a _lot_ of GSSAPI mechanisms that I'm simply not aware of?

The GSSAPI mechanisms that I know about are:

- Kerberos 5
- DCE
- SPKM
- LIPKEY

I know that Kerberos 5, DCE, and LIPKEY all support hostbased service
names.  I'm not sure about SPKM (but the spec says it's designed to
be as compatible with Kerberos as it can, so I would guess that it
would support host-based serivce names).

Meta-observation: most of the code I'm aware of today that uses GSSAPI
is using it as a way to provide Kerberos authentication to protocols &
applications, and all of it is written to use host-based service
names.  If they're truely "not portable" (and I believe the consenses
is that _are_ supposed to be portable) then any mechanism that doesn't
implement host-based service names is going to be for an unpleasant
surprise, to say the least.

--Ken

---

From: Ken Hornstein <[email-masked]>
Date: Wed, 26 Apr 2000 13:11:29 -0400

>I know that they currently don't use GSS-API.
>However if any of those application protocols were expanded to use
>GSS-API (directly or through SASL), a compiled-in hostbased service
>name would have to be "rcmd@hostname", "imap@hostname", "pop@hostname",
>"ftp@hostname", "nfs@hostname", but NEVER "host@hostname"!

Let's address these individually:

rcmd@hostname - rcmd is a leftover V4ism, nothing in the V5 world uses
		it anymore.
imap@hostname,pop@hostname - Already defined and used for those protocols.
			     There's no fallback to host@hostname.
ftp@hostname - We already know all about this one :-)
nfs@hostname - From what Mike has said, nfs@hostname is the only valid
	       GSSAPI service name (that's correct, isn't it, Mike?)

>There is an IANA registry for the services of hostbased service names
>
>"http://www.isi.edu/in-notes/iana/assignments/gssapi-service-names"

See, now this is a bit strange.  How come rcmd was brought forward
as a valid GSSAPI service name?  The RFC referenced in the service
name assignments for rcmd is a Telnet V4 RFC that predates GSSAPI!
It sounds like to me that rcmd should be depreciated and replaced
with host.

>One should not confuse the abstract hostbased service names at
>the GSS-API level with the specific hostbased service principals
>of the Kerberos 5 GSS-API mechanism.  It is up to the mechanism
>to define the mapping, it doesn't need to be one-to-one and it
>doesn't need to be fixed.  The current spec rfc1964 doesn't define
>any mapping at all and is therefore incomplete.

Well, _that_ sounds like a bug in the spec to me.  But I think
everyone agrees here that current implementations don't do any
mapping, nor is one required.

>It is inappropriate to specify for GSS-API enabled application protocols
>to use the hostbased service name "host@hostname" as the target name,
>because that is Kerberos-specific and doesn't meet the GSS-API abstraction.

Okay, so is your complaint that "host@hostname" isn't registered with
IANA?  That should be easy to fix.  I don't think the intent is that
"host@hostname" is supposed to be Kerberos-specific.

>As I initially requested, it should be possible for a user to supply
>a target name to perform a real target authentication, and the application
>must support an arbitrary target name, if any, so that it doesn't
>matter whether it is "host@hostname", "host/f.q.d.n@SOME-REALM" or
>"CN=xyz-service, OU=division, O=company, C=DE" (note that the latter
>two are mechanism specific names, usually imported without nametype OID.

Well, my only answer to this is that it doesn't seem like support for
arbitrary target names in GSS-API is in any IETF protocol today (they
all seem to use host-based service names).  There would need to be
some serious thought as to how to fix this problem if people really
want to use arbitrary target names.

>At the GSS-API level, this is the wrong answer, because it is lacks
>the abstraction.

I'm not sure I know exactly what abstraction you're referring to.

--Ken

---

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

It would be ok for the Kerberos 5 gssapi mechanism to define that
the GSS-API hostbased service name "rcmd@hostname" should be mapped
to the service principal "rcmd/f.q.d.n@SOME-REALM" in general, but
it could also specify that a implmenentation specific service
name resolution might map it to the service principal
"host/f.q.d.n@SOME-REALM" if the user or administrator defines
this in their Kerberos configuration.

> >Your Email seems to suggest that a nfs/f.q.d.n principal is required

I am very pleased that Mike wants to require support for the
GSS-API hostbased service name "nfs@hostname".  It would be ok for
the Kerberos GSS-API mechanism to map this generic name into the
Kerberos mechanism specific name "host/f.q.d.n@SOME-REALM".

At the GSS-API level, this is the wrong answer, because it is lacks
the abstraction.  If one requires different hostbased service names,
then it will be possible to run the services with independent credentials.
It will also be possible to run the services with shared credentials,
one only needs a mechanism-specific or an implementation specific
service name resolution that maps the different abstract GSS-API names
into the same principal.

-Martin

---

From: Mike Eisler <[email-masked]>
Date: Wed, 26 Apr 2000 10:47:23 -0700 (PDT)

> 	       GSSAPI service name (that's correct, isn't it, Mike?)

Correct.

> "host@hostname" is supposed to be Kerberos-specific.

The other complaint might be that host@hostname isn't mentioned in RFC 2743
(GSS-API).  But that's a minor issue. I've always assumed that host@hostname
was not intended to be Kerberos specific and vaugely recall discussion on cat
about this. The reason why I didn't use it for NFS is what I said before: that
NFs servers oare usually kernel resident, and this might cause problems for
implementations on hosts that support r*, telnet, ftp, and nfs simultaneusly.
This wouldn't be a problem for the Solaris implementation of NFS, but  I try
to to think of other operating environments.

	-mre

---

From: Greg Hudson <[email-masked]>
Date: Wed, 26 Apr 2000 14:49:56 -0400

I don't think we can resolve this issue in a satisfactory way.

The whole point of GSSAPI is that we have N services and M security
mechanisms, and we would like to have O(M+N) bits of code instead of
O(M*N) bits of code.  But the mapping of GSSAPI service names to
mechanism-specific service names is an inherently M*N thing; either
the mechanism knows about all the services or the service knows about
all the mechanisms.  Using a configuration file instead of a hardcoded
mapping would help, but it's still not very satisfactory.

The only out is if we require all mechanisms to use the GSSAPI service
name conventions, so that there is no mapping.  But then we lose the
ability to cleanly interface with any kind of preexisting key
management practices for a security mechanism.  Kerberos 5's "host"
key is just the first example.
-++**==--++**==--++**==--++**==--++**==--++**==--++**==
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: Mike Eisler <[email-masked]>
Date: Wed, 26 Apr 2000 12:09:43 -0700 (PDT)

> mapping would help, but it's still not very satisfactory.

Or the mechanism is designed to map arbitrary things of form service@host to
the underlying mechanism specific representation without the need to
have mapping table. Kerberos V5 does this: the transformation from
	service@host 
is
	service/fqdn@REALM

Regardless how the mechanism deals with it, there are still O(N) bits
of application code.

> name conventions, so that there is no mapping.  But then we lose the

Impossible. For example, in Kerberos V5, there is the notion of the REALM that
is part of the full principal name.

If GSS-API starts to dictate mechanism specific naming, then GSS-API will find
few mechanisms it can work over.

---

From: Greg Hudson <[email-masked]>
Date: Wed, 26 Apr 2000 15:15:39 -0400

Uh, we seem to have miscommunicated.  When I was talking about "the
mapping of service names," I meant mapping the actual name of the
service, e.g. mapping the GSSAPI service "telnet" to the Kerberos 5
service "host".  I wasn't talking about mapping the syntax of how you
put the service name and the hostname together, or the mapping of
adding a realm, or whatnot; that clearly doesn't require any knowledge
of the applications.
-++**==--++**==--++**==--++**==--++**==--++**==--++**==
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: Mike Eisler <[email-masked]>
Date: Wed, 26 Apr 2000 12:43:42 -0700 (PDT)

> service, e.g. mapping the GSSAPI service "telnet" to the Kerberos 5
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> service "host".  I wasn't talking about mapping the syntax of how you
^^^^^^^^^^^^^^^^
> adding a realm, or whatnot; that clearly doesn't require any knowledge

I don't consider "host" to be a Kerberos 5 specific service name. It's as
generic as "ldap" , "ftp", or "nfs". If it's not registered with IANA, then it
should be, since RFC 2228 refers to it. RFC 2228 (ftp security extensions),
doesn't state or imply that any mapping from "ftp" to "host" should take place.

I'm not advocating mapping the GSS-API service name for "telnet" to "host". If
"telnet" is passwd to GSS-API, then GSS-API must pass "telnet" to the krb5
mechanism.

If the telnet protocol is specified to use GSS-API with a target of "host",
then telnet clients and servers should use "host". In the end, it's an
application decision. 

	-mre

---

From: Martin Rex <[email-masked]>
Date: Thu, 27 Apr 2000 11:17:34 +0200 (METDST)

> > service, e.g. mapping the GSSAPI service "telnet" to the Kerberos 5

Of course it is Kerberos specific.  It doesn't refer to the service
as the GSS-API abstraction requires, it refers to a shared host key under
the assumption that the service has access to a common host key that
is used with Kerberos.

It is wrong for the application to make assumptions about the
underlying security architecture.  It is particularly wrong for
initiator side of an application to make assumptions about the
security architecture of the gssapi mechanism implementation
that the acceptor side is using.

> "telnet" is passwd to GSS-API, then GSS-API must pass "telnet" to the krb5

Which intermediate layer "GSS-API" between the application
and the krb5 mechanism are your talking of?  The krb5 gssapi mechanism
spec (rfc1964bis) must define whether and how abstract hostbased services
are to be mapped to Kerberos 5 principal names.  And it would be
appropriate if it required to map the abstract services "telnet", "rsh"
and "rlogin" all to the "host" service instance.  But in order not to
limit future development of Kerberos, it should probably rather define
there should be an implementation-specific configuration option that
will cause this mapping, rather than requiring a hardcoded mapping.

> then telnet clients and servers should use "host". In the end, it's an

No, its not.

I'm strongly opposed to register "host" with IANA to cover the rfc2228 error.
Since "host" is already mentioned in rfc2228 for ftp, IANA should refuse
to register it with any other application, even after the error in
rfc2228 is corrected.

-Martin

---

From: "Theodore Y. Ts'o" <[email-masked]>
Date: Thu, 27 Apr 2000 22:22:31 -0400

Date: Wed, 26 Apr 2000 10:47:23 -0700 (PDT)
   From: Mike Eisler <[email-masked]>

   The other complaint might be that host@hostname isn't mentioned in RFC 2743
   (GSS-API).  But that's a minor issue. I've always assumed that host@hostname
   was not intended to be Kerberos specific and vaugely recall
   discussion on cat about this. 

But it *is* mentioned in RFC 2743.  Take a closer look at section 4.1 on
page 85.  It specifically talks about the generic "host" service name.

Sorry for not chiming in on this discussion earlier, but between being
spammed by the discussion on the ietf mailing lists, and now on the
cat-ietf list (never has more bits been killed over something which is
already specified in the RFC :-), I'm a bit behind on all of my
e-mail.....

						- Ted