Questions on kerb 4 vice kerb 5

[Henry B. Hotz]

At 9:23 AM -0500 11/20/01, Ted Anderson wrote:
>On Mon, 19 Nov 2001 14:14:46 -0800 "Henry B. Hotz" <hotz at jpl.nasa.gov> wrote:
>>  > I am not quite sure what you mean by the weel-known replay
>  > > vulnerability,


>  > Since I guess I've exhausted the store of free technical advice on
>>  the subject can I ask people for a reference to the rx protocol so I
>>  can concievably figure this out for myself?
>
>Well, I kind of hate the implication that I've been tapped out already,
>though I applaud your willingness to track down the answer for yourself.

I didn't mean that the way it came out!  More like I've gotten as 
much free help (thanks everyone!) as I can expect and it's time to do 
the rest of the work myself.  Also I'm not being as clear about what 
I'm trying to accomplish as I should.

>I am not at all current the state of documentation for the kaserver and
>Rx.  However, since I wrote the former and have dabbled in the latter on
>and off for more than a decade, I feel sure I could answer your question
>if only I understood it.

Fair enough, and thanks for the offer.  I should have paid attention 
to the domain on your email address. ;-)

[Excellent but long description of k4 and rx protocol (lack of) 
vulnerabilities deleted.]

Let me start over.

Say I've got an AFS server behind a firewall.  I'll live with the 
data being sent in the clear though the firewall (because that 
specific data shouldn't be as sensitive), but I absolutely want to 
guarantee that nobody outside can use the "well-known vulnerability 
in k4" to get at the rest of the stuff on that server.  (That there 
was a vulnerability and that it had something to do with capturing 
and replaying part of someone else's authentication dialog is as much 
as I remembered.)  The naive solution I first asked about was can I 
just block rx and k4 at the firewall and allow k5 through?

(I should also mention an ulterior motive of getting JPL to implement 
a k5 server to ease implementation of single-sign-in with the OS's 
that bundle MIT kerberos code like MacOS X and Solaris 8.)

The answer I got from Magnus was that I could force the tgt to come 
from a k5 server, but the AFS clients still needed to talk rx to the 
AFS servers.  The badly posed question I followed up with was:  is 
that good enough or does rx have enough of the same k4 vulnerability 
that you could still get an AFS token without a tgt?

If I understand your answer then the actual replay vulnerabilities of 
k4 are pretty limited and rx doesn't even have those.  Probably I 
should block UDP port 750 at the firewall and leave it at that. 
(Correct, or should I block TCP as well?)  That's different from my 
going-in belief, but reassuring.

(Of course it means I can't use the vulnerability to force JPL to 
upgrade to k5.)

Thanks for the reference.  The vulnerability I vaguely remembered was 
reference 8 of your reference.  The paper is much more general than I 
had thought, and some of the problems do not apply to k4 the way it 
is used by AFS.
-- 
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry.B.Hotz at jpl.nasa.gov, or hbhotz at oxy.edu