In-Reply-To: <rt-5821-25576.12.79168789335@krbdev.mit.edu>
References: <rt-5821-25576.12.79168789335@krbdev.mit.edu>
MIME-Version: 1.0 (Apple Message framework v752.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-ID: <77984B9F-6D20-4877-8629-8829B51728A0@mit.edu>
Content-Transfer-Encoding: 7bit
From: Ken Raeburn <raeburn@MIT.EDU>
Subject: Re: [krbdev.mit.edu #5821] REQ: in-registry keytab support
Date: Thu, 18 Oct 2007 18:40:24 -0400
To: rt@krbdev.mit.edu
RT-Send-Cc: 
Content-Length: 3150

On Oct 18, 2007, at 17:16, Christopher D. Clausen via RT wrote:
> Sam Hartman via RT <rt@krbdev.mit.edu> wrote:
>> However, many of the other examples are cases where reusing keys  
>> would
>> significantly harm security.  The AFS case is particularly alarming.
>> Pushing out the same key for anonymous cell access would decrease
>> security by allowing anyone with this key to impersonate the cell.
>
> Impersonating an anonymous user is actually what one would want in  
> some
> environments.

Sam said, and I believe meant, impersonating the cell.  More  
specifically, impersonating the cell to any of these anonymous users,  
while giving the illusion of secure access.

Because Kerberos uses symmetric cryptography, not only can any party  
knowing your password pretend to be you when talking to the KDC (and  
then other parties), they can also pretend to be the KDC (and then  
other parties) when talking to you.  There are some preauth systems  
and application protocols (e.g., authenticating inside a TLS- 
protected stream, where the server certificate is verified and  
assumed not to be compromised, as is the CA) that can mitigate this,  
but with the basic, password-based Kerberos protocol, the possibility  
is there.

So, someone extracting this shared "anonymous-client" key from one  
compromised machine can pretend to be the KDC to other anonymous  
clients, sending a fake AS-REP encrypted using that key and holding  
credentials encrypted using not the real TGS key but a key chosen by  
the attacker, and then responding to the following TGS-REQ with  
equally fake credentials for talking to the local AFS service.  Then  
the attacker can pretend to be the AFS server, accepting and sending  
encrypted messages.

So now your anonymous user would be talking to the attacker's version  
of the AFS cell, with encryption.

It may be safer from passive eavesdroppers who don't have the shared  
key, but conservatively, it shouldn't be considered any more secure  
than non-encrypted exchanges, unless you have good reason to believe  
the key can never be compromised.

(An attacker who records live traffic to the real KDC and AFS servers  
and gets access to the key later could go back and decrypt it all,  
but if you're really trying to do protected anonymous access, maybe  
there aren't secrets revealed that way.  But that's not guaranteed; I  
could imagine a protocol implemented over the file system that might  
work otherwise.  Kerberos needs some sort of PFS facility; we know  
this.)

>   (Say non-AD joined machines.  Copying a registry file and
> importing it may be simpler than setting up a file path, etc.  A  
> single
> registry key can contain all the needed configuration info.)  The fact
> that you are actually authenicating but still an anonymous user allows
> for OpenAFS to enable encryption to the cell.  The is a FEATURE in  
> this
> case.  (Well, it will hopefully soon be an OpenAFS feature.)

A better solution, which unfortunately is still in design, might be  
the anonymous-ticket facility for Kerberos, http://www.ietf.org/ 
internet-drafts/draft-ietf-krb-wg-anon-04.txt .

Ken