Subject: Working Group Last Call: GSS-API Domain-Based Service Names and Name Type

From: Jeffrey Altman <[email-masked]>
Date: Tue, 15 Aug 2006 22:37:52 -0400

The Kitten Chair has received a request to submit "GSS-API Domain-Based
Service Names and Name Type"
<http://www.ietf.org/internet-drafts/draft-ietf-kitten-gssapi-domain-based-names-02.txt>
to the IESG for publication as a Proposed Standard.

Abstract

   This document describes domainname-based service principal names and
   the corresponding name type for the Generic Security Service
   Application Programming Interface (GSS-API).

   Domain-based service names are similar to host-based service names,
   but using a domain name (not necessarily an Internet domain name)
   instead of or in addition to a hostname.  The primary purpose of
   domain-based service names is to provide a way to name clustered
   services after the domain which they service, thereby allowing their
   clients to authorize the service's servers based on authentication of
   their names.

A two week Working Group Last Call is being initiated to determine if
this document is ready for publication.   Positive acknowledgment of
document review and feedback is requested.

The working group last call will terminate at 00:00 EDT 30 August 2006.

_______________________________________________
Kitten mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/kitten

---

From: Sam Hartman <[email-masked]>
Date: Mon, 21 Aug 2006 15:14:07 -0400

Hi.

I'm a bit concerned that we have not actually thought through how to
apply domain based names to any actual application technology.

In particular, it looks like all the naming rules for the gssapi
mechanism in SASL would have to change in order to use domain based
names with SASL.

Have we actually thought this through enough that we believe we can
write documents describing how to use domain based names without
ending up changing details in the domain based name spec?

I would feel a lot more comfortable approving this document if it were
accompanied by something that actually used domain based names.
Absent that, I'd like to see discussion here that shows we've thought
through the transition issues.

While reviewing the document, I noticed the following:

   Consider LDAP.  LDAP [RFC3377] with SASL [RFC2222] and the Kerberos V
   mechanism [RFC1964] for the GSS-API [RFC2743] uses a hostbased
   principal with a service name of "ldap", a reasonable approach,
   provided there is only one logical LDAP directory in a Kerberos
   realm's domain, and that all ldap servers in that realm serve that
   one LDAP directory.  

How does LDAP assume there is one LDAP instance for a given domain?
If I have two independent LDAP servers they will have different host
principals.

I think you only run into problems with SRV records.  This needs to be
spelled out much more clearly.

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 21 Aug 2006 17:22:26 -0500

> apply domain based names to any actual application technology.

Me too.  I'm concerned that merely adding a domain component doesn't
tell one enough about the purpose of the given service.  I could see
two LDAP services for a given domain that are distinguished not by the
domain they serve (they serve the same domain) but by the schema they
use.  I'm not sure how to handle this, or whether we want to handle
this.  See the thread we had on instance naming.

> mechanism in SASL would have to change in order to use domain based

The SASL/GS1 mechanism (RFC2222, draft-ietf-sasl-gssapi) mention GSS-API
name types, or one name type anyways, GSS_C_NT_HOSTBASED_SERVICE, but
don't define any strict API, so I'm not sure that SASL/GS1 constrains us
here, or requires updating to truly be able to use the domain-based name
type.

> ending up changing details in the domain based name spec?

I have two use cases, and the draft describes them.  I think we do know
how to use domain-based names, and, IIRC, Microsoft already does.

> through the transition issues.

I believe we've had this discussion, and the draft does discuss
applications, though not normatively.

If you'd like we could hold up publication of these documents until a
document describing, say, the NFSv4 root server location facility (which
would use domain-based service names to authenticate NFSv4 domain root
servers differently from normal NFSv4 servers) is ready for concurrent
publication.

> spelled out much more clearly.

Yes, I'd intended to mention DNS SRV RRs there.  Thanks for catching
this.  Assuming we add text there about DNS SRV RRs, does your concern
go away?

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Mon, 21 Aug 2006 19:24:07 -0400

>>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:

    Nicolas> On Mon, Aug 21, 2006 at 03:14:07PM -0400, Sam Hartman
    Nicolas> wrote:
    >> Hi.
    >> 
    >> I'm a bit concerned that we have not actually thought through
    >> how to apply domain based names to any actual application
    >> technology.

    Nicolas> Me too.  I'm concerned that merely adding a domain
    Nicolas> component doesn't tell one enough about the purpose of
    Nicolas> the given service.  I could see two LDAP services for a
    Nicolas> given domain that are distinguished not by the domain
    Nicolas> they serve (they serve the same domain) but by the schema
    Nicolas> they use.  I'm not sure how to handle this, or whether we
    Nicolas> want to handle this.  See the thread we had on instance
    Nicolas> naming.

You seem to be assuming that the domain in a domain based names has
anything to do with the realm.  I assume it had to do with the string
used for srv record lookups.  Why would you have two different ldap
schemas in the same srv record rotation?

    >> In particular, it looks like all the naming rules for the
    >> gssapi mechanism in SASL would have to change in order to use
    >> domain based names with SASL.

    Nicolas> The SASL/GS1 mechanism (RFC2222, draft-ietf-sasl-gssapi)
    Nicolas> mention GSS-API name types, or one name type anyways,
    Nicolas> GSS_C_NT_HOSTBASED_SERVICE, but don't define any strict
    Nicolas> API, so I'm not sure that SASL/GS1 constrains us here, or
    Nicolas> requires updating
It is my reading of gs1 that it normatively requires hostbased names.

--Sam

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 22 Aug 2006 10:52:07 -0500

> schemas in the same srv record rotation?

Right, thank you -- you've just made my instance naming concern go away.

Perhaps I should add some text specifically describing application use
of domain-based names in conjunction with DNS SRV RR lookups.

> It is my reading of gs1 that it normatively requires hostbased names.

That it does, but to the exclusion of all others?  That I'm not sure of;
RFC2222 does say "MUST use GSS_C_NT_HOSTBASED_SERVICE for acceptor
names."  Perhaps that was an oversight and we should read it as
normatively requiring use of hostbased service principal names for
acceptors.  If we do this then, then would we be able to update GS1?

Should we hold this discussion on the SASL list?

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 22 Aug 2006 12:24:19 -0500

Sam> It is my reading of gs1 that it normatively requires hostbased names.

Sam thinks GS1 excludes use of other name types for acceptors.

I think so too, but I'm not sure that GS1/GS2 need updating as much as
applications do -- certainly applications that wish to use domain-based
names will need updating.

I don't read GS1 to prohibit use of other name types but as providing a
required name type when a priori knowledge of server support for other
name types is not available.  Clients and servers wishing to use name
types other than hostbased service clearly have to agree a priori and
SASL/GS1 implementations have to make it possible (which they might
not); there is no negotiation mechanism..

Applications will require updates to use domain-based names.

GS1 can be said to be a GSS-API application, thus it would need an
update, but SASL/GS1 applications will need updates also, which brings
us to: why bother updating GS1 for this then?

I think the answer would be "so that SASL/GS1 implementors could know to
design their APIs accordingly."

Again, the applications we have in mind: LDAP server discovery through
DNS SRV RRs, and NFSv4 root server discovery through DNS SRV RRs.

If there's any way to insert text into draft-ietf-sasl-gssapi about this
then I would opt for that, though it should not mention domain-based
name types specifically.  Similarly for GS2.  Something like:

   Clients MAY use name types other than GSS_C_NT_HOSTBASED_SERVICE to
   import servers' acceptor names, but only when they have a priori
   knowledge that the servers support alternate name types.  Otherwise
   clients MUST use GSS_C_NT_HOSTBASED_SERVICE for importing acceptor
   names.  Applications should specify what alternate name types may be
   used and in what circumstances.

> Should we hold this discussion on the SASL list?

I'll assume yes.  Cross-posting.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 22 Aug 2006 12:31:00 -0500

On Tue, Aug 22, 2006 at 12:24:19PM -0500, Nicolas Williams wrote:
>                               Clients and servers wishing to use name

Well, there will have to be negotiation mechanisms, but these will have
to be application-specific.  For NFSv4 the mere existence of the
relevant SRV RRs should indicate that the given NFSv4 servers support
domain-based names.  For applications where existing clients already SRV
RRs the apps may need to specify a new front label for the SRV RR lookup
such that presence of the RRs for the new names indicates support for
domain-based names.

Yes, I think the domain-based name type I-D should have additional text
about this.  I will post a proposal later today.

Nico
--

---

From: Jeffrey Altman <[email-masked]>
Date: Tue, 22 Aug 2006 13:48:36 -0400

Speaking as an individual and not as Kitten Chair.

> not); there is no negotiation mechanism..

I believe that given the cookbook style language of RFC 2222 that the
only reasonable interpretation is that only GSS_C_NT_HOSTBASED_SERVICE
was anticipated being used.   The lack of a MUST or SHOULD implies to
me that the authors never considered the possibility that there might
be another name type worth considering or that an alternative usage
model for SASL might require the use of an alternate name type.

The situation we are now confronting is a desire to use SASL for a
usage model that was not previously conceived, authentication involving
domain-based service names.  The question then appears to me to be more
general than the question of whether or not SASL-GSS-1 or SASL-GSS-2
must be updated.  Instead it appears to be "does SASL support the
concept of authentication with domain-based names at all?"  If the
answer is 'yes', then the limitations imposed by the cookbook style
description of how to call GSS_Import_Name from RFC 2222 must be
clarified to indicate when specific name types should be used.  If the
answer is that SASL does not support authentication using domain-based
names, then the SASL working group must decide whether or not it wants
to support those use cases in their specification.

In either case, I do not believe that answering the SASL question should
be a road block on the specification of domain-based service names at
the GSS-API layer.

Jeffrey Altman

---

From: Sam Hartman <[email-masked]>
Date: Tue, 22 Aug 2006 14:46:20 -0400

>>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:

    Nicolas> On Mon, Aug 21, 2006 at 07:24:07PM -0400, Sam Hartman
    Nicolas> wrote:
    >> >>>>> "Nicolas" == Nicolas Williams <[email-masked]>
    >> writes: You seem to be assuming that the domain in a domain
    >> based names has anything to do with the realm.  I assume it had
    >> to do with the string used for srv record lookups.  Why would
    >> you have two different ldap schemas in the same srv record
    >> rotation?

    Nicolas> Right, thank you -- you've just made my instance naming
    Nicolas> concern go away.

    Nicolas> Perhaps I should add some text specifically describing
    Nicolas> application use of domain-based names in conjunction with
    Nicolas> DNS SRV RR lookups.

Please.

---

From: Sam Hartman <[email-masked]>
Date: Tue, 22 Aug 2006 14:47:20 -0400

Note that for things like krb5,, the existence of the domain based
principal may serve as a hint that domain based names are OK.

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 22 Aug 2006 14:12:31 -0500

> principal may serve as a hint that domain based names are OK.

But this is very specific to Kerberos V.  I would not want to rely on
this for negotiation, though I'd be happy with a MAY about it.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 22 Aug 2006 15:25:00 -0400

> be a road block on the specification of domain-based service names at

Nor do I.  I see immediate uses for domain-based service names in a variety 
of non-SASL applications, including SSH, AFS, and NFSv4, just to name a 
few.  Yes, it may be necessary in some cases to modify the application 
protocol specifications to allow the use of domain-based names.  I don't 
consider that to be a significant problem.

-- Jeff

---

From: Sam Hartman <[email-masked]>
Date: Tue, 22 Aug 2006 15:36:48 -0400

>>>>> "Jeffrey" == Jeffrey Hutzelman <[email-masked]> writes:

    Jeffrey> On Tuesday, August 22, 2006 01:48:36 PM -0400 Jeffrey
    Jeffrey> Altman
    Jeffrey> <[email-masked]> wrote:

    >> In either case, I do not believe that answering the SASL
    >> question should be a road block on the specification of
    >> domain-based service names at the GSS-API layer.

    Jeffrey> Nor do I.  I see immediate uses for domain-based service
    Jeffrey> names in a variety of non-SASL applications, including
    Jeffrey> SSH, AFS, and NFSv4, just to name a few.  Yes, it may be
    Jeffrey> necessary in some cases to modify the application
    Jeffrey> protocol specifications to allow the use of domain-based
    Jeffrey> names.  I don't consider that to be a significant
    Jeffrey> problem.

In order to take the document to the IESG I need to be convinced that
it is done.  It would be much easier for me to do that if I saw how to
adapt existing applications.

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 22 Aug 2006 14:38:54 -0500

>     Nicolas> DNS SRV RR lookups.

5.  Server discovery, examples

   Domain-based names are intended for use with applications that may
   discover servers in insecure ways, particularly applications that use
   DNS [STD0013] SRV [SRV] resource record lookups and which cannot count on
   [DNSSEC].

   Initiator applications first query DNS for the SRV RRs for a given
   domainname (e.g., _ldap._tcp.<domain>.).  Then for each SRV RR
   selected by the application (usually one) the application formats a
   string of the form

   <service>@<domainname in SRV RR query>@<server name from selected RR>

   For example, "[email-masked]@ds1.example.com".

   The initiator application MUST know a priori whether the acceptor
   is expected to have credentials for domain-based names.

   Application protocol developers must specify how such a priori
   knowledge is determined, and in what circumstances fallback to
   host-based service naming is allowed, if any.  See Section 6.

6.  Security Considerations

   ...

   Negotiation of use of domain-based versus host-based principal naming
   may be open to downgrade attacks if not designed properly.  For
   example, negotiation of name-type through SRV RR naming conventions
   is open to downgrade attacks through DNS if DNSSEC is not used.

   Another example: applications which rely on the Kerberos V GSS-API
   mechanism [RFC1964] or similar, to negotiate acceptor support for
   domain-based names in the TGS exchange (i.e.,
   KDC_ERR_S_PRINCIPAL_UNKNOWN implying no acceptor support for
   domain-based names) are open to downgrade attacks through spoofed
   KRB-ERROR TGS replies.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 22 Aug 2006 14:45:04 -0500

> adapt existing applications.

See text I just posted.  Please add suggestions.

I am willing to submit an Internet-Draft describing NFSv4 domain root
server discovery if it would help.  It would essentially contain the
text I just posted, using 'nfs' as the GSS-API service name, and
'_nfs._tcp.<domainname>.' as the SRV RR name.  No negotiation would be
provided; instead use of domain-based acceptor names for root servers
would be REQUIRED, with the ability to optionally configure use of
host-based names for specific domains, or all domains.  Such a document
would not say much more, if anything, about NFSv4 global namespace
construction.  I am not sure how quickly such a document could progress,
or how quickly it could become an NFSv4 WG item, if at all.

Nico
--

---

From: Jeffrey Altman <[email-masked]>
Date: Tue, 22 Aug 2006 16:49:17 -0400

>    domain-based names) are open to downgrade attacks through spoofed

I think this text is on the mark.

Jeffrey Altman

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 22 Aug 2006 16:07:33 -0500

> > RFC2222 does say "MUST use GSS_C_NT_HOSTBASED_SERVICE for acceptor
                 ^
		 not
> This seems to be an unfortunate and serious flaw in RFC2222

Think of it as a GSS-API application (or class of applications, as it
encompasses all SASL applications that would use the GSS-API through
SASL) that was only interested in host-based service names.

It is perfectly fine for a GSS-API application to restrict itself to
only one kind of peer.

So, it's not that serious a flaw.  Also, the fix is obvious, obvious
enough that I'm not sure that we really need to update SASL/GS1 (RFC222,
draft-ietf-sasl-gssapi), but don't mind doing if there's still time for
updating draft-ietf-sasl-gssapi and the SASL WG agrees.

Think of RFC2222 as specifying a default acceptor name type for all
SASL/GS1 applications.  For all other acceptor name types the
application must know a priori that it may/should/must use such other
name types.

Nico
--

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 22 Aug 2006 17:24:36 -0400

On Tuesday, August 22, 2006 04:07:33 PM -0500 Nicolas Williams 
<[email-masked]> wrote:

>> > That it does, but to the exclusion of all others?  That I'm not sure
>> > of; RFC2222 does say "MUST use GSS_C_NT_HOSTBASED_SERVICE for acceptor
>                  ^
> 		 not

Incidentally, I think we can specify separate behavior for GS1 and GS2. 
The GS1 document is specific to Kerberos, and so we can do things like have 
it try a domain-based service name and then fall back to a host-based one, 
though existing libraries could not do that without information from the 
application as to the hostname of the server.

Note, BTW, that when I speak of falling back to a host-based service name, 
I'm talking about a service name constructed using the service domain name, 
not a hostname derived from reverse DNS or other insecure sources.

-- Jeff

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 22 Aug 2006 16:28:24 -0500

And yes, there should still be time to so update draft-ietf-sasl-gssapi
as it's in Revised ID Needed state.  The update would be a small change
to the first paragraph of section 3.1.  Unfortunately that paragraph is
already quite long, and I'd hesitate to make it any longer.

Alexey, can we split that paragraph into more manageable chunks?

Something like:

   The client calls GSS_Init_sec_context, passing in

    o input_context_handle == GSS_C_NO_CONTEXT (initially)
    o mech_type == the Kerberos V5 GSS-API mechanism [KRB5GSS]
    o chan_binding == NULL
    o input_token == NULL
    o sequence_req_flag == TRUE
    o integ_req_flag == TRUE
    o conf_req_flag == TRUE if the client will be requesting a security
      layer providing confidentiality protection
    o targ_name -- (see below)

[Aside: the spec says to set sequence_req_flag == TRUE, but
replay_det_req_flag == TRUE should have sufficed, since SASL is stream-
oriented.  Oh well.]

   Typically clients will obtain a NAME for the acceptor by calling
   GSS_Import_name() with GSS_C_NT_HOSTBASED_SERVICE as the
   input_name_type and an input_name_string with the form
   "service@hostname" (see [RFC2743]) where "service" is the service
   name specified in the protocol's profile, and "hostname" is the fully
   qualified host name of the server.  Clients MAY use other name types
   for servers, but MUST know a priori and as decribed in the protocol's
   profile, whether such other name types are allowed.  Hostbased
   service SHALL be the default name type for server for any
   protocol profile which does not specify one.

   The client then responds with the resulting output_token.  If
   GSS_Init_sec_context returns GSS_S_CONTINUE_NEEDED, then the client
   should expect the server to issue a token in a subsequent challenge.
   The client must pass the token to another call to
   GSS_Init_sec_context, repeating the actions in this paragraph.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 22 Aug 2006 16:29:50 -0500

> application as to the hostname of the server.

See the proposed security considerations text in my earlier post.

Nico
--

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 22 Aug 2006 17:37:11 -0400

On Tuesday, August 22, 2006 04:29:50 PM -0500 Nicolas Williams 
<[email-masked]> wrote:

>> The GS1 document is specific to Kerberos, and so we can do things like
>> have  it try a domain-based service name and then fall back to a
>> host-based one,  though existing libraries could not do that without
>> information from the  application as to the hostname of the server.
>

Your text describes a potential "downgrade" attack.  But downgrading to 
host-based service names is only an attack if it somehow makes the 
connection less secure.  That might be the case if you downgraded from 
using a domain-based service name to using a host-based name constructed 
using a hostname from reverse DNS or some other insecure source.  But 
that's not how host-based service names are supposed to work today, and 
it's not what I was proposing.

-- Jeff

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 22 Aug 2006 17:48:13 -0400

>    protocol profile which does not specify one.

No; SASL protocols are mechanism-agnostic, and mechanisms are 
protocol-agnostic.  You cannot require SASL protocol provides to 
parameterize specific mechanisms in this way.

In the case of GS1, I think we can produce something which works and is 
interoperable with what is deployed today, by using a domain-based service 
name if the initial init_sec_context works with that name, and falling back 
to a host-based name otherwise.  Note my previous message explaining why 
there is no attack here, as long as the host-based name is formed correctly.

In the case of GS2, we are defining a new protocol which no one has yet 
deployed.  Thus, we have the opportunity to build in a mechanism by which 
we try establishing a context with a domain-based service name and, if that 
fails, try again with a host-based service name, all without the app 
knowing anything about it.

In either case, existing SASL libraries will probably require modifications 
to allow the application to pass down information about the identity of the 
specific host to which we're authenticating, which is needed in order to 
construct a domain-based service name.

-- Jeff

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 22 Aug 2006 16:50:11 -0500

> it's not what I was proposing.

It's a downgrade attack if the server discovery method is insecure.  I
need to make that clearer in the sec cons text, particularly in the
paragraph that discusses the downgrade due to the lack of integrity
protection for KRB-ERROR in the TGS exchange.

Nico
--

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 22 Aug 2006 17:53:15 -0400

On Tuesday, August 22, 2006 04:50:11 PM -0500 Nicolas Williams 
<[email-masked]> wrote:

> It's a downgrade attack if the server discovery method is insecure.

No.  It's a downgrade if the construction of the host-based service name is 
insecure.

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 22 Aug 2006 16:55:14 -0500

> parameterize specific mechanisms in this way.

Huh?  draft-ietf-sasl-gssapi-06 already talks about "protocol profile,"
by which what is meant is that SASL applications, such as LDAP, IMAP,
etcetera, have to provide some parameter or other.  In the case of
draft-ietf-sasl-gssapi-06 the one parameter that is required of
application protocol profiles is the service name for use in hostbased
service names.

> there is no attack here, as long as the host-based name is formed correctly.

How could GS1 implementations possibly do this without the application
telling them what domainname to use for domain-based service names?
Deriving the domainname from the hostname would be incorrect.  No, GS1
cannot do this.

> knowing anything about it.

Not unless the application provides a domainname.  The application has
got to be in control here.

> construct a domain-based service name.

And the domainname too.  Without a doubt SASL/GS* implementations have
to present APIs which make use of domain-based names possible, else they
cannot make use of domain-based names.

Nico
--

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 22 Aug 2006 17:57:18 -0400

On Tuesday, August 22, 2006 05:53:15 PM -0400 Jeffrey Hutzelman 
<[email-masked]> wrote:

> No.  It's a downgrade if the construction of the host-based service name
> is insecure.

The mistake is conflating the name of the service with what is returned in 
a DNS SRV record.  The SRV record doesn't tell you the name of the service; 
it tells you a DNS domain name that's supposed to resolve to the network 
address you connect to in order to talk to the service.

If I want to talk to the 'imap' service for 'imap.srv.cs.cmu.edu', then the 
correct service name is either [email-masked]@some.host' or 
[email-masked]'.  It should never be [email-masked]'.

-- Jeff

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 22 Aug 2006 16:11:27 -0400

> adapt existing applications.

Personally, I'd love to be able to assume that if you can get as far as the 
first call to init_sec_context, then all is well; that's the technique that 
applications already use to determine whether to offer a GSS-API-based 
mechanism at all.  But, as Nico pointed out, that may not work for every 
mechanism - there will certainly be mechanims for which clients can get 
credentials for _any_ service name.

So, there needs to be an application-specific negotiation.  For SSH key 
exchange, I'd expect that to take the form of a new family of mechanism 
names.  For SSH user auth, I'd expect clients to try with a domain-based 
service name, and then fall back to trying the same mechanism with a 
host-based service name.  For _new_ applications, one might simply specify 
the use of domain-based service names to begin with.

-- Jeff

---

From: Martin Rex <[email-masked]>
Date: Wed, 23 Aug 2006 00:38:04 +0200 (MET DST)

> protection for KRB-ERROR in the TGS exchange.

Hostbased service names as they described in RFC-2743 and as they
had been implemented in MIT Kerberos for more than a decade suffer
a serious vulnerability.  They transform the target name with
the help of INsecure DNS lookups.

Any kind of transformations on the authenticated name through
insecure DNS are a bad idea and implementations should stop suggesting
applications to use functionality that -today- is provided through
insecure DNS.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Wed, 23 Aug 2006 00:47:17 +0200 (MET DST)

>    domain-based names) are open to downgrade attacks through spoofed

Downgrade attack?

The vulnerability might be magnitude more serious than that.

For hostbased service names the transformation as suggested by
RFC-2743 and as implemented in MIT Kerberos 5 allows for a
>>> FULL COMPROMISE <<< (i.e. failure of the mutual authentication)
if the attacker can break into an arbitrary machine
of the realm that has a local key for the desired service
(every machine has a host service, so this one is the most
 vulnerable service of all), and then spoof the insecure
DNS lookup.  Spoofing DNS may also make it easier to redirect
the actual network communication.

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 22 Aug 2006 18:08:21 -0500

One step at a time Martin :)

Yes, we know about hostname canonicalization attacks.

Perhaps we should focus on that first.  If that's your point, say so :)

(I do have a proposal for dealing with hostname canonicalization, one
that is both, applicable to various mechanisms generally, though the
details are specific to each mechanism, and the proposal is really for
GSS-APIv3, not v2.)

In the end the bottom-line is that applications really should interact
with users when hostname canonicalization was performed securely, if
insecure hostname canonicalization is performed at all.

I argue that some users really do want DNS search lists used in hostname
canonicalization because they are very much used to that in
traditionally non-GSS applications, such as web browsers.  The moment
one has DNS search lists securing hostname canonicalization becomes
difficult.  Think of a PKI-based mechanism, where the client won't know
how to really canonicalize[*] the name until it's seen the server's
certificate.

[*]  Forget impractical GSS niceties like gss_canonicalize_name() being
     supposed to give you the canonical version of the given name -- for
     a PKI-based mech w/o a secure directory upfront this isn't
     possible.)

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 22 Aug 2006 18:10:21 -0500

On Tue, Aug 22, 2006 at 06:59:39PM -0400, Jeffrey Hutzelman wrote:
> >>In either case, existing SASL libraries will probably require
> >>modifications  to allow the application to pass down information about
> >>the identity of the  specific host to which we're authenticating, which
> >>is needed in order to  construct a domain-based service name.
> >
> >And the domainname too.
> 
> Yes.  Today, the application has to present one name; to do domain-based 
> names, it has to present two.

So?  The APIs have to change.  Even with your proposal they have to
change, and it means that the application has to provide one more
parameter.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 22 Aug 2006 18:59:39 -0400

> application protocol profiles is the service name for use in hostbased

Yes; SASL applications ("protocols", in SASL-speak) are described by a 
"profile" which describes how to use that application with SASL.  One of 
the things that must be specified is a service name; this is generic to the 
SASL framework, not specific to that mechanism.

More later, after we've finished our off-list discussion.

---

From: Martin Rex <[email-masked]>
Date: Tue, 22 Aug 2006 22:35:52 +0200 (MET DST)

Hostbased service names are optional for GSS-API mechanisms,
and the vast majority of gssapi mechanisms that I know doesn't
implement them at all.

If SASL does not have a fallback for use with GSS-API mechanisms
that do not support hostbased service names, then the GSS-API related
part of the spec is seriously broken.

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 22 Aug 2006 18:23:51 -0500

Jeff H. points out that the main reason to want domain-based names as
opposed to hostbased-names-with-domains-as-hostnames is to avoid
acceptor credential sharing.  In both cases we want to protect
initiators from redirection attacks during unprotected server discovery.

Jeff would like the Kerberos V GSS mechanism, or SASL/GS* when using the
Kerbreos V GSS mechanism to support fallback to hostbased-names-with-
domains-as-hostnames when the KDC responds KDC_ERR_S_PRINCIPAL_UNKNOWN
to requests for service tickets with domain-based service principal
names.

I think it's very important to avoid acceptor credential sharing because
of the complexities of sharing replay caches (or ensuring that they are
not needed) much more than because of any desire not to share keys
amongst members of a cluster.  I do not entirely oppose such a fallback
mechanism -- I agree that there is no downgrade attack there, but there
is the issue of replay cache sharing, which does complicate things.

Thoughts?

Nico
--

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 22 Aug 2006 19:47:54 -0400

> This seems to be an unfortunate and serious flaw in RFC2222

RFC2222 is not current.
RFC4422 does not define the GSS-API mechanisms; those are separate 
documents.

> and the vast majority of gssapi mechanisms that I know doesn't

You've made this argument before.  Mechanisms which do not support 
host-based service names require the application to understand a 
mechanism-specific name type.  That may be fine for SAP, but it's 
unacceptably and unnecessarily complex for SASL.

-- Jeff

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 23 Aug 2006 11:44:59 +0100

>model for SASL might require the use of an alternate name type.
I agree with this conclusion (I wasn't working on RFC 2222)

>concept of authentication with domain-based names at all?"
>
When integrating SASL into SMTP, IMAP and LDAP servers I always assumed 
that the answer to this question was "yes".

>If the answer is 'yes', then the limitations imposed by the cookbook style

---

From: Martin Rex <[email-masked]>
Date: Wed, 23 Aug 2006 14:56:58 +0200 (MET DST)

> unacceptably and unnecessarily complex for SASL.

There seems to be a misunderstanding.

An application doesn't need to know the slightest about a gssapi
mechanism and the nametypes it supports.

gss_import_name() does not require a nametype OID when importing
a printable name -- the mechanism is supposed to interpret the
input with his preferred nametype; for Kerberos it is a
Kerberos principal name.

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 23 Aug 2006 08:11:39 -0500

> mechanism and the nametypes it supports.

But application protocol specs can and do specify what name types to
use.  Think of GS1 as part of the application.

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Wed, 23 Aug 2006 16:55:38 +0200 (MET DST)

> use.  Think of GS1 as part of the application.

As far as GSS-API is concerned, the most what an application protocol
could do is recommendation.  There is no mandatory to implement
nametype, so applications cannot mandate one, either.

Most of the problems root on misconceptions about authentication,
and on the design flaw of Kerberos which requires the initiator
to know the name of the acceptor ahead of time, even if the
initiator does NOT want to (or is not able to) perform mutual
authentication (authenticate the server).

By coming up with clever schemes to correctly guess the Kerberos
principal name of the acceptor, the initiator may be able to
successfully establish a protected communication, but it is
not actually performing a real mutual authentication.

Hostbased service names canonicalized through insecure DNS
is even worse than the weak endpoint identification
performed by Web Browsers when using HTTPS.

If you add insecure transforms (i.e through an insecure directory
lookup, e.g. plain old DNS) on cleverly guessed names, then
you will spoil even the weak endpoint identification.

The ssh leap-of-faith is much better in this respect, because it
realizes the underlying problem and (a) suggests to perform
out-of-band endpoint verification on first encounter and
(b) memorizes user-acknowledged endpoint identification and
enforces future transformations to come to the exact same result.

I never liked DCE (primarily because of its licensing scheme
when it started), but at least they got the architecture right.
A secure Directory service was integral part of the architecture
and in order to find the location and instance-specific identity
of a distributed service, you would do a directory lookup to
acquire these two coneptually seperate pieces of information:
network-location (for establishing the network communication)
and identity of the service.

Requiring hostbased names to work (or even expecting them to work)
is about as flawed as expecting that all mankind should consent on
and switch to one single commmon human language, one single
common identity card, one single programming language, one single
computer architecture and CPU, etc.  It will not happen and
ignorance is not a suitable approach.

-Martin

common programming language, one single common Computer

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 23 Aug 2006 16:13:43 +0100

Nicolas Williams wrote:

>name types specifically.
BTW, DIGEST-MD5 already allows for domain-based names.

>Similarly for GS2.  Something like:
>
I am Ok with adding this text.

>  Applications should specify what alternate name types may be
Is this a requirement on implementations or protocol specs?

---

From: Sam Hartman <[email-masked]>
Date: Wed, 23 Aug 2006 11:22:59 -0400

>>>>> "Martin" == Martin Rex <[email-masked]> writes:

    Martin> Nicolas Williams wrote:
    >> > An application doesn't need to know the slightest about a
    >> gssapi > mechanism and the nametypes it supports.
    >> 
    >> But application protocol specs can and do specify what name
    >> types to use.  Think of GS1 as part of the application.

    Martin> As far as GSS-API is concerned, the most what an
    Martin> application protocol could do is recommendation.  There is
    Martin> no mandatory to implement nametype, so applications cannot
    Martin> mandate one, either.

I'm going to get in here early and stop this discussion before it gets
out of hand as this has the potential to turn into a real flame war.

The IETF has a need for interoperability.  The best way we've come up
with to get that is to assume that GSS mechanisms used with IETF
applications support host based names and to work to make sure that's
true.  That's why Nico has spent so much time working with the Umich
folks on the SPKM3 update discussing host based names.

You are completely correct that you have identified several problems
with this approach.

First, if you see a way of using GSS-API that provides the same or
better usability experience to end users for applications like ssh,
nfs, etc without relying on host-based names, please let us know.  I
ask that you do so in another thread.  If you would like to engage in
a discussion of requirements for such a solution, I'm sure we'd all be
happy to have that discussion.

Secondly, we generally care about mutual authentication.  It would be
great to work on things like a version of RFC 4121 that allowed the
acceptor to tell you what name to use and that you could later
validate that name.  (This interacts badly with delegation)
It would be great to do a number of other things that reduced the dependence on host based names.
ONCE THESE ARE DONE, we can come back and start using them in our protocols.

It is not useful to tell us all that systems we have working are
fundamentally flawed or to tell us that things we're doing should not
be done without providing alternatives.  I don't know if that is what
you were trying to do, but that's how I read your message.  Again,
you've identified several areas for future work--we agree.

However until we have alternatives, we need host based names.

I do not think this discussion is on topic for the domain based names
draft.

Sam Hartman
Security Area Director

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 23 Aug 2006 08:10:08 -0500

On Wed, Aug 23, 2006 at 11:44:59AM +0100, Alexey Melnikov wrote:
> Jeffrey Altman wrote:
> >                             The question then appears to me to be more

Well, RFC4422 does require that a service name always be involved
(section 4, item (1)).  But it doesn't actually discuss the structure of
server names -- it doesn't even mention hostnames or domainnames.

What should one take away from this?

That SASL is underspecified on purpose in this area?  If so then one
might conclude that GS1 only provides a default name type for acceptors
and that applications are free to use any other name type provided that
it's some sort of service name type.

Or that SASL is accidentally underspecified and that in practice it only
supports host-based service names?  In which case the base spec and GS1
and/or GS2 need updating.

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Wed, 23 Aug 2006 11:29:27 -0400

>>>>> "Alexey" == Alexey Melnikov <[email-masked]> writes:

    Alexey> Nicolas Williams wrote:
    >> If there's any way to insert text into draft-ietf-sasl-gssapi
    >> about this then I would opt for that, though it should not
    >> mention domain-based name types specifically.
    >> 
    Alexey> BTW, DIGEST-MD5 already allows for domain-based names.

    >> Clients MAY use name types other than
    >> GSS_C_NT_HOSTBASED_SERVICE to import servers' acceptor names,
    >> but only when they have a priori knowledge that the servers
    >> support alternate name types.  Otherwise clients MUST use
    >> GSS_C_NT_HOSTBASED_SERVICE for importing acceptor names.
    >> 
    Alexey> I am Ok with adding this text.

As AD, I'm OK with adding this text if the SASL WG supports it.

As an individual, I support this text.

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 23 Aug 2006 16:41:49 +0100

> Is this a requirement on implementations or protocol specs?

Also, is this a normative statement or informative?

---

From: Sam Hartman <[email-masked]>
Date: Wed, 23 Aug 2006 11:59:24 -0400

A sasl mechanism spec SHOULd NOT make requirements on application
protocol specs.

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 23 Aug 2006 17:00:30 +0100

>A sasl mechanism spec SHOULd NOT make requirements on application
This is one of the reasons why I don't like the last sentence proposed 
by Nico. Is "application" means "protocol", the sentence violates the 
SHOULD NOT.

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 23 Aug 2006 11:30:06 -0500

> nametype, so applications cannot mandate one, either.

I think this is a bit expansive.  Mandating specific name types can be
expected to constrain the set of applicable mechanisms, and that's about
it.

> performed by Web Browsers when using HTTPS.

There are ways to do hostname canonicalization securely (namely: do no
DNS lookups, only append a pre-configured domainname to hostnames that
don't appear to be fully qualified).  If you want DNS-style search lists
(I think users are used to it and expect it) then it gets a bit more
complex.

> enforces future transformations to come to the exact same result.

But leap-of-faith is just that -- taking a leap of faith.  For hostname
canonicalization it happens to be a lot less iffy than for ssh server
public keys because names are a lot more likely to be meaningful to
users than public key fingerprints.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 23 Aug 2006 11:33:14 -0500

> BTW, DIGEST-MD5 already allows for domain-based names.

Oh!

I wish the base SASL spec talked about this sort of thing...

> Is this a requirement on implementations or protocol specs?

Application protocol specs.

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 23 Aug 2006 11:33:41 -0500

> Also, is this a normative statement or informative?

Normative, like the text in RFC4422, section 4.

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 23 Aug 2006 11:35:01 -0500

> A sasl mechanism spec SHOULd NOT make requirements on application

The text I proposed had a requirement only for applications that would
use name types other than the default.  I.e., apps need do nothing
unless they want to use domain-based names.

But we could work the requirement out.

---

From: Martin Rex <[email-masked]>
Date: Wed, 23 Aug 2006 18:37:25 +0200 (MET DST)

> use.  Think of GS1 as part of the application.

Host-based and domain-based service names are the only names for
which an application or protocol might perform an endpoint
identification instead of an authentication by deriving the
acceptors identity from the network location given by the
user or caller.

For other names, it will be generally impossible to substitute
the authentication with an endpoint identification.
If a mutual authentication is to be performed, then the
user or caller must know and provide the identity of the
acceptor to gss_init_sec_context().

Nametype (OIDs) are difficult to memorize and enter by a user and
nametype OIDs may even be non-portable among independent implementations
of the same gssapi mechanism -- e.g. with rfc-2025 (SPKM)

Therefore GSS-API v2 permits the use of a NULL nametype
OID when importing a printable name, which is a request for
a mechanisms "native" nametype -- for SPKM usually some kind
of printable distinguished name.

Applications that call gss-api ought to provide a means for the user
to provide the name that is passed to gss_init_sec_context() and
is entirely seperate from the network location parameters.
Applications should also provide a means to pass along a nametype
with the name, but they should not require a nametype and they
should not assume/attach a specific nametype (other than NULL) either.

-Martin

---

From: Sam Hartman <[email-masked]>
Date: Wed, 23 Aug 2006 12:54:36 -0400

>>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:

    Nicolas> On Wed, Aug 23, 2006 at 11:59:24AM -0400, Sam Hartman
    Nicolas> wrote:
    >> A sasl mechanism spec SHOULd NOT make requirements on
    >> application protocol specs.

    Nicolas> The text I proposed had a requirement only for
    Nicolas> applications that would use name types other than the
    Nicolas> default.  I.e., apps need do nothing unless they want to
    Nicolas> use domain-based names.

And so I'd prefer it be non-normative.  The normative requirement
should be stated in terms of the SASL mechanism: The client MAY use
another name type if it knows the server will support it.

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 23 Aug 2006 12:44:54 -0500

> another name type if it knows the server will support it.

Sure.

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 24 Aug 2006 18:00:25 +0100

Nicolas Williams wrote:

>(section 4, item (1)).
Yes, however mechanisms are free not to use it and many mechanisms don't.

>But it doesn't actually discuss the structure of
I think this is a mechanism specific issue. But I might be convinced 
that I am wrong.

Anyway, I think GSS1 should be updated to allow for other name types.

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 25 Aug 2006 18:16:12 +0100

>>another name type if it knows the server will support it.
Ok, I've added the following text:

I.e. I removed the last sentence you've proposed.

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 25 Aug 2006 15:27:39 -0500

On Fri, Aug 25, 2006 at 07:56:33PM +0200, Martin Rex wrote:
> There seems to be a significant misunderstanding in how GSS-API works.

I interpret your post as saying, in so many words, that the right thing
to do is to speak of "host-based service" not the specific name type
GSS_C_NT_HOSTBASED_SERVICE in prescribing what an initiator application
ought to do, since, after all, the application could use
mechanism-specific equivalents.

Is that correct?

If so I agree but I am not sure that I care.  Perhaps if you suggested
new text?

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Fri, 25 Aug 2006 19:56:33 +0200 (MET DST)

The nametype used by the client identifies the encoding (syntax&semantics)
of the printable name used by the client to authenticate the server
(in case of mutual authentication), or use as a hint to the gssapi
about the target (acceptor) for mechanisms such as Kerberos 5,
even with unidirectional authentication.

So this nametype is something that the local gssapi mechanism of
the client needs to understand&support, and the (human) user of
the client needs to use the respective syntax&semantics for
the accompanying printable name.

  i.e. an SSH client using Kerberos 5 gssapi for authentication
      could use network location (hostabc.f.q.d.n,tcp,port22) plus 

     a) the SSH client could automagically assert 

          /---- nametype ------\    /---- printable name ----\
          hostbased service name    "[email-masked]"

        to identify the acceptor

     b) or the user might explictly supply

          hostbased service name    "[email-masked]"

        to authenticate or the acceptor

     c) or the user might explictly supply

          kerberos principal name   "host/[email-masked]"

        to authenticate or the acceptor

   An SSH client using an SPKM gssapi for authentication will usually
   get an error message when trying to use hostbased service names,
   and have to explicitly supply a name:

          NULL name type          "CN=hostabc.f.q.d.n,UID=ssh,O=Foo Inc.,C=US"
     or
          proprietary name type   "CN=hostabc.f.q.d.n,UID=ssh,O=Foo Inc.,C=US"

In general, the server never gets to see what kind of name and nametype
the client used to create the gss_name_t "target_name" that it passes
to gss_init_sec_context().  (none of the gssapi mechanisms that I know
passes this name along.  Kerberos 5 passes it to the KDC for
acquiring a (service) ticket, SPKM-like mechanisms use it to
verify the subject DName of the acceptor from the acceptors certificate
that arrives with the second context level token (the first reply
token sent from acceptor back to initiator).

-Martin

---

From: Martin Rex <[email-masked]>
Date: Sat, 26 Aug 2006 01:58:19 +0200 (MET DST)

> If so I agree but I am not sure that I care.  Perhaps if you suggested

The text I didn't like talks about "what the server supports", but that
is inappropriate when talking about the target_name used by the initiator.

:   Clients MAY use name types other than GSS_C_NT_HOSTBASED_SERVICE to
:   import servers' acceptor names, but only when they have a priori
:   knowledge that the servers support alternate name types.  Otherwise

The server might be using SPKM from vendor a (which does NOT support the
hostbased service nametype), use credentials with an X.509 that from
a CA that issued it with a special naming convention.

Now if the client is using a different SPKM implementation that
implement GSS_C_NT_HOSTBASED_SERVICE and performs some sort of
endpoint identification (instead of an authentication) as proposed for 
SPKM3, then you would have the situation that the server doesn't
support hostbased service names, and still the client might succeed
in using it.

In a different (Kerberos-based) installation, an SSH-Server might be running
with a hostbased service name and a special ssh/hostabc.f.q.d.n principal
and a service mapping function ssh@somehost -> ssh/somehost.f.q.d.n
while the client might be using a different service mapping
ssh@somehost -> host/somehost.f.q.d.n.  This will cause the client
to fail the authentication when trying to use the hostbased service name.
But if the client uses ssh/somehost.f.q.d.n with the Kerberos principal
nametype directly the context establishment will succeed.

So whether a hostbased service name can be used depends primarily on

(a) does the initiators gssapi mechanism implementation implement
    this nametype

(b) does the initiators gssapi mechanism implementation's service
    mapping function transform a given hostbased service name to
    the correct principal name as used by the server (this might be
    a local configuration issue).

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 25 Aug 2006 22:15:39 -0500

> is inappropriate when talking about the target_name used by the initiator.

OK, it really should be something like "what the server has acceptor
credentials for."

> support hostbased service names, and still the client might succeed

Because it has credentials that authenticate the hostbased service that
the client wanted.  The details of how that happens are not relevant
here.

> [...]

A server that did this could not interoperate with a client that merely
followed RFC4462 and didn't provide an option by which the user could
provide an alternate service name.

This is why it's important for our specifications to tell us about
acceptor naming.

Even if the Kerberos V GSS-API mechanism allowed the acceptor to tell
the initiator what its name is (and we could define a new version of the
krb5 mechanisms, with a new OID, that did this), the client would still
have to know to use GSS_C_NO_NAME and then tell the user what name was
authenticated and ask if that's OK, or otherwise authorize the
authenticated acceptor name to the actual server/whatever name provided
by the client.  These are instructions that have to be provided by the
application protocol specific for at the common mode of operation,
otherwise we can't have interop.

>     a local configuration issue).

(c) does the acceptor have acceptor credentials for that name.  This is
important for mechanisms which, as you point out repeatedly, don't allow
the initiator to discover the acceptor's name instead of having to
always provide it upfront.

Tough.  Kerberos V is the interoperable mechanism we have, and hostbased
service naming is the interoperable form of server naming.  Can we go
beyond this?  SASL/GS1 is not going to depart from hostbased service
naming as the minimum requirement and common name type for
interoperability -- though we may add more.

Nico
--