[Eric Wedel <ewedel@xxxxxxxxxxx>]

[Sorry, am in a bit of a rush today.]

If dissect_des is expecting a standard DES key then yes, you'll
need to do some work first.

Yes, kerberos does rather strike one as complex and suboptimal.  :-)
But, there it is.

btw, you can generally infer the structure-specific salt type from
the grouping tags in the unencrypted asn.1.  There is usually a tag
identifying the structure, then when you hit embedded ciphertext
you at least have some idea which "structure salt" value to use
in the decryption.  Normally, you could probably rely on context
but ethereal might be better off not doing that, if possible.

regards, Eric

-----Original Message-----
From: Ronnie Sahlberg [mailto:ronnie_sahlberg@xxxxxxxxxxxxxx]
Sent: Thursday, February 05, 2004 3:13 AM
To: Ethereal development
Subject: Re: [Ethereal-dev] telnet/authentication Kerberos stuff


I looked briefly at
http://www.lysator.liu.se/~nisse/nettle/
which seems like a reasonably low-lever library for what we would need and
sopported on many of our platforms.

What you are saying is that I just cant take the shared secret key from the
keytab file and
push it through a des_decrypt(...) function but that I need to do some
manupilation onto the key from the keytab BEFORE i can pass this
key into dissect_des(...) ?
I was under the impression that the salt was only mixed with the password in
order to genreate the key from password+salt => keytab entry
and that the keytab entry was the real key to input into the encrypt/decrypt
engine.
i.e. salt was only required to go from plaintext password to key but then
the key could be used unmodified to pass to the decrypte_/encrypt_
functions.?


that kind of seems complex and suboptimal.
Anyway, do you know for example hat kind of manipulation processing I would
need to do on the key in the keytab in the example I posted
prevoisly before i can feed it to decrypt_xxx() or where i can find the
answer.

remember i am lazy and want it all served on a silver plate :-)



----- Original Message ----- 
From: "Eric Wedel"
Sent: Thursday, February 05, 2004 3:11 PM
Subject: RE: [Ethereal-dev] telnet/authentication Kerberos stuff


> Hi..
>
> Trying to take your questions mostly in order, yes there is an API
> to do the decryption:
>   krb5_c_decrypt(context, key, usage, ivec, input, output)
> in src/lib/crypto/decrypt.c.  Don't know if this is considered "public"
> or not though.
>
> Those formals are roughly:
> context - passed all over the place inside MIT kerb, not used here.
> key - Your key value, from a keytab, ticket or wherever.  _Includes
> encryption type_
> usage - A "salt" value, see below.
> ivec - Might be used by some ciphers, hasn't yet been used in my ADS work.
> input, output - The usual.
>
> That "usage" value is kinda fun.  Don't really know why, but kerberos
> includes
> this structure-specific "salt" value which is factored into the cipher
> calculations.
> This value is a constant that is determined by the higher-level code which
> knows
> what structure it is operating on.  E.g., krb5_mk_req_extended() which
> builds an
> AP-REQ uses value KRB5_KEYUSAGE_AP_REQ_AUTH, which == 11, when encrypting
> its
> authenticator.  This is part of the protocol and cannot be avoided.
>
> A general word on ciphertext:  kerberos always sends these as an
> asn.1-structured
> pair, a "blob" plus an integer encryption type.  The latter helps you to
> determine
> which key to grab from your keytab (along with the principal name of
> course), and
> as shown above is also fed in to the encryption code, which does a table
> lookup based
> on the etype to find the right cipher module.
>
> The master table of known types is in src/lib/crypto/etypes.c.
>
> Once decrypted, the ciphertext is revealed to be yet more asn.1.  You'll
> need to
> browse the source to see what the various fields mean.  As luck would have
> it,
> most of the asn.1 "structure" deserializers may be found in one file:
>   src/lib/krb5/asn1./krb5_decode.c.
> Or this info should be lurking in an RFC somewhere if you prefer.
>
> ---
>
> In answer to your question about decrypting a ticket's payload, yes that
> should
> work, if you use the code as discussed above.  You would then need to grab
> the embedded
> session key and use that to decrypt further traffic in the conversation.
> [iirc, there
> is an optional subkey which may be specified in the AP-REP.  You thus need
> to decrypt
> the AP-REP to see if a subkey is being used and, if so, adopt it as your
> session key.
> Afraid I don't recall under what circumstances it is used.]
>
> regards, Eric
>
>
> -----Original Message-----
> From: Ronnie Sahlberg [mailto:ronnie_sahlberg@xxxxxxxxxxxxxx]
> Sent: Wednesday, February 04, 2004 12:54 AM
> To: Eric Wedel; ethereal-dev@xxxxxxxxxxxx
> Subject: Re: [Ethereal-dev] telnet/authentication Kerberos stuff
>
>
> 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?
>
>
>
>
>
> *********************************************************************
> This e-mail and any attachment is confidential. It may only be read,
copied and used by the intended recipient(s). If you are not the intended
recipient(s), you may not copy, use, distribute, forward, store or disclose
this e-mail or any attachment. If you are not the intended recipient(s) or
have otherwise received this e-mail in error, you should destroy it and any
attachment and notify the sender by reply e-mail or send a message to
sysadmin@xxxxxxxxxxx
> *********************************************************************
>
> _______________________________________________
> Ethereal-dev mailing list
> Ethereal-dev@xxxxxxxxxxxx
> http://www.ethereal.com/mailman/listinfo/ethereal-dev

_______________________________________________
Ethereal-dev mailing list
Ethereal-dev@xxxxxxxxxxxx
http://www.ethereal.com/mailman/listinfo/ethereal-dev


*********************************************************************
This e-mail and any attachment is confidential. It may only be read, copied and used by the intended recipient(s). If you are not the intended recipient(s), you may not copy, use, distribute, forward, store or disclose this e-mail or any attachment. If you are not the intended recipient(s) or have otherwise received this e-mail in error, you should destroy it and any attachment and notify the sender by reply e-mail or send a message to sysadmin@xxxxxxxxxxx
*********************************************************************