[30629] in Kerberos

home help back first fref pref prev next nref lref last post

Re: Suitable Kerberos Server for Packet cable ??

daemon@ATHENA.MIT.EDU (=?ISO-8859-1?Q?Love_H=F6rnquist_=C)
Thu Jan 15 13:17:26 2009

Message-Id: <E16CFC96-836F-469F-A12C-F41E0B898F9B@kth.se>
From: =?ISO-8859-1?Q?Love_H=F6rnquist_=C5strand?= <lha@kth.se>
To: ronnie sahlberg <ronniesahlberg@gmail.com>
In-Reply-To: <c9a3e4540901150032u26390d6ud4ddf7b3bdbb44f3@mail.gmail.com>
Mime-Version: 1.0 (Apple Message framework v930.3)
Date: Thu, 15 Jan 2009 10:15:30 -0800
Cc: Aleem AKHTAR <aleem.akhtar@st.com>, "kerberos@mit.edu" <kerberos@mit.edu>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu

Older versions of heimdal did work with packet cable but since I  
didn't have anything to test with I broke it on purpose when code  
changed.

Love


15 jan 2009 kl. 00.32 skrev ronnie sahlberg:

> I think there is a company called Blue-Cable or something that does
> these things.
>
>
> I doubt that either a MIT or  Heimdal (or any rfc1510) server will
> work since packet-cable uses a non-1510 implementation of kerberos 5.
> Its very similar but there are subtle differences.
> They use either a pre-1510 draft or a forked different standard, dont
> know which, suspect the first.
>
>> From experience implementing both packetcable and also 1510 in
> wireshark we got around this by changing the ASN to make some
> structure fields OPTIONAL which were OPTIONAL in packet-cable but were
> mandatory in the official 1510.
>
> The changes I had to make was rather smallish and I did put a comment
> in packet-kerberos.c in wireshark to indicate these non-1510 changes.
> This was possible since we only unmarshall packets and never marshall
> them and thus sprinkling the ASN with extra OPTIONAL is harmless.
>
> There might be additional changes required  if you also need to
> marshall data. Dont know. You take lots of shortcuts when you only
> unmarshall data.
>
>
> I think I recall also other differences (not ASN changes) that related
> to things like preauthentication types/blobs, enctypes, salt blobs
> etc etc.
> (Some which actually surprised me when they were resurrected in
> microsoft ad krb5   with the same numbers and the same meaning
> sometime around when w2k3 was released).
>
>
> Was a long time ago I did packetcable for wireshark so my memory is  
> hazy...
> There was at some point a post on the wireshark mailinglist (long
> after i implemented the packetcable changes in ws) that linked to a
> full set of official specification for packetcable and in particular
> their krb5 implementation.
> This was in the days when wireshark was called ethereal.
>
>
> regards
> ronnie sahlberg
>
>
> On Thu, Jan 15, 2009 at 7:08 PM, Aleem AKHTAR <aleem.akhtar@st.com>  
> wrote:
>>
>> Hi,
>>
>> Could I get information which kerberos server is best suited for  
>> Packet cable project specification. Is there any limitation if we  
>> use open source krb5 server published by MIT ??
>> In wireshark the incompatibility issue between 1510 and packetcable  
>> is minor since we only ever unmarshall packets and never mashall  
>> them.
>>
>> Thanks,
>> Aleem
>>
>>
>> ________________________________________________
>> Kerberos mailing list           Kerberos@mit.edu
>> https://mailman.mit.edu/mailman/listinfo/kerberos
>>
> ________________________________________________
> Kerberos mailing list           Kerberos@mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos

________________________________________________
Kerberos mailing list           Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

home help back first fref pref prev next nref lref last post