["Ronnie Sahlberg" <ronnie_sahlberg@xxxxxxxxxxxxxx>]

OK. I will consider to consider your advice. maybe.
(reluctantly though, i got "advice" on how "sane" it would be to rewrite
also
smb, most of the dcerpc interfaces and h.323/voip but look where it got us
to
ignore those advices:-) )

anyway, to the point:
Right now I have a number of captures of Kerberos authenticated services and
also the corresponding host/<hostname>
keytabs containing the principals and the keys. these will be excellent for
testing and verification.

My modified version of the kerberos dissector and BER dissection makes it
very easy to pick up the
individual fields of the PDU.
Parsing the keytab files is trivial and should not require any external
software.


I want an easy to use function I can call to decrypt an encrypted array of
bytes into a new array holding the
decrypted data. Something like :
void decrypt_des_cbc_crc(char *encrypted_data, char *decrypted_data, int
len, char *key, int key_len);

Does MIT or Heimdal kerberos provide shared libraries where I can find a
function as easy to use as this
or do i need to do like 1000 lines of setup and stuff first before i can do
this easy function?

Do they proivide me with such a simple API?



I dont really need all of the stuff for things like certificates or so.
Just a simple function to do  decrypt_des_cbc_crc() and return the decrypted
blob which hopefully is asn.1
encoded which i will then manually dissect.


When this works fine I or anyone needing some other method can move on to
add support for, i dont know
des_cbc_md5(), whatever.  one by one as people need support for new types.


How hard would it be to implement a function as above to just decrypt a blob
using des-cbc and not do anything else.
No asn.1 decoding.  that will be done manually anyway after the blob is
decrypted.


It is a serious question.


Another serious question:
(Assume the encryption type is des-cbc-<something>)

Assume I have a kerberos ticket and the ticket specifies the service
principal host/foo
Assume that the encrypted part of the ticket is specified as using the
encryption type des-cbc-<something>
Assume i find in the Keytab file the 8 bytes representing the key/secret for
this principal   CALL these 8 bytes : KEY.
IF I then take the content octets from the octet string holding the
encrypted data and call it  ENC
IF I would then just try to do
    decrypt_des_cbc(ENC, CLEAR, KEY)   (assuming i have a function
decrypt_des_cbc() of course)
would that transform the ENCrypted byte string into a normal ASN.1/BER
encoded data structure?

If it would, would decrypt_des_cbc() be very difficult to implement?




----- Original Message ----- 
From: "Eric Wedel"
Sent: Wednesday, February 04, 2004 2:52 PM
Subject: RE: [Ethereal-dev] telnet/authentication Kerberos stuff


> Hmm..  "kerberos" and "small and simple" don't really go together.
>
> Still, I wish you all the best.  If you get stuck give a holler.
> Unfortunately, I doubt my employer would be willing to part with
> the "port" (read: rewrite) which I did.
>
> One comment:  I didn't even attempt to reimplement the actual
> crypto at the bottom layer:  Kerb uses the ciphers in somewhat
> non-standard (to my slightly experienced eye) ways.  You'll also
> need to keep careful track of the object-specific salt values
> which kerberos uses (don't recall their term for it).
>
> regards, Eric
>
> -----Original Message-----
> From: Ronnie Sahlberg
> To: Eric Wedel; 'Ethereal development'
> Subject: Re: [Ethereal-dev] telnet/authentication Kerberos stuff
>
>
> Yes. non-MIT and non-Heimdal homegrown special kerberos software which is
> simple, minimalistic and only provides those simple functions that
> Ethereal would need.
>  Ethereal has quite a few dependencies as it is already. Being dependent
on
> even more
> external libraries is the only concern I have.
>
> I have not fully understood the entire problem space yet but I belive that
> what ethereal would require would
> be much much simpler than a full blown kerberos implementation.
> I belive it would be sufficient for ethereal to just implement a very
small
> and simple subset of kerberos.
> There are usually quite a few shortcuts to take when the only thing you
> need/want is what ethereal needs.
>
>
> A lot of work? maybe, as much work as a full blown and fully functional
> generic kerberos implementation? probably far from it.
>
> Just being able to pick up the secret keys and open up and dissect the
> encrypted part of kerberos blobs would be a good start
> and since we already have helper functions for des, rc4, md4 and md5 in
> ethereal already that is probably a good start that might cover most
> common cases already.
>
>
> I found the source you referred to, thanks for the pointer.  While the
code
> I found does not match exactly the keytab file i created as a
reference/test
> it was close enough (the code i found reffered to an unknown (too lazy to
> look furhter) to my version of the keytab file (where one of the guint32
> fields were actually a guint16 field in my keytab).