Re: [kitten] One question about Kerberos Protocol in the RFC 4120
Greg Hudson <ghudson@mit.edu> Wed, 18 August 2021 20:01 UTC
Return-Path: <ghudson@mit.edu>
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1])
by ietfa.amsl.com (Postfix) with ESMTP id A8C163A1B43
for <kitten@ietfa.amsl.com>; Wed, 18 Aug 2021 13:01:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.5
X-Spam-Level:
X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.399, NICE_REPLY_A=-0.001,
SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44])
by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id XhGdiUla81pY for <kitten@ietfa.amsl.com>;
Wed, 18 Aug 2021 13:01:30 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by ietfa.amsl.com (Postfix) with ESMTPS id 639C93A1B45
for <kitten@ietf.org>; Wed, 18 Aug 2021 13:01:30 -0700 (PDT)
Received: from [18.28.8.129] ([18.28.8.129]) (authenticated bits=0)
(User authenticated as ghudson@ATHENA.MIT.EDU)
by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 17IK1RHY030643
(version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT);
Wed, 18 Aug 2021 16:01:28 -0400
To: bc a <mrcatcrack@gmail.com>, kitten@ietf.org
References: <CAD8oZZEofs7pYoiVJThme1iOrUZ5rmqi8L9ur-wHirr6QJTt0g@mail.gmail.com>
From: Greg Hudson <ghudson@mit.edu>
Message-ID: <e196987b-225b-cf39-b9c8-b1b47fe8daa1@mit.edu>
Date: Wed, 18 Aug 2021 16:01:27 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
Thunderbird/78.7.1
MIME-Version: 1.0
In-Reply-To: <CAD8oZZEofs7pYoiVJThme1iOrUZ5rmqi8L9ur-wHirr6QJTt0g@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/kitten/GnEIi-oUPuC4uWA3uz_3ODgZcf0>
Subject: Re: [kitten] One question about Kerberos Protocol in the RFC 4120
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/kitten>,
<mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/kitten/>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>,
<mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 18 Aug 2021 20:01:35 -0000
On 8/18/21 11:53 AM, bc a wrote:
> So I want to know whether it can be considered that the authentication
> server creates two "keys" in the AS-REP phase, one in the "enc-part" of
> the "ticket" field,
> and the other one is in the separate "enc-part" , And whether these two
> "key" values are the same?
The two key values are the same. For an AP exchange to work, the ticket
session key must be available to both the client and the application
service. The key field in the EncKDCRepPart is visible to the client,
while the key field in the EncTicketPart is visible to the application
service.
I see that Derek gave the opposite answer. You can check the Heimdal or
MIT krb5 KDC implementations to see that the same key value is used in
both places. In MIT krb5, the relevant lines are in src/kdc/do_tgs_req.c:
enc_tkt_reply.session = &session_key;
[...]
reply_encpart.session = &session_key;
and similarly in do_as_req.c.
- [kitten] One question about Kerberos Protocol in … bc a
- Re: [kitten] One question about Kerberos Protocol… Derek Atkins
- Re: [kitten] One question about Kerberos Protocol… Greg Hudson
- Re: [kitten] One question about Kerberos Protocol… Derek Atkins
- Re: [kitten] One question about Kerberos Protocol… bc a