Vista CFX join and 'out of order' GSSAPI messages

[Andrew Bartlett]

With the changes in this attached patch (not to be applied, pending the
previous question), I've been able to make Vista join Samba4, using AES
kerberos subkeys (and I think therefore GSSAPI CFX).

However, the sequence number is wrong in the server - but only by one.
I wonder if the 'dce-style' changes are to blame?

perhaps a snippet from my gdb session (on the Samba4 server, with the
Vista client) might show the problem well:

_gssapi_msg_order_check (o=0x8ed1470, seq_num=109012496)
    at heimdal/lib/gssapi/krb5/sequence.c:148
148    if (o == NULL)
(gdb) n
151    if ((o->flags & (GSS_C_REPLAY_FLAG|GSS_C_SEQUENCE_FLAG)) == 0)
(gdb)
155    if (o->elem[0] == seq_num - 1) {
(gdb) p o->elem[0]
$8 = 109012494
(gdb) p seq_num
$9 = 109012496

Any ideas?

Thanks,

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


[vista-join.patch]

---

diff --git a/source/auth/gensec/gensec_gssapi.c b/source/auth/gensec/gensec_gssapi.c
index cc0d404..8bd643a 100644
--- a/source/auth/gensec/gensec_gssapi.c
+++ b/source/auth/gensec/gensec_gssapi.c
@@ -1174,10 +1174,9 @@ static NTSTATUS gensec_gssapi_session_key(struct gensec_security *gensec_securit
  *session_key = gensec_gssapi_state->session_key;
  return NT_STATUS_OK;
  }
-
- maj_stat = gsskrb5_get_initiator_subkey(&min_stat,
- gensec_gssapi_state->gssapi_context,
- &subkey);
+ maj_stat = gsskrb5_get_subkey(&min_stat,
+      gensec_gssapi_state->gssapi_context,
+      &subkey);
  if (maj_stat != 0) {
  DEBUG(1, ("NO session key for this mech\n"));
  return NT_STATUS_NO_USER_SESSION_KEY;
diff --git a/source/librpc/rpc/dcerpc_util.c b/source/librpc/rpc/dcerpc_util.c
index 71c6d5f..d79515b 100644
--- a/source/librpc/rpc/dcerpc_util.c
+++ b/source/librpc/rpc/dcerpc_util.c
@@ -647,11 +647,23 @@ NTSTATUS dcerpc_generic_session_key(struct dcerpc_connection *c,
 
 /*
   fetch the user session key - may be default (above) or the SMB session key
+
+  The key is always truncated to 16 bytes
 */
 _PUBLIC_ NTSTATUS dcerpc_fetch_session_key(struct dcerpc_pipe *p,
-  DATA_BLOB *session_key)
+   DATA_BLOB *session_key)
 {
- return p->conn->security_state.session_key(p->conn, session_key);
+ NTSTATUS status;
+ status = p->conn->security_state.session_key(p->conn, session_key);
+ if (!NT_STATUS_IS_OK(status)) {
+ return status;
+ }
+
+ dump_data(0, session_key->data, session_key->length);
+
+ session_key->length = MIN(session_key->length, 16);
+
+ return NT_STATUS_OK;
 }
 
 
diff --git a/source/rpc_server/dcerpc_server.c b/source/rpc_server/dcerpc_server.c
index d8dafd6..2ebdb12 100644
--- a/source/rpc_server/dcerpc_server.c
+++ b/source/rpc_server/dcerpc_server.c
@@ -270,11 +270,22 @@ NTSTATUS dcesrv_generic_session_key(struct dcesrv_connection *p,
 
 /*
   fetch the user session key - may be default (above) or the SMB session key
+
+  The key is always truncated to 16 bytes
 */
 _PUBLIC_ NTSTATUS dcesrv_fetch_session_key(struct dcesrv_connection *p,
   DATA_BLOB *session_key)
 {
- return p->auth_state.session_key(p, session_key);
+ NTSTATUS status = p->auth_state.session_key(p, session_key);
+ if (!NT_STATUS_IS_OK(status)) {
+ return status;
+ }
+
+ dump_data(0, session_key->data, session_key->length);
+
+ session_key->length = MIN(session_key->length, 16);
+
+ return NT_STATUS_OK;
 }
 
 

---

[Love Hörnquist Åstrand]

Hello Andrew,

The DCE-STYLE patches where from metze (I think)

Also, just to confuse us, the seq number might be diffrent for RC4 and  
AES

Does it work if you change the seq number to one larger in the DCE-RPC  
case, near the end of acceptor_wait_for_dcestyle() is the remote seq  
number reset.

Love




22 jul 2008 kl. 10.50 skrev Andrew Bartlett:

> With the changes in this attached patch (not to be applied, pending  
> the
> previous question), I've been able to make Vista join Samba4, using  
> AES
> kerberos subkeys (and I think therefore GSSAPI CFX).
>
> However, the sequence number is wrong in the server - but only by one.
> I wonder if the 'dce-style' changes are to blame?
>
> perhaps a snippet from my gdb session (on the Samba4 server, with the
> Vista client) might show the problem well:
>
> _gssapi_msg_order_check (o=0x8ed1470, seq_num=109012496)
>   at heimdal/lib/gssapi/krb5/sequence.c:148
> 148    if (o == NULL)
> (gdb) n
> 151    if ((o->flags & (GSS_C_REPLAY_FLAG|GSS_C_SEQUENCE_FLAG)) == 0)
> (gdb)
> 155    if (o->elem[0] == seq_num - 1) {
> (gdb) p o->elem[0]
> $8 = 109012494
> (gdb) p seq_num
> $9 = 109012496
>
> Any ideas?
>
> Thanks,
>
> Andrew Bartlett
> --
> Andrew Bartlett                                http://samba.org/~abartlet/
> Authentication Developer, Samba Team           http://samba.org
> Samba Developer, Red Hat Inc.                  http://redhat.com
>
> <vista-join.patch>

[Andrew Bartlett]

On Tue, 2008-07-22 at 19:16 +0100, Love Hörnquist Åstrand wrote:
> Hello Andrew,
>
> The DCE-STYLE patches where from metze (I think)

Yep.  Did you ever get to do any interop with Microsoft on DCE-STYLE?

> Also, just to confuse us, the seq number might be diffrent for RC4 and  
> AES

That is what worried me...

> Does it work if you change the seq number to one larger in the DCE-RPC  
> case, near the end of acceptor_wait_for_dcestyle() is the remote seq  
> number reset.

Presumably, given the sequence numbers are so close.  I'll try that out,
as well as seeing if there are any clues in the WSPP docs.

Andrew Bartlett

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

[Andrew Bartlett]

On Tue, 2008-07-22 at 19:16 +0100, Love Hörnquist Åstrand wrote:

> Hello Andrew,
>
> The DCE-STYLE patches where from metze (I think)
>
> Also, just to confuse us, the seq number might be diffrent for RC4 and  
> AES
>
> Does it work if you change the seq number to one larger in the DCE-RPC  
> case, near the end of acceptor_wait_for_dcestyle() is the remote seq  
> number reset.
>
> Love

No, it now fails with a checksum error.  Could the CFX crypto be
stateful, from the extra AP-REP?

Andrew Bartlett

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

[Jeffrey Altman-2]

To the best of my knowledge Microsoft does not support out of order
delivery of messaging.

Jeffrey Altman


Andrew Bartlett wrote:

> With the changes in this attached patch (not to be applied, pending the
> previous question), I've been able to make Vista join Samba4, using AES
> kerberos subkeys (and I think therefore GSSAPI CFX).
>
> However, the sequence number is wrong in the server - but only by one.
> I wonder if the 'dce-style' changes are to blame?
>
> perhaps a snippet from my gdb session (on the Samba4 server, with the
> Vista client) might show the problem well:
>
> _gssapi_msg_order_check (o=0x8ed1470, seq_num=109012496)
>     at heimdal/lib/gssapi/krb5/sequence.c:148
> 148    if (o == NULL)
> (gdb) n
> 151    if ((o->flags & (GSS_C_REPLAY_FLAG|GSS_C_SEQUENCE_FLAG)) == 0)
> (gdb)
> 155    if (o->elem[0] == seq_num - 1) {
> (gdb) p o->elem[0]
> $8 = 109012494
> (gdb) p seq_num
> $9 = 109012496
>
> Any ideas?
>
> Thanks,
>
> Andrew Bartlett

[Andrew Bartlett]

On Thu, 2008-07-24 at 13:52 -0400, Jeffrey Altman wrote:
> To the best of my knowledge Microsoft does not support out of order
> delivery of messaging.

The issue here is incorrect computation of the sequence number, and the
crypto state, when using DCE_STYLE.  The problem here is that the first
wrapped packet from the Vista client has a 'wrong' sequence number.  

(The checksum failure might actually be due to AEAD - need to look into
how this works with CFX compared with arcfour).

Andrew Bartlett

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

[Andrew Bartlett]

On Tue, 2008-07-22 at 19:16 +0100, Love Hörnquist Åstrand wrote:
> Hello Andrew,
>
> The DCE-STYLE patches where from metze (I think)
>
> Also, just to confuse us, the seq number might be diffrent for RC4 and  
> AES

It certainly appears that way.  Patched to allow the sequence number to
match for Vista, it fails to accept a join from WinXP.

Andrew Bartlett

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