In message <[EMAIL PROTECTED]>, Ken Hornstein write
s:
>>mpb>Encryption? There are many ways to do that already.
>>ken>Okay, give me one way of encrypting my network AFS traffic today.
>>
>>I can't comment on _your_ network AFS traffic since I know nothing
>>of your network/servers/clients etc.
>
>But you said, "Encryption? There are many ways to do that already.".

The tunneling solution is one example, AND i haven't read the
AFS code for a long time, but it used to be the case that when
the client created the connection to the server, it would 
specifiy the 'flavor' of connection.  The choices of flavor
would dictate the kind of security connection.   If i remeber right,
the kind of ticket you had helped the client code select between
different flavors.

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.

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.

Maybe the mods to correctly support encryption are more
significant than just mods at the protocol layer, or are
you primarily concerned about sniffers like NFR?

mts.

Reply via email to