I think that while encryption may be desirable in some cases,
checksum'ing (or signing) the message/data payload in the RPC is often
an adequate compromise.  I guess I'm more worried about active attacks
than I am passive sniffing!   I think I'm correct in assuming that the
AFS RPC never had a provision for this protection level. (right?)   

Unfortunately, it is my understanding even if this were available that
Kerberos 4 (CBC) is known to be broken in this respect.  (I'm pretty
sure I remember reading this).

This of course brings up another wish of mine, "that AFS would migrate
to Kerberos 5".        

My $0.02!


Nathan J Williams wrote:
> 
> >I also seem to remember that the security code which manages
> >the connections had code available for encrypting every byte
> >in the connection, but in the RT days that code wasn't turned
> >on.  It could be that over time since the code wasn't used
> >much, its falled into disrepair, and may have even been reaped,
> >but it was considered in the past.
> 
>         The code has not been reaped. With the (short) patch that MIT
> submitted to Transarc in the mentioned defect report, I have
> encryption enabled on several of my workstations, and it does appear
> that everything's being encrypted. At least, I could make sense of the
> tcpdump'd output of my AFS data before and identify textual data, but
> now it's complete gobbledygook, and appears to be all the rx data,
> including things like the fid in requests.
> 
> >I'm assuming that such a client would have to be physically
> >secure, and that it would have to flush its cache frequently
> >to purge any traces of the (decrypted) files on the local
> >machine... at the very least when the user loses tokens.
> 
>         It's true that transport-level encryption support (whether
> application-level, as the patch, or network level, as Mr. Blackburn is
> supporting) isn't the end of the story, but it's an important step. As
> always, keeping one workstation mostly secure from breakins is much
> easier than keeping the entire local network secure from them.
> 
>         - Nathan

-- 
Chris Cowan                       
[EMAIL PROTECTED]                 
512-342-3635 (always)
614-677-3784 (until 6/1/98)
begin:          vcard
fn:             Chris Cowan
n:              Cowan;Chris
org:            PSW Technologies, BSS
adr;dom:        6300 Bridgepoint Pkwy;;Bldg 3, Suite 200;Austin;TX;78730;
email;internet: [EMAIL PROTECTED]
title:          Senior Software Engineer
tel;work:       512-342-3635
tel;fax:        512-345-4976
x-mozilla-cpt:  ;0
x-mozilla-html: FALSE
version:        2.1
end:            vcard

Reply via email to