From nobody Wed Oct 10 09:30:34 2018 Return-Path: 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 534E1130F84 for ; Wed, 10 Oct 2018 09:30:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham 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 aJDGaT7M5w-y for ; Wed, 10 Oct 2018 09:30:28 -0700 (PDT) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (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 5676A130FB5 for ; Wed, 10 Oct 2018 09:30:28 -0700 (PDT) X-AuditID: 1209190c-247ff700000076cc-b1-5bbe29227e73 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id 80.A3.30412.2292EBB5; Wed, 10 Oct 2018 12:30:27 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id w9AGUNig031632 for ; Wed, 10 Oct 2018 12:30:24 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w9AGUKAW027118 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 10 Oct 2018 12:30:22 -0400 Date: Wed, 10 Oct 2018 11:30:19 -0500 From: Benjamin Kaduk To: kitten@ietf.org Message-ID: <20181010163019.GL3293@kduck.kaduk.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrDIsWRmVeSWpSXmKPExsUixG6noqusuS/a4Ol6Houjm1exODB6LFny kymAMYrLJiU1J7MstUjfLoEro+FNO3vBSqaKd/NKGhh/MnYxcnJICJhIHG+awdTFyMUhJLCY SeL02b/MEM5xRonu/c3sEM5rJok5H16CtbAIqEpcav3FDmKzCahINHRfZgaxRQSEJXZvfQdm Cws4SCyaMRnM5hUwlvh1phnKFpQ4OfMJC4jNLKAlcePfS6DVHEC2tMTyfxwgYVEBZYm9fYfY JzDyzkLSMQtJxyyEjgWMzKsYZVNyq3RzEzNzilOTdYuTE/PyUot0DfVyM0v0UlNKNzGCAolT kmcH45k3XocYBTgYlXh4f0jtixZiTSwrrsw9xCjJwaQkytvlvjdaiC8pP6UyI7E4I76oNCe1 +BCjBAezkgjvanmgct6UxMqq1KJ8mJQ0B4uSOO+ElsXRQgLpiSWp2ampBalFMFkZDg4lCV5W DaBGwaLU9NSKtMycEoQ0EwcnyHAeoOHH1UGGFxck5hZnpkPkTzEqSonzOoIkBEASGaV5cL2g SJfI3l/zilEc6BVhXmGQFTzAJAHX/QpoMBPQ4FMhe0AGlyQipKQaGLff2Hr4Z+4qH915RRuC LrwP1ArlffLJ45Q347N4PZnT9avtY+cvLnL4VXZRvFWzPHWOaSgj94QON88T+o43Z94x3XJH cUOq3MLDlnvT1I7frsiwc3iWL1ARc3qKi1jZ1Lr3ZppCS/dH6IXdk58hX5OWW/Dv5OqqeX3+ h61ilrqylaTs367+TomlOCPRUIu5qDgRAIJ9xgfPAgAA Archived-At: Subject: [kitten] draft-ietf-kitten-krb-service-discovery and URI records X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2018 16:30:30 -0000 Hi all, Just noting that when we pick draft-ietf-kitten-krb-service-discovery up again, there's going to be a registry for global DNS "underscore" names, created by draft-ietf-dnsop-attrleaf. So we'd want to add entries to that registry for URI+{_kerberos,_kpasswd,_kerberos-adm}. -Ben From nobody Sat Oct 20 01:10:51 2018 Return-Path: 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 24A6512872C for ; Sat, 20 Oct 2018 01:10:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=openfortress.nl 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 7WaSKo28Ol8X for ; Sat, 20 Oct 2018 01:10:47 -0700 (PDT) Received: from lb3-smtp-cloud7.xs4all.net (lb3-smtp-cloud7.xs4all.net [194.109.24.31]) (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 337C11271FF for ; Sat, 20 Oct 2018 01:10:47 -0700 (PDT) Received: from popmini.vanrein.org ([83.161.146.46]) by smtp-cloud7.xs4all.net with ESMTP id DmLLg6MPCw2L8DmLMgkSW3; Sat, 20 Oct 2018 10:10:45 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=openfortress.nl; i=rick@openfortress.nl; q=dns/txt; s=fame; t=1540023037; h=message-id : date : from : mime-version : to : subject : content-type : content-transfer-encoding : date : from : subject; bh=cpBcOsDHA3RuZCUNDCJy/geuFYAuw0BICpuBIDKFwQw=; b=I3f/4pJqu8qXOojWeEkbA869MP0qhUsofSCFV27pQ06Kqw28Om1l4Yp2 k5th+Y3fEfkt/MzchdYks6SHEc4XBxH92Gpcd6SyLNfsbqHuupzs09aRJ3 rEkvcsvTmho1tttlcWKDvEWioG0vIQbRyVZr7dfDC8ZlIfnSy7JT1JCoA= Received: by fame.vanrein.org (Postfix, from userid 1006) id 7E75920740; Sat, 20 Oct 2018 08:10:37 +0000 (UTC) X-Original-To: kitten@ietf.org Received: from airhead.local (phantom.vanrein.org [83.161.146.46]) by fame.vanrein.org (Postfix) with ESMTPA id C782220742; Sat, 20 Oct 2018 08:10:31 +0000 (UTC) Message-ID: <5BCAE2F5.3040405@openfortress.nl> Date: Sat, 20 Oct 2018 10:10:29 +0200 From: Rick van Rein User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: "kitten@ietf.org" X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Bogosity: Unsure, tests=bogofilter, spamicity=0.520000, version=1.2.4 X-CMAE-Envelope: MS4wfNeT3ZQRE+l/P+Ovg5LV5Pg00YSpkezDFKQCEL7lyAgX5p+4KAC8foS/u/3UVRjmULcdEB5zYityHdna+kwMrrAGeTIQBO+Ntx8LPT8LstOGSWjTfKqe Gv7cmKoU3j45Eh8+/s5YtkHjCi9My5BLEMENCX/NIfMhdDmUlGRr1U+8 Archived-At: Subject: [kitten] FYI, new I-D :- Diameter messaging in Kerberos AuthorizationData X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Oct 2018 08:10:50 -0000 Hello, FYI -- I filed an I-D that describes Kerberos AuthorizationData in a format that follows a general format, namely Diameter messages. Any comment on this combination of technologies is welcome. It is not my current intention to push for RFC status, but merely to specify the option clearly and get a unique tag number for it. If you think it should be more than that, please share. Cheers, -Rick -------- Original Message -------- Subject: New Version Notification for draft-vanrein-krb5-authzdata-diameter-00.txt Date: Sat, 20 Oct 2018 01:01:24 -0700 From: internet-drafts@ietf.org To: Rick van Rein A new version of I-D, draft-vanrein-krb5-authzdata-diameter-00.txt has been successfully submitted by Rick van Rein and posted to the IETF repository. Name: draft-vanrein-krb5-authzdata-diameter Revision: 00 Title: Diameter Messages in Kerberos5 AuthorizationData Document date: 2018-10-20 Group: Individual Submission Pages: 8 URL: https://www.ietf.org/internet-drafts/draft-vanrein-krb5-authzdata-diameter-00.txt Status: https://datatracker.ietf.org/doc/draft-vanrein-krb5-authzdata-diameter/ Htmlized: https://tools.ietf.org/html/draft-vanrein-krb5-authzdata-diameter-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-vanrein-krb5-authzdata-diameter Abstract: The Kerberos5 infrastructure is concerned with authentication, but it can also carry AuthorizationData in a variety of formats. Diameter is an extensible standard for the expression of authorisation information. This specification defines an embedding of Diameter data in the AuthorizationData fields of Kerberos5. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Mon Oct 29 00:52:18 2018 Return-Path: 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 D491C130DF5 for ; Mon, 29 Oct 2018 00:52:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.601 X-Spam-Level: X-Spam-Status: No, score=-0.601 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=openfortress.nl 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 UxVeXQHgnVJA for ; Mon, 29 Oct 2018 00:52:14 -0700 (PDT) Received: from lb3-smtp-cloud7.xs4all.net (lb3-smtp-cloud7.xs4all.net [194.109.24.31]) (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 CF8CD130DEC for ; Mon, 29 Oct 2018 00:52:10 -0700 (PDT) Received: from popmini.vanrein.org ([83.161.146.46]) by smtp-cloud7.xs4all.net with ESMTP id H2LGgPsKKw2L8H2LHgUacX; Mon, 29 Oct 2018 08:52:08 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=openfortress.nl; i=rick@openfortress.nl; q=dns/txt; s=fame; t=1540799520; h=message-id : date : from : mime-version : to : subject : content-type : content-transfer-encoding : date : from : subject; bh=Zjaxnz+8/tVGl/ciZUs9PJeR+FHTpsn8s7O5TxDNXIE=; b=rKwwKurHkM66ax84gKL4hT20lU5Ru05bJJEw8SoPzREUxrg2cunO76AD hyQiAJhqxmoDuP+rLY9bjwc0FZcsYabkUoKZHRIZQPCyV6Xy6KZQ++Jbst Z2XaZ6Tmqtv7f+kGBrR+SfkiwvACnJX9vsr8x0wGxjig7Vc47Z71OAC+k= Received: by fame.vanrein.org (Postfix, from userid 1006) id DD69A20FA8; Mon, 29 Oct 2018 07:52:00 +0000 (UTC) X-Original-To: kitten@ietf.org Received: from airhead.local (phantom.vanrein.org [83.161.146.46]) by fame.vanrein.org (Postfix) with ESMTPA id C7E0621621; Mon, 29 Oct 2018 07:52:00 +0000 (UTC) Message-ID: <5BD6BC1F.5000800@openfortress.nl> Date: Mon, 29 Oct 2018 08:51:59 +0100 From: Rick van Rein User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: "kitten@ietf.org" X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Bogosity: Unsure, tests=bogofilter, spamicity=0.520000, version=1.2.4 X-CMAE-Envelope: MS4wfBRG4dAns5NesTzNwQqknVIXN08zOjXSXl6ygAQiFsPr66DJgbBB9HDrxePLFo/dGdmk9Gtf7vDG+PHo432pZAMekhKhtjvBmuHiif1ZcSGuYOSPJf2m Jw8FCXl/QSdY3YPiTrwCsJAuk0agKP/ZiaZTLN0XlINeVSKQlk538XAn Archived-At: Subject: [kitten] User-to-user Kerberos in GSS-API X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2018 07:52:17 -0000 Hello, I'm looking into user-to-user encryption with Kerberos, and that can be done when a user submits a TGT (without the key) to the intended communication peer, who can then send it to the KDC to obtain a user-to-user ticket. This is considered difficult and theoretical. In GSS-API, it should be doable to insert a phase preceding standard Kerberos5, where a TGT is pushed from the initiator to the acceptor, who then contacts its KDC, and so on. We've seen a similar thing in SPNEGO. Has this been considered / and if so, why did it not mature? Thanks, -Rick From nobody Mon Oct 29 10:26:21 2018 Return-Path: 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 43227131050 for ; Mon, 29 Oct 2018 10:26:20 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Non-encoded 8-bit data (char 9C hex): Received: ...s kaduk@ATHENA.MIT.EDU)\n\t\234by outgoing.mit[...] X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham 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 YXYKxk1Cakry for ; Mon, 29 Oct 2018 10:26:18 -0700 (PDT) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (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 30C7F13104A for ; Mon, 29 Oct 2018 10:26:18 -0700 (PDT) X-AuditID: 1209190d-ef1ff70000006cdc-3b-5bd742b8df86 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 58.39.27868.8B247DB5; Mon, 29 Oct 2018 13:26:17 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-3.mit.edu (8.14.7/8.9.2) with ESMTP id w9THQFvM004486; Mon, 29 Oct 2018 13:26:15 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) œby outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id w9THQB2h022438 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 29 Oct 2018 13:26:14 -0400 Date: Mon, 29 Oct 2018 12:26:11 -0500 From: Benjamin Kaduk To: Rick van Rein Cc: "kitten@ietf.org" Message-ID: <20181029172611.GL45914@kduck.kaduk.org> References: <5BD6BC1F.5000800@openfortress.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5BD6BC1F.5000800@openfortress.nl> User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrJIsWRmVeSWpSXmKPExsUixCmqrbvT6Xq0waNGRoujm1exWDx9dY/N gcljyZKfTB4b/jWxBTBFcdmkpOZklqUW6dslcGVc3vyMrWAie8XXzQuZGxivsHYxcnJICJhI 3LrcydjFyMUhJLCGSWLZodMsEM5GRokdT7+yg1QJCdxlkpjcLNXFyMHBIqAq0X1OECTMJqAi 0dB9mRnEFhHQkPj8ayobiM0soC5x9HkTmC0sYCYx8e0dJhCbF2jZ9yvvoUbqSVyb9pkFIi4o cXLmExaIXi2JG/9eMoGsYhaQllj+jwMkzCmgLzHp1iKwkaICyhJ7+w6xT2AUmIWkexaS7lkI 3QsYmVcxyqbkVunmJmbmFKcm6xYnJ+blpRbpGunlZpbopaaUbmIEh6gk7w7Gf3e9DjEKcDAq 8fBq6FyPFmJNLCuuzD3EKMnBpCTK6+kAFOJLyk+pzEgszogvKs1JLT7EKMHBrCTC+94AKMeb klhZlVqUD5OS5mBREued0LI4WkggPbEkNTs1tSC1CCYrw8GhJMF71hGoUbAoNT21Ii0zpwQh zcTBCTKcB2j4fJAa3uKCxNzizHSI/ClGRSlx3nyQhABIIqM0D64XlEIksvfXvGIUB3pFmNcO mFCEeIDpB677FdBgJqDBi4WugAwuSURISTUwurqkfHSdcPfa0y63Vsltiu0Hz0taJ/mZGHbJ HVh7soI1Ksar+jxbh/L3lQtMJPP5l+5zPKyZtf8887f+dy07F7k/Uq/v3Wf8d2WDpGTF6dvp dZtqt53aPGX6i/99+6Q+L1qeHaTWpl0Se4Tjo2r4i9M5T2e/MORYX8bH+Pa+9buXJ+q8dBz0 lViKMxINtZiLihMB1UOXb/wCAAA= Archived-At: Subject: Re: [kitten] User-to-user Kerberos in GSS-API X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2018 17:26:20 -0000 On Mon, Oct 29, 2018 at 08:51:59AM +0100, Rick van Rein wrote: > Hello, > > I'm looking into user-to-user encryption with Kerberos, and that can be > done when a user submits a TGT (without the key) to the intended > communication peer, who can then send it to the KDC to obtain a > user-to-user ticket. This is considered difficult and theoretical. > > In GSS-API, it should be doable to insert a phase preceding standard > Kerberos5, where a TGT is pushed from the initiator to the acceptor, who > then contacts its KDC, and so on. We've seen a similar thing in SPNEGO. > > Has this been considered / and if so, why did it not mature? I don't know of it having been explicitly considered previously (though I did not attempt to search the archives and confirm), but mostly assume that it was seen as uninteresting given the general low usage level of user-to-user functionality. -Ben From nobody Mon Oct 29 11:31:52 2018 Return-Path: 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 7EFA6131066 for ; Mon, 29 Oct 2018 11:31:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 TWZi7kSF08r8 for ; Mon, 29 Oct 2018 11:31:48 -0700 (PDT) Received: from glass.birch.relay.mailchannels.net (glass.birch.relay.mailchannels.net [23.83.209.70]) (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 E9DC9131059 for ; Mon, 29 Oct 2018 11:31:47 -0700 (PDT) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 92DC45C3D98; Mon, 29 Oct 2018 18:31:45 +0000 (UTC) Received: from pdx1-sub0-mail-a60.g.dreamhost.com (unknown [100.96.11.179]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 2A45A5C47BF; Mon, 29 Oct 2018 18:31:45 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a60.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.16.2); Mon, 29 Oct 2018 18:31:45 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Callous-Whimsical: 20849cbb7c9d28d5_1540837905346_4218739831 X-MC-Loop-Signature: 1540837905346:2799269298 X-MC-Ingress-Time: 1540837905346 Received: from pdx1-sub0-mail-a60.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a60.g.dreamhost.com (Postfix) with ESMTP id D6825807F9; Mon, 29 Oct 2018 11:31:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=ZipAvHq2cBYBOz 8P88J0iPHGciA=; b=ea1Qr3KyaS80SMUMRfiQfAsdEFMtzBcM4OlwyvXcD5OA8w hDBVqyrmKiXHitZw4X+anFzmQZ/1VskVFiG7jX1dKmnY/NdjviGM82l4/Z45muS6 DRfr1144hZxHVzIkrrL4bouUFbCGynEYV4KAgeTxk2+Rw4DoCaTT5e3Ta4AP0= Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a60.g.dreamhost.com (Postfix) with ESMTPSA id A32CD807E8; Mon, 29 Oct 2018 11:31:40 -0700 (PDT) Date: Mon, 29 Oct 2018 13:31:38 -0500 X-DH-BACKEND: pdx1-sub0-mail-a60 From: Nico Williams To: Benjamin Kaduk Cc: Rick van Rein , "kitten@ietf.org" Message-ID: <20181029183137.GB2486@localhost> References: <5BD6BC1F.5000800@openfortress.nl> <20181029172611.GL45914@kduck.kaduk.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20181029172611.GL45914@kduck.kaduk.org> User-Agent: Mutt/1.5.24 (2015-08-30) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedtkedrheekgdduudehucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepfffhvffukfhfgggtuggjfgesthdtredttdervdenucfhrhhomheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqeenucfkphepvdegrddvkedruddtkedrudekfeenucfrrghrrghmpehmohguvgepshhmthhppdhhvghloheplhhotggrlhhhohhsthdpihhnvghtpedvgedrvdekrddutdekrddukeefpdhrvghtuhhrnhdqphgrthhhpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqpdhmrghilhhfrhhomhepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhdpnhhrtghpthhtohepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhenucevlhhushhtvghrufhiiigvpedt Archived-At: Subject: Re: [kitten] User-to-user Kerberos in GSS-API X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2018 18:31:51 -0000 On Mon, Oct 29, 2018 at 12:26:11PM -0500, Benjamin Kaduk wrote: > On Mon, Oct 29, 2018 at 08:51:59AM +0100, Rick van Rein wrote: > > Hello, > > > > I'm looking into user-to-user encryption with Kerberos, and that can be > > done when a user submits a TGT (without the key) to the intended > > communication peer, who can then send it to the KDC to obtain a > > user-to-user ticket. This is considered difficult and theoretical. > > > > In GSS-API, it should be doable to insert a phase preceding standard > > Kerberos5, where a TGT is pushed from the initiator to the acceptor, who > > then contacts its KDC, and so on. We've seen a similar thing in SPNEGO. > > > > Has this been considered / and if so, why did it not mature? > > I don't know of it having been explicitly considered previously (though I > did not attempt to search the archives and confirm), but mostly assume that > it was seen as uninteresting given the general low usage level of > user-to-user functionality. I have a use for user-to-user, as well as for multi-round-trip extensions to the existing mechanism. The use for this has to do with keying clusters atomically, which is difficult to pull off. If you have user-to-user, you can always just make sure that each member of a cluster can get a TGT for the service principal name and not bother making sure they all have the latest keys for the service principal name. Using PA-TGS for AS exchanges would even make it possible for a host to get TGTs for containers/guests without having to ever even have keys for the container services -- this would be an amazing simplification to key management. Multi-round-trip extensions can also make cluster key management easier, naturally. Of course, since we have these key management issues now, we already work to solve them in our key management frameworks (e.g., Roland Dowdeswell's krb5_admin/krb5_keytab stack), and will continue to have to for a long time. But it would be very nice if we could get started on making these problems go away, even if it takes a decade to get universal support. Nico -- From nobody Mon Oct 29 11:38:38 2018 Return-Path: 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 1863B131062 for ; Mon, 29 Oct 2018 11:38:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 YklCUpRrWf5D for ; Mon, 29 Oct 2018 11:38:34 -0700 (PDT) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (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 41B9D131059 for ; Mon, 29 Oct 2018 11:38:34 -0700 (PDT) X-AuditID: 1209190f-be7ff70000005fb8-4b-5bd753a715b3 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id B7.D0.24504.8A357DB5; Mon, 29 Oct 2018 14:38:32 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-2.mit.edu (8.14.7/8.9.2) with ESMTP id w9TIcSOE028536; Mon, 29 Oct 2018 14:38:29 -0400 Received: from [192.168.1.4] (pool-74-104-191-203.bstnma.fios.verizon.net [74.104.191.203]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id w9TIcPrr017629 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 29 Oct 2018 14:38:27 -0400 To: Rick van Rein , "kitten@ietf.org" References: <5BD6BC1F.5000800@openfortress.nl> From: Greg Hudson Message-ID: <3777aea8-4799-e58f-391d-42006b693d85@mit.edu> Date: Mon, 29 Oct 2018 14:38:25 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <5BD6BC1F.5000800@openfortress.nl> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBIsWRmVeSWpSXmKPExsUixG6norsi+Hq0wYw2c4ujm1exWDx9dY/N gcljyZKfTB4b/jWxBTBFcdmkpOZklqUW6dslcGVseTyDteA6a8XbUzcZGxiPsHQxcnJICJhI vF37Fsjm4hASWMMk0TJlFyOEs5FR4tTEJnYI5yaTxJp7f8BahAXMJCa+vcMEYosI+Er8mNrC BmILCehJXJv2GayGTUBZYv3+rWA2r4CVxJ8Zd1i7GDk4WARUJXp3pYOERQUiJO6d/8QGUSIo cXLmE7ByTgF9iUm3FoHFmYFWzdv8kBnCFpe49WQ+E4QtL7H97RzmCYwCs5C0z0LSMgtJyywk LQsYWVYxyqbkVunmJmbmFKcm6xYnJ+blpRbpmujlZpbopaaUbmIEBTCnJP8OxjkN3ocYBTgY lXh4NXSuRwuxJpYVV+YeYpTkYFIS5fV0AArxJeWnVGYkFmfEF5XmpBYfYpTgYFYS4X1vAJTj TUmsrEotyodJSXOwKInzTmhZHC0kkJ5YkpqdmlqQWgSTleHgUJLg7QsCahQsSk1PrUjLzClB SDNxcIIM5wEaHgBSw1tckJhbnJkOkT/FqCglzvsnECghAJLIKM2D6wUlGK+M/adfMYoDvSLM +wikigeYnOC6XwENZgIavFjoCsjgkkSElFQDI/u5LdNvHHUr1lmUFHFldUu63xlj3S8BzxKK Bb4otkQL1K7suhapO3vPb1VX2Z0zf3hen7RHc9KkCUdkecy9fFWr5VfOywmZzSBYJpZkuVVK v+2zX7G+Fev+/IogEZ7m3WxVzFNrF/yacstx3SQfsR+72/M5mr9HRCz+z8xxSfb3FqN7KyU7 lViKMxINtZiLihMBWNRkcQsDAAA= Archived-At: Subject: Re: [kitten] User-to-user Kerberos in GSS-API X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2018 18:38:36 -0000 On 10/29/2018 03:51 AM, Rick van Rein wrote: > In GSS-API, it should be doable to insert a phase preceding standard > Kerberos5, where a TGT is pushed from the initiator to the acceptor, who > then contacts its KDC, and so on. We've seen a similar thing in SPNEGO. There is https://tools.ietf.org/html/draft-swift-win2k-krb-user2user-03 which I believe is implemented in Windows SSPI but not in MIT krb5 or Heimdal. In this mechanism the TGT goes from the acceptor to the initiator, which I think helps keep the code paths similar to what they are for the regular krb5 mech (although the acceptor cred for this mech would need to be more similar to a krb5 initiator cred than to a krb5 acceptor cred). From nobody Mon Oct 29 11:52:37 2018 Return-Path: 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 A53BE131063 for ; Mon, 29 Oct 2018 11:52:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 dbDO-tGHCmiq for ; Mon, 29 Oct 2018 11:52:33 -0700 (PDT) Received: from bonobo.maple.relay.mailchannels.net (bonobo.maple.relay.mailchannels.net [23.83.214.22]) (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 0C9C8131065 for ; Mon, 29 Oct 2018 11:52:32 -0700 (PDT) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 9F691501B37; Mon, 29 Oct 2018 18:52:28 +0000 (UTC) Received: from pdx1-sub0-mail-a50.g.dreamhost.com (unknown [100.96.16.121]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id C9180501A51; Mon, 29 Oct 2018 18:52:27 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a50.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.16.2); Mon, 29 Oct 2018 18:52:28 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Desert-Decisive: 43a902f076e155e6_1540839148245_1206968025 X-MC-Loop-Signature: 1540839148245:192368741 X-MC-Ingress-Time: 1540839148245 Received: from pdx1-sub0-mail-a50.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a50.g.dreamhost.com (Postfix) with ESMTP id 71B07807FE; Mon, 29 Oct 2018 11:52:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=xNeRV0THjbMEEj 2aonX41NPxDLo=; b=sJaXq/2iZfqIjRSCeeW7yRXuYg51CBYSAXzKOCkqMLNWvG oAujXD99DS2AVUhbBXXXzuoysRCuBOT6I58rWEYM1FuNkP0KSxWTUxp72alWkUrZ cD4sApcFJdZpgoOns30TReq9BRdZKj+6ONEta6Tx+txZvkgLg0sgmuD1lHPI4= Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a50.g.dreamhost.com (Postfix) with ESMTPSA id 3D772807FA; Mon, 29 Oct 2018 11:52:23 -0700 (PDT) Date: Mon, 29 Oct 2018 13:52:21 -0500 X-DH-BACKEND: pdx1-sub0-mail-a50 From: Nico Williams To: Greg Hudson Cc: Rick van Rein , "kitten@ietf.org" Message-ID: <20181029185219.GC2486@localhost> References: <5BD6BC1F.5000800@openfortress.nl> <3777aea8-4799-e58f-391d-42006b693d85@mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3777aea8-4799-e58f-391d-42006b693d85@mit.edu> User-Agent: Mutt/1.5.24 (2015-08-30) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedtkedrheekgdduudelucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepfffhvffukfhfgggtuggjfgesthdtredttdervdenucfhrhhomheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqeenucffohhmrghinhepihgvthhfrdhorhhgnecukfhppedvgedrvdekrddutdekrddukeefnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehlohgtrghlhhhoshhtpdhinhgvthepvdegrddvkedruddtkedrudekfedprhgvthhurhhnqdhprghthheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqedpmhgrihhlfhhrohhmpehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmpdhnrhgtphhtthhopehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmnecuvehluhhsthgvrhfuihiivgeptd Archived-At: Subject: Re: [kitten] User-to-user Kerberos in GSS-API X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2018 18:52:36 -0000 On Mon, Oct 29, 2018 at 02:38:25PM -0400, Greg Hudson wrote: > On 10/29/2018 03:51 AM, Rick van Rein wrote: > >In GSS-API, it should be doable to insert a phase preceding standard > >Kerberos5, where a TGT is pushed from the initiator to the acceptor, who > >then contacts its KDC, and so on. We've seen a similar thing in SPNEGO. > > There is > > https://tools.ietf.org/html/draft-swift-win2k-krb-user2user-03 > > which I believe is implemented in Windows SSPI but not in MIT krb5 or > Heimdal. We should implement this. > In this mechanism the TGT goes from the acceptor to the initiator, > which I think helps keep the code paths similar to what they are for the > regular krb5 mech (although the acceptor cred for this mech would need to be > more similar to a krb5 initiator cred than to a krb5 acceptor cred). That is the correct way to do it. (An inverted mechanism would also work, but would require new AP messages so that authorization data can flow from the initiator to the acceptor.) We could also do this with the same mechanism OID as in RFC4121 as follows (this is desirable because it simplifies negotiation): 1. TGS-driven user2user with RFC4121 mech OID: a) the initiator attempts a TGS exchange and gets KDC_ERR_MUST_USE_USER2USER, b) the initiator prepares a 1-octet initial security context token (plus the OID wrapper) and sends it, c) (a) implies that the acceptor knows how to handle this 1-octet token and sends back its TGT, d) the initiator does a TGS exchange with the acceptor's TGT as the second ticket and then sends an AP-REQ, e) the acceptor responds with an AP-REP (if GSS_C_MUTUAL_FLAG is set anyways). 2. Acceptor-driven user2user with RFC4121 mech OID: This is a variant of the multi-round-trip extension... a) the initiator does a TGS exchange, gets a service ticket, sends an AP-REQ, but with an ap-option indicating it's willing to perform additional round-trips, b) the acceptor can't decrypt the service ticket but has a TGT, so it responds with its TGT as the reply token, c) the initiator does a TGS exchange with the acceptor's TGT as the second ticket and then sends an AP-REQ, d) the acceptor responds with an AP-REP (if GSS_C_MUTUAL_FLAG is set anyways). Nico -- From nobody Mon Oct 29 14:21:01 2018 Return-Path: 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 4A3C0130FF6 for ; Mon, 29 Oct 2018 14:21:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 NzpbQjIMu7yr for ; Mon, 29 Oct 2018 14:20:57 -0700 (PDT) Received: from bongo.maple.relay.mailchannels.net (bongo.maple.relay.mailchannels.net [23.83.214.21]) (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 94BE4130F58 for ; Mon, 29 Oct 2018 14:20:57 -0700 (PDT) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id A041912454E; Mon, 29 Oct 2018 21:20:56 +0000 (UTC) Received: from pdx1-sub0-mail-a69.g.dreamhost.com (unknown [100.96.36.160]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 5AC2C124538; Mon, 29 Oct 2018 21:20:56 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a69.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.16.2); Mon, 29 Oct 2018 21:20:56 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Shade-Wiry: 6009af2c1ce88beb_1540848056476_3488613958 X-MC-Loop-Signature: 1540848056476:1560263471 X-MC-Ingress-Time: 1540848056475 Received: from pdx1-sub0-mail-a69.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a69.g.dreamhost.com (Postfix) with ESMTP id 19F2980864; Mon, 29 Oct 2018 14:20:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=I3TkehLyMBrJfv bk/17yxYTl3MY=; b=Cz9Kjh8XGQmDbQSQb4/U2sapplQ+6VF5Dior9zxv3u7FnB tFgC0BEx9xxIfonhrgIi+guLAEJTRw2PzpZg2Gb9kuChlm4o6LnardNI/3Ot1dcU ukpXylF050H5Nk4rp/O1ZBxzu8vCqWbbYLKVHGBnehFaqpq/HtGkX1kcbxAwE= Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a69.g.dreamhost.com (Postfix) with ESMTPSA id 9C9E780868; Mon, 29 Oct 2018 14:20:50 -0700 (PDT) Date: Mon, 29 Oct 2018 16:20:47 -0500 X-DH-BACKEND: pdx1-sub0-mail-a69 From: Nico Williams To: Greg Hudson Cc: Rick van Rein , "kitten@ietf.org" Message-ID: <20181029212046.GD2486@localhost> References: <5BD6BC1F.5000800@openfortress.nl> <3777aea8-4799-e58f-391d-42006b693d85@mit.edu> <20181029185219.GC2486@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20181029185219.GC2486@localhost> User-Agent: Mutt/1.5.24 (2015-08-30) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedtkedrheekgddufeekucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepfffhvffukfhfgggtuggjfgesthdtredttdervdenucfhrhhomheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqeenucfkphepvdegrddvkedruddtkedrudekfeenucfrrghrrghmpehmohguvgepshhmthhppdhhvghloheplhhotggrlhhhohhsthdpihhnvghtpedvgedrvdekrddutdekrddukeefpdhrvghtuhhrnhdqphgrthhhpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqpdhmrghilhhfrhhomhepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhdpnhhrtghpthhtohepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhenucevlhhushhtvghrufhiiigvpedt Archived-At: Subject: Re: [kitten] User-to-user Kerberos in GSS-API X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2018 21:21:00 -0000 On Mon, Oct 29, 2018 at 01:52:21PM -0500, Nico Williams wrote: > On Mon, Oct 29, 2018 at 02:38:25PM -0400, Greg Hudson wrote: > > In this mechanism the TGT goes from the acceptor to the initiator, > > which I think helps keep the code paths similar to what they are for the > > regular krb5 mech (although the acceptor cred for this mech would need to be > > more similar to a krb5 initiator cred than to a krb5 acceptor cred). > > That is the correct way to do it. (An inverted mechanism would also > work, but would require new AP messages so that authorization data can > flow from the initiator to the acceptor.) Although even such an inverted flow would still have the problem that the KDC could not communicate KDC-issued ADs to the acceptor without extending the TGS-REP as well. But on the other hand, anything we do to increase symmetry in the protocol would be good. Nico -- From nobody Mon Oct 29 15:25:19 2018 Return-Path: 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 C27A9131069 for ; Mon, 29 Oct 2018 15:25:17 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Non-encoded 8-bit data (char 9C hex): Received: ...s kaduk@ATHENA.MIT.EDU)\n\t\234by outgoing.mit[...] X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 trRa0MEXmSVo for ; Mon, 29 Oct 2018 15:25:16 -0700 (PDT) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (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 D6424127133 for ; Mon, 29 Oct 2018 15:25:14 -0700 (PDT) X-AuditID: 1209190f-be7ff70000005fb8-8e-5bd788c8db98 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id B5.B1.24504.9C887DB5; Mon, 29 Oct 2018 18:25:13 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-4.mit.edu (8.14.7/8.9.2) with ESMTP id w9TMP8V7019965; Mon, 29 Oct 2018 18:25:09 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) œby outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id w9TMP4D1006879 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 29 Oct 2018 18:25:06 -0400 Date: Mon, 29 Oct 2018 17:25:03 -0500 From: Benjamin Kaduk To: Nico Williams Cc: Greg Hudson , "kitten@ietf.org" Message-ID: <20181029222503.GN45914@kduck.kaduk.org> References: <5BD6BC1F.5000800@openfortress.nl> <3777aea8-4799-e58f-391d-42006b693d85@mit.edu> <20181029185219.GC2486@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20181029185219.GC2486@localhost> User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDIsWRmVeSWpSXmKPExsUixG6nrnuy43q0wdoZOhZHN69isTh17Qib A5PHy1PnGD2WLPnJFMAUxWWTkpqTWZZapG+XwJXxsvEIc8EtyYoD324yNzCeF+5i5OSQEDCR OHb5IVMXIxeHkMAaJoltZ2YzQjgbGSUmNd5hh3DuMkl8m76DHaSFRUBVYlLrTEYQm01ARaKh +zIziC0ioClxfd5SNhCbWcBN4kvDbBYQW1jATGLi2ztMIDYv0LqO7qUsEEObGSVOzZ/HDJEQ lDg58wkLRLOWxI1/L4EaOIBsaYnl/zhAwpwCehK35nwF2ysqoCyxt+8Q+wRGgVlIumch6Z6F 0L2AkXkVo2xKbpVubmJmTnFqsm5xcmJeXmqRrolebmaJXmpK6SZGUKBySvLvYJzT4H2IUYCD UYmHV0PnerQQa2JZcWXuIUZJDiYlUV5PB6AQX1J+SmVGYnFGfFFpTmrxIUYJDmYlEd73BkA5 3pTEyqrUonyYlDQHi5I474SWxdFCAumJJanZqakFqUUwWRkODiUJ3qftQI2CRanpqRVpmTkl CGkmDk6Q4TxAw2+A1PAWFyTmFmemQ+RPMSpKifOeAkkIgCQySvPgekGJRCJ7f80rRnGgV4R5 00CqeIBJCK77FdBgJqDBi4WugAwuSURISTUwKrvf+xT164Jh5/uL7fsbO2LOrgg5dbohkPfk l/krDF6m5Rx55uS/98qTuW3r7ivkrBG8/Og63xaJeV9Un1wsljyr0apUH9i5+vWqyc+EelZo fu8xcHIRZpn0aVn8oqrT8dcvcq03TOi7InX1UFqk2QmJt1/9zsjadTVXX597+eGGMiu7qbZc 2kosxRmJhlrMRcWJABSYHB7/AgAA Archived-At: Subject: Re: [kitten] User-to-user Kerberos in GSS-API X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2018 22:25:18 -0000 On Mon, Oct 29, 2018 at 01:52:21PM -0500, Nico Williams wrote: > On Mon, Oct 29, 2018 at 02:38:25PM -0400, Greg Hudson wrote: > > On 10/29/2018 03:51 AM, Rick van Rein wrote: > > >In GSS-API, it should be doable to insert a phase preceding standard > > >Kerberos5, where a TGT is pushed from the initiator to the acceptor, who > > >then contacts its KDC, and so on. We've seen a similar thing in SPNEGO. > > > > There is > > > > https://tools.ietf.org/html/draft-swift-win2k-krb-user2user-03 > > > > which I believe is implemented in Windows SSPI but not in MIT krb5 or > > Heimdal. > > We should implement this. > > > In this mechanism the TGT goes from the acceptor to the initiator, > > which I think helps keep the code paths similar to what they are for the > > regular krb5 mech (although the acceptor cred for this mech would need to be > > more similar to a krb5 initiator cred than to a krb5 acceptor cred). > > That is the correct way to do it. (An inverted mechanism would also > work, but would require new AP messages so that authorization data can > flow from the initiator to the acceptor.) > > We could also do this with the same mechanism OID as in RFC4121 as > follows (this is desirable because it simplifies negotiation): > > 1. TGS-driven user2user with RFC4121 mech OID: > > a) the initiator attempts a TGS exchange and gets > KDC_ERR_MUST_USE_USER2USER, > > b) the initiator prepares a 1-octet initial security context token > (plus the OID wrapper) and sends it, > > c) (a) implies that the acceptor knows how to handle this 1-octet > token and sends back its TGT, I'm not sure that I see this implication always occurring -- we don't have a great channel for an acceptor to inform the KDC about its functional capabilities (as a floor of functionality across all nodes that have a key for that principal). > d) the initiator does a TGS exchange with the acceptor's TGT as the > second ticket and then sends an AP-REQ, > > e) the acceptor responds with an AP-REP (if GSS_C_MUTUAL_FLAG is set > anyways). > > 2. Acceptor-driven user2user with RFC4121 mech OID: > > This is a variant of the multi-round-trip extension... > > a) the initiator does a TGS exchange, gets a service ticket, sends an > AP-REQ, but with an ap-option indicating it's willing to perform > additional round-trips, > > b) the acceptor can't decrypt the service ticket but has a TGT, so it > responds with its TGT as the reply token, > > c) the initiator does a TGS exchange with the acceptor's TGT as the > second ticket and then sends an AP-REQ, To be clear, this is just for the case when the service ticket is encrypted to a key that is "too new" for this instance to have, but the principal in the TGT is the same as the principal that the service ticket is for? If it can change then we have some exciting authorization checks to make... -Ben > d) the acceptor responds with an AP-REP (if GSS_C_MUTUAL_FLAG is set > anyways). > > Nico > -- > > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten From nobody Mon Oct 29 16:18:29 2018 Return-Path: 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 0CE95131028 for ; Mon, 29 Oct 2018 16:18:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 i4XPZteECJiR for ; Mon, 29 Oct 2018 16:18:26 -0700 (PDT) Received: from bongo.maple.relay.mailchannels.net (bongo.maple.relay.mailchannels.net [23.83.214.21]) (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 7F477131021 for ; Mon, 29 Oct 2018 16:18:26 -0700 (PDT) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 996B45C4790; Mon, 29 Oct 2018 23:18:25 +0000 (UTC) Received: from pdx1-sub0-mail-a67.g.dreamhost.com (unknown [100.96.19.74]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 5672F5C47E3; Mon, 29 Oct 2018 23:18:25 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a67.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.16.2); Mon, 29 Oct 2018 23:18:25 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Dime-Vacuous: 315d512b25580226_1540855105469_3218145016 X-MC-Loop-Signature: 1540855105469:3850984346 X-MC-Ingress-Time: 1540855105468 Received: from pdx1-sub0-mail-a67.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a67.g.dreamhost.com (Postfix) with ESMTP id 1E3C98090B; Mon, 29 Oct 2018 16:18:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=RUTG2ydGA/mjf2 s5K6B3Ga5lJiM=; b=K5UjvdMlw+DvIDctW4VFggXtzfBsjZRXiCduhheurdZkPC xf+fmhIG5GsCOoZxLurzQCkZov+p5Umqgio7gFcj4DKYNk1kAh+G9i3zOtG98jeP BoVNBQKi3xXL5FqOgscfgXnC1SU0jWMZl2Mt86cPVFamiOYfCQqWz8tDKB+tI= Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a67.g.dreamhost.com (Postfix) with ESMTPSA id CE7C480900; Mon, 29 Oct 2018 16:18:19 -0700 (PDT) Date: Mon, 29 Oct 2018 18:18:17 -0500 X-DH-BACKEND: pdx1-sub0-mail-a67 From: Nico Williams To: Benjamin Kaduk Cc: Greg Hudson , "kitten@ietf.org" Message-ID: <20181029231816.GE2486@localhost> References: <5BD6BC1F.5000800@openfortress.nl> <3777aea8-4799-e58f-391d-42006b693d85@mit.edu> <20181029185219.GC2486@localhost> <20181029222503.GN45914@kduck.kaduk.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20181029222503.GN45914@kduck.kaduk.org> User-Agent: Mutt/1.5.24 (2015-08-30) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedtkedrheelgddtjecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucggtfgfnhhsuhgsshgtrhhisggvpdfftffgtefojffquffvnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpeffhffvuffkfhggtggujggfsehttdertddtredvnecuhfhrohhmpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqnecukfhppedvgedrvdekrddutdekrddukeefnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehlohgtrghlhhhoshhtpdhinhgvthepvdegrddvkedruddtkedrudekfedprhgvthhurhhnqdhprghthheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqedpmhgrihhlfhhrohhmpehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmpdhnrhgtphhtthhopehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmnecuvehluhhsthgvrhfuihiivgeptd Archived-At: Subject: Re: [kitten] User-to-user Kerberos in GSS-API X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2018 23:18:28 -0000 On Mon, Oct 29, 2018 at 05:25:03PM -0500, Benjamin Kaduk wrote: > On Mon, Oct 29, 2018 at 01:52:21PM -0500, Nico Williams wrote: > > We could also do this with the same mechanism OID as in RFC4121 as > > follows (this is desirable because it simplifies negotiation): > > > > 1. TGS-driven user2user with RFC4121 mech OID: > > > > a) the initiator attempts a TGS exchange and gets > > KDC_ERR_MUST_USE_USER2USER, > > > > [...] > > I'm not sure that I see this implication always occurring -- we don't have > a great channel for an acceptor to inform the KDC about its functional > capabilities (as a floor of functionality across all nodes that have a > key for that principal). Sure we do, and KDC_ERR_MUST_USE_USER2USER exists, and it assumes that channel. It's the same channel we use to negotiate a shared secret key(set) between the two, and the service principal's supported enctype set. And the existing kadm5/kadmin/kadmind implementations I do believe support this (it's just an attribute). > > 2. Acceptor-driven user2user with RFC4121 mech OID: > > > > This is a variant of the multi-round-trip extension... > > > > a) the initiator does a TGS exchange, gets a service ticket, sends an > > AP-REQ, but with an ap-option indicating it's willing to perform > > additional round-trips, > > > > [...] > > To be clear, this is just for the case when the service ticket is encrypted > to a key that is "too new" for this instance to have, but the principal in > the TGT is the same as the principal that the service ticket is for? If it > can change then we have some exciting authorization checks to make... Yes, the initiator has to make sure that the service principal name does not change. And it'd better already be the case that the TGS exchange with the second ticket protects the second ticket from modification in flight, and that the KDC verifies the ticket's sname. (But that all better be true now, else u2u is broken.) Nico -- From nobody Tue Oct 30 02:45:57 2018 Return-Path: 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 5375312D4EB for ; Tue, 30 Oct 2018 02:45:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=openfortress.nl 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 zNC5zSqR6Bci for ; Tue, 30 Oct 2018 02:45:53 -0700 (PDT) Received: from lb2-smtp-cloud7.xs4all.net (lb2-smtp-cloud7.xs4all.net [194.109.24.28]) (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 56575128DFD for ; Tue, 30 Oct 2018 02:45:50 -0700 (PDT) Received: from popmini.vanrein.org ([83.161.146.46]) by smtp-cloud7.xs4all.net with ESMTP id HQaogjXWSw2L8HQapgi0k9; Tue, 30 Oct 2018 10:45:48 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=openfortress.nl; i=rick@openfortress.nl; q=dns/txt; s=fame; t=1540892740; h=message-id : date : from : mime-version : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding : date : from : subject; bh=Q8FQEa8ZIu6sIeYjvH6aGdd1NbYC4rz46sIfQ6dGwec=; b=cja1ODXzl2N3K13rax7g88O92AKdyVaK+ln7cOc07xJnh/Dm1TFqeatW 0TNd2w/Gy7hkxb0mQK4M+VWQ++wWdjvzRwQP69tISjK2b9NRIxzJv/7tJt vt2xa6gyn2ZByZpoqV8ZBuLlocKV8nUcO2obWku0qhlxE3aeWLoJECWeg= Received: by fame.vanrein.org (Postfix, from userid 1006) id 8343B21852; Tue, 30 Oct 2018 09:45:40 +0000 (UTC) X-Original-To: kitten@ietf.org Received: from airhead.local (phantom.vanrein.org [83.161.146.46]) by fame.vanrein.org (Postfix) with ESMTPA id CF8EA2184E; Tue, 30 Oct 2018 09:45:33 +0000 (UTC) Message-ID: <5BD8283C.4060402@openfortress.nl> Date: Tue, 30 Oct 2018 10:45:32 +0100 From: Rick van Rein User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: Nico Williams CC: Benjamin Kaduk , "kitten@ietf.org" References: <5BD6BC1F.5000800@openfortress.nl> <20181029172611.GL45914@kduck.kaduk.org> <20181029183137.GB2486@localhost> In-Reply-To: <20181029183137.GB2486@localhost> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Bogosity: Unsure, tests=bogofilter, spamicity=0.520000, version=1.2.4 X-CMAE-Envelope: MS4wfKPsW4HbX7Tzd2j8VIiJUOtm7VTlJNIJrbBqp9XmYGsDwX8PlhScGN2SNIgmGM8DqrB4M06hv54qQPPk800z8esXvwcCHGWdazUrPp6L7TBuk1YSpqt1 sGOzN0oEqPgYMZI0oLXhxAtNgEz/l0kpsIHxPGjQgFiSg8H7rvFf+olE Archived-At: Subject: Re: [kitten] User-to-user Kerberos in GSS-API X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2018 09:45:56 -0000 Hey Nico, > The use for this has to do with keying clusters atomically, which is > difficult to pull off. If you have user-to-user, you can always just > make sure that each member of a cluster can get a TGT for the service > principal name and not bother making sure they all have the latest keys > for the service principal name. I had to read this five times :) but if I understand it, it is a clever use. I was thinking p2p protocols, but you are saying that you don't want to use the long-term service keytab but rather derive a TGT on a daily basis, right? Intereting to use u2u for that indeed! and sound like it'd work. I've been thinking about such problems too, but resorted to doing the GSS exchange in a protected environment and then handing out the security context to a lesser process that could handle the symmetric stuff. In fact, that's what we're considering doing with TLS also; hand off the long-term credentials-based negotiation to a separate TLS Pool, and get back the symmetric stuff for local, in-line handling. (Whoops, I'm taking off now, sorry.) It does sound like TLS-KDH can do what you want. Progress on that has been stifling, mostly because 1.3 grabbed the attention of GnuTLS developers, but I'm told that it will soon get in there -- and then we'll move on with that spec too. It has a Kerberos-only mode and is Post Quantum, by the way. In short, the server either sends no key or a TGT, and the client either sends a service ticket or initiates u2u exchanges. I thought it was the first such application. > Using PA-TGS for AS exchanges would > even make it possible for a host to get TGTs for containers/guests > without having to ever even have keys for the container services -- this > would be an amazing simplification to key management. Yes, our work with TLS Pool confirms that. It also simplifies code, but then again, TLS is always more dramatic than Kerberos. If you want to read more (all in-progress): https://tools.ietf.org/html/draft-vanrein-tls-kdh-04 https://github.com/arpa2/tlspool https://github.com/arpa2/docker-demo/tree/master/build-tlspool [the latter is not yet built with a TLS-KDH supportive GnuTLS] > Multi-round-trip extensions can also make cluster key management easier, > naturally. I have no idea what you mean with this. But I am curious! -Rick From nobody Tue Oct 30 03:47:17 2018 Return-Path: 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 AF1F4130DC2 for ; Tue, 30 Oct 2018 03:47:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=openfortress.nl 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 ovLrxXMuBdMH for ; Tue, 30 Oct 2018 03:47:11 -0700 (PDT) Received: from lb2-smtp-cloud7.xs4all.net (lb2-smtp-cloud7.xs4all.net [194.109.24.28]) (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 3568B12F295 for ; Tue, 30 Oct 2018 03:47:10 -0700 (PDT) Received: from popmini.vanrein.org ([83.161.146.46]) by smtp-cloud7.xs4all.net with ESMTP id HRYAgkTcFw2L8HRYBgig8M; Tue, 30 Oct 2018 11:47:07 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=openfortress.nl; i=rick@openfortress.nl; q=dns/txt; s=fame; t=1540896420; h=message-id : date : from : mime-version : to : subject : references : in-reply-to : content-type : content-transfer-encoding : date : from : subject; bh=NT6NvvYLME7F9bx3Q2+2kcrJHy1WdSue28T11Bnz1sQ=; b=GGPFMVAw83HFavAcnqeavvnWAIrbO6cMFAgmbEjtNOZzHgXzU4LssQny p2tafzF+1BRZrNOK2x3GFIoIdGZjC2A6nxmLZzDPpOVRwY+A75Rkc3prgZ mBo5Ux9bt5a0TwpvckrTreA5Iuz8OIPJiKXZGIpheIBaTJBz3smiF7qMw= Received: by fame.vanrein.org (Postfix, from userid 1006) id AD5AD21882; Tue, 30 Oct 2018 10:47:00 +0000 (UTC) X-Original-To: kitten@ietf.org Received: from airhead.local (phantom.vanrein.org [83.161.146.46]) by fame.vanrein.org (Postfix) with ESMTPA id 8871C21880; Tue, 30 Oct 2018 10:46:59 +0000 (UTC) Message-ID: <5BD836A1.5060200@openfortress.nl> Date: Tue, 30 Oct 2018 11:46:57 +0100 From: Rick van Rein User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: "kitten@ietf.org" References: <5BD6BC1F.5000800@openfortress.nl> <3777aea8-4799-e58f-391d-42006b693d85@mit.edu> In-Reply-To: <3777aea8-4799-e58f-391d-42006b693d85@mit.edu> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Bogosity: Unsure, tests=bogofilter, spamicity=0.520000, version=1.2.4 X-CMAE-Envelope: MS4wfHtchW4HicS7D9yaujoqUgo7etVh8dneh4wBGQrlGbKZ4EtqJ226cVr8uFG/ddawpdbZiaZGpad6jh7XWN6nf+HJE/ID+cuAQhIpSHO9mkz8domSPV8k E81fmTZ4MZF9TwGqlEaCR1dR6FOO2GfpzS/U0wtcqi00V/XozE24uv/W Archived-At: Subject: Re: [kitten] User-to-user Kerberos in GSS-API X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2018 10:47:14 -0000 Hey, > https://tools.ietf.org/html/draft-swift-win2k-krb-user2user-03 I think this one might raise problems: 1. The service may declare its realm; in other Kerberos protocols that is considered to be a no-go area. 2. For services it makes sense to prod them for their TGT; for users this could be a privacy leak, as they are given no grounds for acceptance vs. denial decisions. I was thinking about a symmetric approach, where peers start as acceptors, but switch to initiator when they need to send, and ship their TGT for it. In case of cross-fire, the TGT with the highest bytes (MSB at the entropic end) wins and the other cuts heel, becomes an acceptor and deferring sending until connected. When a context expires, it switches to a new initiator on sending, or a new acceptor on receiving. This wraps around (or prefixes) the usual Kerberos flow. Perhaps it's worth speccing this one out as an alternative? I am thinking primarily of users. I would like to experiment with a STARTGSS operation that behaves somewhat like STARTTLS, but could also connect users directly (finally a good mechanism to exchange passwords, yay!) It could be added to my TLS Pool, invalidating its name but not its logic, and make it a one-hour patch to existing code. -Rick From nobody Tue Oct 30 08:02:48 2018 Return-Path: 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 B8C491293FB for ; Tue, 30 Oct 2018 08:02:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 Gl_7tcoXJDOd for ; Tue, 30 Oct 2018 08:02:43 -0700 (PDT) Received: from giraffe.birch.relay.mailchannels.net (giraffe.birch.relay.mailchannels.net [23.83.209.69]) (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 65383128CFD for ; Tue, 30 Oct 2018 08:02:43 -0700 (PDT) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 0E50D12481B; Tue, 30 Oct 2018 15:02:42 +0000 (UTC) Received: from pdx1-sub0-mail-a30.g.dreamhost.com (unknown [100.96.36.160]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id B9DCC12365E; Tue, 30 Oct 2018 15:02:41 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a30.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.16.2); Tue, 30 Oct 2018 15:02:42 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Juvenile-Soft: 6a1a1dae5ef0451b_1540911761879_3940424494 X-MC-Loop-Signature: 1540911761879:2603446456 X-MC-Ingress-Time: 1540911761878 Received: from pdx1-sub0-mail-a30.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a30.g.dreamhost.com (Postfix) with ESMTP id 82F737F8D4; Tue, 30 Oct 2018 08:02:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=ILWYnwWaU999XK gbBKPKe99aYHs=; b=oV5kbyPaMMWMoAjluuknohoEsS6kklnOH9hf+lhLC2YMaq sbS+54pGYIShxjlGiL4sK37mx3bCR1Vzlfef1bGlrIIu1CJcpFaOGHKLnfglADR+ qIT6CctueS0hIergrCvJuCIQ9QKIX16cO5V0/9TCrlwqC5ReRdVVpSJyQP/2I= Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a30.g.dreamhost.com (Postfix) with ESMTPSA id 844A27F8DC; Tue, 30 Oct 2018 08:02:34 -0700 (PDT) Date: Tue, 30 Oct 2018 10:02:32 -0500 X-DH-BACKEND: pdx1-sub0-mail-a30 From: Nico Williams To: Rick van Rein Cc: Benjamin Kaduk , "kitten@ietf.org" Message-ID: <20181030150230.GF2486@localhost> References: <5BD6BC1F.5000800@openfortress.nl> <20181029172611.GL45914@kduck.kaduk.org> <20181029183137.GB2486@localhost> <5BD8283C.4060402@openfortress.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5BD8283C.4060402@openfortress.nl> User-Agent: Mutt/1.5.24 (2015-08-30) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedtkedriedtgdeilecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucggtfgfnhhsuhgsshgtrhhisggvpdfftffgtefojffquffvnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpeffhffvuffkfhggtggujggfsehttdertddtredvnecuhfhrohhmpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqnecuffhomhgrihhnpehgihhthhhusgdrtghomhdpihgvthhfrdhorhhgnecukfhppedvgedrvdekrddutdekrddukeefnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehlohgtrghlhhhoshhtpdhinhgvthepvdegrddvkedruddtkedrudekfedprhgvthhurhhnqdhprghthheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqedpmhgrihhlfhhrohhmpehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmpdhnrhgtphhtthhopehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmnecuvehluhhsthgvrhfuihiivgeptd Archived-At: Subject: Re: [kitten] User-to-user Kerberos in GSS-API X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2018 15:02:47 -0000 On Tue, Oct 30, 2018 at 10:45:32AM +0100, Rick van Rein wrote: > > The use for this has to do with keying clusters atomically, which is > > difficult to pull off. If you have user-to-user, you can always just > > make sure that each member of a cluster can get a TGT for the service > > principal name and not bother making sure they all have the latest keys > > for the service principal name. > > I had to read this five times :) but if I understand it, it is a > clever use. I was thinking p2p protocols, but you are saying that you > don't want to use the long-term service keytab but rather derive a TGT > on a daily basis, right? Intereting to use u2u for that indeed! and > sound like it'd work. Correct. User-to-user was originally meant for X11, both for users to be able to connect to their own X11 displays, and for display sharing (I imagine anyways) without having to have long-term service keys, but that just hasn't worked out. Perhaps new p2p cases can be deployed, but given that most of the relevant services involve some degree of centralization (in the enterprise at least), I doubt it. > I've been thinking about such problems too, but resorted to doing the > GSS exchange in a protected environment and then handing out the > security context to a lesser process that could handle the symmetric > stuff. [...] The problem with that is increased latency on the server side. > [...]. In fact, that's what we're considering doing with TLS also; > hand off the long-term credentials-based negotiation to a separate TLS > Pool, and get back the symmetric stuff for local, in-line handling. > (Whoops, I'm taking off now, sorry.) No, I do think that's interesting from a privilege separation point of view. > It does sound like TLS-KDH can do what you want. Progress on that has > been stifling, mostly because 1.3 grabbed the attention of GnuTLS > developers, but I'm told that it will soon get in there -- and then > we'll move on with that spec too. It has a Kerberos-only mode and is > Post Quantum, by the way. In short, the server either sends no key or > a TGT, and the client either sends a service ticket or initiates u2u > exchanges. I thought it was the first such application. TLS 1.3 can do what I want, yes. A few things worth thinking about re: TLS 1.3: - Kerberos tickets can function as session resumption tickets It would be good to have a general purpose ticket cache library for clients and ticket decryptor / authenticator validation library for services. - TLS 1.3 could be the foundation of new Kerberos KDC protocols: - TLS 1.3 w/ PSK -> replaces PA-ENC-TIMESTAMP - TLS 1.3 w/ client certs -> replaces PKINIT - TLS 1.3 w/ Kerberos tickets as resumption tickets -> replace PA-TGS - TLS 1.3 w/ some PAKE -> replaces the new Kerberos PAKE PA - TLS 1.3 can secure KDC exchanges and completely simplify everything to do with reply keys and what not - we'd still have AP exchanges, but we could also have... - ...a TLS 1.3 based GSS-API mechanism (like the GSI SSL mech) - ... On the down side, we'd then lose FAST unless we did TLS-over-TLS (not quite renegotiation, mind you), which I'm sure is bound to upset some. > https://tools.ietf.org/html/draft-vanrein-tls-kdh-04 > https://github.com/arpa2/tlspool > https://github.com/arpa2/docker-demo/tree/master/build-tlspool > [the latter is not yet built with a TLS-KDH supportive GnuTLS] I'll take a look. > > Multi-round-trip extensions can also make cluster key management easier, > > naturally. > > I have no idea what you mean with this. But I am curious! RFCs 1964 and 4121 specify the GSS-API Kerberos mechanism, and that is a half- or one-round trip mechanism. The initiator sends an AP-REQ plus a little header, the acceptor responds with an AP-REP plus a little header. But if anything goes wrong, then the acceptor sends back a KRB-ERROR and the whole thing fails. We could (should!) extend the mechanism so that the initiator can indicate that it can do extra round trips, and then we can have the following scenario: I->A: AP-REQ A->I: KRB-ERROR (KRB_AP_ERR_BADKEYVER) I<->TGS: get new service ticket I->A: AP-REQ A->I: AP-REP (this could happen if you rebuild the service with new keys and lose the old keys) or I->A: AP-REQ A->I: Ticket I<->TGS: user-to-user I->A: AP-REQ A->I: AP-REP all while using the same GSS-API mechanism OID. Nico -- From nobody Tue Oct 30 08:20:06 2018 Return-Path: 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 C5987130E05 for ; Tue, 30 Oct 2018 08:19:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 sBaz47L6Ljay for ; Tue, 30 Oct 2018 08:19:52 -0700 (PDT) Received: from giant.birch.relay.mailchannels.net (giant.birch.relay.mailchannels.net [23.83.209.68]) (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 9FBD1130E06 for ; Tue, 30 Oct 2018 08:19:52 -0700 (PDT) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id D303B680165; Tue, 30 Oct 2018 15:19:51 +0000 (UTC) Received: from pdx1-sub0-mail-a30.g.dreamhost.com (unknown [100.96.19.78]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 86F266810B3; Tue, 30 Oct 2018 15:19:51 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a30.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.16.2); Tue, 30 Oct 2018 15:19:51 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Chief-Cooing: 7bab72a93128f9d5_1540912791720_3469312206 X-MC-Loop-Signature: 1540912791720:2778563509 X-MC-Ingress-Time: 1540912791720 Received: from pdx1-sub0-mail-a30.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a30.g.dreamhost.com (Postfix) with ESMTP id 454727F8E3; Tue, 30 Oct 2018 08:19:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=IBDrFBV53Wj5h7 1UFH2EfFDI4jw=; b=nEshsW5WjZuVpnYFdDm0j31v3Q2f2ffJQdkEFByxc+7AiM 3rBs4lI8jMwdGcHK5mc+0GK90bWB130pMngARWIibTVjERMrNqC4xLFWEXUusJOB zbyjTo4H6HlQ+0Z+hNh3SbsUUqTFiFBvHS5LxPeA8UjIEdFguvtlUfIwvwxtI= Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a30.g.dreamhost.com (Postfix) with ESMTPSA id 317607F8D7; Tue, 30 Oct 2018 08:19:47 -0700 (PDT) Date: Tue, 30 Oct 2018 10:19:45 -0500 X-DH-BACKEND: pdx1-sub0-mail-a30 From: Nico Williams To: Rick van Rein Cc: "kitten@ietf.org" Message-ID: <20181030151944.GG2486@localhost> References: <5BD6BC1F.5000800@openfortress.nl> <3777aea8-4799-e58f-391d-42006b693d85@mit.edu> <5BD836A1.5060200@openfortress.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5BD836A1.5060200@openfortress.nl> User-Agent: Mutt/1.5.24 (2015-08-30) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedtkedriedtgdejfecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucggtfgfnhhsuhgsshgtrhhisggvpdfftffgtefojffquffvnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpeffhffvuffkfhggtggujggfsehttdertddtredvnecuhfhrohhmpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqnecuffhomhgrihhnpehivghtfhdrohhrghenucfkphepvdegrddvkedruddtkedrudekfeenucfrrghrrghmpehmohguvgepshhmthhppdhhvghloheplhhotggrlhhhohhsthdpihhnvghtpedvgedrvdekrddutdekrddukeefpdhrvghtuhhrnhdqphgrthhhpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqpdhmrghilhhfrhhomhepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhdpnhhrtghpthhtohepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhenucevlhhushhtvghrufhiiigvpedt Archived-At: Subject: Re: [kitten] User-to-user Kerberos in GSS-API X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2018 15:20:04 -0000 On Tue, Oct 30, 2018 at 11:46:57AM +0100, Rick van Rein wrote: > Hey, > > > https://tools.ietf.org/html/draft-swift-win2k-krb-user2user-03 > > I think this one might raise problems: > > 1. The service may declare its realm; in other Kerberos > protocols that is considered to be a no-go area. I don't follow. > 2. For services it makes sense to prod them for their TGT; > for users this could be a privacy leak, as they are given no > grounds for acceptance vs. denial decisions. Yes. > I was thinking about a symmetric approach, where peers start as > acceptors, but switch to initiator when they need to send, and ship > their TGT for it. In case of cross-fire, the TGT with the highest bytes > (MSB at the entropic end) wins and the other cuts heel, becomes an > acceptor and deferring sending until connected. When a context expires, > it switches to a new initiator on sending, or a new acceptor on > receiving. This wraps around (or prefixes) the usual Kerberos flow. > > Perhaps it's worth speccing this one out as an alternative? Elsewhere in this thread I explained the problem with reversing the flows: the protocols are insufficiently symmetric as to authorization data. And, of course, the fix is to make them more symmetric. So, yes, this should work: I->A: TGT A<->TGS: 2nd ticket request to get a ticket for talking to the initiator A->I: AP-REQ I->A: AP-REP > I am thinking primarily of users. I would like to experiment with a > STARTGSS operation that behaves somewhat like STARTTLS, but could also > connect users directly (finally a good mechanism to exchange passwords, > yay!) It could be added to my TLS Pool, invalidating its name but not > its logic, and make it a one-hour patch to existing code. StartTLS is a feature of protocols like SMTP, SUBMIT, IMAP, and so on -- generally SASL apps. (HTTP has a StartTLS that is not implemented and nobody uses.) Where would you use StartGSS? Anyways, we (SASL WG, now KITTEN WG) long ago decided that the right approch for SASL apps is to a) use TLS, b) use SASL with channel binding to TLS, c) do not use GSS for the "SL" part of SASL. See RFC5801. SASL effectively became SA. Nico -- From nobody Tue Oct 30 18:13:49 2018 Return-Path: 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 3C3CE1292F1 for ; Tue, 30 Oct 2018 18:13:44 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Non-encoded 8-bit data (char 9C hex): Received: ...s kaduk@ATHENA.MIT.EDU)\n\t\234by outgoing.mit[...] X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 T6yNf6xaerKx for ; Tue, 30 Oct 2018 18:13:42 -0700 (PDT) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (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 C061D1277CC for ; Tue, 30 Oct 2018 18:13:41 -0700 (PDT) X-AuditID: 12074424-399ff700000060f3-c3-5bd901c3c432 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 34.23.24819.3C109DB5; Tue, 30 Oct 2018 21:13:40 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-1.mit.edu (8.14.7/8.9.2) with ESMTP id w9V1Dbd7007907; Tue, 30 Oct 2018 21:13:38 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) œby outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id w9V1DVZG015388 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 30 Oct 2018 21:13:34 -0400 Date: Tue, 30 Oct 2018 20:13:31 -0500 From: Benjamin Kaduk To: Nico Williams Cc: Rick van Rein , "kitten@ietf.org" Message-ID: <20181031011331.GA45914@kduck.kaduk.org> References: <5BD6BC1F.5000800@openfortress.nl> <20181029172611.GL45914@kduck.kaduk.org> <20181029183137.GB2486@localhost> <5BD8283C.4060402@openfortress.nl> <20181030150230.GF2486@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20181030150230.GF2486@localhost> User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpkleLIzCtJLcpLzFFi42IR4hRV1j3CeDPa4FEXm8XRzatYLE5dO8Jm 8fTVPTYHZo+Xp84xeixZ8pPJY8O/JrYA5igum5TUnMyy1CJ9uwSujD2T/rEU/FWraLm3mbWB cbJcFyMnh4SAicSOrt+sXYxcHEICa5gkpvT3s4IkhAQ2MkpM63aGSNxlkjjZv48NJMEioCpx Z+cnJhCbTUBFoqH7MjOILSKgKXF93lKwGmYBX4lNy5+DDRIWMJOY+PYOWD0v0LaeZ/fYIYYe Y5SYcng9G0RCUOLkzCcsEM1aEjf+vQRq4ACypSWW/+MACXMK6Em0Ht7HCGKLCihL7O07xD6B UWAWku5ZSLpnIXQvYGRexSibklulm5uYmVOcmqxbnJyYl5dapGuul5tZopeaUrqJERS67C4q Oxi7e7wPMQpwMCrx8D5IvhEtxJpYVlyZe4hRkoNJSZT3/Mfr0UJ8SfkplRmJxRnxRaU5qcWH GCU4mJVEeKdWAJXzpiRWVqUW5cOkpDlYlMR5J7YsjhYSSE8sSc1OTS1ILYLJynBwKEnw9jHc jBYSLEpNT61Iy8wpQUgzcXCCDOcBGl4IUsNbXJCYW5yZDpE/xajLse1M5wxmIZa8/LxUKXHe AyBFAiBFGaV5cHNAKUcie3/NK0ZxoLeEefNAqniA6Qpu0iugJUxAS7jYQT4oLklESEk1MMbs FF554ICwFnvdCt7o109E1xrkLdZbsnZjx/d3bjYPpuxQnNyQ1mt/J+9It43cJrbsO2ncFlNY vI7opnUzO936zfin4O2rLqkP+vPXCx04XXXw29nkSzPVt4tvKdYyv3iG0Wqy8LI7FbP2B32u f7s//YDi3KqKxdq3T7W8FZj2LSfr4N1l5muUWIozEg21mIuKEwF5TBDvFAMAAA== Archived-At: Subject: Re: [kitten] User-to-user Kerberos in GSS-API X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2018 01:13:44 -0000 On Tue, Oct 30, 2018 at 10:02:32AM -0500, Nico Williams wrote: > On Tue, Oct 30, 2018 at 10:45:32AM +0100, Rick van Rein wrote: > > > The use for this has to do with keying clusters atomically, which is > > > difficult to pull off. If you have user-to-user, you can always just > > > make sure that each member of a cluster can get a TGT for the service > > > principal name and not bother making sure they all have the latest keys > > > for the service principal name. > > > > I had to read this five times :) but if I understand it, it is a > > clever use. I was thinking p2p protocols, but you are saying that you > > don't want to use the long-term service keytab but rather derive a TGT > > on a daily basis, right? Intereting to use u2u for that indeed! and > > sound like it'd work. > > Correct. > > User-to-user was originally meant for X11, both for users to be able to > connect to their own X11 displays, and for display sharing (I imagine > anyways) without having to have long-term service keys, but that just > hasn't worked out. Perhaps new p2p cases can be deployed, but given > that most of the relevant services involve some degree of > centralization (in the enterprise at least), I doubt it. > > > I've been thinking about such problems too, but resorted to doing the > > GSS exchange in a protected environment and then handing out the > > security context to a lesser process that could handle the symmetric > > stuff. [...] > > The problem with that is increased latency on the server side. > > > [...]. In fact, that's what we're considering doing with TLS also; > > hand off the long-term credentials-based negotiation to a separate TLS > > Pool, and get back the symmetric stuff for local, in-line handling. > > (Whoops, I'm taking off now, sorry.) > > No, I do think that's interesting from a privilege separation point of > view. > > > It does sound like TLS-KDH can do what you want. Progress on that has > > been stifling, mostly because 1.3 grabbed the attention of GnuTLS > > developers, but I'm told that it will soon get in there -- and then > > we'll move on with that spec too. It has a Kerberos-only mode and is > > Post Quantum, by the way. In short, the server either sends no key or > > a TGT, and the client either sends a service ticket or initiates u2u > > exchanges. I thought it was the first such application. > > TLS 1.3 can do what I want, yes. > > A few things worth thinking about re: TLS 1.3: > > - Kerberos tickets can function as session resumption tickets > > It would be good to have a general purpose ticket cache library for > clients and ticket decryptor / authenticator validation library for > services. > > - TLS 1.3 could be the foundation of new Kerberos KDC protocols: > > - TLS 1.3 w/ PSK -> replaces PA-ENC-TIMESTAMP > - TLS 1.3 w/ client certs -> replaces PKINIT > - TLS 1.3 w/ Kerberos tickets as resumption tickets -> replace PA-TGS > - TLS 1.3 w/ some PAKE -> replaces the new Kerberos PAKE PA Have you seen draft-barnes-tls-pake? > - TLS 1.3 can secure KDC exchanges and completely simplify > everything to do with reply keys and what not > - we'd still have AP exchanges, but we could also have... > - ...a TLS 1.3 based GSS-API mechanism (like the GSI SSL mech) > - ... > > On the down side, we'd then lose FAST unless we did TLS-over-TLS (not > quite renegotiation, mind you), which I'm sure is bound to upset > some. See https://www.ietf.org/mail-archive/web/atlas/current/maillist.html . (Spoiler: yes, it has.) -Ben > > https://tools.ietf.org/html/draft-vanrein-tls-kdh-04 > > https://github.com/arpa2/tlspool > > https://github.com/arpa2/docker-demo/tree/master/build-tlspool > > [the latter is not yet built with a TLS-KDH supportive GnuTLS] > > I'll take a look. > > > > Multi-round-trip extensions can also make cluster key management easier, > > > naturally. > > > > I have no idea what you mean with this. But I am curious! > > RFCs 1964 and 4121 specify the GSS-API Kerberos mechanism, and that is a > half- or one-round trip mechanism. The initiator sends an AP-REQ plus a > little header, the acceptor responds with an AP-REP plus a little > header. But if anything goes wrong, then the acceptor sends back a > KRB-ERROR and the whole thing fails. We could (should!) extend the > mechanism so that the initiator can indicate that it can do extra round > trips, and then we can have the following scenario: > > I->A: AP-REQ > A->I: KRB-ERROR (KRB_AP_ERR_BADKEYVER) > I<->TGS: get new service ticket > I->A: AP-REQ > A->I: AP-REP > > (this could happen if you rebuild the service with new keys and lose the > old keys) > > or > > I->A: AP-REQ > A->I: Ticket > I<->TGS: user-to-user > I->A: AP-REQ > A->I: AP-REP > > all while using the same GSS-API mechanism OID. > > Nico > -- From nobody Tue Oct 30 21:10:13 2018 Return-Path: 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 6EF8A1252B7 for ; Tue, 30 Oct 2018 21:10:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 VxJx7enknG56 for ; Tue, 30 Oct 2018 21:10:09 -0700 (PDT) Received: from bonobo.maple.relay.mailchannels.net (bonobo.maple.relay.mailchannels.net [23.83.214.22]) (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 4B29E123FFD for ; Tue, 30 Oct 2018 21:10:09 -0700 (PDT) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id E8D2C5C3C14; Wed, 31 Oct 2018 04:10:07 +0000 (UTC) Received: from pdx1-sub0-mail-a65.g.dreamhost.com (unknown [100.96.33.121]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id A4BEB5C3B2F; Wed, 31 Oct 2018 04:10:07 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a65.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.16.2); Wed, 31 Oct 2018 04:10:07 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Average-Language: 186f1aea6c7944e5_1540959007790_2478247310 X-MC-Loop-Signature: 1540959007789:3040116475 X-MC-Ingress-Time: 1540959007789 Received: from pdx1-sub0-mail-a65.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a65.g.dreamhost.com (Postfix) with ESMTP id 7AE4E805A5; Tue, 30 Oct 2018 21:10:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=2jHAtPE1nU1rfb okKomGAvS3A7w=; b=ESa5yeJNpiHpTSGZcsecCoKySwlyCKZdldzYi9A/tBdr7K RcCk1lH9+26zcV6V1bwt+2QLWPNwhD0eVPXdy74B/iAO7qFmgxRFVVIrVGxU5Dbh hnDYkYTc+LRh8a+Owm6XoxHguAtjddMboHoa3esArwjPmeFGLK2VOpDVFYizU= Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a65.g.dreamhost.com (Postfix) with ESMTPSA id 89635805BB; Tue, 30 Oct 2018 21:10:02 -0700 (PDT) Date: Tue, 30 Oct 2018 23:10:00 -0500 X-DH-BACKEND: pdx1-sub0-mail-a65 From: Nico Williams To: Benjamin Kaduk Cc: Rick van Rein , "kitten@ietf.org" Message-ID: <20181031040959.GI2486@localhost> References: <5BD6BC1F.5000800@openfortress.nl> <20181029172611.GL45914@kduck.kaduk.org> <20181029183137.GB2486@localhost> <5BD8283C.4060402@openfortress.nl> <20181030150230.GF2486@localhost> <20181031011331.GA45914@kduck.kaduk.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20181031011331.GA45914@kduck.kaduk.org> User-Agent: Mutt/1.5.24 (2015-08-30) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedtkedriedugdeikecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucggtfgfnhhsuhgsshgtrhhisggvpdfftffgtefojffquffvnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpeffhffvuffkfhggtggujggfsehttdertddtredvnecuhfhrohhmpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqnecuffhomhgrihhnpehivghtfhdrohhrghenucfkphepvdegrddvkedruddtkedrudekfeenucfrrghrrghmpehmohguvgepshhmthhppdhhvghloheplhhotggrlhhhohhsthdpihhnvghtpedvgedrvdekrddutdekrddukeefpdhrvghtuhhrnhdqphgrthhhpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqpdhmrghilhhfrhhomhepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhdpnhhrtghpthhtohepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhenucevlhhushhtvghrufhiiigvpedt Archived-At: Subject: Re: [kitten] User-to-user Kerberos in GSS-API X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2018 04:10:12 -0000 On Tue, Oct 30, 2018 at 08:13:31PM -0500, Benjamin Kaduk wrote: > On Tue, Oct 30, 2018 at 10:02:32AM -0500, Nico Williams wrote: > > - TLS 1.3 w/ some PAKE -> replaces the new Kerberos PAKE PA > > Have you seen draft-barnes-tls-pake? Indeed, I have. > > On the down side, we'd then lose FAST unless we did TLS-over-TLS (not > > quite renegotiation, mind you), which I'm sure is bound to upset > > some. > > See https://www.ietf.org/mail-archive/web/atlas/current/maillist.html . > (Spoiler: yes, it has.) Oh, I bet! There's at least two other ways to get FAST-like privacy semantics. One would be to copy ACME, which will be doing HTTP-in-HTTP (sort of, IIUC), where encrypted requests as POSTed in the outer HTTP. We could do something similar using a the GSI mechanism, where we'd POST GSS tokens (context and wrap tokens) on an outer HTTPS and the unwrapped contents are the inner requests and responses. If it works for ACME, it would work for this. It's not like we're averse to nesting things, considering that FAST *is* just that. Another possibility would be to pursue encrypted cert payload, much like encrypted SNI. If we can get encrypted SNI, we can encrypt other privacy-sensitive parts fo the handshake. My preference would be the latter, mostly because it simplifies the application. I'm pretty sure we can get it too. We are going to need a GSS-API mechanism that can use PK credentials for a variety of reasons, even if we also do an RFC2712 follow-on. Yes, there's PKU2U, but I'm not too keen on it: for complexity management reasons I'd rather use the GSI approach than PKU2U. Yes, I know the GSI approach has some interesting issues, but I think we can iron them all out (e.g., TLS has no out of order messaging, but that's what DTLS is for, and neither has anything like MIC tokens, but we can construct them anyways, and neither has a channel binding input, but we can extend TLS for that too). Nico -- From nobody Tue Oct 30 21:50:25 2018 Return-Path: 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 95317127148 for ; Tue, 30 Oct 2018 21:50:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 i5i9yKC-AtnE for ; Tue, 30 Oct 2018 21:50:20 -0700 (PDT) Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com [IPv6:2607:f8b0:4864:20::d32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3AA0126DBF for ; Tue, 30 Oct 2018 21:50:19 -0700 (PDT) Received: by mail-io1-xd32.google.com with SMTP id p83-v6so8768029iod.12 for ; Tue, 30 Oct 2018 21:50:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :content-transfer-encoding:mime-version; bh=3cpjUehSyQ6usgC8/h1PdI/Zzp5v2E1rW97sbpe8uoE=; b=exYKmHMDTFsj3XofyzhFNmHI5+ZbHfWWbYL/z+MHAyWt5cZZBST+fDd58PJl2BdlBJ /wfmw06FPME070jzPFYzX7om+qhR/xhhfrSIIAGtPhm6A+Cz0q2sshm5Akx8/Ey0kLTB xjYx5VsWRlaia5VgagI8IVl8CRUUBRc3w15zfiyOeBG8ZdepyuoAFWCP3u/cZh3JKTY5 XkodFSxBl4u6yIS09+W6KTUAgUduMHBbFOsxrYswUTTqTOSrvYsVFeVkH+JINZDc2bI5 2Qhh40wieWidFSdPvKcXXyHswrO2WEDdbbd7/w2+TxbcKHuXlfUzFeTsVAISLUw447P/ h4Rw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:content-transfer-encoding:mime-version; bh=3cpjUehSyQ6usgC8/h1PdI/Zzp5v2E1rW97sbpe8uoE=; b=FAn3GFCGuSVxpqQg+YWcSHNhf2wMtRDjQ+oOk2C0xXqPikEY+D9/8CnoKSPKKCI5oE IGsyRy3OhWuHyhWMUNosArd64KhuomNVUjJAx8JA3Ie8OgNwwXCO+0vGJ/z/wdO/xuw0 8dGkGmelaalYt7qZYnwqXkFSXvKNVYENV+dKirkihYwwaQEZe8cC9jTMPpBQcbzd156O ZpnuOtEaC3NFETcx89qRSMfZsTTrIT2t3/D13zXvtlnikiiuKH+AKjDz63WHnEjOTZqw 7J/XH3NLj/nrwUOcHX4B1DiNJO3Mv4331bK20ngRDO6mIi6cicGi+eQ3GReMGb+8YzAo VwGw== X-Gm-Message-State: AGRZ1gI92qTApAHN0ys+ECikbJMyJLP9PWSgsyYggNwGpbu8dCZnZ4nU MXw+05G+xxjGF3GVi//GdovpDsXE X-Google-Smtp-Source: AJdET5elOOpgEuNwj8r9BmyDdP23ZCnHEOunbirVIwaajG02pzbWjoS908RCY8wLq7W0JjOsXnSB+A== X-Received: by 2002:a6b:8d44:: with SMTP id p65-v6mr963468iod.222.1540961419021; Tue, 30 Oct 2018 21:50:19 -0700 (PDT) Received: from PN1PR01MB0782.INDPRD01.PROD.OUTLOOK.COM ([40.100.138.53]) by smtp.gmail.com with ESMTPSA id q15-v6sm5314208itc.38.2018.10.30.21.50.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 30 Oct 2018 21:50:18 -0700 (PDT) From: Srinivas Cheruku To: Nico Williams CC: "kitten@ietf.org" Thread-Topic: [kitten] User-to-user Kerberos in GSS-API Thread-Index: ATAwNTE2KYokkQXE4oGtBKORfxy6VjQ0MTcwNkIzMTEyMDQzOMOcC0NK X-MS-Exchange-MessageSentRepresentingType: 1 Date: Wed, 31 Oct 2018 04:50:14 +0000 Message-ID: References: <5BD6BC1F.5000800@openfortress.nl> <20181029172611.GL45914@kduck.kaduk.org> <20181029183137.GB2486@localhost> <5BD8283C.4060402@openfortress.nl> In-Reply-To: <5BD8283C.4060402@openfortress.nl> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-Exchange-Organization-SCL: -1 X-MS-TNEF-Correlator: X-MS-Exchange-Organization-RecordReviewCfmType: 0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [kitten] User-to-user Kerberos in GSS-API X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2018 04:50:25 -0000 Hello Nico, =20 > The use for this has to do with keying clusters atomically, which is > difficult to pull off. If you have user-to-user, you can always just > make sure that each member of a cluster can get a TGT for the service > principal name and not bother making sure they all have the latest ke= ys > for the service principal name. =20 How does the cluster get the TGT for itself if it has no key e.g. no key ta= ble file?=20 Or if the key in the key table file is old, then MS AD would not issue a TG= T using that old key. Or am I missing something here? Thanks, Srini From nobody Tue Oct 30 21:58:35 2018 Return-Path: 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 CF324124D68 for ; Tue, 30 Oct 2018 21:58:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 EUQMfe2iicrW for ; Tue, 30 Oct 2018 21:58:31 -0700 (PDT) Received: from glass.birch.relay.mailchannels.net (glass.birch.relay.mailchannels.net [23.83.209.70]) (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 40283124C04 for ; Tue, 30 Oct 2018 21:58:31 -0700 (PDT) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 512E33E39CD; Wed, 31 Oct 2018 04:58:30 +0000 (UTC) Received: from pdx1-sub0-mail-a65.g.dreamhost.com (unknown [100.96.36.160]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 055163E375A; Wed, 31 Oct 2018 04:58:30 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a65.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.16.2); Wed, 31 Oct 2018 04:58:30 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Lettuce-Versed: 1ac3389269bf477d_1540961910160_1084088074 X-MC-Loop-Signature: 1540961910160:3547770473 X-MC-Ingress-Time: 1540961910160 Received: from pdx1-sub0-mail-a65.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a65.g.dreamhost.com (Postfix) with ESMTP id BF3BB805C4; Tue, 30 Oct 2018 21:58:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=6UxMlIfbFJAPFL LzfwQL/F4D1Ww=; b=Vqnpwhjzcy8kR5GOILzJo1XoapHSNQ67BLx3YRh2PyQDu8 SJUcqvIC7qcFE6DHr265qF07ZeNrqifzoD2yTYGtMVP3PzkYpZfh0/uhDaIWpMuc r24YimI23O2VSqgGIhlcMwiyUNDSibO89O0JNGd/474sNHMzaKsBfFk7stc9o= Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a65.g.dreamhost.com (Postfix) with ESMTPSA id B62B3805C3; Tue, 30 Oct 2018 21:58:28 -0700 (PDT) Date: Tue, 30 Oct 2018 23:58:26 -0500 X-DH-BACKEND: pdx1-sub0-mail-a65 From: Nico Williams To: Srinivas Cheruku Cc: "kitten@ietf.org" Message-ID: <20181031045825.GK2486@localhost> References: <5BD6BC1F.5000800@openfortress.nl> <20181029172611.GL45914@kduck.kaduk.org> <20181029183137.GB2486@localhost> <5BD8283C.4060402@openfortress.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedtkedriedugdejkecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucggtfgfnhhsuhgsshgtrhhisggvpdfftffgtefojffquffvnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpeffhffvuffkfhggtggujggfsehttdertddtredvnecuhfhrohhmpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqnecukfhppedvgedrvdekrddutdekrddukeefnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehlohgtrghlhhhoshhtpdhinhgvthepvdegrddvkedruddtkedrudekfedprhgvthhurhhnqdhprghthheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqedpmhgrihhlfhhrohhmpehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmpdhnrhgtphhtthhopehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmnecuvehluhhsthgvrhfuihiivgeptd Archived-At: Subject: Re: [kitten] User-to-user Kerberos in GSS-API X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2018 04:58:33 -0000 On Wed, Oct 31, 2018 at 04:50:14AM +0000, Srinivas Cheruku wrote: > > The use for this has to do with keying clusters atomically, which is > > difficult to pull off. If you have user-to-user, you can always just > > make sure that each member of a cluster can get a TGT for the service > > principal name and not bother making sure they all have the latest keys > > for the service principal name. > > How does the cluster get the TGT for itself if it has no key e.g. no > key table file? Or if the key in the key table file is old, then MS > AD would not issue a TGT using that old key. Or am I missing > something here? It's not necessarily that it has no key, but that it may not have the latest keys, or enough keys for all outstanding tickets. Also, suppose you have a host running various guests/containers: the host could push the TGTs into the guests. How does the host get the TGTs? Perhaps by using PA-TGS as pre-auth for an AS-REQ, and the KDC knows that the host is authorized to request TGTs for the given guest services. Nico --