IETF Logo Mail Archive

Re: [kitten] One question about Kerberos Protocol in the RFC 4120

Derek Atkins <derek@ihtfp.com> Wed, 18 August 2021 20:22 UTC

Return-Path: <derek@ihtfp.com>
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 D80943A1C38 for <kitten@ietfa.amsl.com>; Wed, 18 Aug 2021 13:22:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.699
X-Spam-Level:
X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=ihtfp.com
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 ppLLod4NKv6V for <kitten@ietfa.amsl.com>; Wed, 18 Aug 2021 13:22:27 -0700 (PDT)
Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE5FE3A1C16 for <kitten@ietf.org>; Wed, 18 Aug 2021 13:22:27 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 199B4E2040; Wed, 18 Aug 2021 16:22:26 -0400 (EDT)
Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 19955-10; Wed, 18 Aug 2021 16:22:21 -0400 (EDT)
Received: by mail2.ihtfp.org (Postfix, from userid 48) id 78A3EE2042; Wed, 18 Aug 2021 16:22:21 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1629318141; bh=HqEKFqB1Ucx5tcOJGHoTvyYk4ge36x3G/0nL8S+kEnc=; h=In-Reply-To:References:Date:Subject:From:To:Cc; b=DUMM5nSJ++OuSy2F+YZMrBicVpWmTjokIvVlMJ79LVlJfve+0eCIVzOqVLQB5+ULu WH0BxMZws0C5ImOGz8B2VrgCTAsFiwIyUN7mk2Tvx56Kj+ZKrymEOAMp14+w3P1dxx pHmt0fgSaIspMf6qlNoEj7WMC1lH/oX/oc2Hgug8=
Received: from 192.168.248.243 (SquirrelMail authenticated user warlord) by mail2.ihtfp.org with HTTP; Wed, 18 Aug 2021 16:22:21 -0400
Message-ID: <2a1053eb77e1a74efff7b25288de9cb4.squirrel@mail2.ihtfp.org>
In-Reply-To: <e196987b-225b-cf39-b9c8-b1b47fe8daa1@mit.edu>
References: <CAD8oZZEofs7pYoiVJThme1iOrUZ5rmqi8L9ur-wHirr6QJTt0g@mail.gmail.com> <e196987b-225b-cf39-b9c8-b1b47fe8daa1@mit.edu>
Date: Wed, 18 Aug 2021 16:22:21 -0400
From: "Derek Atkins" <derek@ihtfp.com>
To: "Greg Hudson" <ghudson@mit.edu>
Cc: "bc a" <mrcatcrack@gmail.com>, kitten@ietf.org
User-Agent: SquirrelMail/1.4.22-14.fc20
MIME-Version: 1.0
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
X-Virus-Scanned: Maia Mailguard 1.0.2a
Archived-At: <https://mailarchive.ietf.org/arch/msg/kitten/gKfrAnZy4PK2PhRcgQF6cX5zBTc>
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:22:45 -0000

Hi,

On Wed, August 18, 2021 4:01 pm, Greg Hudson wrote:
> 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.

I didn't *quite* give the opposite answer.  Every session key is unique. 
But you are correct that I was unclear on the fact that the KDC has to
transmit the same session key to the user and the service.

>   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.

-derek

> _______________________________________________
> Kitten mailing list
> Kitten@ietf.org
> https://www.ietf.org/mailman/listinfo/kitten
>


-- 
       Derek Atkins                 617-623-3745
       derek@ihtfp.com             www.ihtfp.com
       Computer and Internet Security Consultant

v2.8.7 | Report a Bug | By Email