Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02

Benjamin Kaduk <kaduk@mit.edu> Tue, 26 June 2018 16:46 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: ace@ietfa.amsl.com
Delivered-To: ace@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23B141310B9; Tue, 26 Jun 2018 09:46:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
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, 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 ihSBUxRz3U1I; Tue, 26 Jun 2018 09:46:14 -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 A6C10130EBF; Tue, 26 Jun 2018 09:46:14 -0700 (PDT)
X-AuditID: 12074424-37dff700000073cb-e6-5b326dd5f51f
Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 23.13.29643.5DD623B5; Tue, 26 Jun 2018 12:46:13 -0400 (EDT)
Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id w5QGkB78017048; Tue, 26 Jun 2018 12:46:12 -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 w5QGk7Xu016641 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 26 Jun 2018 12:46:09 -0400
Date: Tue, 26 Jun 2018 11:46:06 -0500
From: Benjamin Kaduk <kaduk@mit.edu>
To: Hannes Tschofenig <Hannes.Tschofenig@arm.com>
Cc: Mike Jones <Michael.Jones@microsoft.com>, Jim Schaad <ietf@augustcellars.com>, "draft-ietf-ace-cwt-proof-of-possession@ietf.org" <draft-ietf-ace-cwt-proof-of-possession@ietf.org>, "ace@ietf.org" <ace@ietf.org>
Message-ID: <20180626164603.GJ79565@kduck.kaduk.org>
References: <VI1PR0801MB2112C4D6D3CED7C15D9AE886FA750@VI1PR0801MB2112.eurprd08.prod.outlook.com> <20180622204344.GP64617@kduck.kaduk.org> <MW2PR00MB02986BC1E87754046C8CDC6AF5750@MW2PR00MB0298.namprd00.prod.outlook.com> <20180623212956.GE99689@kduck.kaduk.org> <VI1PR0801MB2112F3791E8467A53C440E11FA490@VI1PR0801MB2112.eurprd08.prod.outlook.com> <20180626150003.GD79565@kduck.kaduk.org> <VI1PR0801MB2112F73E53F790A076D5FFEBFA490@VI1PR0801MB2112.eurprd08.prod.outlook.com> <20180626151415.GE79565@kduck.kaduk.org> <VI1PR0801MB21121F740E199419EB9AC4F7FA490@VI1PR0801MB2112.eurprd08.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <VI1PR0801MB21121F740E199419EB9AC4F7FA490@VI1PR0801MB2112.eurprd08.prod.outlook.com>
User-Agent: Mutt/1.9.1 (2017-09-22)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprIKsWRmVeSWpSXmKPExsUixCmqrHs11yjaYM0WaYvv33qYLX7+u85s cXPGKSaL1dO/s1nsnfaJxYHVY828NYweG+dMZ/NYsuQnk0frjr/sASxRXDYpqTmZZalF+nYJ XBmvt7YyF0zWrHg87yZ7A+NSxS5GTg4JAROJ122/WboYuTiEBBYzSRxv/ckG4WxklLixcisj hHOVSWLCmf2sIC0sAqoSZ5adZwOx2QRUJBq6LzOD2CIChhJ7mw+xgjQwC3xglLiw4SYLSEJY IEziyYO1jCA2L9C+jTunMEFMfcIisebjCiaIhKDEyZlPwBqYBbQkbvx7CRTnALKlJZb/4wAx OQUSJVbMDQOpEBVQltjbd4h9AqPALCTNs5A0z0JoXsDIvIpRNiW3Sjc3MTOnODVZtzg5MS8v tUjXXC83s0QvNaV0EyMotNldVHYwdvd4H2IU4GBU4uG9YW8ULcSaWFZcmXuIUZKDSUmU94Mz UIgvKT+lMiOxOCO+qDQntfgQowQHs5II77G3htFCvCmJlVWpRfkwKWkOFiVx3txFjNFCAumJ JanZqakFqUUwWRkODiUJXnVgDAsJFqWmp1akZeaUIKSZODhBhvMADdfNAarhLS5IzC3OTIfI n2LU5fh3c38vsxBLXn5eqpQ47xmQIgGQoozSPLg5oJQkkb2/5hWjONBbwrxRIFU8wHQGN+kV 0BImoCVljw1AlpQkIqSkGhjnzPmks2TrwqDKn/0Ku3zepj1uZty91Oxa0PGVlheOzJDZ/fjY qm42H7+Tf6b2+LNdzeltSRGIS23VDPgoqu9sICDCd/vazqI/Rw9PT9GfNztnhsack8cWLF34 0aRxYt2nF9Fr716Otu/6aOe1XbNQYmusyKxLnUIL98etWfzwz6Y5V4wNGd/EKrEUZyQaajEX FScCAFyeSYQkAwAA
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/9u-9usJ_8hP5Q5OXMb6fywVQbV8>
Subject: Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02
X-BeenThere: ace@ietf.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <ace.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ace>, <mailto:ace-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ace/>
List-Post: <mailto:ace@ietf.org>
List-Help: <mailto:ace-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ace>, <mailto:ace-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Jun 2018 16:46:18 -0000

In Kerberos, the full principal name includes a realm name as well as the
name of the principal itself; this realm would be roughly analogous to an
OAuth Issuer.  There are plenty of case where there are collisions between
the non-realm portion of the Kerberos principal; for example, I control all
of kaduk@ATHENA.MIT.EDU, kaduk@ZONE.MIT.EDU, and kaduk@GRAND.CENTRAL.ORG 
but apply different levels of trust and privilege to them.   A more
poignant example would be the case of bjk@FREEBSD.ORG and
bjk@ATHENA.MIT.EDU, of which I control the former but not the latter.
There is some potential for actual issues when the GSSAPI is involved,
since the standard way to pick a server ("GSS acceptor") to talk to is to
generate a host-based principal name, e.g., service="host" and
hostname="ssh.dialup.example.com", which does not include Kerberos realm
information (since the GSSAPI does not have such a concept).  The Kerberos
library uses the hostname and some mapping rules/heuristics to pick a
Kerberos realm to use for ssh.dialup.example.com, but if the heuristic is
wrong for a particular case, an attacker could acquire that service
principal in the "wrong" realm, MITM, and appear to make the client connect
successfully.  (Non-MITM'd connections would fail, though, so this is
likely to be detected quickly as a configuration error.)

Within a single realm (and database), there is equivalence between account
and principal name, though there are some occurrences of re-use of the same
principal name when users or machines leave the system and reenter.  There
is usually a broad time separtation for that, though.

-Ben

On Tue, Jun 26, 2018 at 04:08:42PM +0000, Hannes Tschofenig wrote:
> Hi Ben,
> 
> You are right. We were talking about the key identifiers.
> 
> Let me still stick with the Kerberos example. In that context this would mean that the KDC stores multiple accounts in the database that point to the same principal name. Have you seen that happening?
> Re-using the same principle name over time as identifier get recycle when users get retired or otherwise leave the system might be an option. Is this a more likely?
> 
> As you see I am trying to find some examples of vulnerabilities in existing systems and I am having a hard time.
> 
> Ciao
> Hannes
> 
> -----Original Message-----
> From: Benjamin Kaduk [mailto:kaduk@mit.edu]
> Sent: 26 June 2018 17:14
> To: Hannes Tschofenig
> Cc: Mike Jones; Jim Schaad; draft-ietf-ace-cwt-proof-of-possession@ietf.org; ace@ietf.org
> Subject: Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02
> 
> I thought we were worried about collision of key *identifiers*, which were
> not necessarily raw keys or hashes thereof.  But it's possible I was not
> paying enough attention and got confused.
> 
> -Ben
> 
> On Tue, Jun 26, 2018 at 03:12:52PM +0000, Hannes Tschofenig wrote:
> > It does answer my question, Ben.
> >
> > This begs the question why the collision of session keys is suddenly a problem in the ACE context when it wasn't a problem so far. Something must have changed.
> >
> > Ciao
> > Hannes
> >
> >
> > -----Original Message-----
> > From: Benjamin Kaduk [mailto:kaduk@mit.edu]
> > Sent: 26 June 2018 17:00
> > To: Hannes Tschofenig
> > Cc: Mike Jones; Jim Schaad; draft-ietf-ace-cwt-proof-of-possession@ietf.org; ace@ietf.org
> > Subject: Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02
> >
> > On Tue, Jun 26, 2018 at 08:53:57AM +0000, Hannes Tschofenig wrote:
> > > Ben,
> > >
> > > I was wondering whether the situation is any different in Kerberos. If the KDC creates tickets with a session key included then it needs to make sure that it does not create the same symmetric key for different usages.
> > > The key in the Kerberos ticket is similar to the PoP key in our discussion.
> > >
> > > Are we aware of key collision in Kerberos?
> >
> > I don't believe key collision is an issue in Kerberos.  Long-term keys
> > (which are not what we're talking about here) are identified by a principal
> > name, encryption type, and version number.  Session keys that are contained
> > within tickets (and returned to the client in the KDC-REP) are random, so
> > even if we are only using the birthday bound we're still in pretty good
> > shape.  The modern enctypes tend to use subsession keys generated by the
> > client and/or server as well as the KDC-generated session key, which
> > provides further binding to the current session.
> >
> > Does that answer your question?
> >
> > -Ben
> > IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
> IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.