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

Sam Hartman <hartmans@painless-security.com> Mon, 20 July 2015 11:29 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 A55201A219F for <radext@ietfa.amsl.com>; Mon, 20 Jul 2015 04:29:53 -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 1hKgnA8DHnqV for <radext@ietfa.amsl.com>; Mon, 20 Jul 2015 04:29:52 -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 1F0741A2119 for <radext@ietf.org>; Mon, 20 Jul 2015 04:29:52 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id B38B420752; Mon, 20 Jul 2015 07:29:31 -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 w3LAAFFk1jjQ; Mon, 20 Jul 2015 07:29:30 -0400 (EDT)
Received: from carter-zimmerman.suchdamage.org (dhcp-8970.meeting.ietf.org [31.133.137.112]) (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; Mon, 20 Jul 2015 07:29:30 -0400 (EDT)
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id A2E8A82120; Mon, 20 Jul 2015 07:29:48 -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>
Date: Mon, 20 Jul 2015 07:29:48 -0400
In-Reply-To: <BLU181-W94C6FC52C2E3CD666F631A93850@phx.gbl> (Bernard Aboba's message of "Mon, 20 Jul 2015 04:12:40 -0700")
Message-ID: <tslzj2r5aoj.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/qzNRzBH2QDFmnM6F33iPBdCdNV8>
Cc: "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: Mon, 20 Jul 2015 11:29:53 -0000

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

    Bernard>    One of the fundamental assumptions of this document is
    Bernard> that the EAP-Response/Identity is somehow determined from
    Bernard> the method-specific identities.  This is not correct, as
    Bernard> RFC 3748 Section 5.1 makes clear:

Hi.  I was very confused to read this paragraph, because we've discussed
this issue several times and I think we're all in agreement that the
method-specific identities are not directly related to the eap
response/identity.  I think that as the text you cite from RFC 3748
points out, the EAP response is often used for routing, so in many
deployments there is some relation.

I stopped reading your review after this first paragraph, because I
think that this disconnect colors the entire review.  I'd really
appreciate it if you would explain why you think the document is
assuming that the eap-response/identity is determined from method
identities.
I know that was not our intent.

I do think it's true that implementations sometimes derive both the eap
response/identity and the method-specific identities from a common
principal.
Other implementations request both identities from the user.
However, I don't know anything that tries to map back from a method
identity to an eap response.

--Sam