Path: csiph.com!tncsrv06.tnetconsulting.net!.POSTED.mailman.mit.edu!not-for-mail
From: Michael B Allen <ioplex@gmail.com>
Newsgroups: comp.protocols.kerberos
Subject: Re: GSS unwrap fails using RC4 session key instead of subkey
Date: Thu, 8 May 2025 14:17:45 -0400
Organization: TNet Consulting
Lines: 86
Message-ID: <mailman.196.1746728286.2322.kerberos@mit.edu>
References: <CAGMFw4h2LAOk0qLXkf0mg8yWTZNdXTHZgBcC2Lpupj=UX+fJ_g@mail.gmail.com> <ab72df03-6661-4eaf-90f7-eac59420b9f2@mit.edu> <CAGMFw4idqCuPHAzvf6CJRQeChCjLmBPqWOvOi26FLxrNbY1+Bg@mail.gmail.com> <CAGMFw4hjFLkP0J0G7CzJ=oQK0gwjNW-F=n+VPjwVXQM=y=4c-A@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Injection-Info: tncsrv06.tnetconsulting.net; posting-host="mailman.mit.edu:18.7.21.50"; logging-data="25029"; mail-complaints-to="newsmaster@tnetconsulting.net"
To: kerberos <kerberos@mit.edu>
Received-SPF: Pass (protection.outlook.com: domain of gmail.com designates 2607:f8b0:4864:20::c2e as permitted sender) receiver=protection.outlook.com; client-ip=2607:f8b0:4864:20::c2e; helo=mail-oo1-xc2e.google.com; pr=C
In-Reply-To: <CAGMFw4idqCuPHAzvf6CJRQeChCjLmBPqWOvOi26FLxrNbY1+Bg@mail.gmail.com>
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 May 2025 18:17:58.8954 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 70f3e3c7-990f-4d06-c96c-08dd8e5ca99b
X-MS-Exchange-CrossTenant-Id: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b
X-MS-Exchange-CrossTenant-AuthSource: SJ5PEPF000001C9.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: Internet
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO6PR01MB7500
X-Content-Filtered-By: Mailman/MimeDel 2.1.34
X-BeenThere: kerberos@mit.edu
X-Mailman-Version: 2.1.34
Precedence: list
List-Id: The Kerberos Authentication System Mailing List <kerberos.mit.edu>
List-Unsubscribe: <https://mailman.mit.edu/mailman/options/kerberos>, <mailto:kerberos-request@mit.edu?subject=unsubscribe>
List-Archive: <http://mailman.mit.edu/pipermail/kerberos/>
List-Post: <mailto:kerberos@mit.edu>
List-Help: <mailto:kerberos-request@mit.edu?subject=help>
List-Subscribe: <https://mailman.mit.edu/mailman/listinfo/kerberos>, <mailto:kerberos-request@mit.edu?subject=subscribe>
X-Mailman-Original-Message-ID: <CAGMFw4hjFLkP0J0G7CzJ=oQK0gwjNW-F=n+VPjwVXQM=y=4c-A@mail.gmail.com>
X-Mailman-Original-References: <CAGMFw4h2LAOk0qLXkf0mg8yWTZNdXTHZgBcC2Lpupj=UX+fJ_g@mail.gmail.com> <ab72df03-6661-4eaf-90f7-eac59420b9f2@mit.edu> <CAGMFw4idqCuPHAzvf6CJRQeChCjLmBPqWOvOi26FLxrNbY1+Bg@mail.gmail.com>
Xref: csiph.com comp.protocols.kerberos:5412

On Thu, May 8, 2025 at 12:10=E2=80=AFAM Michael B Allen <ioplex@gmail.com> =
wrote:

> So the session key used starts with C952.
>

I meant to say subkey not session key.

For completeness I ran my initiator against the Windows Server SSPI
acceptor, and got the following:

InitStepState: Authenticator {
  cname: TsspiUserAes256@MEGA.CORP
  cksum: Checksum8003 {
    channelBindings: 00000000000000000000000000000000
    gssflags: 0x0000403E
        GSS_C_DELEG_FLAG
      Y GSS_C_MUTUAL_FLAG
      Y GSS_C_REPLAY_FLAG
      Y GSS_C_SEQUENCE_FLAG
      Y GSS_C_CONF_FLAG
      Y GSS_C_INTEG_FLAG
        GSS_C_DCE_STYLE
        GSS_C_IDENTIFY_FLAG
      Y GSS_C_EXTENDED_ERROR_FLAG
  }
  cusec: 588294
  ctime: 20250508174734Z
  subkey: (23)412213...
  seq-number: 656590050
}
InitStepState: GssContextToken {
  mech: KRB5 (1.2.840.113554.1.2.2)
  Krb5InnerContextToken {
    tokId: 0x0001
    ApReq {
      ap-options: 0x20000000
      ticket: Ticket {
        sname: HOST/TsspiCompRc4.mega.corp@MEGA.CORP
        enc-part: (23)6D9EDF...
      }
      authenticator: (23)3B0B5F...
    }
  }
}
InitStepState: GssContextToken {
  mech: KRB5 (1.2.840.113554.1.2.2)
  Krb5InnerContextToken {
    tokId: 0x0002
    ApRep {
      enc-part: (23)8A32FD...
    }
  }
}
InitStepState: EncAPRepPart {
  ctime: 20250508174734Z
  cusec: 588294
  subkey: (23)412213...
  seq-number: 2110239284
}
Rc4 wrap: key:
00000: 41 22 13 30 34 0D D6 44 39 7E 27 E5 91 31 30 1D  |A".04.=C3=96D9~'=
=C3=A5.10.

As you can see, the SSPI acceptor simply uses the same key for the
Authenticator subkey and AP-REP subkey.
Not sure how the SSPI knows to do this.
Maybe it's just hardcoded behavior of RC4.

So when MITK initiates to an SSPI RC4 service, it uses the Acceptor subkey
whereas the SSPI initiator will use the AP-REP subkey but it doesn't matter
because the keys are the same.

The bottom line is that if anyone writes an acceptor from scratch like me,
and they want to support RC4, the acceptor will need to either "Negotiated
enctype" to a different enctype so that the MITK initiator uses the AP-REP
subkey (the MITK way), or just return the same RC4 subkey for the
Authenticator and AP-REP subkeys (the SSPI way) so that does not matter if
the MITK initiator uses the Authenticator subkey.

Mike

--=20
Michael B Allen
Java AD DS Integration
https://www.ioplex.com/ <http://www.ioplex.com/>