Subject: RE: Crossrealm Referal

From: "John Brezak" <[email-masked]>
Date: Thu, 15 Feb 2001 10:04:07 -0800

Inline.

> -----Original Message-----
> From: Martin Rex [mailto:[email-masked]] 
> Sent: Tuesday, February 13, 2001 11:58 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: Crossrealm Referal
> 
> 
> 
> Douglas E. Engert wrote:
> > 
> > I would like to see the revisions go forward with the 
> canonicalization 
> > for the AS_REQ, and this new draft to cover the TGS. This 
> will allow 
> > the WG to concentrate on the revisions, while allowing indepenent 
> > discussing the merit of these new features.
> 
> I am strongly opposed to include the currently proposed 
> name canonicalization with the Kerberos revisions document.
> 
> It should either be fixed or removed!
> 
> It is broken because this behaviour will create a seriously 
> mis-behaving Kerberos gssapi mechanism.  To work under the 
> GSS-API model, a seperate-from-ticket-request name 
> lookup/canonicalization will be required, and it MUST be optional.
> 
> There is a serious problem with Microsoft's W2K Kerberos, and 
> I really want the Kerberos revisions spec NOT to bless this 
> incompatibility and GSS-API architecture violation and I 
> especially don't want to see it being promoted any further.
> 
> If you don't know what I'm talking about:
> Take a standalone (i.e. domain-less and directory-less) W2K 
> pro and attach it to a MIT Kerberos KDC.  Create a Kerberos 
> hostbased service principal for this workstation and try to 
> (a) install these credentials on the W2K machine and (b) try 
> to accept security contexts with these credentials on the W2K 
> machine using Microsoft's Kerberos.
> -- It's impossible!

[Jbrezak] You can take a standalone Win2000 server and configure it to
authenticate users presenting Kerberos credentials from a MIT Kerberos
realm.
Microsoft does test this as an interop scenario. Local accounts need to
managed to provide authorization identity and need to be mapped to
the Kerberos principal name. The computer must be configured to a
Kerberos
realm and the computer password must be set to the password used in the
host principal for the computer.

From the description it appears you are having problems setting this
scenario up. If you are still having a problem, let me know so that I
can help you get this working.

> 
> There is another problem with Microsoft's approach to 
> implement service principals purely by name canonicalization 
> which is even present with an Active directory, namely that 
> host-specific instances of a distributed service can not use 
> host-specific credentials while operating under a common user account.

[Jbrezak] Microsoft completely seperates the identity that is used for
authentication from the identity used for authorization when using
Kerberos. The Windows 2000 identity (represented by the SIDs), is
carried
in the authorization data with the Kerberos ticket. It is this identity
that is used for authorization decisions (i.e. evaluating ACLs).

If the authorization data is missing, then the principal name is used
to locate an account (either in AD or locally) to provide the SIDs used
for authorization checks.

DCE used a very similar mechanism. Authorization in DCE is based on the
authorization data that carries the UUIDs of the user identity. This is
used to evaluate access to resources in ACL checks. AFAIK there is no
way to
represent users on ACLs based on their Kerberos principal name.

> 
> 
> Although these are more an operational and API issues than 
> Kerberos protocol issues, I really think the Kerberos group 
> should NOT be totally ignorant of the Kerberos 5 gssapi 
> mechanism spec and its (non-)future.

[Jbrezak] You should look at the DCE GSSAPI mechtypes. There are 2 in
The standard distribution - Kerberos5 and DCE. IIRC the DCE mechtype
uses
the DCE identities.

> -Martin

---

From: Martin Rex <[email-masked]>
Date: Thu, 15 Feb 2001 21:50:36 +0100 (MET)

> host principal for the computer.

I know how that works.  This is what I meant by "attaching a standalone
W2K pro to an MIT KDC.

Now what doesn't work is to create a hostbased service principal
like "sample/w2kpro.f.q.d.n" in the MIT KDC database and configure
the W2K machine so that an application can request the
credentials for "sample/w2kpro.f.q.d.n" and accept security context
from initiators that use "sample/w2kpro.f.q.d.n" as the target name.

It sounds like there is a special hack in place that could make it work
for the "host/f.q.d.n" principal, but this is *NOT* the service principal
that I want.  (Eventually you still have a copy of the following: ).

Martin Rex wrote (on 29-Jun-2000):
> C:\ksetup
> default realm = WDF.SAP-AG.DE (external)
> WDF.SAP-AG.DE:
>       kdc = uw1048.wdf.sap-ag.de
> Mapping [email-masked] to d019080.
> Mapping d019080/[email-masked] to d019080.
> 
> 
> 
> F:\sspigss>gssserver d019080/p35956n5.wdf.sap-ag.de mypasswd 
> WDF.SAP-AG.DE
> reading token length: -1 of 4 bytes read
> 
> 
> F:\sspigss>gssclient localhost d019080 Hallo
> LoadLib = 77BE5629
> checking localhost...calling host localhost, name d019080, 
> msg "Hallo".
> Sending init_sec_context token (size=451)... continue needed...
> Received accept_sec_context token (size=114)...
> 
> 
> Block Size is 8, inbuffer = 6
> Signature verified.
> 
> 
> F:\sspigss>gssclient localhost d019080/p35956n5.wdf.sap-ag.de Hallo
> LoadLib = 77BE5629
> checking localhost...calling host localhost, name 
> d019080/p35956n5.wdf.sap-ag.de
> , msg "Hallo".
> Sending init_sec_context token (size=481)... continue needed...
> Received accept_sec_context token (size=101)...
> 
> Sending init_sec_context token (size=499)... continue needed...
> Received accept_sec_context token (size=101)...
> 
> GSS-API error initializing context: 80090322
> GSS-API error initializing context: 0

> that is used for authorization decisions (i.e. evaluating ACLs).

I know all that.
That's interesting how you describe that there really is a
name-based authentication in the underlying Kerberos protocol ...
*I* do remember *when* QueryContextAttributes(NATIVE_NAMES) was added ;-)

> way to represent users on ACLs based on their Kerberos principal name.

I didn't want to imply that all of DCE is good or that anyone should
be using DCE.  But when I read some parts of the DCE docs back in
1995/1996 I noticed that they had two workable solutions for 
connecting and authenticating with distributed services that
both fit just fine under GSS-API.

1.) A name service where instances of a distributed service can
    register.  Clients can connect and look up the hostbased service
    principal accompanied by the connection info (IP-Address,port,protocol)
    of a particular service instance.
    This would be a workable out-of-band canonicalization.

2.) A distributed service that wants to use a single principal name
    can use a DCE-specific 3-way authentication that will not be
    vulnerable to cross-host session replay that the authenticator-based
    Kerberos authentication would have when reusing a single
    principal for multiple instances of a distributed service
    on different hosts.

For our situation, 2.) is not an option because it will NOT interoperate
with the rfc1964-based installed base.  1.) is probably the direction
how we should solve the canonicalization of service principals.

-Martin