[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANO7a6waxnXbts6Fe4i=o=HKO3ggQoOoqDUoyEdmtL8znmY90g@mail.gmail.com>
Date: Sat, 8 Dec 2012 10:13:28 +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 9:49 AM, Dhiru Kholia <dhiru.kholia@...il.com> wrote:
> 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.
For now, I have kept the "salt type" field.
>> 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.
Done in commit 6aa836b442c2b089d9850e3be31fdba03507102f
I have added sample krb5 pcap files to the wiki,
http://openwall.info/wiki/_media/john/krbv5-pcaps.tar.gz
Let me know if you need more pcap files.
--
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.
