[32148] in Kerberos
Re: Kerberos Direct Service Authentication without Client / KDC
daemon@ATHENA.MIT.EDU (Jeffrey Altman)
Mon Mar 15 15:27:29 2010
X-Envelope-From: jaltman@secure-endpoints.com
X-MDaemon-Deliver-To: kerberos@mit.edu
Message-ID: <4B9E89A9.8040700@secure-endpoints.com>
Date: Mon, 15 Mar 2010 15:25:29 -0400
From: Jeffrey Altman <jaltman@secure-endpoints.com>
MIME-Version: 1.0
To: kerberos@mit.edu
In-Reply-To: <78c6bd861003151208l4d087fc6xdd1602813be83005@mail.gmail.com>
Reply-To: jaltman@secure-endpoints.com
Content-Type: multipart/mixed; boundary="===============1205007716=="
Errors-To: kerberos-bounces@mit.edu
This is a cryptographically signed message in MIME format.
--===============1205007716==
Content-Type: multipart/signed; protocol="application/pkcs7-signature";
micalg=sha1; boundary="------------ms010301060003020501050906"
This is a cryptographically signed message in MIME format.
--------------ms010301060003020501050906
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On 3/15/2010 3:08 PM, Michael B Allen wrote:
> Hi All,
>
> Is there a mode of operation where a Kerberos client can directly
> authenticate with a service without first communicating with a KDC?
>
> Kerberos currently requires that clients are using a suitable DNS
> server, have access to whatever KDCs DNS is referring it to and have
> relatively accurate time. In many environments these requirements are
> too demanding.
>
> There should be a mode of operation where a client can compose a
> kerberos request without communicating with the KDC, DNS or time
> services and which can be submitted directly to a Kerberos service.
> This request would contain information about the client principal and
> target principal and would be encrypted using the client principal
> secret key known only to the client and the KDC. The Kerberos service
> accepting this ticket could compose a request containing the client's
> request and pass this to a KDC as a sort of AS-REQ. In return the
> service would receive either an error (such as indicating that the
> client request could not be successfully decrypted) or a service
> ticket with the usual fields like authorization-data and possibly a
> TGT that would be equivalent to a TGT that a client might normally
> submit through delegation. The service would then pass the service
> ticket down to the client to indicate that authentication was
> successful.
>
> The objective is to have the Kerberos service act as a proxy to the
> KDC so as to release the client from impractical communication and
> configuration requirements. The client should only need to know the
> shared secret.
>
> If such a thing does not already exist, I think it should.
>
> Mike
A process to do this through GSS-API based service proxies as been
proposed to the
IETF Kerberos Working Group.=20
http://datatracker.ietf.org/doc/draft-ietf-krb-wg-iakerb/
Jeffrey Altman
--------------ms010301060003020501050906--
--===============1205007716==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
--===============1205007716==--
