>Chris Calabrese <[EMAIL PROTECTED]> on 10/25/99 11:42:14 AM
>Sent by: Chris Calabrese <[EMAIL PROTECTED]>
>
>To: [EMAIL PROTECTED]
>Subject: a specific protocol proposal
>
>...
I am generally in agreement with this XML-based encoding approach but I think there
are some known problems not solved. I would like to see some specific discussion of
the client-loghost authentication, at connect time. However, this looks like a
workable approach for a draft replacement specification. Could you write up a more
complete description of the protocol, so the following security features become clear?
(Does not have to be in RFC form at this time.)
>Authentication and encryption:
>Most existing secure syslog implementations have extended
>the protocol with network-level hop-by-hop authentication
>and encryption. What I'm after, however, is something in
>the data stream itself so that the data can pass through
>un-trusted third parties and so that third parties can
>independently verify that logs stored on disk/tape/whatever
>have not been modified.
>To do this, I introduce <CRYPT> and <AUTH>. Auth works
>something like this:
> <AUTH SIGNER>stuff to be signed</AUTH
> SIG.TYPE=md5, SIG.VALUE=j43kj3248>
>Where the signature value is encoded in base-64.
>Crypt with static previously exchanged keys looks like:
> <CRYPT [EMAIL PROTECTED]
"CRYPT" would probably be "PRIV" for "privacy", in the usual crypto terminology, cf.
IPSEC.
>
> [EMAIL PROTECTED] KEY=STATIC
> CIPHER=static>
> base-64 representation of stream
> encrypted in blowfish using previously
> exchanged key in previously exchanged
> cipher
> </CRYPT>
>Crypt with public-key (which also provides sender and
>recipient authentication) looks like this:
> <CRYPT [EMAIL PROTECTED]
> [EMAIL PROTECTED] TYPE=RSA
> CIPHER=blowfish KEY=jfkadj43098kjer>
> base-64 representation of stream
> encrypted in blowfish using key
> specified above, itself encrypted using
> [EMAIL PROTECTED]'s private RSA key and
> [EMAIL PROTECTED]'s public RSA key
> </CRYPT>
>You could also leave out the ENCRYPTOR to get the "anyone
>could have written it but only this guy can read it"
>situation (which can be fixed with an extra <AUTH>). Or
>leave out the RECIPIENT to get "any of a small number of
>people I've sent my public key to can read it but only I
>could have sent it".
>The reference implementation will also need code to process
>the authentication and encryption records. Perhaps the
>"expand" function mention above can automagically decrypt
>and stick in AUTH=NONE, AUTH=<signer>, and AUTH=!<signer>
>(for failed authentication).
>--
>Chris Calabrese
>Internet Infrastructure and Security
>Merck-Medco Managed Care, L.L.C.
>[EMAIL PROTECTED]
--
Alex Brown v 4 323 2283
Consulting engineer - MSD software development
Marlborough MA USA
