Re: [radext] Review of draft-winter-radext-populating-eapidentity-01

Sam Hartman <hartmans@painless-security.com> Wed, 22 July 2015 09:23 UTC

Return-Path: <hartmans@painless-security.com>
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB6AD1AD182 for <radext@ietfa.amsl.com>; Wed, 22 Jul 2015 02:23:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 J96yuOXkgBgK for <radext@ietfa.amsl.com>; Wed, 22 Jul 2015 02:23:12 -0700 (PDT)
Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58F191ACE3A for <radext@ietf.org>; Wed, 22 Jul 2015 02:21:09 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 3265C2075B; Wed, 22 Jul 2015 05:20:44 -0400 (EDT)
Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mgRtXtHcL3o3; Wed, 22 Jul 2015 05:20:43 -0400 (EDT)
Received: from carter-zimmerman.suchdamage.org (dhcp-89db.meeting.ietf.org [31.133.137.219]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Wed, 22 Jul 2015 05:20:43 -0400 (EDT)
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 7A2CA82120; Wed, 22 Jul 2015 05:21:06 -0400 (EDT)
From: Sam Hartman <hartmans@painless-security.com>
To: Bernard Aboba <bernard_aboba@hotmail.com>
References: <11856_1427820628_551AD054_11856_4576_1_6B7134B31289DC4FAF731D844122B36EEF6888@PEXCVZYM13.corporate.adroot.infra.ftgroup> <tsllhid84gm.fsf@mit.edu> <BLU181-W6B49664DD504DDAF5CC9F93F40@phx.gbl> <30317_1427824394_551ADF0A_30317_14370_1_6B7134B31289DC4FAF731D844122B36EEF74CD@PEXCVZYM13.corporate.adroot.infra.ftgroup> <BLU181-W86B005505E6468F75180593F40@phx.gbl> <tsl4mp182ku.fsf@mit.edu> <BA6CBD09-148F-4F8C-9B81-8A4A88B64287@deployingradius.com> <BLU406-EAS343D630A63D85F897C0EC8793F40@phx.gbl> <14078_1427880628_551BBAB4_14078_5155_1_6B7134B31289DC4FAF731D844122B36EF0B91F@PEXCVZYM13.corporate.adroot.infra.ftgroup> <190D3355-0BB7-48D5-BEA2-55773E9BD785@deployingradius.com> <24001_1437383629_55ACBBCD_24001_3716_1_6B7134B31289DC4FAF731D844122B36E01CC9ED3@OPEXCLILM43.corporate.adroot.infra.ftgroup> <BLU181-W94C6FC52C2E3CD666F631A93850@phx.gbl> <55AE9EDF.9000105@restena.lu> <BLU406-EAS346AF21C878460C2F9BC0F93840@phx.gbl>
Date: Wed, 22 Jul 2015 05:21:06 -0400
In-Reply-To: <BLU406-EAS346AF21C878460C2F9BC0F93840@phx.gbl> (Bernard Aboba's message of "Wed, 22 Jul 2015 01:11:18 +0200")
Message-ID: <tsl615czgxp.fsf@mit.edu>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <http://mailarchive.ietf.org/arch/msg/radext/PN28tmlXUHbhQglhvtEfOfnvwRg>
Cc: Stefan Winter <stefan.winter@restena.lu>, "radext@ietf.org" <radext@ietf.org>
Subject: Re: [radext] Review of draft-winter-radext-populating-eapidentity-01
X-BeenThere: radext@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: RADIUS EXTensions working group discussion list <radext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/radext>, <mailto:radext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/radext/>
List-Post: <mailto:radext@ietf.org>
List-Help: <mailto:radext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/radext>, <mailto:radext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Jul 2015 09:23:18 -0000

>>>>> "Bernard" == Bernard Aboba <bernard_aboba@hotmail.com> writes:


    Bernard>    [BA] Having valid outer config would help too.

    Bernard>      Encoding (as in: to UTF-8) should always be possible
    Bernard> (the EAP peer hopefully knows the original
    Bernard> encoding). Again, if the resulting string is not a NAI but
    Bernard> a NAI would be needed to route the authentication - time to
    Bernard> give up.

    Bernard>    [BA] The EAP implementation needs to provide an NAI for
    Bernard> the outer identity because the standard requires it. No
    Bernard> need to sugar code it - not doing so is broken.
    Bernard> _______________________________________________ radext
    Bernard> mailing list radext@ietf.org
    Bernard> https://www.ietf.org/mailman/listinfo/radext

I agree that the implementation MUST provide an outer identity.
I do want to permit mapping from some common idea of an account.
Especially for things like RFC 7055 where you're integrating EAP into
something else, you may only have space in the involved APIs for a
single concept of identity.
There you almost certainly want to do a privacy-based outer ID, and
you'll need to have specific knowledge of the methods you use, and there
may be some configurations you don't work with.
It's not fully general, but it is more intuitive than an iterface that
prompts for a lot of identities.

ONe thing to clarify in this document is which identities are we talking
about.  There are:

* The outer identity carried in an EAP response in RADIUS/Diameter.  I
  know we're talking about that one.  That's the primary point of the
  document.

* The Inner identity (if you have a tunnel method) often carried in an
  EAP response/identity in the tunnel.  You could argue this one is
  either in or out of scope.  You could argue this is an internal
  identifier of the tunnel method.

* The method specific identifier of the EAP method within the tunnel.
  In case of password authentication in something like TEAP this
  identity may be carried and the classic inner identity may not.  I
  think this identity is clearly out of scope for this document.

--Sam