Hello!
On Tue, Feb 25, 2003 at 01:56:08PM -0500, Devin Heitmueller wrote:
> I think this would make a great addition to Ethereal.
The real reason is I always have to convince my customers, that loosing (or
not securely storing) the keys is the end of secret communication but there are
no simple tools available to demonstrate this claim.
> You won't be able to decrypt the stream from within Ethereal if Perfect
> Forward Secrecy (PFS) is used, even if you have the keying info.
That's right. Which ESP payload cipher uses PFS? Or is PFS only used in key
negotiation?
> Are you looking to provide some sort of API to get the negotiated symmetric
> key out of one of the peers?
I intend to implement (first) only some basic parts of IPsec, to make it
possible to decrypt my own IPsec traffic. This is the lowest possible level but
then I have to make sure somehow to let the scheme open for future
enhancements.
> Or are you just going to support only sessions that use RSA for key
> negotiation?
I don't care about key negotiation, as I HAVE TO use manual keying and simple
block ciphers like DES or 3DES and that's the only traffic I need to decrypt
(first).
> Also, how commonplace is PFS in IPSec implementations?
I have no idea. The mandatory algorithms for ESP (RFC2406) are only:
- DES in CBC mode
- HMAC with MD5
- HMAC with SHA-1
- NULL Authentication algorithm
- NULL Encryption algorithm
and they don't use PFS.
> Is it the norm, or is it rarely used? How
> common PFS is could dictate how to approach the issue. If it is rarely
> used, you could probably get away with only decrypting RSA based
> sessions. If it is very common, then you will need some sort of
> approach or else the feature will not have much practical application.
But anyway, I think IPsec is a big task and the first step should come first
and first we need some kind of SA database.
Here's my approach: we could use a text file with a similar format or (even
better) the same as the Solaris command:
/usr/sbin/ipseckey save all
which prints out blocks like
# begin assoc
add esp \
spi 0x1234 encr_alg des-cbc auth_alg hmac-sha1 replay 0 \
src hostwest \
dst hosteast \
authkey 22222222deadbeefdeadbeefdeadbeefdeadbeef/160 \
encrkey 8664432086644320/64 \
# end assoc
A lex/yacc based parser for this should be fairly easy to write.
We could set the file name as an Ethereal preference string (preference apply
call back routine reads the SA database in). If we in the end support an IKE
scheme, this would have to get the keys out of IKE packets (all of them) anyway
and could store them in the same SA database at dissection time.
Bye, Uwe
