Kerberos Ticket Forwarding Patch/Update (3.2)

[Derrick Schommer-2]

Here is the follow up patch for Samba 3.2 for ticket forwarding tickets
in Kerberos to match the 3.0 patch (code was a bit different in this
release so I had to re-patch)

 

Derrick Schommer |  Corporate Systems Engineer

F5 Networks

  P 978.513.2900

 F 978.513.2990

www.f5.com <http://www.f5.com>  

  D 978.513.2960

 M 603.765.0012

 

 

[Derrick Schommer-2]

Here is the update with C-style comment fixes for 3.2 for the Kerberos
update and the gss_init() updated to have the C_DELEGAT flag enabled.

 

Derrick Schommer |  Corporate Systems Engineer

F5 Networks

  P 978.513.2900

 F 978.513.2990

www.f5.com <http://www.f5.com>  

  D 978.513.2960

 M 603.765.0012

 

 

[Love Hörnquist Åstrand]

The flags field in the 8003 checksum should match the gss-api flags  
given to gss_init_sec_context(), your patch sets it to  
GSSAPI_NO_C_BINDINGS (0), which is wrong, it should at least be  
GSS_C_DELEG_FLAG, see page 4 of rfc1934.

+  uint8_t    deleg[];                    /* Deleg field buffer ( one  
or more bytes of GSS-API data) */

This is not valid c89.

The patch do no byte swaping, so it will only work on LE machines.

Love


25 jul 2008 kl. 20.14 skrev Derrick Schommer:

> Here is the update with C-style comment fixes for 3.2 for the Kerberos
> update and the gss_init() updated to have the C_DELEGAT flag enabled.
>

[Derrick Schommer-2]

I'll work on the fixes for those, thanks!

-----Original Message-----
From: Love Hörnquist Åstrand [mailto:lha@...]
Sent: Saturday, July 26, 2008 14:41
To: Derrick Schommer
Cc: samba-technical@...
Subject: Re: Kerberos Ticket Forwarding Patch/Update (3.2)

The flags field in the 8003 checksum should match the gss-api flags  
given to gss_init_sec_context(), your patch sets it to  
GSSAPI_NO_C_BINDINGS (0), which is wrong, it should at least be  
GSS_C_DELEG_FLAG, see page 4 of rfc1934.

+  uint8_t    deleg[];                    /* Deleg field buffer ( one  
or more bytes of GSS-API data) */

This is not valid c89.

The patch do no byte swaping, so it will only work on LE machines.

Love


25 jul 2008 kl. 20.14 skrev Derrick Schommer:

> Here is the update with C-style comment fixes for 3.2 for the Kerberos
> update and the gss_init() updated to have the C_DELEGAT flag enabled.
>

[Derrick Schommer-2]

I'm not sure anything needs to be byte swapped if I'm reading this spec right:


The 0x8003 GSS checksum MUST have the following
   structure:
Octet     Name       Description
      -----------------------------------------------------------------
      0..3      Lgth       Number of octets in Bnd field;  Represented
                            in little-endian order;  Currently contains
                            hex value 10 00 00 00 (16).
      4..19     Bnd        Channel binding information, as described in
                            section 4.1.1.2 [RFC4121].
      20..23    Flags      Four-octet context-establishment flags in
                            little-endian order as described in section
                            4.1.1.1 [RFC4121].
      24..25    DlgOpt     The delegation option identifier (=1) in
                            little-endian order [optional].  This field
                            and the next two fields are present if and
                            only if GSS_C_DELEG_FLAG is set as described
                            in section 4.1.1.1 [RFC4121].
      26..27    Dlgth      The length of the Deleg field in
                            little-endian order [optional].
      28..(n-1) Deleg      KRB_CRED message (n = Dlgth + 28) [optional].
      n..last   Exts       Extensions


source: http://www.ietf.org/internet-drafts/draft-ietf-krb-wg-gss-cb-hash-agility-04.txt



-----Original Message-----
From: Love Hörnquist Åstrand [mailto:lha@...]
Sent: Saturday, July 26, 2008 14:41
To: Derrick Schommer
Cc: samba-technical@...
Subject: Re: Kerberos Ticket Forwarding Patch/Update (3.2)

The flags field in the 8003 checksum should match the gss-api flags  
given to gss_init_sec_context(), your patch sets it to  
GSSAPI_NO_C_BINDINGS (0), which is wrong, it should at least be  
GSS_C_DELEG_FLAG, see page 4 of rfc1934.

+  uint8_t    deleg[];                    /* Deleg field buffer ( one  
or more bytes of GSS-API data) */

This is not valid c89.

The patch do no byte swaping, so it will only work on LE machines.

Love


25 jul 2008 kl. 20.14 skrev Derrick Schommer:

> Here is the update with C-style comment fixes for 3.2 for the Kerberos
> update and the gss_init() updated to have the C_DELEGAT flag enabled.
>

[Love Hörnquist Åstrand]

All fields longer then one byte needs to be byte swaped to LE on BE  
platforms.

Love



28 jul 2008 kl. 20.44 skrev Derrick Schommer:

> I'm not sure anything needs to be byte swapped if I'm reading this  
> spec right:
>
>
> The 0x8003 GSS checksum MUST have the following
>   structure:
> Octet     Name       Description
>      -----------------------------------------------------------------
>      0..3      Lgth       Number of octets in Bnd field;  Represented
>                            in little-endian order;  Currently contains
>                            hex value 10 00 00 00 (16).
>      4..19     Bnd        Channel binding information, as described in
>                            section 4.1.1.2 [RFC4121].
>      20..23    Flags      Four-octet context-establishment flags in
>                            little-endian order as described in section
>                            4.1.1.1 [RFC4121].
>      24..25    DlgOpt     The delegation option identifier (=1) in
>                            little-endian order [optional].  This field
>                            and the next two fields are present if and
>                            only if GSS_C_DELEG_FLAG is set as  
> described
>                            in section 4.1.1.1 [RFC4121].
>      26..27    Dlgth      The length of the Deleg field in
>                            little-endian order [optional].
>      28..(n-1) Deleg      KRB_CRED message (n = Dlgth + 28)  
> [optional].
>      n..last   Exts       Extensions
>
>
> source: http://www.ietf.org/internet-drafts/draft-ietf-krb-wg-gss-cb-hash-agility-04.txt
>
>
>
> -----Original Message-----
> From: Love Hörnquist Åstrand [mailto:lha@...]
> Sent: Saturday, July 26, 2008 14:41
> To: Derrick Schommer
> Cc: samba-technical@...
> Subject: Re: Kerberos Ticket Forwarding Patch/Update (3.2)
>
> The flags field in the 8003 checksum should match the gss-api flags
> given to gss_init_sec_context(), your patch sets it to
> GSSAPI_NO_C_BINDINGS (0), which is wrong, it should at least be
> GSS_C_DELEG_FLAG, see page 4 of rfc1934.
>
> +  uint8_t    deleg[];                    /* Deleg field buffer ( one
> or more bytes of GSS-API data) */
>
> This is not valid c89.
>
> The patch do no byte swaping, so it will only work on LE machines.
>
> Love
>
>
> 25 jul 2008 kl. 20.14 skrev Derrick Schommer:
>
>> Here is the update with C-style comment fixes for 3.2 for the  
>> Kerberos
>> update and the gss_init() updated to have the C_DELEGAT flag enabled.
>>
>

[Derrick Schommer-2]

Ah yes, forgot, samba probably actually compiles on a BE system. :)

Derrick

-----Original Message-----
From: Love Hörnquist Åstrand [mailto:lha@...]
Sent: Monday, July 28, 2008 17:44
To: Derrick Schommer
Cc: samba-technical@...
Subject: Re: Kerberos Ticket Forwarding Patch/Update (3.2)

All fields longer then one byte needs to be byte swaped to LE on BE  
platforms.

Love



28 jul 2008 kl. 20.44 skrev Derrick Schommer:

> I'm not sure anything needs to be byte swapped if I'm reading this  
> spec right:
>
>
> The 0x8003 GSS checksum MUST have the following
>   structure:
> Octet     Name       Description
>      -----------------------------------------------------------------
>      0..3      Lgth       Number of octets in Bnd field;  Represented
>                            in little-endian order;  Currently contains
>                            hex value 10 00 00 00 (16).
>      4..19     Bnd        Channel binding information, as described in
>                            section 4.1.1.2 [RFC4121].
>      20..23    Flags      Four-octet context-establishment flags in
>                            little-endian order as described in section
>                            4.1.1.1 [RFC4121].
>      24..25    DlgOpt     The delegation option identifier (=1) in
>                            little-endian order [optional].  This field
>                            and the next two fields are present if and
>                            only if GSS_C_DELEG_FLAG is set as  
> described
>                            in section 4.1.1.1 [RFC4121].
>      26..27    Dlgth      The length of the Deleg field in
>                            little-endian order [optional].
>      28..(n-1) Deleg      KRB_CRED message (n = Dlgth + 28)  
> [optional].
>      n..last   Exts       Extensions
>
>
> source: http://www.ietf.org/internet-drafts/draft-ietf-krb-wg-gss-cb-hash-agility-04.txt
>
>
>
> -----Original Message-----
> From: Love Hörnquist Åstrand [mailto:lha@...]
> Sent: Saturday, July 26, 2008 14:41
> To: Derrick Schommer
> Cc: samba-technical@...
> Subject: Re: Kerberos Ticket Forwarding Patch/Update (3.2)
>
> The flags field in the 8003 checksum should match the gss-api flags
> given to gss_init_sec_context(), your patch sets it to
> GSSAPI_NO_C_BINDINGS (0), which is wrong, it should at least be
> GSS_C_DELEG_FLAG, see page 4 of rfc1934.
>
> +  uint8_t    deleg[];                    /* Deleg field buffer ( one
> or more bytes of GSS-API data) */
>
> This is not valid c89.
>
> The patch do no byte swaping, so it will only work on LE machines.
>
> Love
>
>
> 25 jul 2008 kl. 20.14 skrev Derrick Schommer:
>
>> Here is the update with C-style comment fixes for 3.2 for the  
>> Kerberos
>> update and the gss_init() updated to have the C_DELEGAT flag enabled.
>>
>

[Andrew Bartlett]

On Fri, 2008-07-25 at 15:14 -0400, Derrick Schommer wrote:
> Here is the update with C-style comment fixes for 3.2 for the Kerberos
> update and the gss_init() updated to have the C_DELEGAT flag enabled.

I still think it is silly to be extending Samba3's mini-GSSAPI like
this, but the change to make it just use real GSSAPI is a more difficult
patch.

Can you please test this against Samba4 when you are done?  We have an
active implementation of a CIFS proxy using GSSAPI forwarding, and it
would be unfortunate to have Samba3 code out there that does not use it.

Andrew Bartlett

--
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Red Hat Inc.

[Derrick Schommer-3]

Andrew,

I'm looking into the gss API, honestly, I've never used them before so there
is a bit of a learning curve, there seems to be no great documentation to
build a gss security context with a GSS Checksum. I think I get the
"theory," I'm just struggling on time to build it, as I'm currently wearing
"many hats" here and trying to get this through along with other internal
work. Currently, I'm reading the header files and the samba sources to see
if I can build a GSS API checksum in the context rather than my silly gss
checksum structure.

If you've got any GSS-API guru's that can tell me how to (or show me how to)
take my silly GSS checksum "hack" and build it into the real gss API I'd
love to learn. I'm going to try my hand at it this week, I hope, before I
give in and just little-endian byte order my field values and say it
works...

I've not worked with the code I wrote in this patch (or kerberos) for about
three years, so I'm a bit out of practice. I'm a stickler for doing it
right, so I really want to strive to make it perfect. If that means
submitting something that works today and cleaning it up in a future
release, I'd rather do that than give you guys something you think isn't on
par with a samba code drop.

Derrick



On 7/30/08 9:12 PM, "Andrew Bartlett" <abartlet@...> wrote:

> On Fri, 2008-07-25 at 15:14 -0400, Derrick Schommer wrote:
>> Here is the update with C-style comment fixes for 3.2 for the Kerberos
>> update and the gss_init() updated to have the C_DELEGAT flag enabled.
>
> I still think it is silly to be extending Samba3's mini-GSSAPI like
> this, but the change to make it just use real GSSAPI is a more difficult
> patch.
>
> Can you please test this against Samba4 when you are done?  We have an
> active implementation of a CIFS proxy using GSSAPI forwarding, and it
> would be unfortunate to have Samba3 code out there that does not use it.
>
> Andrew Bartlett

[Andrew Bartlett]

On Wed, 2008-07-30 at 23:32 -0400, Derrick Schommer wrote:
> Andrew,
>
> I'm looking into the gss API, honestly, I've never used them before so there
> is a bit of a learning curve, there seems to be no great documentation to
> build a gss security context with a GSS Checksum.

That's because you are not meant to hand-build it.  Your system GSSAPI
library should do it.  The fact that we did it in Samba3 is not a good
example.  Samba4 has taken the route of using real GSSAPI for this
reason.

I realise this change is not what you were hoping to do, but I just want
it noted that doing this by hand is always going to cause problems.

Andrew Bartlett

--
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Red Hat Inc.

[Derrick Schommer-3]

>
> That's because you are not meant to hand-build it.  Your system GSSAPI
> library should do it.  The fact that we did it in Samba3 is not a good
> example.  Samba4 has taken the route of using real GSSAPI for this
> reason.

So, I'm staying consistent with the theme? :) I think mine might be even
more down and dirty than the way samba3 did it.

>
> I realise this change is not what you were hoping to do, but I just want
> it noted that doing this by hand is always going to cause problems.

So, should I just keep what's there and get the byte ordering right and then
work towards samba4?

Derrick

[Jeremy Allison]

On Wed, Jul 30, 2008 at 11:47:31PM -0400, Derrick Schommer wrote:

>
> >
> > That's because you are not meant to hand-build it.  Your system GSSAPI
> > library should do it.  The fact that we did it in Samba3 is not a good
> > example.  Samba4 has taken the route of using real GSSAPI for this
> > reason.
>
> So, I'm staying consistent with the theme? :) I think mine might be even
> more down and dirty than the way samba3 did it.
>
> >
> > I realise this change is not what you were hoping to do, but I just want
> > it noted that doing this by hand is always going to cause problems.
>
> So, should I just keep what's there and get the byte ordering right and then
> work towards samba4?

Once the Love has blessed the byte ordering using his
Heimdal experience then I'll look at getting this into
Samba 3.

Thanks for persevering with this. I have some experience
hand-crafting gss packets, so I'll try and take a look
after next week (the busyest week of my year :-( ) is
over.

Cheers & thanks,

Jeremy.

[Jeremy Allison]

On Thu, Jul 31, 2008 at 11:12:23AM +1000, Andrew Bartlett wrote:
> On Fri, 2008-07-25 at 15:14 -0400, Derrick Schommer wrote:
> > Here is the update with C-style comment fixes for 3.2 for the Kerberos
> > update and the gss_init() updated to have the C_DELEGAT flag enabled.
>
> I still think it is silly to be extending Samba3's mini-GSSAPI like
> this, but the change to make it just use real GSSAPI is a more difficult
> patch.

It needs doing. Samba3 is production file and print for most UNIX
systems. At some point I'd like to cut over to 'real' gssapi  but
this is more work than I have time for currently.

Jeremy.

[Jeremy Allison]

On Wed, Jul 30, 2008 at 11:32:50PM -0400, Derrick Schommer wrote:

> I'm looking into the gss API, honestly, I've never used them before so there
> is a bit of a learning curve, there seems to be no great documentation to
> build a gss security context with a GSS Checksum. I think I get the
> "theory," I'm just struggling on time to build it, as I'm currently wearing
> "many hats" here and trying to get this through along with other internal
> work. Currently, I'm reading the header files and the samba sources to see
> if I can build a GSS API checksum in the context rather than my silly gss
> checksum structure.

I usually start by digging into the MIT krb5 sources for their
latest release. It's not so bad to figure things out from there
once you're used to messing with it.

> If you've got any GSS-API guru's that can tell me how to (or show me how to)
> take my silly GSS checksum "hack" and build it into the real gss API I'd
> love to learn. I'm going to try my hand at it this week, I hope, before I
> give in and just little-endian byte order my field values and say it
> works...

If that's what you have to do to make it work, then I'd go that route :-).

> I've not worked with the code I wrote in this patch (or kerberos) for about
> three years, so I'm a bit out of practice. I'm a stickler for doing it
> right, so I really want to strive to make it perfect. If that means
> submitting something that works today and cleaning it up in a future
> release, I'd rather do that than give you guys something you think isn't on
> par with a samba code drop.

That works for me :-).

Thanks !

Jeremy.

[Love Hörnquist Åstrand]

31 jul 2008 kl. 16.31 skrev Jeremy Allison:

> On Thu, Jul 31, 2008 at 11:12:23AM +1000, Andrew Bartlett wrote:
>> On Fri, 2008-07-25 at 15:14 -0400, Derrick Schommer wrote:
>>> Here is the update with C-style comment fixes for 3.2 for the  
>>> Kerberos
>>> update and the gss_init() updated to have the C_DELEGAT flag  
>>> enabled.
>>
>> I still think it is silly to be extending Samba3's mini-GSSAPI like
>> this, but the change to make it just use real GSSAPI is a more  
>> difficult
>> patch.
>
> It needs doing. Samba3 is production file and print for most UNIX
> systems. At some point I'd like to cut over to 'real' gssapi  but
> this is more work than I have time for currently.

SPENGO have change since you implemented it (RFC4178), and since you  
claim to be a spnego implemntor you have update if you want to be in  
the game since msft implement it.

Love

[Jeremy Allison]

On Thu, Jul 31, 2008 at 08:22:12PM +0100, Love Hörnquist Åstrand wrote:
>
> SPENGO have change since you implemented it (RFC4178), and since you  
> claim to be a spnego implemntor you have update if you want to be in  
> the game since msft implement it.

Thanks for the reference, I'll take a look !

Cheers,

Jeremy.

[Jeremy Allison]

On Mon, Jul 28, 2008 at 05:56:24PM -0400, Derrick Schommer wrote:
> Ah yes, forgot, samba probably actually compiles on a BE system. :)

Use the following MACROs to convert native byte order to LE.

SSVAL(buf,pos,val) - put a 2 byte SMB value (val) into a buffer (buf) at position (pos)
SIVAL(buf,pos,val) - put a 4 byte SMB value (val) into a buffer (buf) at position (pos)

These are defined in include/byteorder.h and are what we
use for creating LE fields in the SMB protocol.

Jeremy.

[Jeremy Allison]

On Fri, Jul 25, 2008 at 03:14:56PM -0400, Derrick Schommer wrote:
> Here is the update with C-style comment fixes for 3.2 for the Kerberos
> update and the gss_init() updated to have the C_DELEGAT flag enabled.

Ok, just looked this over and you can't use a struct
to create a memory block like that. There's no guarentee
of correct packing by the compiler and also as Love
pointed out this needs to be explicitly LE.

Take a look at the code in smbd/nttrans.c around line 384
for an example of how we manually do this for SMB/CIFS.
eg.

    384         p = (char *)req->outbuf + smb_vwv2;
    385         p++;
    386         SSVAL(p,0,pnum);
    387         p += 2;
    388         SIVAL(p,0,FILE_WAS_OPENED);
    389         p += 4;
    390         p += 32;
    391         SIVAL(p,0,FILE_ATTRIBUTE_NORMAL); /* File Attributes. */
    392         p += 20;
    393         /* File type. */
    394         SSVAL(p,0,FILE_TYPE_MESSAGE_MODE_PIPE);
    395         /* Device state. */
    396         SSVAL(p,2, 0x5FF); /* ? */
    397         p += 4;

Cheers,

Jeremy.