[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 8 Dec 2012 09:49:04 +0530
From: Dhiru Kholia <dhiru.kholia@...il.com>
To: john-dev@...ts.openwall.com
Subject: Re: rc4-hmac parsing support + etype 17 + input format
unification (Was: Re: [john-users] support for weak kerberos etypes)
On Sat, Dec 8, 2012 at 12:41 AM, magnum <john.magnum@...hmail.com> wrote:
> On 7 Dec, 2012, at 18:30 , Dhiru Kholia <dhiru.kholia@...il.com> wrote:
>> On Thu, Dec 6, 2012 at 5:38 PM, magnum <john.magnum@...hmail.com> wrote:
>> I am using the following format which is slightly different from the original.
>>
>> $ krb5pa $ etype $ salttype $ user $ realm $ timestamp $ checksum
>
> After digging around a bit I have a slightly changed proposition... sorry! :)
>
> Let's drop the "salt type" field. Use a "salt" field instead, and leave it blank if not available (fill in user and realm regardless). We then let the format decide what to use (for current applications we'll use salt if available, and otherwise use the concatenation of realm.user).
We have "salt" field only in case of M$ AD authentication. In case of
plain Kerberos we use user and realm fields.
If we decide to drop "salt type" field, then how are you planning to
parse the "ciphertext"? strtok will jump to next field (user)
automatically. "salt type" field is helping us know if we have M$ AD
style salt available.
Always figuring out user and realm fields is not easy (at least with
the current parser) when M$ AD is involved.
> Also, do not split the timestamp in two fields (it simplifies the pcap parser with no downside):
>
> $ krb5pa $ etype $ user $ realm $ salt $ timestampIncludingChecksum
>
> The rationale is that's how it comes on the wire (timestamp and checksum in one blob). So just put that in the timestamp field - the formats will know where to split it. This will simplify addition of other etypes - I think you can actually implement them in the python script without any samples.
Sounds good. Implementing it.
> I can do these changes if you commit your current work (and provided noone objects to this). Or you do it if you like.
I can commit the basic changes required. You can pickup from there.
The current parser is not good. It could use some work.
> Note though that we might save ourselves some future work by researching what we'll need to include for etype 1, 3 and 16. Will this format be enough for them too?
Hopefully it will suffice. I don't know if I can configure my Kerberos
infrastructure to use these etypes easily.
--
Cheers,
Dhiru
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
