Re: [eap] Re-review of draft-ietf-hokey-erx-13.txt
<Bernard_Aboba@hotmail.com> Wed, 12 March 2008 21:43 UTC
Return-Path: <owner-radiusext@ops.ietf.org>
X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26BB828C375 for <ietfarch-radext-archive-IeZ9sae2@core3.amsl.com>; Wed, 12 Mar 2008 14:43:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.891
X-Spam-Level:
X-Spam-Status: No, score=0.891 tagged_above=-999 required=5 tests=[AWL=-0.281, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, SARE_HEAD_XUNSENT=1.666, STOX_REPLY_TYPE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gXEHvmEAqIto for <ietfarch-radext-archive-IeZ9sae2@core3.amsl.com>; Wed, 12 Mar 2008 14:42:59 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BD52728C7FD for <radext-archive-IeZ9sae2@lists.ietf.org>; Wed, 12 Mar 2008 14:42:58 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from <owner-radiusext@ops.ietf.org>) id 1JZYcb-000Jdz-T9 for radiusext-data@psg.com; Wed, 12 Mar 2008 21:36:25 +0000
Received: from [65.55.175.194] (helo=blu139-omc2-s24.blu139.hotmail.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from <bernard_aboba@hotmail.com>) id 1JZYcX-000JcB-JI for radiusext@ops.ietf.org; Wed, 12 Mar 2008 21:36:23 +0000
Received: from BLU137-DS3 ([65.55.162.186]) by blu139-omc2-s24.blu139.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 12 Mar 2008 14:36:21 -0700
X-Originating-IP: [130.129.19.169]
X-Originating-Email: [bernard_aboba@hotmail.com]
Message-ID: <BLU137-DS37F8BBC22EAF70D756C4693080@phx.gbl>
From: Bernard_Aboba@hotmail.com
In-Reply-To: <BLU137-DS3EAA88CC94748F23197EB93080@phx.gbl> <C24CB51D5AA800449982D9BCB90325130142D5F2@NAEX13.na.qualcomm.com>
To: "Narayanan, Vidya" <vidyan@qualcomm.com>, Jari Arkko <jari.arkko@piuha.net>, "Dondeti, Lakshminath" <ldondeti@qualcomm.com>, clancy@ltsnet.net, "Tim.Polk@nist.gov" <tim.polk@nist.gov>, Sam Hartman <hartmans-ietf@mit.edu>, pasi.eronen@nokia.com
Cc: iesg@ietf.org, 'eap-WG' <eap@frascone.com>, radiusext@ops.ietf.org
References: <BLU137-DS3EAA88CC94748F23197EB93080@phx.gbl> <C24CB51D5AA800449982D9BCB90325130142D5F2@NAEX13.na.qualcomm.com>
X-Unsent: 1
Subject: Re: [eap] Re-review of draft-ietf-hokey-erx-13.txt
Date: Wed, 12 Mar 2008 14:36:32 -0700
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="iso-8859-1"; reply-type="original"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
Importance: Normal
X-Mailer: Microsoft Windows Live Mail 12.0.1606
X-MIMEOLE: Produced By Microsoft MimeOLE V12.0.1606
X-OriginalArrivalTime: 12 Mar 2008 21:36:21.0499 (UTC) FILETIME=[1D2DDCB0:01C88489]
Sender: owner-radiusext@ops.ietf.org
Precedence: bulk
> Note that since the DSRK is only handed out as part of an EAP or > ERP exchange in which the peer is involved, there is no question of a > random local ER server receiving a DSRK and generating bogus accounting > records. [BA] I'm going to post a message to the HOKEY WG list trying to provide more detail so that we can discuss this whether there is a problem here, and if so, why. >The domain name is communicated in an authenticated ERP > bootstrapping exchange to the peer, so that the peer and the home AAA > server have the same idea about the domain. [BA] Would the same security properties be provided in the EAP bootstrapping case? > This is a reference just saying that in cases like IEEE 802.1x, where > the peer may send an EAPoL-Start message to start EAP, there is no need > for the authenticator to wait to receive a response for ERP - when it > receives the EAPoL-Start, it knows that the peer is interested in > starting EAP. [BA] Sure. But given the current state of ERP compatibility with IEEE 802, the reference is confusing. > Also, ERP may be network initiated and so, while the > peer-initiated mode does not work for 802.1x as written, the network > initiated mode will work fine, as long as codes greater than 4 are > allowed. [BA] The problem is that IEEE 802.1X (2001, at least) doesn't support that. > We seem to have different directions on this - Jari seems to want to > place MUSTs on lower layers, while you seem to not want that. [BA] I'm just asking what "break the connection" means, especially for a connectionless link layer. >> [BA] Do you really mean that the authenticator is using the >> realm to determine the IP address of the ER server? Or is >> the keyname-NAI field just copied into the User-Name >> attribute so that routing happens normally? >> > > The latter. [BA] Can you clarify that in the document? >> [BA] Since the local ER server does not determine whether it >> is on the path how is "path pinning" to be achieved? How does >> the AAA server know whether an ER server is on the path or not? >> What does it do if it is not on the path? In other words, >> what does the MUST imply? >> > Deployments that wish to run ERP must place the local ER server in the > path. Those that do not cannot run this protocol in the local domain. > So, there is no behavior to define when the server is not in the path. [BA] If the MUST doesn't imply anything in terms of behavior, can we drop it? > This is part of the ERP exchange and hence, carried in a AAA attribute. > The domain name is used to route the message just like any other regular > AAA routed message. [BA] The issue is that AAA routing is typically not implemented on the authenticator, only in the AAA infrastructure. Is ERX requiring that the authenticator implement a realm routing table? >> [BA] Which "original NAI" are we talking about? The NAI used >> in the EAP-Response/Identity in the original EAP >> conversation? The NAI in the Peer-Id? The NAI in the ERX >> conversation? >> > The first one. [BA] Can you state that in the draft? >> [BA] Transport of the MSK is already specified in existing >> AAA documents, such as RFC 4072 (Diameter EAP). Why is >> reference 12 being given here rather than those existing >> documents? This document does not update those specifications. >> > Reference [12] is an example from the RADIUS side. For Diameter, we do > reuse RFC4072. There still needs to be a document that describes > encapsulation of ERP messages - that is what reference 15 does, for > instance. [BA] The problem is that reference [12] is not used by existing RADIUS/ EAP implementations, and the ERP document should not be updating or obsoleting legacy EAP or RADIUS/EAP behavior. >> [BA] I think you mean "ERX" not "EAP re-authentication" or >> ERP, right? >> One thing that is left out here is authentication between the >> ERX local server and the ERX home server. This exists if >> they are one hop apart, but otherwise not. So I think there >> is an assumption that the ERX server is only willing to >> provide keys to domains that it is explicitly authorized to >> deal with. > > The authorization text that I pointed out earlier covers this. [BA] OK. I'll take a look at this. > I thought that the intent was clear, but, if you prefer this wording, we > can change it as you suggest. [BA] I prefer the suggested text since RADIUS application layer security is also being considered. >> [BA] The rest of the spec does not talk about use of the >> Peer-Id. Since not all EAP method deriving keys have a >> Peer-Id, do you really want this mentioned here? >> > The peer-id is a remnant that should be deleted. We will delete that in > the next revision. [BA] Great. > This is a note to lower layers and is obviously not binding. It is > ultimately the lower layer that will define the authorization state. [BA] You might say that in the document. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/radiusext/>
- Re-review of draft-ietf-hokey-erx-13.txt Bernard_Aboba
- Re: [eap] Re-review of draft-ietf-hokey-erx-13.txt Bernard_Aboba