Re: [abfab] Gen-ART review of draft-ietf-abfab-eapapplicability-03

"Joseph Salowey (jsalowey)" <jsalowey@cisco.com> Tue, 18 June 2013 17:47 UTC

Return-Path: <jsalowey@cisco.com>
X-Original-To: abfab@ietfa.amsl.com
Delivered-To: abfab@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9523A11E80DF; Tue, 18 Jun 2013 10:47:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level:
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eRUCxIPRbfch; Tue, 18 Jun 2013 10:47:05 -0700 (PDT)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id E391C11E80EC; Tue, 18 Jun 2013 10:47:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2198; q=dns/txt; s=iport; t=1371577625; x=1372787225; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Tl0W1XPlBj7Q7T8U4EZPVfIrpXaWB8G9FYDbLyRLqJI=; b=cZvKpaWkdEdheb+GuYb9/qy3lsQVZaaLVXj3eSSn3Hw+I37mNtYzLHxo NXMu5jlhPexVFY2tLTsZIlCdzuUA5yRaZDZb7S1vY1dO11A3Rglkyfptn 2H9TWvQGiFQNm6cd/oc58A2Q+wWE9OT2NQ9Bcn2nE4nXtIDtcun2ixFAS U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ag0FALecwFGtJV2d/2dsb2JhbABPCoMJer8PgQIWdIIkAQEEOj8QAgEIIhQQMiUBAQQODYgGuwuNf4EJAjEHgwBhA6kEgw+CKA
X-IronPort-AV: E=Sophos;i="4.87,890,1363132800"; d="scan'208";a="224169702"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-1.cisco.com with ESMTP; 18 Jun 2013 17:47:04 +0000
Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r5IHl4iY016128 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 18 Jun 2013 17:47:04 GMT
Received: from xmb-rcd-x09.cisco.com ([169.254.9.220]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0318.004; Tue, 18 Jun 2013 12:47:04 -0500
From: "Joseph Salowey (jsalowey)" <jsalowey@cisco.com>
To: "Black, David" <david.black@emc.com>
Thread-Topic: [abfab] Gen-ART review of draft-ietf-abfab-eapapplicability-03
Thread-Index: Ac5rzQ3h5Vr98eb9RParuraCHgwUcgAYb7oMABB0QQAAClxl4P//t2GA
Date: Tue, 18 Jun 2013 17:47:03 +0000
Message-ID: <A95B4818FD85874D8F16607F1AC7C628CFA26E@xmb-rcd-x09.cisco.com>
References: <8D3D17ACE214DC429325B2B98F3AE71298265158@MX15A.corp.emc.com> <tsl38sfbiyd.fsf@mit.edu> <A95B4818FD85874D8F16607F1AC7C628CF9E35@xmb-rcd-x09.cisco.com> <8D3D17ACE214DC429325B2B98F3AE712982652A5@MX15A.corp.emc.com>
In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712982652A5@MX15A.corp.emc.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.33.248.222]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <6D250E7F34578C4DB2BC1DE691351E73@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: General Area Review Team <gen-art@ietf.org>, "abfab@ietf.org" <abfab@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>
Subject: Re: [abfab] Gen-ART review of draft-ietf-abfab-eapapplicability-03
X-BeenThere: abfab@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" <abfab.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/abfab>, <mailto:abfab-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/abfab>
List-Post: <mailto:abfab@ietf.org>
List-Help: <mailto:abfab-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/abfab>, <mailto:abfab-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 Jun 2013 17:47:10 -0000

>> 
>> I think we could state this a bit better as something like:
>> 
>> "In environments where EAP is used for applications authentication and network
>> access authentication all EAP servers MUST understand channel bindings and
>> require that application bindings MUST be present in application
>> authentication and that application bindings MUST be absent in network
>> authentication.   All network access EAP peer implementations SHOULD support
>> channel binding to explicitly identify the reason for authentication.  Any new
>> usage of EAP MUST support channel bindings to prevent confusion with network
>> access usage. "
> 
> That text is an improvement, and it's headed in the same direction as Sam's
> comment - "application bindings MUST be present in application authentication"
> is a "MUST use" requirement, not just a "MUST implement" requirement.
> 
> OTOH, I'm not clear on what "application bindings" means, as that term's not
> in the current draft.  Specifically, I'm a bit unclear on "application bindings
> MUST be absent in network authentication" - does that mean that channel
> binding must be absent, or that channel binding is optional, but if channel
> binding is present, it MUST NOT be an "application binding", whatever that is?
> 

[Joe] Good points, the text can be more specific:

"In environments where EAP is used for purposes other than network access authentication all EAP servers MUST enforce channel bindings.  For application authentication, the EAP server MUST require that the correct EAP lower-layer attribute be present in the channel binding data.   For network access authentication, the EAP server MUST require that if channel bindings are present they MUST contain the correct EAP lower-layer attribute.   All network access EAP peer implementations SHOULD use channel bindings including the EAP lower-layer attribute to explicitly identify the reason for authentication.  Any new usage of EAP MUST use channel bindings including the EAP lower-layer attribute to prevent confusion with network access usage. "

Does this help?

Thanks,

Joe