Subject: Soliciting additional GSS/Kerberos interoperability results

From: "Linn, John" <[email-masked]>
Date: Thu, 10 May 2001 12:59:37 -0400

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. 

--jl

---

From: "Douglas E. Engert" <[email-masked]>
Date: Thu, 10 May 2001 13:04:17 -0500

> Standards.  We've some results already reported, but could use more.

If its 2743 and 2744 you would like to move along, then you must also be interested
 in GSS mechanisms other then Kerberos and how they could be written to use these 
RFCs. The Globus GSI  which implements a GSS using PKI and SSL is one example.
See: http://www.globus.org 

As we pointed out at the last IETF, we wished that there where a few additions
to the RFCs, but did not find any problems with the current RFCs themselves. 

As an interoperability example, the Globus applications (including ssh and ftp) are
written to work with either the GSI or the Kerberos mechanisms. This choice can be made
at link time. When using the ssh client, SecureCRT, on Windows, the choice can be made
at run time via a DLL. (If the mechglue was working for UNIX, UNIX could make the choice
at run time too.) 

So I would say that these RFCs are in good shape, and could move forward. 

-- 

 Douglas E. Engert  <[email-masked]>
 Argonne National Laboratory
 9700 South Cass Avenue
 Argonne, Illinois  60439 
 (630) 252-5444

---

From: Martin Rex <[email-masked]>
Date: Fri, 11 May 2001 23:05:40 +0200 (MET DST)

> 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

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 11 May 2001 17:37:28 -0400

> (3) the suggestion to "canonicalize" the hostname part via DNS,

Why? Elsewhere you suggest it's ok to use an insecure service location
mechanism since GSS mutual authentication will defeat attacks on the
lookup mechanism? Or did I mis-read your post?

Granted, DNS is a poor service lookup system... But it is what we've
got.

> -Martin

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Fri, 11 May 2001 23:57:08 +0200 (METDST)

> lookup mechanism? Or did I mis-read your post?

Transformations on the authenticated name must be performed in a
secure fashion.  Looking up the where a particular service lives
doesn't require protection if you perform mutual authentication,
because you are able to detect an attack.

Protecting the lookup of the address of the service would *not* save
you, the attacker could still capture/redirect your communication
with the target on the network.

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Sun, 13 May 2001 01:12:55 -0400

I may be myopic, but I see no difference between using insecure service
location services and using insecure server address resolution services.
Either way mutual authentication will allow the [savvy] user to detect
any attack on those insecure services.

The problem I do see is that an attacker may redirect users to
legitimate hosts which the attacker has broken and such aliasing may
look normal to the user (*) -- but if the attacker has broken into
legitimate servers and your lookup protocols and network setup are so
open to tampering, then you've got *big* problems.

(*) This may be what you meant, but I think this can happen even with
    insecure service location protocols, not just insecure address
    resolution protocols.

Cheers,

Nico

--

---

From: Martin Rex <[email-masked]>
Date: Mon, 14 May 2001 10:37:35 +0200 (METDST)

Nico,

Nicolas Williams wrote:
> Martin Rex wrote:

The transformation of the authenticated name is the operation that
*MUST* be performed in a secure manner.  I.e.  if the target name
supplied by the initiator to establish a mutually authenticated
connection is *NOT* the same as the canonical name of the credentials
that the service uses for accepting the security context, then any
transformation of the initiator's target name ("canonicalization")
to the representation that *exactly* matches the name of the
target's credentials *must* be performed in a secure fashion,
otherwise that authentication is not secure (or sometimes
it is even *no* authentication -- see HTTPS).

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 14 May 2001 10:41:41 -0400

Yes, but what I can't see is the difference between insecure service
location and insecure address resolution protocols.

Nico
--

---

From: Derek Atkins <[email-masked]>
Date: 14 May 2001 11:13:59 -0400

> location and insecure address resolution protocols.

This is the "authenticating an identity" problem that has been
discussed to death, here.  To use the SSL example, a user types in
"https://www.foo.com/", which is the only user input.  The system
performs a service lookup and determines that protocol "https" for the
domain "www.foo.com" needs to contact host "xxx.yyy.zzz".  Then DNS is
consulteed to determine that host xxx.yyy.zzz is at IP Address
1.2.3.4.

The problem is that unless the "www.foo.com" -> "xxx.yyy.zzz" lookup
is done securely, there is no way to authenticate.  One "secure" way
would be for xxx.yyy.zzz to _know_ that they are www.foo.com.  Another
secure way would be to have the KDC make that assurance.  Yet another
would be DNSSec, or some other "secure" service location/naming
service.

Without this secure re-naming, a client only has "www.foo.com" and the
server only has "xxx.yyy.zzz".  Clearly there needs to be a secure
translation (or equality match) between these two names.

The reason DNS can be used in-securely is that the host at IP Address
1.2.3.4 can know that it's name is www.foo.com.  However, the people
at yyy.zzz have no control over the what the people at foo.com put in
their service location database.  For example, ftp.gnu.org used to
point to aeneus.ai.mit.edu, which then pointed to aeneus.mit.edu.
This is perfectly "legal", but how is aeneus supposed to know all the
names that refer to it, when some names are controled by other
administrators?

> Nico

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [email-masked]                        PGP key available

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 14 May 2001 11:31:16 -0400

I understand. Martin Rex had claimed in [1] that using insecure service
location protocols was not a problem. I think it is. I probably
mis-understood.

IMHO, secure service location and address resolution systems are needed.

DNSSEC, as it stands, will probably not succeed -- it would be much more
practical to authenticate the DNS servers and the resolvers to each
other than it is to authenticate every RR to every requestor, but
long-lived TCP connections would be needed to help spread the cost of
authentication over multiple requests, and a flag would be needed to
indicate wether [recursive] query responses have been authenticated
end-to-end. That said, I do hope DNSSEC becomes the norm...

[1] <[email-masked]>

Nico

--

---

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

> end-to-end. That said, I do hope DNSSEC becomes the norm...

IMO there should be a *secure* directory for users to search/browse
for services and other users, and that directory should provide
the canonical names of such services plus a location anchor.
i.e.  SAP's official FTP-Server has the canonical name "[email-masked]"
and the location anchor is "ftp.sap.com".

DNS maps ftp.sap.com to foo.sap-ag.de and DNS resolves it to an IP-Address.

Our operations team should be free to move the machine around between
subnets (or renumber subnets), move the service from machine foo to
machine bar or add more machines to run the service and put up
round-robin DNS A records or set up a NAT for load balancing.

The information of where this service lives at a certain day should be
seperated from the authenticated identity.  Unfortunately, with
Kerberos most people tie the Kerberos authentication into their
network setup (using hostbased service names) and therefore
make it difficult for operations or painful for users when the
network setup of the service needs to be changed.  That is
a major pain (ita).

-Martin