Subject: RE: Soliciting additional GSS/Kerberos interoperability results

From: "Linn, John" <[email-masked]>
Date: Mon, 14 May 2001 09:50:00 -0400

(Martin's original message was posted to the Kerberos mailing list; I'm
cross-cc'ing this reply to include CAT-WG as well, as it raises a
cross-mechanism GSS issue.)

Recognizing that RFC-2743 doesn't mandate that conformant mechanisms must
support the individual name types it defines, since support for the
host-based service name type is required at least by RFC-2847 (LIPKEY) as
well as being included within Kerberos implementations, and since multiple
standards-track GSS consumer applications require support for this name type
within their underlying mechanisms, it could be quite disruptive to remove
the type's definition from a successor to RFC-2743.  Unless we lack
suitably-demonstrated implementation experience with a set of mechanism
implementations (not necessarily all, or even most) and of applications
making use of this name type, I believe that its definition should remain.
I'd be interested in any comments that others within the GSS community might
have. 

--jl

> -----Original Message-----
> From: Martin Rex [mailto:[email-masked]]
> Sent: Friday, May 11, 2001 5:06 PM
> To: Linn, John
> Cc: [email-masked]
> Subject: Re: Soliciting additional GSS/Kerberos 
> interoperability results
> 
> 
> Linn, John wrote:
> > 
> > Kerberos WG:
> > 
> > This will be familiar news for those also subscribing to 
> the CAT-WG mailing
> > list, but I'd like to point out to others in the Kerberos 
> community that
> > we're looking for interoperability testing results which 
> could support
> > advancement of the GSS-API RFCs (2743, and 2744 and/or 
> 2853) to Draft
> > Standards.  We've some results already reported, but could use more.
> > Recognizing that several Kerberos-based GSS implementations 
> exist, I'd like
> > to solicit any summaries which their keepers can provide 
> concerning the
> > scope of testing undertaken, other implementations that 
> have been tested
> > against, and particularly the sets of GSS-selectable 
> features which were
> > exercised in testing.  Please send any results you can 
> offer either to the
> > CAT-WG list at [email-masked], or to me as 
> CAT-WG chair.
> > Thanks for any support you can provide in this effort. 
> 
> As it is, I really would like to see section 4.1 removed from
> rfc2743 when it is advance to draft standard because
> 
> (1) the non-support of this nametype by the majority of 
> gssapi mechanisms
> 
> (2) the flawed assumption by application protocol designers that the
>     use of *this* nametype would increase portabilty when in fact it
>     seriously limits portability to a single mechanism (Kerberos).
> 
> (3) the suggestion to "canonicalize" the hostname part via DNS,
> 
> 
> -Martin
> 
-++**==--++**==--++**==--++**==--++**==--++**==--++**==
This message was posted through the Stanford campus mailing list
server.  If you wish to unsubscribe from this mailing list, send the
message body of "unsubscribe ietf-cat-wg" to [email-masked]

---

From: Martin Rex <[email-masked]>
Date: Mon, 14 May 2001 18:43:45 +0200 (METDST)

Linn, John wrote:
> the type's definition from a successor to RFC-2743.

Why should it be disruptive.  The hostbased service name is still
present in rfc1964, the Kerberos gssapi mechanism, where it originates
and where it belongs.

rfc-2847 (lipkey) is an incomplete spec, just as rfc-2025 (spkm) is
an incomplete spec.  I've been complaining about spkm long ago and
I have raised that problem during WG last call of lipkey, but nobody
wanted to see the document delayed.  spkm and lipkey _both_lack_
a mechanism specific nametype and lipkey, although it requires
support for the hostbased service name, can not provide a definition
of how to map from the hostbased service name namespace into the
mechanism specific namespace, simply because such a namespace
was never defined.  How do you expect independent implementors
to come up with independent interoperable implementations if the
spec doesn't even contain the slightest hint about what to do?
I've seen several independent implementations of SPKM1 and not
two of them are interoperable on names.  GREAT work, really!

>                                                         Unless we lack

It would be perfectly sufficient to have the hostbased service name in the
gssapi mechanism spec only. 

Maybe not as drastic as removing them, we should at least indicate all
the nametypes in rfc-2743 as being purely optional and that a portable
application must be prepared that a gssapi mechanism may not be able
to map any of them into their mechanism native (or mechanism specific)
namespace.

The notion of hostbased service names is very Kerberos-specific.
Other GSS-API mechanisms or when used with non-TCP/IP transports
or when used across firewalls/proxies the notion of hostbased
service names does not scale to today's application environments.

The suggestion to transform the hostname part through DNS should
be removed, or at least be rewritten as

when used for mutual authentication, the hostname part of a hostbased
service name SHOULD NOT be transformed through an insecure naming
service like conventional DNS before being used for verifying
the authenticated peer.

-Martin