From owner-aaa-wg@merit.edu Fri Mar 1 01:33:01 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07021 for ; Fri, 1 Mar 2002 01:33:00 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 4B23F91213; Fri, 1 Mar 2002 01:32:23 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 17FF79137D; Fri, 1 Mar 2002 01:32:22 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2977991213 for ; Fri, 1 Mar 2002 01:32:20 -0500 (EST) Received: by segue.merit.edu (Postfix) id EF6635DDD4; Fri, 1 Mar 2002 01:32:19 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 8BEB15DDAF for ; Fri, 1 Mar 2002 01:32:19 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g215qHH07162 for ; Thu, 28 Feb 2002 21:52:17 -0800 Date: Thu, 28 Feb 2002 21:52:17 -0800 (PST) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: -09 Base Draft available Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Many thanks to John Loughney and the AAA editors team for preparing the -09 revision of the Base Draft. Updated versions of the other drafts will also be appearing shortly. For those of you who would like to get a head start on reading it before it appears on the IETF archive, Base -09 is available for your perusal at: http://www.drizzle.com/~aboba/AAA/draft-ietf-aaa-diameter-09.txt From owner-aaa-wg@merit.edu Fri Mar 1 04:28:40 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02082 for ; Fri, 1 Mar 2002 04:28:40 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 76F579133F; Fri, 1 Mar 2002 04:28:24 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 443909137D; Fri, 1 Mar 2002 04:28:24 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 348B69133F for ; Fri, 1 Mar 2002 04:28:23 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1472B5DDAF; Fri, 1 Mar 2002 04:28:23 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by segue.merit.edu (Postfix) with ESMTP id 27FA05DDA5 for ; Fri, 1 Mar 2002 04:28:22 -0500 (EST) Received: from fredrikj (bravo-54.local.ipunplugged.com [192.168.2.54]) by mailgw.ipunplugged.com (8.9.3/8.9.3) with SMTP id KAA09070; Fri, 1 Mar 2002 10:25:57 +0100 From: "Fredrik Johansson" To: , Cc: , Subject: RE: [AAA-WG]: Issue 279: Base does not sufficiently explain what 'MAY encrypt means - CLOSED for BASE Date: Fri, 1 Mar 2002 10:28:50 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEFA22AF7@esebe004.NOE.Nokia.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit According to the discussion on where to send accounting records http://www.merit.edu/mail.archives/aaa-wg/2002-02/msg00182.html It was proposed that intermediate servers could collect accounting data on the way to the home accounting server for inter-operator settlements. But if accounting record AVPs are encrypted, the intermediate servers will not have any chance to interpret the content. I still believe that accounting records generated in the access network should be able to send to a accounting server in the access network and not to the home network. It should be configurable. /Fredrik P.S. kind of strange that AVPs marked with MAY encrypt in the table MUST be encrypted :-) Change the column name to MUST encr. >-----Original Message----- >From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of >john.loughney@nokia.com >Sent: den 27 februari 2002 20:45 >To: stephen.farrell@baltimore.ie >Cc: jari.arkko@kolumbus.fi; aaa-wg@merit.edu >Subject: RE: [AAA-WG]: Issue 279: Base does not sufficiently explain >what 'MAY encrypt means - CLOSED for BASE > > >Hi Stephen, > > >> After some off-list discussion it appears that the following >> is the correct interpretation of the "MAY encr" column: >> >> "For the originator of a Diameter message, "MAY encr" means >> that if a message containing that AVP is to be sent via a >> proxy/agent then the message MUST NOT be sent unless there >> is a DSA between the originator and the recipient OR the >> originator has locally trusted configuration that indicates >> that CMS need not be used." >> >> I'll put this into CMS, but would also recommend it go >> somewhere in the base. > >I'll make this change > >ORIGINAL TEXT > > 4.6 Diameter Base Protocol AVPs > > The following table describes the Diameter AVPs defined > in the base protocol, their AVP Code values, types, possible > flag values and whether the AVP MAY be encrypted. If an AVP > MAY be encrypted, section 2.0 of the Diameter CMS security > extension [CMS] defines in which situations the encryption is > actually employed. > >NEW TEXT: > > 4.6 Diameter Base Protocol AVPs > > The following table describes the Diameter AVPs defined > in the base protocol, their AVP Code values, types, possible > flag values and whether the AVP MAY be encrypted. For the > originator of a Diameter message, "MAY Encr" means that if > a message containing that AVP is to be sent via a > proxy/agent then the message MUST NOT be sent unless there > is a DSA between the originator and the recipient OR the > originator has locally trusted configuration that indicates > that CMS need not be used. > >John From owner-aaa-wg@merit.edu Fri Mar 1 10:41:12 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00713 for ; Fri, 1 Mar 2002 10:41:12 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2221A9120D; Fri, 1 Mar 2002 10:40:43 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E01D291381; Fri, 1 Mar 2002 10:40:42 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id EA1A29120D for ; Fri, 1 Mar 2002 10:40:41 -0500 (EST) Received: by segue.merit.edu (Postfix) id B7AC35DE04; Fri, 1 Mar 2002 10:40:41 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id A38165DD9B for ; Fri, 1 Mar 2002 10:40:41 -0500 (EST) Received: from Interlinknetworks.com (nat.interlinknetworks.com [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with ESMTP id D1BD77E for ; Fri, 1 Mar 2002 10:40:07 -0500 (EST) Message-ID: <3C7FA0DE.36B46258@Interlinknetworks.com> Date: Fri, 01 Mar 2002 10:40:14 -0500 From: David Spence Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: AAA Working Group Subject: [AAA-WG]: [issue] Relax Service-Type from REQUIRED to RECOMMENDED in nasreq Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Subject: [issue] Relax Service-Type from REQUIRED to RECOMMENDED in nasreq Submitter name: David Spence Submitter email address: DSpence@Interlinknetworks.com Date first submitted: March 1, 2002 Reference: Document: NASREQ Comment type: T Priority: 1 Section: various Rationale/Explanation of issue: Although nasreq-08 is not entirely consistent on this, it seems to require the Service-Type AVP to appear in all messages. Unfortunately, RADIUS does not make this requirement. Therefore I am relaxing the requirement in nasreq from MUST to SHOULD. The alternative would be to add an heuristic to the RADIUS/Diameter gateway section explaining how a RADIUS to Diameter gateway should infer the value of the Service-Type based on the attributes present in the RADIUS message. Being lazy, I opt for relaxing the requirement. Requested change: State that Service-Type SHOULD (rather than MUST) be included, change the ABNF from "{ Service-Type }" to "[ Service-Type ]", and change the AVP Ocurrence Tables from 1 to 0-1. From owner-aaa-wg@merit.edu Fri Mar 1 21:53:41 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11963 for ; Fri, 1 Mar 2002 21:53:40 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9D85891201; Fri, 1 Mar 2002 21:53:31 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6554C91208; Fri, 1 Mar 2002 21:53:31 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 52F9B91201 for ; Fri, 1 Mar 2002 21:53:30 -0500 (EST) Received: by segue.merit.edu (Postfix) id 338195DDAD; Fri, 1 Mar 2002 21:53:30 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from cms3.etri.re.kr (unknown [129.254.16.13]) by segue.merit.edu (Postfix) with ESMTP id 7693B5DD8F for ; Fri, 1 Mar 2002 21:53:29 -0500 (EST) Received: by cms3.etri.re.kr with Internet Mail Service (5.5.2653.19) id ; Sat, 2 Mar 2002 11:54:27 +0900 Message-ID: <8470181DABD5D511B3E700D0B7A8AC4A69E2BF@cms3.etri.re.kr> From: anny5@etri.re.kr To: stephen.farrell@baltimore.ie, anny5@etri.re.kr Cc: jari.arkko@kolumbus.fi, aaa-wg@merit.edu Subject: Re: [AAA-WG]: Re: [AAA-WG]: CMS Question Date: Sat, 2 Mar 2002 11:54:26 +0900 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1C195.90BC1E20" Sender: owner-aaa-wg@merit.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1C195.90BC1E20 Content-Type: text/plain; charset="euc-kr" Hi, > anny5@etri.re.kr wrote: > > I think DSA/DSAA message contain several AAA-Node-Cert AVP . AAA-Node- Cert AVP contains > certificates of > > AAA hosts in same realm. > > if the size of one certificate is 700k and there is 5 hosts in same realm, does DSAR/DSAA( contain 700k!!! X.509 has been accused of bloat, but never that much bloat! Certificates are usually <2k. sorry. that is my mistake. i misunderstood "byte" and "k". i mean 700 byte and 3500 byte.. > > 3500k certificate - 5 AAA-Node-Cert AVPs ) message have to transport? > > also, if one realm and antoher realm(one host and one host) has a DSA, don't other hosts at these > > realm need to establish DSA? Without DSA establish step, the communocation is possible? That depends on how many of the hosts have access to the private key concerned. One option is that all the hosts use the same key pair (put all their names in the relevant certificate). Stephen. if even all hosts in same real use same certificates, i think it is impossible communacation without DSA establish. so it has no something to do with using same certificate or not. DSA is 1:1 connectios, isn' it? i think only one AAA-Node-Cert AVP must appear in DSAR/DSAA.(without common 3-des key by DSA establish step, how they can communcate?) regards ------_=_NextPart_001_01C1C195.90BC1E20 Content-Type: text/html; charset="euc-kr" Content-Transfer-Encoding: quoted-printable Re: [AAA-WG]: Re: [AAA-WG]: CMS Question

Hi,
> anny5@etri.re.kr wrote:
>
> I think DSA/DSAA message contain several = AAA-Node-Cert AVP . AAA-Node-Cert AVP  contains
> certificates of
>
> AAA hosts in same realm.
>
> if the size of one certificate is 700k and = there is 5 hosts in same realm, does DSAR/DSAA( contain
700k!!! X.509 has been accused of bloat, but never = that much bloat!
Certificates are usually <2k.

sorry. that is my mistake. i misunderstood = "byte" and "k". i mean 700 byte and 3500 = byte..


>
> 3500k certificate - 5 AAA-Node-Cert AVPs ) = message have to transport?
>
> also, if one realm and antoher realm(one host = and one host) has a DSA,  don't other hosts at these
>
> realm need to establish DSA? Without DSA = establish step, the communocation is possible?
That depends on how many of the hosts have access to = the private key
concerned. One option is that all the hosts use the = same key pair
(put all their names in the relevant = certificate).
Stephen.
 
if even all hosts in same real use same = certificates, i think it is impossible communacation without DSA = establish.

so it has no something to do with using same = certificate or not.  DSA is  1:1 connectios, isn' it?

i think only one AAA-Node-Cert AVP must appear in = DSAR/DSAA.(without common 3-des key by  DSA establish step,

how they can communcate?)

regards

------_=_NextPart_001_01C1C195.90BC1E20-- From owner-aaa-wg@merit.edu Fri Mar 1 22:54:54 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13903 for ; Fri, 1 Mar 2002 22:54:54 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 27C7D91208; Fri, 1 Mar 2002 22:54:43 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E9D2891217; Fri, 1 Mar 2002 22:54:42 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 07DFE91208 for ; Fri, 1 Mar 2002 22:54:41 -0500 (EST) Received: by segue.merit.edu (Postfix) id D420C5DDAD; Fri, 1 Mar 2002 22:54:41 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 6565E5DDAA for ; Fri, 1 Mar 2002 22:54:41 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g223EYU13755 for ; Fri, 1 Mar 2002 19:14:34 -0800 Date: Fri, 1 Mar 2002 19:14:34 -0800 (PST) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: Drafts for your perusal Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk The AAA WG editors have been working hard on addressing the last call comments and readying updated drafts. Until they show up on the IETF archive, here are the latest drafts for your examination: http://www.drizzle.com/~aboba/AAA/draft-ietf-aaa-diameter-nasreq-09.txt http://www.drizzle.com/~aboba/AAA/draft-ietf-aaa-mobileip-09.txt http://www.drizzle.com/~aboba/AAA/draft-ietf-aaa-diameter-cms-04.txt http://www.drizzle.com/~aboba/AAA/draft-ietf-aaa-diameter-09.txt I will also be putting up a Diameter Base -10 draft which is a last-minute update that fixes some problems found in -09. It is not up on the archive quite yet, but should be very soon. From owner-aaa-wg@merit.edu Sat Mar 2 01:12:38 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16970 for ; Sat, 2 Mar 2002 01:12:38 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A74E091217; Sat, 2 Mar 2002 01:12:22 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7D5BD91381; Sat, 2 Mar 2002 01:12:22 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9392D91217 for ; Sat, 2 Mar 2002 01:12:21 -0500 (EST) Received: by segue.merit.edu (Postfix) id 733615DD8F; Sat, 2 Mar 2002 01:12:21 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 066F45DDE9 for ; Sat, 2 Mar 2002 01:12:21 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g225WD421426 for ; Fri, 1 Mar 2002 21:32:13 -0800 Date: Fri, 1 Mar 2002 21:32:13 -0800 (PST) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: Base -10 draft now online Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk The Diameter Base -10 draft is now online. Many thanks to Jari Arkko and John Loughney for editing it. Until they show up on the IETF archive, here is where you can get the drafts: http://www.drizzle.com/~aboba/AAA/draft-ietf-aaa-diameter-nasreq-09.txt http://www.drizzle.com/~aboba/AAA/draft-ietf-aaa-mobileip-09.txt http://www.drizzle.com/~aboba/AAA/draft-ietf-aaa-diameter-cms-04.txt http://www.drizzle.com/~aboba/AAA/draft-ietf-aaa-diameter-10.txt From owner-aaa-wg@merit.edu Sat Mar 2 08:56:47 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00195 for ; Sat, 2 Mar 2002 08:56:47 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 6E35D9121B; Sat, 2 Mar 2002 08:56:20 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3A1C491223; Sat, 2 Mar 2002 08:56:20 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3E0B59121B for ; Sat, 2 Mar 2002 08:56:19 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1C17B5DDE9; Sat, 2 Mar 2002 08:56:19 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id D98A55DD8E for ; Sat, 2 Mar 2002 08:56:18 -0500 (EST) Received: from phoenix (nat.interlinknetworks.com [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with SMTP id 9CE546C; Sat, 2 Mar 2002 08:56:18 -0500 (EST) From: "Bob Kopacz" To: "Bernard Aboba" , Subject: RE: [AAA-WG]: Drafts for your perusal Date: Sat, 2 Mar 2002 08:55:22 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Bernard, Minor correction: the link to the Mobile IPv4 draft should be: http://www.drizzle.com/~aboba/AAA/draft-ietf-aaa-diameter-mobileip-09.txt Bob K. > -----Original Message----- > From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of > Bernard Aboba > Sent: Friday, March 01, 2002 10:15 PM > To: aaa-wg@merit.edu > Subject: [AAA-WG]: Drafts for your perusal > > > The AAA WG editors have been working hard on addressing the last call > comments and readying updated drafts. Until they show up on the IETF > archive, here are the latest drafts for your examination: > > http://www.drizzle.com/~aboba/AAA/draft-ietf-aaa-diameter-nasreq-09.txt > http://www.drizzle.com/~aboba/AAA/draft-ietf-aaa-mobileip-09.txt > http://www.drizzle.com/~aboba/AAA/draft-ietf-aaa-diameter-cms-04.txt > http://www.drizzle.com/~aboba/AAA/draft-ietf-aaa-diameter-09.txt > > I will also be putting up a Diameter Base -10 draft which is a last-minute > update that fixes some problems found in -09. It is not up on the archive > quite yet, but should be very soon. > > From owner-aaa-wg@merit.edu Sun Mar 3 01:58:43 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11581 for ; Sun, 3 Mar 2002 01:58:43 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 23CBF91221; Sun, 3 Mar 2002 01:58:31 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EBE9E91222; Sun, 3 Mar 2002 01:58:30 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0BF9691221 for ; Sun, 3 Mar 2002 01:58:29 -0500 (EST) Received: by segue.merit.edu (Postfix) id D42CD5DDC2; Sun, 3 Mar 2002 01:58:14 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 5FA685DD9C for ; Sun, 3 Mar 2002 01:58:14 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g236Ht006063 for ; Sat, 2 Mar 2002 22:17:56 -0800 Date: Sat, 2 Mar 2002 22:17:55 -0800 (PST) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: Preliminary AAA WG Agenda for IETF 53 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Authentication, Authorization and Accounting WG (AAA) Thursday, March 21,2002 at 1300-1500 ==================================== CHAIRS: Bernard Aboba David Mitton Agenda: 1. Preliminaries (10 minutes) Agenda Bashing Blue sheets Minute takers Document status WG Last Call Summary 2. Connectathon Update (5 minutes) 3. Diameter Base (John Loughney, 15 minutes) http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-10.txt 4. Mobile IP (Tony Johansson, 15 minutes) http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-mobileip-09.txt 5. NASREQ (David Spence & David Mitton, 15 minutes) http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-nasreq-09.txt 6. CMS (Stephen Farrell, 15 minutes) http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-cms-04.txt 7. Transport (Bernard Aboba, 5 minutes) http://www.ietf.org/internet-drafts/draft-ietf-aaa-transport-05.txt 8. Roadmap (Bernard Aboba & ADs, 10 minutes) From owner-aaa-wg@merit.edu Sun Mar 3 12:02:16 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26258 for ; Sun, 3 Mar 2002 12:02:16 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9643991224; Sun, 3 Mar 2002 12:01:49 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AA3B09121D; Sun, 3 Mar 2002 12:01:33 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 690219121A for ; Sun, 3 Mar 2002 12:01:25 -0500 (EST) Received: by segue.merit.edu (Postfix) id 27B785DE21; Sun, 3 Mar 2002 12:01:25 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 9D7685DD97 for ; Sun, 3 Mar 2002 12:01:24 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g23GL0a09784 for ; Sun, 3 Mar 2002 08:21:00 -0800 Date: Sun, 3 Mar 2002 08:21:00 -0800 (PST) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: [Issue] NASREQ: Keying AVPs are insecure Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Submitter: Jesse Walker Submitter email address: jesse.walker@intel.com Date first submitted: March 2, 2002 Reference: Document: NASREQ Comment type: T Priority: S Section: 2.1 Rationale/Explanation of issue: Diameter keying AVPs cannot securely distribute a key for its intended purpose. While they may be suitable for handing off a key between the authentication server and the NAS/Access Point, intended for communications between themselves alone, as constituted today they are insecure for transferring a session key intended for use between the NAS/AP and the client. To become secure, the key handoff has to be enhanced to incorporate additional cryptographic state that can be used to provide assurances to all these parties involved in the transaction. Examples of such state are the information communicated among the KDC and the communicating parties in the Needham-Schroeder and Otway-Rees protocols. Proposed change: A three-way handshake should be incorporated so that key distribution and confirmation can be dealt with uniformly across multiple environments. These key distribution methods require active participation by three parties instead of two. From owner-aaa-wg@merit.edu Mon Mar 4 11:06:16 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29884 for ; Mon, 4 Mar 2002 11:06:15 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id AC4BE9121A; Mon, 4 Mar 2002 11:06:05 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8461B9121D; Mon, 4 Mar 2002 11:06:05 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8642B9121A for ; Mon, 4 Mar 2002 11:06:04 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5C3565DDCD; Mon, 4 Mar 2002 11:06:04 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id DB3835DDAB for ; Mon, 4 Mar 2002 11:06:03 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g24FPdb21448 for ; Mon, 4 Mar 2002 07:25:40 -0800 Date: Mon, 4 Mar 2002 07:25:39 -0800 (PST) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: Updated Preliminary AAA WG Agenda for IETF 53 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Authentication, Authorization and Accounting WG (AAA) Thursday, March 21,2002 at 1300-1500 ==================================== CHAIRS: Bernard Aboba David Mitton Agenda: 1. Preliminaries (10 minutes) Agenda Bashing Blue sheets Minute takers Document status WG Last Call Summary 2. Connectathon Update (David Frascone, 5 minutes) 3. Diameter Base (John Loughney, 10 minutes) http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-10.txt 4. Mobile IP (Tony Johansson, 10 minutes) http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-mobileip-09.txt 5. CMS (Pat Calhoun, 10 minutes) http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-cms-04.txt 6. Transport (Bernard Aboba, 5 minutes) http://www.ietf.org/internet-drafts/draft-ietf-aaa-transport-05.txt 7. NASREQ (David Spence & David Mitton, 10 minutes) http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-nasreq-09.txt 8. Security issues with the NASREQ Keying Attributes (Jesse Walker, 10 minutes) 9. Roadmap (Bernard Aboba & ADs, 5 minutes) From owner-aaa-wg@merit.edu Mon Mar 4 13:26:00 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07854 for ; Mon, 4 Mar 2002 13:26:00 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 4049F91206; Mon, 4 Mar 2002 13:25:48 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 145FB9121D; Mon, 4 Mar 2002 13:25:48 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 122D891206 for ; Mon, 4 Mar 2002 13:25:47 -0500 (EST) Received: by segue.merit.edu (Postfix) id EB33B5DE28; Mon, 4 Mar 2002 13:25:46 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 4C5445DDDD for ; Mon, 4 Mar 2002 13:25:46 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g24HjPq29197 for ; Mon, 4 Mar 2002 09:45:25 -0800 Date: Mon, 4 Mar 2002 09:45:24 -0800 (PST) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: Why NASREQ Key Distribution is insecure (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk This is followup documentation on the issue posted to the list earlier. --------------------------------------------------------------------- From: Jesse Walker : To: eap@frascone.com >Given that the AS and AP trust each other (assumed), why >is a reasonable cryptographic protocol (such as CMS or even IPSec) is >insufficient to protect the transfer of a STA-AP session key from the AS to >the AP? There has been in fact ample discussion around exactly these points. There is, for instance, the whole key handoff discussion, of which AS-AP handoff is a special case. As a second example, there is the flap around the Arbaugh-Mishra 802.1X paper, which echos many of our key handoff discussions, and which we have also discussed. But even if we had never discussed these points before, we would be forced to if the issue were raised; if someone perceives holes in our security, then these have to be addressed, and making an appeal that this wasn't ever an issue before doesn't help. I don't buy the assumed trust argument, because it is not specific enough to offer any useful insight. Let me respond to it by asking why should we assume the AS and the AP trust each other, and, more to the point, for what purpose should they trust each other? I think the correct assumptions are something like a. The AS and the AP share a key used for key distribution, and that both parties can be trusted to use this key for no other purpose, and to expose it to no other parties; b. The AS can be trusted to distribute a fresh key whenever it distributes a key. Why should we assume substantially more about the AP-AS relationship? Each assumption represents a new point of attack if compromised, so we would do well to think about eliminating as many assumptions as possible. Protocols exist that would allow us to reduce the number of assumptions we make by incorporating explicit verification in place of trust assumptions. It is feasible to add protocol state allowing the AS to verify that the key distribution request really did originate with a legitimate station and not as the result of a rogue AP or a rogue station. It is feasible for both the AS and the station to verify that the key distribution is live, even though they can't verify it is fresh (that's why we have to make the second trust assumption). It is feasible for both the AP and the station to verify that the AS intended to distribute this particular key to this particular pair, i.e., that each is talking to the other intended recipient of the key, and to no one else, and for the protocol to protect against either the AP or the station cheating (except by exposing a key). The existing method of throwing keys over the fence to the AP does not have any of these guarantees built in, so we have to assume much more to use it. Each such assumption may reasonable in a sufficiently constrained environment, but I question whether together they are reasonable in a network as open as a WLAN. And I don't buy basing the security on mechanisms like IPsec. By definition, IPsec provides bilateral security between the two parties sharing a security association, and binds only the two together. A key distribution protocol of the sort we are discussing is not a bilateral relationship. Key distribution is a trilateral relationship among three parties--the AS, the AP, and the station--and because of this will have to cryptographically bind the three parties together somehow to be secure, i.e., to minimize points to attack. You can replace IPsec by any other bilateral security protocol, and the same argument obtains. My position is that it would be prudent for us to look at adapting a key distribution protocol that reduces our exposure by minimizing security assumptions. I believe this because we are building systems that expose many more attack points than in the past. Indeed, I think the burden of proof is on the other foot: what leads us to think the special conditions and circumstances and topologies that permitted security shortcuts in the past are still applicable in the more fragile environments we are building today? Why should the mechanisms that worked in more restricted environments still be applicable unchanged when moved into new environments that, on the surface at least, seem to violate many of the assumptions we made before? From owner-aaa-wg@merit.edu Mon Mar 4 17:06:28 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26310 for ; Mon, 4 Mar 2002 17:06:28 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E378291203; Mon, 4 Mar 2002 17:06:16 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A948B9122B; Mon, 4 Mar 2002 17:06:16 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B961691203 for ; Mon, 4 Mar 2002 17:06:15 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9C5DA5DDE2; Mon, 4 Mar 2002 17:06:15 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 874B35DDD2 for ; Mon, 4 Mar 2002 17:06:15 -0500 (EST) Received: from Interlinknetworks.com (nat.interlinknetworks.com [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with ESMTP id D7DFC6C for ; Mon, 4 Mar 2002 17:06:14 -0500 (EST) Message-ID: <3C83EFDD.156281BE@Interlinknetworks.com> Date: Mon, 04 Mar 2002 17:06:21 -0500 From: David Spence Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: AAA Working Group Subject: [AAA-WG]: [issue] New NASREQ AVPs Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Subject: [issue] More NASREQ AVPs needed Submitter name: David Spence Submitter email address: DSpence@Interlinknetworks.com Date first submitted: March 4, 2002 Reference: Document: NASREQ-09 Comment type: T Priority: S Section: various Rationale/Explanation of issue: There are a number of attributes defined in RADIUS RFCs that are needed for the correct operation of the Diameter NASREQ application. They are: CODE NAME RFC ---- ---- ---- 29 Termination-Action 2865 41 Acct-Delay-Time 2866 51 Acct-Link-Count 2866 55 Event-Timestamp 2869 78 Configuration-Token 2869 85 Acct-Interim-Interval 2869 87 NAS-Port-Id 2869 88 Framed-Pool 2869 95 NAS-IPv6-Address 3162 98 Login-IPv6-Host 3162 Note: These AVPs were not added to nasreq-09, so this issue requires more work in nasreq. Requested change: Add these attributes to nasreq as Diameter AVPs. From owner-aaa-wg@merit.edu Mon Mar 4 17:07:52 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26395 for ; Mon, 4 Mar 2002 17:07:47 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 8C33A9122F; Mon, 4 Mar 2002 17:07:38 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5820D9122B; Mon, 4 Mar 2002 17:07:38 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 872A69122F for ; Mon, 4 Mar 2002 17:07:36 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6905D5DDD2; Mon, 4 Mar 2002 17:07:36 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from EXCHSRV.stormventures.com (unknown [65.107.25.226]) by segue.merit.edu (Postfix) with ESMTP id 1B0315DDCC for ; Mon, 4 Mar 2002 17:07:36 -0500 (EST) Received: by EXCHSRV.stormventures.com with Internet Mail Service (5.5.2653.19) id <1QP7SHKD>; Mon, 4 Mar 2002 14:07:32 -0800 Message-ID: From: "Pat R. Calhoun" To: "'David Spence'" , AAA Working Group Subject: RE: [AAA-WG]: [issue] New NASREQ AVPs Date: Mon, 4 Mar 2002 14:07:31 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1C3C8.FB021DE0" Sender: owner-aaa-wg@merit.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1C3C8.FB021DE0 Content-Type: text/plain -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Note that some of these had been intentionally left out because they made no sense for Diameter. PatC - -----Original Message----- From: David Spence [mailto:DSpence@Interlinknetworks.com] Sent: Monday, March 04, 2002 2:06 PM To: AAA Working Group Subject: [AAA-WG]: [issue] New NASREQ AVPs Subject: [issue] More NASREQ AVPs needed Submitter name: David Spence Submitter email address: DSpence@Interlinknetworks.com Date first submitted: March 4, 2002 Reference: Document: NASREQ-09 Comment type: T Priority: S Section: various Rationale/Explanation of issue: There are a number of attributes defined in RADIUS RFCs that are needed for the correct operation of the Diameter NASREQ application. They are: CODE NAME RFC ---- ---- ---- 29 Termination-Action 2865 41 Acct-Delay-Time 2866 51 Acct-Link-Count 2866 55 Event-Timestamp 2869 78 Configuration-Token 2869 85 Acct-Interim-Interval 2869 87 NAS-Port-Id 2869 88 Framed-Pool 2869 95 NAS-IPv6-Address 3162 98 Login-IPv6-Host 3162 Note: These AVPs were not added to nasreq-09, so this issue requires more work in nasreq. Requested change: Add these attributes to nasreq as Diameter AVPs. -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 7.0.3 for non-commercial use iQA/AwUBPIPwIzN1fXKoxmisEQLulwCeLwV+vxIEowM8zPnYtFZexYQAnNUAnRUG n3NEsOTkwIKo9GyDwiPSu9Cd =FzMY -----END PGP SIGNATURE----- ------_=_NextPart_001_01C1C3C8.FB021DE0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [AAA-WG]: [issue] New NASREQ AVPs

 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Note that some of these had been intentionally left = out because they
made no sense for Diameter.

PatC

- -----Original Message-----
From: David Spence [mailto:DSpence@Interlinkne= tworks.com]
Sent: Monday, March 04, 2002 2:06 PM
To: AAA Working Group
Subject: [AAA-WG]: [issue] New NASREQ AVPs


Subject: [issue] More NASREQ AVPs needed

Submitter name: David Spence
Submitter email address: = DSpence@Interlinknetworks.com
Date first submitted: March 4, 2002
Reference:
Document: NASREQ-09
Comment type: T
Priority: S
Section: various
Rationale/Explanation of issue:

    There are a number of attributes = defined in RADIUS RFCs that are
    needed for the correct operation = of the Diameter NASREQ
application.
    They are:

       = CODE      = NAME           &n= bsp;           &n= bsp;    RFC
       = ----      = ----           &n= bsp;           &n= bsp;    ----
         = 29      = Termination-Action         =      2865
         = 41      = Acct-Delay-Time         &nb= sp;       2866
         = 51      = Acct-Link-Count         &nb= sp;       2866
         = 55      = Event-Timestamp         &nb= sp;       2869
         = 78      = Configuration-Token         = ;    2869
         = 85      = Acct-Interim-Interval        &nb= sp;  2869
         = 87      = NAS-Port-Id          &= nbsp;          2869
         = 88      = Framed-Pool          &= nbsp;          2869
         = 95      = NAS-IPv6-Address         &n= bsp;      3162
         = 98      = Login-IPv6-Host         &nb= sp;       3162

    Note: These AVPs were not added to = nasreq-09, so this issue
requires
    more work in nasreq.


Requested change:

    Add these attributes to nasreq as = Diameter AVPs.

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use = <http://www.pgp.com>

iQA/AwUBPIPwIzN1fXKoxmisEQLulwCeLwV+vxIEowM8zPnYtFZexYQAnNUAnRU= G
n3NEsOTkwIKo9GyDwiPSu9Cd
=3DFzMY
-----END PGP SIGNATURE-----

------_=_NextPart_001_01C1C3C8.FB021DE0-- From owner-aaa-wg@merit.edu Mon Mar 4 17:10:30 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26624 for ; Mon, 4 Mar 2002 17:10:29 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D77269122B; Mon, 4 Mar 2002 17:10:18 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AE41C9122C; Mon, 4 Mar 2002 17:10:17 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5CBEC9122B for ; Mon, 4 Mar 2002 17:10:16 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3A3CF5DDD2; Mon, 4 Mar 2002 17:10:16 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id B30E15DDCC for ; Mon, 4 Mar 2002 17:10:15 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g24LTNM09062; Mon, 4 Mar 2002 13:29:23 -0800 Date: Mon, 4 Mar 2002 13:29:23 -0800 (PST) From: Bernard Aboba To: "Pat R. Calhoun" Cc: "'David Spence'" , AAA Working Group Subject: RE: [AAA-WG]: [issue] New NASREQ AVPs In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > Note that some of these had been intentionally left out because they > made no sense for Diameter. Which ones? Why didn't they make sense? > CODE NAME RFC > ---- ---- ---- > 29 Termination-Action 2865 > 41 Acct-Delay-Time 2866 > 51 Acct-Link-Count 2866 > 55 Event-Timestamp 2869 > 78 Configuration-Token 2869 > 85 Acct-Interim-Interval 2869 > 87 NAS-Port-Id 2869 > 88 Framed-Pool 2869 > 95 NAS-IPv6-Address 3162 > 98 Login-IPv6-Host 3162 From owner-aaa-wg@merit.edu Mon Mar 4 17:13:56 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26895 for ; Mon, 4 Mar 2002 17:13:56 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7C9C891230; Mon, 4 Mar 2002 17:13:42 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4C9B191231; Mon, 4 Mar 2002 17:13:42 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5295491230 for ; Mon, 4 Mar 2002 17:13:41 -0500 (EST) Received: by segue.merit.edu (Postfix) id 35F755DDD2; Mon, 4 Mar 2002 17:13:41 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 219015DDCC for ; Mon, 4 Mar 2002 17:13:41 -0500 (EST) Received: from Interlinknetworks.com (nat.interlinknetworks.com [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with ESMTP id E20476C for ; Mon, 4 Mar 2002 17:13:40 -0500 (EST) Message-ID: <3C83F19C.49C74123@Interlinknetworks.com> Date: Mon, 04 Mar 2002 17:13:48 -0500 From: David Spence Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: AAA Working Group Subject: [AAA-WG]: [issue] Possible new AVP for MobileIPv4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Subject: [issue] Possible new AVP for MobileIPv4 Submitter name: David Spence Submitter email address: DSpence@Interlinknetworks.com Date first submitted: March 4, 2002 Reference: Document: MobileIPv4 Comment type: T Priority: 2 Section: Rationale/Explanation of issue: The following attribute is defined in RADIUS for use in accounting messages. It might be useful in the MobileIPv4 application. CODE NAME RFC ---- ---- ---- 55 Event-Timestamp 2869 Requested change: Consider adding this attribute to MobileIPv4 as a Diameter AVP. Note: This AVP will need to be defined in NASREQ for RADIUS compatibility. See issue TBA. -- David Spence email: DSpence@Interlinknetworks.com Interlink Networks, Inc. phone: (734) 821-1203 775 Technology Drive, Suite 200 fax: (734) 821-1235 Ann Arbor, MI 48108 U.S.A. From owner-aaa-wg@merit.edu Mon Mar 4 17:15:01 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27011 for ; Mon, 4 Mar 2002 17:15:01 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 205DB91231; Mon, 4 Mar 2002 17:14:47 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E69CF91232; Mon, 4 Mar 2002 17:14:46 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2FB4091231 for ; Mon, 4 Mar 2002 17:14:45 -0500 (EST) Received: by segue.merit.edu (Postfix) id 146465DDD2; Mon, 4 Mar 2002 17:14:45 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from EXCHSRV.stormventures.com (unknown [65.107.25.226]) by segue.merit.edu (Postfix) with ESMTP id BA0985DDCC for ; Mon, 4 Mar 2002 17:14:44 -0500 (EST) Received: by EXCHSRV.stormventures.com with Internet Mail Service (5.5.2653.19) id <1QP7SHK4>; Mon, 4 Mar 2002 14:14:44 -0800 Message-ID: From: "Pat R. Calhoun" To: "'Bernard Aboba'" Cc: "'David Spence'" , AAA Working Group Subject: RE: [AAA-WG]: [issue] New NASREQ AVPs Date: Mon, 4 Mar 2002 14:14:43 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1C3C9.FC5D99C0" Sender: owner-aaa-wg@merit.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1C3C9.FC5D99C0 Content-Type: text/plain -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Unfortunately, I don't have that info in front of me, but an example is the Terminate-Action. This is a way for the server to inform the NAS how to behave when the session is terminated. Diameter has specific ways of asking for re-auth and/or to be requested when a session is terminated. So for each we must evaluate whether they are needed or not. PatC - -----Original Message----- From: Bernard Aboba [mailto:aboba@internaut.com] Sent: Monday, March 04, 2002 1:29 PM To: Pat R. Calhoun Cc: 'David Spence'; AAA Working Group Subject: RE: [AAA-WG]: [issue] New NASREQ AVPs > Note that some of these had been intentionally left out because > they made no sense for Diameter. Which ones? Why didn't they make sense? > CODE NAME RFC > ---- ---- ---- > 29 Termination-Action 2865 > 41 Acct-Delay-Time 2866 > 51 Acct-Link-Count 2866 > 55 Event-Timestamp 2869 > 78 Configuration-Token 2869 > 85 Acct-Interim-Interval 2869 > 87 NAS-Port-Id 2869 > 88 Framed-Pool 2869 > 95 NAS-IPv6-Address 3162 > 98 Login-IPv6-Host 3162 -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 7.0.3 for non-commercial use iQA/AwUBPIPx0zN1fXKoxmisEQK53wCcCguW/5118kB9I/azfCxGQM+i0asAnRWz Pb2Rve8sGowSKlS8/dm1REeH =9f13 -----END PGP SIGNATURE----- ------_=_NextPart_001_01C1C3C9.FC5D99C0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [AAA-WG]: [issue] New NASREQ AVPs

 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Unfortunately, I don't have that info in front of me, = but an example
is the Terminate-Action. This is a way for the = server to inform the
NAS how to behave when the session is terminated. = Diameter has
specific ways of asking for re-auth and/or to be = requested when a
session is terminated.

So for each we must evaluate whether they are needed = or not.

PatC

- -----Original Message-----
From: Bernard Aboba [mailto:aboba@internaut.com] =
Sent: Monday, March 04, 2002 1:29 PM
To: Pat R. Calhoun
Cc: 'David Spence'; AAA Working Group
Subject: RE: [AAA-WG]: [issue] New NASREQ = AVPs


> Note that some of these had been intentionally = left out because
> they  made no sense for Diameter.

Which ones? Why didn't they make sense?

>        = CODE      = NAME           &n= bsp;           &n= bsp;    RFC
>        = ----      = ----           &n= bsp;           &n= bsp;    ----
>          = 29      = Termination-Action         =      2865
>          = 41      = Acct-Delay-Time         &nb= sp;       2866
>          = 51      = Acct-Link-Count         &nb= sp;       2866
>          = 55      = Event-Timestamp         &nb= sp;       2869
>          = 78      = Configuration-Token         = ;    2869
>          = 85      = Acct-Interim-Interval        &nb= sp;  2869
>          = 87      = NAS-Port-Id          &= nbsp;          2869
>          = 88      = Framed-Pool          &= nbsp;          2869
>          = 95      = NAS-IPv6-Address         &n= bsp;      3162
>          = 98      = Login-IPv6-Host         &nb= sp;       3162

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use = <http://www.pgp.com>

iQA/AwUBPIPx0zN1fXKoxmisEQK53wCcCguW/5118kB9I/azfCxGQM+i0asAnRW= z
Pb2Rve8sGowSKlS8/dm1REeH
=3D9f13
-----END PGP SIGNATURE-----

------_=_NextPart_001_01C1C3C9.FC5D99C0-- From owner-aaa-wg@merit.edu Mon Mar 4 17:18:13 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27187 for ; Mon, 4 Mar 2002 17:18:12 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id BA83C91232; Mon, 4 Mar 2002 17:18:05 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8A91991233; Mon, 4 Mar 2002 17:18:05 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 579AD91232 for ; Mon, 4 Mar 2002 17:18:04 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3366B5DDE2; Mon, 4 Mar 2002 17:18:04 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from fep03-svc.swip.net (fep03.swip.net [130.244.199.131]) by segue.merit.edu (Postfix) with ESMTP id 6524D5DDCC for ; Mon, 4 Mar 2002 17:18:03 -0500 (EST) Received: from ipunplugged.com ([213.100.60.212]) by fep03-svc.swip.net with ESMTP id <20020304221749.RJDH16920.fep03-svc.swip.net@ipunplugged.com>; Mon, 4 Mar 2002 23:17:49 +0100 Message-ID: <3C8400C7.4090602@ipunplugged.com> Date: Mon, 04 Mar 2002 23:18:31 +0000 From: Johan Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226 X-Accept-Language: en-us MIME-Version: 1.0 To: David Spence Cc: AAA Working Group Subject: Re: [AAA-WG]: [issue] Possible new AVP for MobileIPv4 References: <3C83F19C.49C74123@Interlinknetworks.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit David Spence wrote: >Subject: [issue] Possible new AVP for MobileIPv4 > >Submitter name: David Spence >Submitter email address: DSpence@Interlinknetworks.com >Date first submitted: March 4, 2002 >Reference: >Document: MobileIPv4 >Comment type: T >Priority: 2 >Section: >Rationale/Explanation of issue: > > The following attribute is defined in RADIUS for use in accounting > messages. It might be useful in the MobileIPv4 application. > > CODE NAME RFC > ---- ---- ---- > 55 Event-Timestamp 2869 > >Requested change: > > Consider adding this attribute to MobileIPv4 as a Diameter AVP. > > Note: This AVP will need to be defined in NASREQ for RADIUS > compatibility. See issue TBA. > I'm in favour anyway. If nowhere else it is useful when sending records left on the access device due to crashes or network failures. j From owner-aaa-wg@merit.edu Mon Mar 4 17:34:57 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28174 for ; Mon, 4 Mar 2002 17:34:57 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 509EA91233; Mon, 4 Mar 2002 17:34:46 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2ABB891238; Mon, 4 Mar 2002 17:34:46 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 38CD991233 for ; Mon, 4 Mar 2002 17:34:45 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9F7135DE28; Mon, 4 Mar 2002 17:34:43 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 8C0245DDE2 for ; Mon, 4 Mar 2002 17:34:43 -0500 (EST) Received: from Interlinknetworks.com (nat.interlinknetworks.com [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with ESMTP id 130316C for ; Mon, 4 Mar 2002 17:34:43 -0500 (EST) Message-ID: <3C83F68A.F2354E0@Interlinknetworks.com> Date: Mon, 04 Mar 2002 17:34:50 -0500 From: David Spence Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: AAA Working Group Subject: [AAA-WG]: [issue] NASREQ-specific values for Termination-Cause AVP Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Subject: [issue] NASREQ-specific values for Termination-Cause AVP Submitter name: David Spence Submitter email address: DSpence@Interlinknetworks.com Date first submitted: March 4, 2002 Reference: Document: NASREQ Comment type: T Priority: S Section: Rationale/Explanation of issue: The RADIUS Acct-Terminate-Cause attribute (#49) is superseded in Diameter by the Termination-Cause AVP (#295). However, there are many values defined for Acct-Terminate-Cause that have no counterpart in Termination-Cause. Many of these values are nasreq-specific. Requested change: Define addional values in nasreq for the base draft's Termination-Cause AVP to cover the semantics of the RADIUS Acct-Terminate-Cause attribute. Ensure that all values for Acct-Terminate-Cause listed in IANA's radius-types.txt are covered. Specify the mapping between the Acct-Terminate-Cause values and the Termination-Cause values so that a RADIUS/Diameter gateway can translate between them. From owner-aaa-wg@merit.edu Mon Mar 4 17:58:43 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29086 for ; Mon, 4 Mar 2002 17:58:43 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id F218D91238; Mon, 4 Mar 2002 17:58:34 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C82F39123C; Mon, 4 Mar 2002 17:58:33 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DA4BF91238 for ; Mon, 4 Mar 2002 17:58:32 -0500 (EST) Received: by segue.merit.edu (Postfix) id BF7D55DDDA; Mon, 4 Mar 2002 17:58:32 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 76E485DE2D for ; Mon, 4 Mar 2002 17:58:32 -0500 (EST) Received: from Interlinknetworks.com (nat.interlinknetworks.com [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with ESMTP id 86E557A; Mon, 4 Mar 2002 17:58:13 -0500 (EST) Message-ID: <3C83FC0C.649E229B@Interlinknetworks.com> Date: Mon, 04 Mar 2002 17:58:20 -0500 From: David Spence Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Pat R. Calhoun" Cc: "'Bernard Aboba'" , AAA Working Group Subject: Re: [AAA-WG]: [issue] New NASREQ AVPs References: Content-Type: multipart/mixed; boundary="------------847A285C7E5A13AB1D9B9C25" Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. --------------847A285C7E5A13AB1D9B9C25 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I'm really not sure you're correct here. It is certainly possible that some of the AVPs in my list are not needed, but I sure would like an explanation for each one. This includes Termination-Action. The Termination-Action AVP is primarily for use with the Login service. It allows the AAA server to tell the NAS whether to drop the connection to the user when the connection to the host goes down or whether to prompt the user for a new destination instead. This could be accomplished in Diameter by sending a request for reauthentication and reauthorization. The trouble is, I don't know how to signal the semantics of the Termination-Action AVP to the NAS in the original AA-Answer message. I will grant that a number of RADIUS attributes MUST NOT appear in Diameter messages. My list of these is as follows, although, again I could be mistaken on one or two. CODE NAME RADIUS ------ ---- ------ 3 CHAP-Password RFC 2865 26 Vendor-Specific RFC 2865 40 Acct-Status-Type RFC 2866 42 Acct-Input-Octets RFC 2866 43 Acct-Output-Octets RFC 2866 47 Acct-Input-Packets RFC 2866 48 Acct-Output-Packets RFC 2866 49 Acct-Terminate-Cause RFC 2866 52 Acct-Input-Gigawords RFC 2869 53 Acct-Output-Gigawords RFC 2869 80 Message-Authenticator RFC 2869 So could you look over the list from my issue rather carefully and set me straight if any of them really are not needed? > "Pat R. Calhoun" wrote: > > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Unfortunately, I don't have that info in front of me, but an example > is the Terminate-Action. This is a way for the server to inform the > NAS how to behave when the session is terminated. Diameter has > specific ways of asking for re-auth and/or to be requested when a > session is terminated. > > So for each we must evaluate whether they are needed or not. > > PatC > > - -----Original Message----- > From: Bernard Aboba [mailto:aboba@internaut.com] > Sent: Monday, March 04, 2002 1:29 PM > To: Pat R. Calhoun > Cc: 'David Spence'; AAA Working Group > Subject: RE: [AAA-WG]: [issue] New NASREQ AVPs > > > Note that some of these had been intentionally left out because > > they made no sense for Diameter. > > Which ones? Why didn't they make sense? > > > CODE NAME RFC > > ---- ---- ---- > > 29 Termination-Action 2865 > > 41 Acct-Delay-Time 2866 > > 51 Acct-Link-Count 2866 > > 55 Event-Timestamp 2869 > > 78 Configuration-Token 2869 > > 85 Acct-Interim-Interval 2869 > > 87 NAS-Port-Id 2869 > > 88 Framed-Pool 2869 > > 95 NAS-IPv6-Address 3162 > > 98 Login-IPv6-Host 3162 > > -----BEGIN PGP SIGNATURE----- > Version: PGPfreeware 7.0.3 for non-commercial use > > iQA/AwUBPIPx0zN1fXKoxmisEQK53wCcCguW/5118kB9I/azfCxGQM+i0asAnRWz > Pb2Rve8sGowSKlS8/dm1REeH > =9f13 > -----END PGP SIGNATURE----- --------------847A285C7E5A13AB1D9B9C25 Content-Type: text/x-vcard; charset=us-ascii; name="DSpence.vcf" Content-Description: Card for David Spence Content-Disposition: attachment; filename="DSpence.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:; tel;fax:+1 734 821 1235 tel;work:+1 734 821 1203 x-mozilla-html:FALSE url:http://www.interlinknetworks.com org:Interlink Networks, Inc. adr:;;775 Technology Dr., Suite 200;Ann Arbor;MI;48108;USA version:2.1 email;internet:DSpence@Interlinknetworks.com title:Architect fn:David Spence end:vcard --------------847A285C7E5A13AB1D9B9C25-- From owner-aaa-wg@merit.edu Mon Mar 4 19:32:44 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01577 for ; Mon, 4 Mar 2002 19:32:44 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 70F0991209; Mon, 4 Mar 2002 19:32:13 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 38BD59122D; Mon, 4 Mar 2002 19:32:13 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4D90A91209 for ; Mon, 4 Mar 2002 19:32:10 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2D7425DDDF; Mon, 4 Mar 2002 19:32:10 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by segue.merit.edu (Postfix) with ESMTP id A771C5DE39 for ; Mon, 4 Mar 2002 19:32:09 -0500 (EST) Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g250Xcx21488 for ; Mon, 4 Mar 2002 18:33:38 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 4 Mar 2002 18:31:30 -0600 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 4 Mar 2002 18:30:21 -0600 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Subject: [AAA-WG]: FW: I-D ACTION:draft-le-aaa-mipv6-requirements-00.txt Date: Mon, 4 Mar 2002 18:30:21 -0600 Message-ID: <57A26D272F67A743952F6B4371B8F8119AD4A9@daebe007.NOE.Nokia.com> Thread-Topic: [AAA-WG]: [issue] New NASREQ AVPs Thread-Index: AcHD0CswXr4cVk5wRzaej8U75917tgADG62w From: To: X-OriginalArrivalTime: 05 Mar 2002 00:30:21.0844 (UTC) FILETIME=[EF521540:01C1C3DC] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id TAA01577 A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Mobile IPv6 Authentication, Authorization, and Accounting Requirements Author(s) : S. Faccin et al. Filename : draft-le-aaa-mipv6-requirements-00.txt Pages : 14 Date : 26-Feb-02 This document describes the motivation why Diameter support for Mobile IPv6 is required and needs to be developped. It analyses the requirements expressed in RFC 2977 which was written both for MIPv4 and MIPv6; and it finally updates the IPv6 requirements for the AAA support for Mobile IPv6 to reflect the latest modifications and evolution of the Mobile IP, AAA and other relevant working groups. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-le-aaa-mipv6-requirements-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-le-aaa-mipv6-requirements-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-le-aaa-mipv6-requirements-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. From owner-aaa-wg@merit.edu Mon Mar 4 19:44:37 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02128 for ; Mon, 4 Mar 2002 19:44:37 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 258979123E; Mon, 4 Mar 2002 19:44:27 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EDCA491241; Mon, 4 Mar 2002 19:44:26 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 07A199123E for ; Mon, 4 Mar 2002 19:44:26 -0500 (EST) Received: by segue.merit.edu (Postfix) id E32F65DE3B; Mon, 4 Mar 2002 19:44:25 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 6A3D95DDDF for ; Mon, 4 Mar 2002 19:44:25 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g25042K17781 for ; Mon, 4 Mar 2002 16:04:02 -0800 Date: Mon, 4 Mar 2002 16:04:02 -0800 (PST) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: Updated AAA WG Agenda for IETF 53 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Authentication, Authorization and Accounting WG (AAA) Thursday, March 21,2002 at 1300-1500 ==================================== CHAIRS: Bernard Aboba David Mitton Agenda: 1. Preliminaries (5 minutes) Agenda Bashing Blue sheets Minute takers Document status WG Last Call Summary 2. Connectathon Update (David Frascone, 5 minutes) 3. Diameter Base (John Loughney, 10 minutes) http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-10.txt 4. Mobile IP (Tony Johansson, 10 minutes) http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-mobileip-09.txt 5. CMS (Pat Calhoun, 10 minutes) http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-cms-04.txt 6. Transport (Bernard Aboba, 10 minutes) http://www.ietf.org/internet-drafts/draft-ietf-aaa-transport-05.txt 7. NASREQ (David Spence & David Mitton, 10 minutes) http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-nasreq-09.txt 8. Security issues with the NASREQ Keying Attributes (Jesse Walker, 10 minutes) 9. Mobile IPv6 AAA Requirements (Franck Le, 5 minutes) http://www.ietf.org/internet-drafts/draft-le-aaa-mipv6-requirements-00.txt 10. Diameter Multimedia application (Tony Johansson, 5 minutes) http://www.ietf.org/internet-drafts/draft-johansson-aaa-diameter-mm-app-01.txt 11. Roadmap (Bernard Aboba & ADs, 5 minutes) From owner-aaa-wg@merit.edu Mon Mar 4 19:59:12 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02428 for ; Mon, 4 Mar 2002 19:59:12 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3143291234; Mon, 4 Mar 2002 19:59:02 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EF5689123C; Mon, 4 Mar 2002 19:59:01 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D6CC291234 for ; Mon, 4 Mar 2002 19:59:00 -0500 (EST) Received: by segue.merit.edu (Postfix) id B66225DDDF; Mon, 4 Mar 2002 19:59:00 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 77B085DDD1 for ; Mon, 4 Mar 2002 19:59:00 -0500 (EST) Received: from bkopacz98 (bgp01023602bgs.sanarb01.mi.comcast.net [68.40.81.246]) by aaa.interlinknetworks.com (Postfix) with SMTP id BDD3E6C; Mon, 4 Mar 2002 19:58:59 -0500 (EST) Message-ID: <000901c1c3e0$ebc60b80$f6512844@sanarb01.mi.comcast.net> From: "Bob Kopacz" To: "Tony Johansson" Cc: "aaa-wg" Subject: [AAA-WG]: [issue] Minor corrections to mobileip-09 Date: Mon, 4 Mar 2002 19:58:53 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Tony, Issue : Minor corrections to mobileip-09 Submitter name: Bob Kopacz Submitter email address:bkopacz@interlinknetworks.com Date first submitted: 03-04-2002 Reference: Document: draft-mobileip-09 Comment type: Technical Priority: 1 Section: Rationale/Explanation of issue: Minor editing corrections. Requested change: - - - The NASREQ draft has a section "Legacy RADIUS Attributes" with text along the lines of "The Diameter protocol reserves the AVP Codes 0-255 for "legacy RADIUS" support. The following table contains the RADIUS attributes supported by this Diameter application, their AVP code values, types, possible flag values and whether the AVP MAY be encrypted. RADIUS attributes not listed are not supported by the Diameter protocol." After section 4.0 Mandatory AVPs, create a similar section 4.1 which says something like the following (to indicate the subset of RADIUS attributes a Diameter Mobile-IP client/server requires in its dictionary): > 4.1 Supported Legacy RADIUS Attributes > > The Diameter protocol reserves the AVP Codes 0-255 for "legacy RADIUS" > support. The base protocol defines the RADIUS attributes User-Name, > Session-Timeout, Acct-Session-Time, Acct-Multi-Session-Id, Proxy-State, > and Class, all supported by this Diameter application. This application > supports these RADIUS attributes and no others. - - - In section 4.3 MIP-Mobile-Node-Address AVP > The Mobile-Node-Address AVP (AVP Code 333) is of type IPAddress and ^^^^^^^^^^^^^^^^^^^ Change to "MIP-Mobile-Node-Address" - - - In section 4.4 MIP-Home-Agent-Address AVP > The Home-Agent-Addess AVP (AVP Code 334) is of type IPAddress and ^^^^^^^^^^^^^^^^^ Change to "MIP-Home-Agent-Address" - - - In section 4.5 MIP-Feature-Vector AVP > Whenever the Foreign Agent sets either the Mobile-Node-Home-Address- > Requested flag or the Home-Agent-Request flag to one, it MUST set the ^^^^^^^^^^^^^^^^^^ Change to "Home-Agent-Requested" - - - In the following, move the 5.5.1 section header down by one paragraph, i.e. Change: > 5.5 Distributing the Foreign-Home Session Key > > 5.5.1 Home Agent in the home network > > If the home agent is in the home realm, then the AAAH has to generate > the Foreign-Home session key. Otherwise, it is generated by the AAAF. > > In the cases when the AAAH generates the Foreign-Home session key, > ... To: > 5.5 Distributing the Foreign-Home Session Key > > If the home agent is in the home realm, then the AAAH has to generate > the Foreign-Home session key. Otherwise, it is generated by the AAAF. > > 5.5.1 Home Agent in the home network > > In the cases when the AAAH generates the Foreign-Home session key, > ... - - - In section 6.6 MIP-MN-to-HA-Key AVP > * [ AVP ].fi Remove ".fi" - - - In section 11.1 Normative References > [DIAMBASE] P. Calhoun, H. Akhtar, J. Arkko, E. Guttman, A. Rubens, > "Diameter Base Protocol", draft-ietf-aaa-diameter-08.txt, > IETF work in progress, November 2001. Change to draft-10 (or maybe draft-11 for the next revision) > [MOBILEIP] C. Perkins, Editor. IP Mobility Support. > RFC 2002, October 1996. RFC2002 has been obsoleted by RFC3220, January 2002. > [CMS] P. Calhoun, W. Bulley, S. Farrell, "Diameter CMS Security > Application", draft-ietf-aaa-diameter-cms-sec-03.txt, > IETF work in progress, November 2001. Change to draft-ietf-aaa-diameter-cms-04.txt (or maybe -05 for next revision) > [MIPKEYS] C. Perkins, P. Calhoun, "AAA Registration Keys for Mobile > IP", draft-ietf-mobileip-aaa-key-08.txt, IETF work in > progress, July 2001. The above has expired, but key-09, 26 February 2002, is out. From owner-aaa-wg@merit.edu Mon Mar 4 23:20:14 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08673 for ; Mon, 4 Mar 2002 23:20:14 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 85A4E9122D; Mon, 4 Mar 2002 23:20:01 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5BB3F91235; Mon, 4 Mar 2002 23:20:01 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 453589122D for ; Mon, 4 Mar 2002 23:20:00 -0500 (EST) Received: by segue.merit.edu (Postfix) id 25B695DE3E; Mon, 4 Mar 2002 23:20:00 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 10E6A5DDD1 for ; Mon, 4 Mar 2002 23:20:00 -0500 (EST) Received: from bkopacz98 (bgp01023602bgs.sanarb01.mi.comcast.net [68.40.81.246]) by aaa.interlinknetworks.com (Postfix) with SMTP id 901147A; Mon, 4 Mar 2002 23:19:59 -0500 (EST) Message-ID: <000701c1c3fc$ff09ece0$f6512844@sanarb01.mi.comcast.net> From: "Bob Kopacz" To: "Tony Johansson" Cc: "aaa-wg" Subject: [AAA-WG]: [issue] Need more explanation about handling MN handoffs Date: Mon, 4 Mar 2002 23:19:50 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Issue : Need more explanation about handling MN handoffs Submitter name: Bob Kopacz Submitter email address:bkopacz@interlinknetworks.com Date first submitted: 03-04-2002 Reference: Document: draft-mobileip-09 Comment type: Technical Priority: 1 Section: Rationale/Explanation of issue: I may be missing something significant here, but ... This issue has to do with how an AAAF and AAAH, when given a Home Agent's IP address, derive the domain/realm/DiameterIdentity information needed by the Diameter AAA servers. This issue may also have some bearing on the relationship between a DiameterIdentity and a FQDN. Unfortunately I don't have a good solution to present, so I'm indicating what the problems are, as indicated by "-->". It may be that the solution is to enhance the Mobile IP protocol to provide more information in the Registration Request. THE AAAF's PROBLEM: ------------------ Section 1.4. Allocation of Home Agent in Foreign Network, says the following: > 1.4 Allocation of Home Agent in Foreign Network > > [...] > > In the event that the mobile node requests a home agent in the > foreign network, and the AAAF authorizes its use, the AAAF MUST set > the Home-Agent-In-Foreign-Network bit in the MIP-Feature-Vector AVP. > This could happen when the AAA request is sent to "extend" a mobile > node's current session. > -->(1) I think some text needs to be added to describe how the AAAF determines if the HA is in a foreign network. That is, I am guessing the method is along these lines: Suppose a MN initially connects, is allocated an HA, and later undergoes a handoff to a new FA and new AAAF. Depending on the MN's new point of attachment, the new FA and AAAF may or may not be in the same foreign domain as before, or the foreign domain may be same but the AAAFs are different, or the handoff may involve the same AAAF as before. In the AMR, the new AAAF is provided with the MN user's NAI and the HA's IP address. Say the MN user is "bob@donut.com" and the specified HA IP address is 1.2.3.4. The new AAAF does a reverse DNS lookup of tbe HA's IP address, 1.2.3.4, and the DNS response is that IP address 1.2.3.4 corresponds to an FQDN of "homeagent86.westcoast.spinach.com". Now the AAAF extracts the realm part of the NAI, "donut.com", and pre-pends a dot, coming up with ".donut.com". The AAAF then checks if this ".donut.com" string is a trailing substring of the "homeagent86.westcoast.spinach.com" FQDN. It isn't, so the AAAF concludes the HA is in a foreign network and sends the Home-Agent-In-Foreign-Network flag with a value of one. If the tail of the FQDN matched ".donut.com", the AAAF would conclude the HA was in the home network. -->(2) This may or may not be anywhere close to the AAAF's method. At any rate, the method should be described in sufficient detail for an AAAF implementation. -->(3) If this DNS reverse lookup is indeed the AAAF's method to make this "home-agent-is-in-a-foreign-network" determination, then this introduces a delay into the handoff, and should probably be noted. THE AAAH's PROBLEM ------------------ Section 1.2 Inter-Realm Mobile IP, says the following: > > 1.2 Inter-Realm Mobile IP > > [...] > > If the Mobile Node was successfully authenticated, the AAAH checks if > the Home Agent was located in the foreign realm, by checking the > Home-Agent-In-Foreign-Network flag of the MIP-Feature-Vector AVP. If > the flag is enabled, then the Home Agent is located in the foreign > realm then AAAH sends an HAR message to AAAF which contains a MIP- > Reg-Request AVP. Continuing the example, suppose the AAAF has determined that the HA is in a foreign network, and has forwarded the AMR to the home realm. The AAAH receives the AMR, and the AMR indicates the HA's address is 1.2.3.4, the Home-Agent-In-Foreign-Network flag is ON, and the User-Name is "bob@donut.com". -->(4) Now the AAAH wants to send an HAR to the HA. But Diameter routes by Destination-Realm and Destination-Host, not by IP address, so the AAAH has to somehow come up with the HA's DiameterIdentity for the Destination-Host AVP of the HAR, and the HA's realm for the Destination-Realm of the HAR. AAAH's 1st Problem: How to discover the HA's DiameterIdentity: If the AAAH maintains session-state, then this HA identity information can be part of the cached session-state information, and there may be no problem. But there is a problem if either (a) the AAAH is not session-stateful, or (b) the AAAH is session-stateful but has no session-state info because the handoff AMR is received by a different AAAH than the AAAH which received the original AMR for the session. So if we have case (a) or (b), the hapless AAAH is holding the HA's IP address, and needs to come up with the HA's realm and DiameterIdentity. The method might be along these lines: The AAAH can do a reverse lookup of the IP address 1.2.3.4, and again DNS returns an FQDN of "homeagent86.westcoast.spinach.com" *If* the DiameterIdentity is the same as the FQDN, then the AAAH constructs the HAR's Destination-Host = "homeagent86.westcoast.spinach.com". (An aside: I haven't kept up with the recent DiameterIdentity thread, but I thought the DiameterIdentity needed to be something like "FQDN+extra", so that multiple Diameter applications could run on the same box. In which case the FQDN isn't sufficient). AAAH's 2nd Problem: How to discover the HA's Realm: The AAAH still needs to derive the HAR's Destination-Realm, from the FQDN. The realm is probably either "westcoast.spinach.com" or "spinach.com". Does the AAAH have a way to know for sure, or is the best-guess algorithm to say that the realm is what follows the next-to-last dot of the FQDN, e.g. "spinach.com". -->(5) Again, this may or may not be anywhere close to what the AAAH needs to do to surmise the HA's realm and identity. At any rate, the method should be described in sufficient detail to implement an AAAH. -->(6) If this DNS reverse lookup is indeed part of the AAAH's method, then this introduces a delay (maybe a 2nd delay depending on what the AAAF had to do) into the handoff, and should probably be noted. -->(7) It seems the AAAF and AAAH are both starting from scratch with the HA's IP address, and duplicating efforts and delays. Maybe the AAAF's DNS-lookup results (or whatever useful knowledge the AAAF possesses) could be passed along to the AAAH. From owner-aaa-wg@merit.edu Tue Mar 5 01:23:50 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10579 for ; Tue, 5 Mar 2002 01:23:49 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id C8AAE9121E; Tue, 5 Mar 2002 01:23:35 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9691C9123F; Tue, 5 Mar 2002 01:23:35 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A6B1B9121E for ; Tue, 5 Mar 2002 01:23:34 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8A0FA5DDC6; Tue, 5 Mar 2002 01:23:34 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 1583C5DD94 for ; Tue, 5 Mar 2002 01:23:34 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g255h7Q03911; Mon, 4 Mar 2002 21:43:07 -0800 Date: Mon, 4 Mar 2002 21:43:07 -0800 (PST) From: Bernard Aboba To: aaa-wg@merit.edu Cc: jesse.walker@intel.com Subject: [AAA-WG]: Re: Why NASREQ Key Distribution is insecure (fwd) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Here is a paper by Bellare and Rogaway paper on provably secure 3 way key distribution which may relate to this issue. http://www.drizzle.com/~aboba/AAA/3pkd.pdf On Mon, 4 Mar 2002, Bernard Aboba wrote: > This is followup documentation on the issue posted to the list > earlier. > > --------------------------------------------------------------------- > From: Jesse Walker : > To: eap@frascone.com > > > >Given that the AS and AP trust each other (assumed), why > >is a reasonable cryptographic protocol (such as CMS or even IPSec) is > >insufficient to protect the transfer of a STA-AP session key from the AS to > >the AP? > > There has been in fact ample discussion around exactly these points. There > is, for instance, the whole key handoff discussion, of which AS-AP handoff > is a special case. As a second example, there is the flap around the > Arbaugh-Mishra 802.1X paper, which echos many of our key handoff > discussions, and which we have also discussed. From owner-aaa-wg@merit.edu Tue Mar 5 06:06:40 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23035 for ; Tue, 5 Mar 2002 06:06:40 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id ADD1A91241; Tue, 5 Mar 2002 06:06:28 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6D70391243; Tue, 5 Mar 2002 06:06:28 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 50FCE91241 for ; Tue, 5 Mar 2002 06:06:27 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2B4155DE4C; Tue, 5 Mar 2002 06:06:27 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by segue.merit.edu (Postfix) with ESMTP id 7011F5DDF8 for ; Tue, 5 Mar 2002 06:06:26 -0500 (EST) Received: from ipunplugged.com (catsandlogs.local.ipunplugged.com [192.168.4.29]) by mailgw.ipunplugged.com (8.9.3/8.9.3) with ESMTP id MAA17650; Tue, 5 Mar 2002 12:03:50 +0100 Message-ID: <3C84B497.7080706@ipunplugged.com> Date: Tue, 05 Mar 2002 13:05:43 +0100 From: Johan Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020204 X-Accept-Language: en-us MIME-Version: 1.0 To: Bob Kopacz Cc: Tony Johansson , aaa-wg Subject: Re: [AAA-WG]: [issue] Need more explanation about handling MN handoffs References: <000701c1c3fc$ff09ece0$f6512844@sanarb01.mi.comcast.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Bob Kopacz wrote: >In the AMR, the new AAAF is provided with the MN user's NAI and the > HA's IP address. Say the MN user is "bob@donut.com" and the specified > HA IP address is 1.2.3.4. > > The new AAAF does a reverse DNS lookup of tbe HA's IP address, > 1.2.3.4, and the DNS response is that IP address 1.2.3.4 corresponds > to an FQDN of "homeagent86.westcoast.spinach.com". > > Now the AAAF extracts the realm part of the NAI, "donut.com", and > pre-pends a dot, coming up with ".donut.com". The AAAF then checks > if this ".donut.com" string is a trailing substring of the > "homeagent86.westcoast.spinach.com" FQDN. It isn't, so the AAAF > concludes the HA is in a foreign network and sends the > Home-Agent-In-Foreign-Network flag with a value of one. If the tail > of the FQDN matched ".donut.com", the AAAF would conclude the HA was > in the home network. > Is this the intended interpretation of piggybacked in Realm The string in the NAI that immediately follows the '@' character. NAI realm names are required to be unique, and are piggybacked on the administration of the DNS namespace. This has rather important consequences for what configurations of realms and nais would be legal. >-->(3) If this DNS reverse lookup is indeed the AAAF's method to > make this "home-agent-is-in-a-foreign-network" determination, then > this introduces a delay into the handoff, and should probably be > noted. > The last time this matter was discussed our mobile ip implementers disliked the idea for the very same reason and I thought I sent a message to the list about it but I can't seem to locate it in the archive so I guess I didn't. >(a) the AAAH is not session-stateful, or (b) the AAAH is > session-stateful but has no session-state info because the handoff > AMR is received by a different AAAH than the AAAH which received > the original AMR for the session. > > So if we have case (a) or (b), the hapless AAAH is holding the HA's > IP address, and needs to come up with the HA's realm and > DiameterIdentity. The method might be along these lines: > > The AAAH can do a reverse lookup of the IP address 1.2.3.4, and > again DNS returns an FQDN of "homeagent86.westcoast.spinach.com" > > *If* the DiameterIdentity is the same as the FQDN, then the AAAH > constructs the HAR's Destination-Host = > "homeagent86.westcoast.spinach.com". (An aside: I haven't kept up > with the recent DiameterIdentity thread, but I thought the > DiameterIdentity needed to be something like "FQDN+extra", so that > multiple Diameter applications could run on the same box. In > which case the FQDN isn't sufficient). > Draft 10 states FQDN only but does not state that it needs to be registered in DNS as was stated at least at some time during the discussion. The idea is to use aliasing if I recall correctly so that each process could use its own FQDN. Even if it is indeed registered in DNS, which seems likely in a production system, I'm not quite sure how you could tell which identity to use. >AAAH's 2nd Problem: How to discover the HA's Realm: > > The AAAH still needs to derive the HAR's Destination-Realm, from > the FQDN. The realm is probably either "westcoast.spinach.com" > or "spinach.com". Does the AAAH have a way to know for sure, or > is the best-guess algorithm to say that the realm is what > follows the next-to-last dot of the FQDN, e.g. "spinach.com". > Probably not since this excludes subrealming. How about the next-to-first dot instead? >-->(7) It seems the AAAF and AAAH are both starting from scratch > with the HA's IP address, and duplicating efforts and delays. Maybe > the AAAF's DNS-lookup results (or whatever useful knowledge the AAAF > possesses) could be passed along to the AAAH. > A possible and slight optimization, but in my opinion the fundamental flaw is to not have the only entity capable of carrying the information across all scenarios actually do so, i.e. the MN. If this is politically infeasible we must look at suboptimal solutions of course. j From owner-aaa-wg@merit.edu Tue Mar 5 10:11:50 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03786 for ; Tue, 5 Mar 2002 10:11:50 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 95E7991247; Tue, 5 Mar 2002 10:11:35 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 69C4A91248; Tue, 5 Mar 2002 10:11:35 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 24CA391247 for ; Tue, 5 Mar 2002 10:11:34 -0500 (EST) Received: by segue.merit.edu (Postfix) id 03E5C5DDB3; Tue, 5 Mar 2002 10:11:34 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from thalia.fm.intel.com (fmfdns02.fm.intel.com [132.233.247.11]) by segue.merit.edu (Postfix) with ESMTP id 7EB755DDB1 for ; Tue, 5 Mar 2002 10:11:33 -0500 (EST) Received: from fmsmsxvs043.fm.intel.com (fmsmsxv043-1.fm.intel.com [132.233.48.128]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.52 2002/03/01 19:20:46 root Exp $) with SMTP id PAA08285 for ; Tue, 5 Mar 2002 15:11:22 GMT Received: from fmsmsx019.fm.intel.com ([132.233.42.130]) by fmsmsxvs043.fm.intel.com (NAVGW 2.5.1.16) with SMTP id M2002030507102808089 ; Tue, 05 Mar 2002 07:10:28 -0800 Received: by fmsmsx019.fm.intel.com with Internet Mail Service (5.5.2653.19) id <19DPN11S>; Tue, 5 Mar 2002 07:11:21 -0800 Message-ID: <10C8636AE359D4119118009027AE9987120B834E@FMSMSX34> From: "Walker, Jesse" To: "'Bernard Aboba'" , aaa-wg@merit.edu Subject: [AAA-WG]: RE: Why NASREQ Key Distribution is insecure (fwd) Date: Tue, 5 Mar 2002 07:11:04 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Thanks Bernard, This is a very good paper that will help people understand the issues. This has been one of the most influential papers ever published to help form the thinking about these protocols in the cryptographic community. This is some of the most inspired and original work by two of the very best cryptographers in the world. One thing to note about 3PP is, however, that almost as soon as it was published somone pointed out a problem with it, even though the proof of security is entirely valid! The problem arises because one of the assumptions is wrong. The wrong assumption is that an adversary could use the Test operation only once and then only at the "end of the game." Real adversaries don't restrict themselves in this way. So Bellare and Rogaway fixed this assumption and their proof and went on, although they never published this. Victor Shoup has published one way to fix it in http://shoup.net/papers/skey.pdf. The point is that key distribution is a damnably hard and subtle problem in ways that are not apparent even to the very best experts in the world. My recommendation to 802.11 has been and is that we need to take any one of several protocols that the crypto community has confidence in and then adapt it to our setting, and I make the same appeal now to AAA, because fixing this problem is outside the scope of 802.11's charter, but they cannot succeed in fixing their security without getting key distribution correct. Trying to roll our own is just a disaster waiting to happen. -- Jesse -----Original Message----- From: Bernard Aboba [mailto:aboba@internaut.com] Sent: Monday, March 04, 2002 9:43 PM To: aaa-wg@merit.edu Cc: jesse.walker@intel.com Subject: Re: Why NASREQ Key Distribution is insecure (fwd) Here is a paper by Bellare and Rogaway paper on provably secure 3 way key distribution which may relate to this issue. http://www.drizzle.com/~aboba/AAA/3pkd.pdf On Mon, 4 Mar 2002, Bernard Aboba wrote: > This is followup documentation on the issue posted to the list > earlier. > > --------------------------------------------------------------------- > From: Jesse Walker : > To: eap@frascone.com > > > >Given that the AS and AP trust each other (assumed), why > >is a reasonable cryptographic protocol (such as CMS or even IPSec) is > >insufficient to protect the transfer of a STA-AP session key from the AS to > >the AP? > > There has been in fact ample discussion around exactly these points. There > is, for instance, the whole key handoff discussion, of which AS-AP handoff > is a special case. As a second example, there is the flap around the > Arbaugh-Mishra 802.1X paper, which echos many of our key handoff > discussions, and which we have also discussed. From owner-aaa-wg@merit.edu Tue Mar 5 10:32:04 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04674 for ; Tue, 5 Mar 2002 10:32:04 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 95F7791248; Tue, 5 Mar 2002 10:31:52 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4F15691249; Tue, 5 Mar 2002 10:31:52 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 38C9291248 for ; Tue, 5 Mar 2002 10:31:51 -0500 (EST) Received: by segue.merit.edu (Postfix) id 190EE5DDF0; Tue, 5 Mar 2002 10:31:51 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 70EAB5DDE3 for ; Tue, 5 Mar 2002 10:31:42 -0500 (EST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g25FVDZ12645 for ; Tue, 5 Mar 2002 17:31:13 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 5 Mar 2002 17:31:01 +0200 Received: from esebe014.NOE.Nokia.com ([172.21.138.53]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 5 Mar 2002 17:31:01 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [AAA-WG]: Can CER from unknown hosts cause Peer Table entries Date: Tue, 5 Mar 2002 17:31:01 +0200 Message-ID: <9E3407CE45911B4097632389B77B202306D049@esebe014.NOE.Nokia.com> Thread-Topic: [AAA-WG]: RE: Why NASREQ Key Distribution is insecure (fwd) Thread-Index: AcHEWE1HGHuk3n1eRFqH+yJ9Hq3HZQAAM3GA From: To: X-OriginalArrivalTime: 05 Mar 2002 15:31:01.0984 (UTC) FILETIME=[C1C10E00:01C1C45A] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA04674 Hi, Referring section 5.3 on capabilities-exchange which says, "If the local policy permits receiving CERs from unknown hosts, a successful CEA MAY be returned." I have the following queries, if someone can clarify. If a node accepts CER from an unknown host and returns a successful CEA, does it amount to a peer discovery and can an entry be made in the peer table. If this is possible, I have further questions. The information present in a CER may not be sufficient to make a peer table entry. For example the CER does not contain the port on which the peer listens for connections, the transport protocols that the peer supports etc. Thanks in advance. Regards, Kishore -----Original Message----- From: ext Walker, Jesse [mailto:jesse.walker@intel.com] Sent: 05. March 2002 17:11 To: 'Bernard Aboba'; aaa-wg@merit.edu Subject: [AAA-WG]: RE: Why NASREQ Key Distribution is insecure (fwd) Thanks Bernard, This is a very good paper that will help people understand the issues. This has been one of the most influential papers ever published to help form the thinking about these protocols in the cryptographic community. This is some of the most inspired and original work by two of the very best cryptographers in the world. One thing to note about 3PP is, however, that almost as soon as it was published somone pointed out a problem with it, even though the proof of security is entirely valid! The problem arises because one of the assumptions is wrong. The wrong assumption is that an adversary could use the Test operation only once and then only at the "end of the game." Real adversaries don't restrict themselves in this way. So Bellare and Rogaway fixed this assumption and their proof and went on, although they never published this. Victor Shoup has published one way to fix it in http://shoup.net/papers/skey.pdf. The point is that key distribution is a damnably hard and subtle problem in ways that are not apparent even to the very best experts in the world. My recommendation to 802.11 has been and is that we need to take any one of several protocols that the crypto community has confidence in and then adapt it to our setting, and I make the same appeal now to AAA, because fixing this problem is outside the scope of 802.11's charter, but they cannot succeed in fixing their security without getting key distribution correct. Trying to roll our own is just a disaster waiting to happen. -- Jesse -----Original Message----- From: Bernard Aboba [mailto:aboba@internaut.com] Sent: Monday, March 04, 2002 9:43 PM To: aaa-wg@merit.edu Cc: jesse.walker@intel.com Subject: Re: Why NASREQ Key Distribution is insecure (fwd) Here is a paper by Bellare and Rogaway paper on provably secure 3 way key distribution which may relate to this issue. http://www.drizzle.com/~aboba/AAA/3pkd.pdf On Mon, 4 Mar 2002, Bernard Aboba wrote: > This is followup documentation on the issue posted to the list > earlier. > > --------------------------------------------------------------------- > From: Jesse Walker : > To: eap@frascone.com > > > >Given that the AS and AP trust each other (assumed), why > >is a reasonable cryptographic protocol (such as CMS or even IPSec) is > >insufficient to protect the transfer of a STA-AP session key from the AS to > >the AP? > > There has been in fact ample discussion around exactly these points. There > is, for instance, the whole key handoff discussion, of which AS-AP handoff > is a special case. As a second example, there is the flap around the > Arbaugh-Mishra 802.1X paper, which echos many of our key handoff > discussions, and which we have also discussed. From owner-aaa-wg@merit.edu Tue Mar 5 11:39:10 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08044 for ; Tue, 5 Mar 2002 11:39:09 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 29C249123B; Tue, 5 Mar 2002 11:38:47 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EDDCF9124A; Tue, 5 Mar 2002 11:38:46 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 07C4B9123B for ; Tue, 5 Mar 2002 11:38:45 -0500 (EST) Received: by segue.merit.edu (Postfix) id D0BC05DDC3; Tue, 5 Mar 2002 11:38:45 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id BE1405DDB1 for ; Tue, 5 Mar 2002 11:38:45 -0500 (EST) Received: from Interlinknetworks.com (nat.interlinknetworks.com [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with ESMTP id 765E97B; Tue, 5 Mar 2002 11:38:45 -0500 (EST) Message-ID: <3C84F49E.6B0087A3@Interlinknetworks.com> Date: Tue, 05 Mar 2002 11:38:54 -0500 From: David Spence Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Ext-Venkata.Ghadiyaram@nokia.com Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Can CER from unknown hosts cause Peer Table entries References: <9E3407CE45911B4097632389B77B202306D049@esebe014.NOE.Nokia.com> Content-Type: multipart/mixed; boundary="------------001D957869E79E01FE860E0B" Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. --------------001D957869E79E01FE860E0B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Ext-Venkata.Ghadiyaram@nokia.com wrote: > > Hi, > > Referring section 5.3 on capabilities-exchange which says, > > "If the local policy permits receiving CERs from unknown hosts, a successful CEA MAY be returned." > I have the following queries, if someone can clarify. > > If a node accepts CER from an unknown host and returns a successful CEA, does it amount to a peer discovery and can an entry be made in the peer table. Yes, this means that you have either been "discovered" or redirected to. You will need to decide whether you want to accept a connection from the originator of the CER. I think there are definite security concerns here which I will raise in a separate message. > If this is possible, I have further questions. The information present in a CER may not be sufficient to make a peer table entry. For example the CER does not contain the port on which the peer listens for connections, the transport protocols that the peer supports etc. If, by a peer table entry, you mean do you have enough information to create an entry that would allow you to recreate the connection if the connection you are establishing now gets broken, the answer is no. In this case, he wanted to talk to you, so it's his responsiblity to re-establish the connection. As far as the current connection is concerned, however, you don't need any further information. You don't need the port number on which he listens. You know what transport protocol is in use for this connection. And whatever security needs to be established has already been established, you hope, because, by CER/CEA time, the security stuff has already happened. > > Thanks in advance. > > Regards, > Kishore >... --------------001D957869E79E01FE860E0B Content-Type: text/x-vcard; charset=us-ascii; name="DSpence.vcf" Content-Description: Card for David Spence Content-Disposition: attachment; filename="DSpence.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:; tel;fax:+1 734 821 1235 tel;work:+1 734 821 1203 x-mozilla-html:FALSE url:http://www.interlinknetworks.com org:Interlink Networks, Inc. adr:;;775 Technology Dr., Suite 200;Ann Arbor;MI;48108;USA version:2.1 email;internet:DSpence@Interlinknetworks.com title:Architect fn:David Spence end:vcard --------------001D957869E79E01FE860E0B-- From owner-aaa-wg@merit.edu Tue Mar 5 12:09:53 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09707 for ; Tue, 5 Mar 2002 12:09:52 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id CC7939124A; Tue, 5 Mar 2002 12:09:42 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9A3779124B; Tue, 5 Mar 2002 12:09:42 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8E18D9124A for ; Tue, 5 Mar 2002 12:09:41 -0500 (EST) Received: by segue.merit.edu (Postfix) id DE6AA5DDB7; Tue, 5 Mar 2002 12:09:39 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 05AF55DDB1 for ; Tue, 5 Mar 2002 12:09:39 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g25GT8107521 for ; Tue, 5 Mar 2002 08:29:09 -0800 Date: Tue, 5 Mar 2002 08:29:08 -0800 (PST) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: [Issue] NASREQ: EAP corner conditions Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Submitter: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: March 5, 2002 Reference: Document: NASREQ Comment type: T Priority: S Section: 4.0 Rationale/Explanation of issue: NASREQ has some corner conditions that have turned out to be a big headache. These occur when the encapsulated EAP Message does not agree with the Diameter message within which it is encapsulated. These problems are inherited from RFC 2869. NASREQ needs to make clear, as RFC 2865 does, that a NAS makes its access decision based on the Diameter message alone (Accept or Reject), *not* based on the contents of any enclosed attributes, including an EAP-Message attribute. This makes sense, since the NAS acts as a "passthrough" for EAP. However, this makes for some interesting corner conditions, because the following packets may be sent by the Diameter server: a. Accept/EAP-Message/EAP-Failure b. Reject/EAP-Message/EAP-Success c. Accept/EAP-Message/Notification d. Reject/EAP-Message/Notification e. Accept (no EAP Message) f. Reject (no EAP Message) g. Accept/EAP-Message/EAP-Failure, Reply-Message h. Accept/EAP-Message/EAP-Success, Reply-Message i. Reject/EAP-Message/EAP-Failure, Reply-Message j. Accept/EAP-Message/EAP-Success, Reply-Message k. Challenge/EAP-Message/EAP-Success l. Challenge/EAP-Message/EAP-Failure There are probably more corner conditions than this, but my fingers are getting tired :( a. Message a is a problem because the Accept says "grant access" while the Failure, if passed on to the EAP peer will make it think that authentication has failed. If there are alternate indications of success, one might argue that the peer will eventually figure it out. For media in which there are no such indications (IEEE 802 and 802.11 are examples), a timeout will result. b. Message b is a problem because the Reject says "no access" while the EAP-Success passed to the peer makes it think it is successful. If there are alternate indications of Failure on a given media, the peer may eventually figure things out. On IEEE 802.11 a Disassociate from the AP would put things right, as would an LCP-Terminate in PPP. On wired IEEE 802 there is no alternate indication of failure, so a timeout will result. c-d. These are an issue since the peer receives a displayable Notification, but no indication of Success/Failure. Alternate indications might help, but for media in which they don't exist, a timeout will result. e-f. Ditto, except no notification. g-j. These are a problem since it is not clear within NASREQ how a Reply-Message is to be handled within an EAP conversation. Some NAS implementations translate Reply-Mesage to an EAP-Notification, resulting in the NAS having *two* EAP messages to send to the peer. Some NAS implementations treat the Reply-Message as a terminal non-ACK'd message, in which case the subsequent EAP-Message attributes are never sent. Which interpretation is correct? If you're in the "translate to Notification" camp, then presumably the Notification has to be sent first, since the Success/Failure message terminates the conversation and therefore nothing can be sent after that. Note that the Reply-Message doesn't come with an Identifier field, so presumably the NAS has to make one up. But since the Success/Failure already has an Identifier field in it, what is the NAS/AP supposed to do, particularly if the Identifier field is incremented sequentially? The problems are obviously worse if the Reply-Message is sent in the middle of the conversation, so that a simple Identifier swap wouldn't work. k-l. These are problematic because an Access-Challenge indicates a continuing conversation, but an EAP-Success/EAP-Failure is a terminating message. Therefore the Diameter Server will not receive a response to these messages -- but the NAS will neither have granted nor rejected access. Proposed change: Here are some possible ways to address the Reply-Message issue: 1. On the Reply-Message processing issue, we could suggest that the right way to notify the EAP peer in an EAP conversation is to use EAP-Notification instead of Reply-Message, and that Reply-Message is a terminal message that is sent, and not translated to EAP-Motification. 2. Alternatively, we could specify that Reply Message is to be translated to EAP-Notification by an EAP capable NAS (what about one which isn't EAP capable?). Here are some approaches to addressing the issue of a mismatch between the RADIUS message (accept/reject) and the EAP-Message attribute: 1. "Dr., it hurts when I do this". This approach says: these corner conditions are difficult to handle for media in which there are no alternate failure/success indications, so that NASREQ should state that Diameter servers SHOULD NOT (MUST NOT?) send these messages. Since an Diameter server can be assumed not to send these messages, the NAS can blithely decapsulate and send whatever is inside an EAP-Message attribute, if one is present, then act on the Diameter message (Accept/Reject). In this approach, NASREQ states that a Challenge MUST NOT contain an EAP-Success/Failure message, and that if a Reply-Message needs to be sent, then this should be encapsulated in a packet with no EAP-Message attribute, adding an extra round-trip; the Reply-Message is translated to EAP-Notification, and an Access-Request/EAP-Message/Notification-Response is sent back to the Diameter server, after which the EAP conversation continues. 2. "Mr. NAS will make it better". This approach says: the NAS should make sure these corner conditions will not occur by "manufacturing" EAP Success packets on receipt of an Access Accept, and "manufacturing" EAP Failure packets on receipt of an Access Reject. This handles cases a-f, but has some undesirable implications for cryptographically protected EAP. In proposals to cryptographically protect EAP (such as EAP TTLS or PEAP), it is desirable to have as much of the EAP conversation as possible be protected. The idea of these protocols is to create an encrypted channel, then complete the EAP conversation within that channel. That means that in theory the final Success/Failure message is sent down the encrypted channel. Since EAP Success/Failure messages are not ACK'd, such a message, if sent, must terminate the EAP conversation. This implies that they must be the last message sent, and so if the NAS is to know the result of the conversation, then they need to be sent within an Access Accept or Reject message. But if the "Mr. NAS will make it better" approach is taken, then the NAS will swallow the encrypted Success/Failure packet and replace it with a cleartext Success/Failure. This undermines the concept of protection, which is to be able to authenticate and encrypt each packet in the EAP conversation. So it seems to me that, to address these issues in NASREQ, we need to do one of two things: 1. If we adopt the "Dr., it hurts when I do this" approach, then we need to suggest changes to the 802.1X state machine to conform to NASREQ. In this approach, we would presumably leave the EAP Success/Failure messages as they are in RFC 2284, forbid the bad messages, and add some text on how Reply-Message attributes are to be processed within an EAP conversation. 2. If we adopt the "Mr. NAS will make it better" approach, then we may need to introduce new ACK'd Success and Failure messages within EAP. Doing this will ensure a response to the success/failure indication, removing the need for "alternative indications" and ensuring that the encrypted Success/Failure indication gets through. From owner-aaa-wg@merit.edu Tue Mar 5 15:55:25 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28070 for ; Tue, 5 Mar 2002 15:55:25 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 270D791250; Tue, 5 Mar 2002 15:55:08 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E2E8191251; Tue, 5 Mar 2002 15:55:07 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id F11C491250 for ; Tue, 5 Mar 2002 15:55:06 -0500 (EST) Received: by segue.merit.edu (Postfix) id D46A35DDCC; Tue, 5 Mar 2002 15:55:06 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id BEC315DDA0 for ; Tue, 5 Mar 2002 15:55:06 -0500 (EST) Received: from phoenix (nat.interlinknetworks.com [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with SMTP id 7235B7B; Tue, 5 Mar 2002 15:55:06 -0500 (EST) From: "Bob Kopacz" To: "Tony Johansson" Cc: "aaa-wg" Subject: [AAA-WG]: [issue] Securing the AAAH-generated session keys Date: Tue, 5 Mar 2002 15:54:08 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Issue : Securing the AAAH-generated session keys Submitter name: Bob Kopacz Submitter email address:bkopacz@interlinknetworks.com Date first submitted: 03-05-2002 Reference: Document: draft-mobileip-09 Comment type: Technical Priority: 1 Section: Rationale/Explanation of issue: The draft-mobileip-09 was updated per issue#266. Issue#266 addressed the case where the HA was in a foreign network, the destination AAAF generated the FA-HA key, and the destination AAAF wanted to use CMS to return the key to the FA in a secure manner. Because the mobility agents may not support CMS (CMS is a SHOULD for clients but a MUST for servers), the issue#266 solution was for the destination AAAF (i.e. the HA's AAAF) to set up a DSA with the originating AAAF (i.e. the FA's AAAF), and to pass the CMS-encrypted FA-HA key to the originating AAAF within a CMS-Encrypted-Data AVP. The key is thus hidden as it traverses the home domain and any intermediary proxy/relay AAA servers. Issue#266 was retricted to the case of CMS-securing the AAAF-generated session key. There is a similar need to CMS-secure the AAAH-generated session keys, if there are intervening proxy networks between the home network and the mobility agent's network. The proposal here is for an AAAH who wants to CMS-secure its generated session keys, to set up a DSA with the mobility agent's local AAAF, and to pass the CMS-secured keys to the AAAF a la issue#266. AAAH-generated keys destined for the FA: An AAAH-generated FA-MN key (and maybe an AAAH-generated FA-HA key) is returned to the FA in the AMA, which possibly traverses intermediary proxies. The AAAH can CMS-secure these keys by setting up a DSA with the FA's local AAAF, and passing the CMS-encrypted keys to the AAAF a la issue#266. The AAAH knows the identity of the originating AAAF because this is kindly provided in the AMR's MIP-Originating-Foreign-AAA AVP. AAAH-generated keys destined for a foreign HA: The AAAH-generated HA-MN key is forwarded in the HAR to the HA. If the HA resides in a foreign network, the HAR may traverse intermediary proxies, and the AAAH may want to CMS-secure this key. Unfortunately the AAAH doesn't necessarily know who the destination AAAF is. The problem here is that the AAAH wants to set up the DSA before forwarding the HAR which carries the encrypted keys. In this case, I am currently stuck and soliciting suggestions. (One goofy notion, whose only virtue is that it works, is this: The AAAH sends a "half-baked" HAR which doesn't contain the keys. The AAAF receives this half-baked HAR, extracts the AAAH's identity from the half-baked HAR, sets up a DSA with the AAAH, who resends a fully-baked HAR with the CMS-encrypted keys. Unfortunately, this entails another round trip.) Requested change: In section 5.0 Key Distribution Center > 5.0 Key Distribution Center > > [...] > > If the AAAH does not communicate directly with the foreign agent, and > it does not wish for intermediate proxies to have access to the > session keys, they SHOULD be protected using the CMS security > application [CMS]. Change the first sentence to : "If the AAAH does not communicate directly with one or both mobility agents,..." - - - In section 5.2 Key Material vs. Session Key > 5.2 Key Material vs. Session Key > > [...] > > The session keys destined for mobility agents may be encoded using > the security association available between the AAA server and the > agents (e.g. IPSec, TLS, CMS). Change the above sentence to: "The session keys destined for mobility agents may be encoded using the security association available between the AAA server and the agents (e.g. IPSec, TLS, CMS), or, if the AAAH suspects a foreign mobility agent doesn't support CMS, by using the security association available between the AAAH and the AAA server hosting the mobility agent." - - - In section 5.3 Distributing the Mobile-Home Session Key > 5.3 Distributing the Mobile-Home Session Key > [Need some text here to address the case where the HA is in a foreign network, the HA doesn't support CMS, and the AAAH wants to set up a DSA with the destination AAAF, and pass the CMS-encrypted HA-MN key to the destination AAAF.] - - - In section 5.4 Distributing the Mobile-Foreign Session Key > 5.4 Distributing the Mobile-Foreign Session Key > > The Mobile-Foreign session key material is also generated by AAAH > (upon request) and is added to the MIP-MN-to-FA-Key AVP, which is > added to the HAR, and copied by the home agent into a Generalized MN- > FA Key Reply Extension [MIPKEYS] to the Mobile IP Registration Reply > message, using the SPI proposed by the Mobile Node in the MN-FA Key > Request From AAA Subtype extension. Further, the home agent includes > the SPI in the HAA's MIP-FA-to-MN-SPI AVP. The AAAH includes the > session key in the MIP-FA-to-MN-Key AVP in the HAA, which contains > the session key used by the foreign agent in the computation of the > Mobile-Foreign authentication extension. > > Upon receipt of the HAA, the Diameter server responsible for key > allocation creates the MIP-FA-to-HA Key AVP, using the SPI in the > MIP-FA-to-HA-SPI. If the key is generated at the AAAF (home agent in > foreign domain), it adds the MIP-FA-to-HA Key AVP to the HAA and > sends it to the AAAH. Depending upon where the HA was located the > AAAH either generates the MIP-FA-to-HA Key AVP itself or extracts the > AVP from the HAA sent by the AAAF. The AAAH adds the MIP-FA-to-HA Key > to the AMA. If the MIP-FA-to-MN-Key AVP was present in the AMA, the > foreign agent MUST include the Mobile-Foreign authentication > extension in the Registration Reply, using the newly distributed key. Append the following paragraph: "If the AAAH is returning an FA-HA or FA-MN key to the FA, and the AAAH wants to secure these keys because the originating AAAF is not a peer (there are intermediate proxies), the AAAH first sets up a DSA with the originating AAAF, and passes the FA's key(s) within a CMS-Encrypted-Data AVP in the AMA." From owner-aaa-wg@merit.edu Tue Mar 5 18:16:26 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05719 for ; Tue, 5 Mar 2002 18:16:26 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DA06591249; Tue, 5 Mar 2002 18:15:45 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A7C3791253; Tue, 5 Mar 2002 18:15:45 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id ADE7F91249 for ; Tue, 5 Mar 2002 18:15:44 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8A6485DDF4; Tue, 5 Mar 2002 18:15:44 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 75FEE5DDDB for ; Tue, 5 Mar 2002 18:15:44 -0500 (EST) Received: from phoenix (nat.interlinknetworks.com [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with SMTP id 264837A; Tue, 5 Mar 2002 18:15:44 -0500 (EST) From: "Bob Kopacz" To: "John Loughney" , "David Spence" , "Stephen Farrell" , "Tony Johansson" Cc: "aaa-wg" Subject: [AAA-WG]: [issue] Combine occurrence rules tables with message ABNF Date: Tue, 5 Mar 2002 18:14:46 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Issue : Combine occurrence rules tables with message ABNF Submitter name: Bob Kopacz Submitter email address:bkopacz@interlinknetworks.com Date first submitted: 03-05-2002 Reference: Document: all drafts Comment type: Technical Priority: 1 Section: Rationale/Explanation of issue: 1. There are often conflicts between the message ABNF and the [redundant] information in the occurrence rules tables. Combining the message ABNF with the occurrence rules would create one location for the message AVP occurrence information, and eliminate the redundancies and neverending conflicts. 2. The current ABNF is a little tricky, in that the default number of occurrences depends on the type of braces around the AVPs. So replace the and the *'s with the explicit counts as in the occurrence rules, e.g. 0, 0+, 0-1, etc. Then we don't need both the {}braces and the []braces, as the numeric counts indicate required versus optional. For example, the current ABNF for the AA-Mobile-Node-Request is: > ::= < Diameter Header: 260, REQ, PXY > > < Session-Id > > { Auth-Application-Id } > { User-Name } > { Destination-Realm } > { Origin-Host } > { Origin-Realm } > { MIP-Reg-Request } > { MIP-MN-AAA-Auth } > [ Destination-Host ] > [ Origin-State-Id ] > [ MIP-Mobile-Node-Address ] > [ MIP-Home-Agent-Address ] > [ MIP-Feature-Vector ] > [ MIP-Originating-Foreign-AAA ] > [ Authorization-Lifetime ] > [ Auth-Grace-Period ] > [ Auth-Session-State ] > [ MIP-FA-Challenge ] > [ MIP-Candidate-Home-Agent-Host ] > * [ AVP ] > * [ Proxy-Info ] > * [ Route-Record ] The occurrence rule tables could be absorbed into the message ABNF (and eliminated), with a message ABNF that looks like: > ::= < Diameter Header: 260, REQ, PXY > > 1 < Session-Id > > 1 [ Auth-Application-Id ] > 1 [ Destination-Realm ] > 1 [ MIP-Reg-Request ] > 1 [ MIP-MN-AAA-Auth ] > 1 [ Origin-Host ] > 1 [ Origin-Realm ] > 1 [ User-Name ] > 0-1 [ Authorization-Lifetime ] > 0-1 [ Auth-Grace-Period ] > 0-1 [ Auth-Session-State ] > 0-1 [ Accounting-Multi-Session-Id ] > 0-1 [ Destination-Host ] > 0-1 [ MIP-Candidate-Home-Agent-Host ] > 0-1 [ MIP-Originating-Foreign-AAA ] > 0-1 [ MIP-FA-Challenge ] > 0-1 [ MIP-Feature-Vector ] > 0-1 [ MIP-Home-Agent-Address ] > 0-1 [ MIP-Mobile-Node-Address ] > 0-1 [ Original-State-Id ] > 0+ [ Proxy-Info ] > 0+ [ Route-Record ] > 0 [ Acct-Application-Id ] > 0 [ Error-Message ] > 0 [ Error-Reporting-Host ] > 0 [ MIP-FA-to-HA-Key ] > 0 [ MIP-FA-to-HA-SPI ] > 0 [ MIP-FA-to-MN-Key ] > 0 [ MIP-FA-to-MN-SPI ] > 0 [ MIP-Filter-Rule ] > 0 [ MIP-Foreign-Agent-Host ] > 0 [ MIP-HA-to-FA-Key ] > 0 [ MIP-HA-to-MN-Key ] > 0 [ MIP-Key-Lifetime ] > 0 [ MIP-MN-to-FA-Key ] > 0 [ MIP-MN-to-HA-Key ] > 0 [ MIP-Reg-Reply ] > 0 [ Redirect-Host ] > 0 [ Redirect-Host-Usage ] > 0 [ Redirect-Max-Cache-Time ] > 0 [ Result-Code ] > 0 [ Re-Auth-Request-Type ] > 0 [ Session-Timeout ] > 0+ [ AVP ] 3. This is not a significant change to the drafts. Requested Change: Do this in all the Diameter drafts. From owner-aaa-wg@merit.edu Wed Mar 6 03:23:10 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27252 for ; Wed, 6 Mar 2002 03:23:09 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3D1919125D; Wed, 6 Mar 2002 03:22:44 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 08D6A9125C; Wed, 6 Mar 2002 03:22:43 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DE8BD9125D for ; Wed, 6 Mar 2002 03:22:42 -0500 (EST) Received: by segue.merit.edu (Postfix) id B55AA5DE17; Wed, 6 Mar 2002 03:22:42 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id B00AF5DDB9 for ; Wed, 6 Mar 2002 03:21:05 -0500 (EST) Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g268L4Z11034 for ; Wed, 6 Mar 2002 10:21:04 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 6 Mar 2002 10:20:53 +0200 Received: from esebe014.NOE.Nokia.com ([172.21.138.53]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 6 Mar 2002 10:20:53 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Can CER from unknown hosts cause Peer Table entries Date: Wed, 6 Mar 2002 10:20:51 +0200 Message-ID: <9E3407CE45911B4097632389B77B202306D04A@esebe014.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Can CER from unknown hosts cause Peer Table entries Thread-Index: AcHEZDxEOIxddm00QqaZTDoWPBandQAgMD5Q From: To: Cc: X-OriginalArrivalTime: 06 Mar 2002 08:20:53.0695 (UTC) FILETIME=[D53A6CF0:01C1C4E7] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA27252 Hi, By peer table entry, I meant an entry that would allow to recreate a connection. As this is not possible, should the specification say, "If a CER from and unknown peer is answered with a successful CEA, the lifetime of the peer entry is equal to the lifetime of the transport connection. In case of a transport failure, all the pending transactions destied to the unknown per can be discarded." Regards, Kishore -----Original Message----- From: ext David Spence [mailto:DSpence@Interlinknetworks.com] Sent: 05. March 2002 18:39 To: Ghadiyaram Venkata (EXT-TataConsultancy/Helsinki) Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Can CER from unknown hosts cause Peer Table entries Ext-Venkata.Ghadiyaram@nokia.com wrote: > > Hi, > > Referring section 5.3 on capabilities-exchange which says, > > "If the local policy permits receiving CERs from unknown hosts, a successful CEA MAY be returned." > I have the following queries, if someone can clarify. > > If a node accepts CER from an unknown host and returns a successful CEA, does it amount to a peer discovery and can an entry be made in the peer table. Yes, this means that you have either been "discovered" or redirected to. You will need to decide whether you want to accept a connection from the originator of the CER. I think there are definite security concerns here which I will raise in a separate message. > If this is possible, I have further questions. The information present in a CER may not be sufficient to make a peer table entry. For example the CER does not contain the port on which the peer listens for connections, the transport protocols that the peer supports etc. If, by a peer table entry, you mean do you have enough information to create an entry that would allow you to recreate the connection if the connection you are establishing now gets broken, the answer is no. In this case, he wanted to talk to you, so it's his responsiblity to re-establish the connection. As far as the current connection is concerned, however, you don't need any further information. You don't need the port number on which he listens. You know what transport protocol is in use for this connection. And whatever security needs to be established has already been established, you hope, because, by CER/CEA time, the security stuff has already happened. > > Thanks in advance. > > Regards, > Kishore >... From owner-aaa-wg@merit.edu Wed Mar 6 08:58:44 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08183 for ; Wed, 6 Mar 2002 08:58:43 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2C73991265; Wed, 6 Mar 2002 08:58:13 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EA4AE91266; Wed, 6 Mar 2002 08:58:12 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B78FD91265 for ; Wed, 6 Mar 2002 08:58:11 -0500 (EST) Received: by segue.merit.edu (Postfix) id B09E65DE33; Wed, 6 Mar 2002 08:57:36 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by segue.merit.edu (Postfix) with ESMTP id 062AE5DE55 for ; Wed, 6 Mar 2002 08:57:36 -0500 (EST) Received: from fredrikj (hotel-33.local.ipunplugged.com [192.168.8.33]) by mailgw.ipunplugged.com (8.9.3/8.9.3) with SMTP id OAA17837; Wed, 6 Mar 2002 14:53:27 +0100 From: "Fredrik Johansson" To: , Subject: RE: [AAA-WG]: Issue 244: ELECTION_LOST result code Date: Wed, 6 Mar 2002 14:56:27 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEFA22A9F@esebe004.NOE.Nokia.com> Importance: Normal Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit I agree that this issue should be rejected. And I guess it has. The strange thing is that I can't find the Result Code ELECTION_LOST anywhere in base-10? Has it been deleted anyway? /Fredrik >-----Original Message----- >From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of >john.loughney@nokia.com >Sent: den 26 februari 2002 21:46 >To: aaa-wg@merit.edu >Subject: [AAA-WG]: Issue 244: ELECTION_LOST result code > > >This issue has been marked as a poosible reject. I agree & unless >someone speaks up, I will mark this as a reject. > >John > >Issue 244: ELECTION_LOST result code >Submitter name: Michael Chen >Submitter email address: cchen@erilab.com >Date first submitted: 19-Nov-01 >Reference: >Document: base-08 >Comment type: E >Priority: 1 >Section: Base: 5.4.3 > >Rationale/Explanation of issue: >DPR is not sent to its peer when lost the election so ELECTION_LOST >result code is not used. > >Requested change: >Remove this result code. From owner-aaa-wg@merit.edu Wed Mar 6 10:29:35 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13050 for ; Wed, 6 Mar 2002 10:29:34 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E1F189126B; Wed, 6 Mar 2002 10:29:23 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AFB6E9126C; Wed, 6 Mar 2002 10:29:23 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7CF419126B for ; Wed, 6 Mar 2002 10:29:22 -0500 (EST) Received: by segue.merit.edu (Postfix) id 56C865DE33; Wed, 6 Mar 2002 10:29:22 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by segue.merit.edu (Postfix) with ESMTP id 734E05DE2A for ; Wed, 6 Mar 2002 10:29:21 -0500 (EST) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g26FTxi23141 for ; Wed, 6 Mar 2002 17:29:59 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 6 Mar 2002 17:29:20 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 6 Mar 2002 17:29:20 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C1C523.AF4BD14F" Subject: RE: [AAA-WG]: Issue 244: ELECTION_LOST result code Date: Wed, 6 Mar 2002 17:29:19 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64B44@esebe004.NOE.Nokia.com> X-MS-Has-Attach: yes Thread-Topic: [AAA-WG]: Issue 244: ELECTION_LOST result code Thread-Index: AcHFFyl83O+PUXNbR1OWnuZOGwpoyAADAVVQ From: To: , X-OriginalArrivalTime: 06 Mar 2002 15:29:20.0225 (UTC) FILETIME=[AF839D10:01C1C523] Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C1C523.AF4BD14F Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Fredrik, > I agree that this issue should be rejected. And I guess it=20 > has. The strange > thing is that I can't find the Result Code ELECTION_LOST anywhere in > base-10? Has it been deleted anyway? There was continued discussion on this, that it is not used anymore. So, I have removed it. However, I just noticed one mail I did not see - I've included the relevant mails. So, we are left with 3 possibilities: 1) ELECTION_LOST code removed from the spec 2) Restore ELECTION_LOST code to where it was in Base (Disconnect-Cause = AVP) 3) Put ELECTION_LOST into the Result_Code AVP, probably under Transient = Failures Your thoughts? John ------_=_NextPart_001_01C1C523.AF4BD14F Content-Type: message/rfc822 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebe004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 27 Feb 2002 00:05:53 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebe013.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 27 Feb 2002 00:05:53 +0200 Received: from esvir05nok.ntc.nokia.com ([172.21.143.37]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 27 Feb 2002 00:05:53 +0200 Received: from mgw-x1.nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 27 Feb 2002 00:05:52 +0200 Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by mgw-x1.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1QM5J308851 for ; Wed, 27 Feb 2002 00:05:20 +0200 (EET) Received: from mr5.exu.ericsson.se (mr5u3.ericy.com [208.237.135.124]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g1QM5nh27578; Tue, 26 Feb 2002 16:05:49 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g1QM5mW02581; Tue, 26 Feb 2002 16:05:49 -0600 (CST) Received: from qpop.exu.ericsson.se (qpop [138.85.75.72]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id QAA17317; Tue, 26 Feb 2002 16:05:47 -0600 (CST) Received: from ericberk107 (letmein2-025.exu.ericsson.se [138.85.130.25]) by qpop.exu.ericsson.se (8.9.1/8.9.1) with SMTP id QAA29659; Tue, 26 Feb 2002 16:05:46 -0600 (CST) content-class: urn:content-classes:message Subject: Re: [AAA-WG]: Issue 244: ELECTION_LOST result code Date: Wed, 27 Feb 2002 00:05:43 +0200 Message-ID: <009101c1bf11$be7a2630$6400a8c0@ew.us.am.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AAA-WG]: Issue 244: ELECTION_LOST result code Thread-Index: AcG/EcH+VxE6Bd0PTPCwzwEGZ54xdA== From: To: , , Content-Transfer-Encoding: quoted-printable > I don't understand why this is being rejected. Is the ELECTION_LOST > result code used anymore? Agreed. If memory serves, originally when a peer lost an election, it = would send a CEA with a result code indicating success and then immediately = send a DPR with a Disconnect-Cause indicating ELECTION_LOST. As a result of = the last interop event, it was decided it would be better to just send a CEA with the ELECTION_LOST result code. Thus, the idea with this issue was = to simply move this result code from the enumerated Disconnect-Cause AVP = into the Result-Code AVP. -Kev > > Don Z. > > john.loughney@nokia.com wrote: > > > This issue has been marked as a poosible reject. I agree & unless > > someone speaks up, I will mark this as a reject. > > > > John > > > > Issue 244: ELECTION_LOST result code > > Submitter name: Michael Chen > > Submitter email address: cchen@erilab.com > > Date first submitted: 19-Nov-01 > > Reference: > > Document: base-08 > > Comment type: E > > Priority: 1 > > Section: Base: 5.4.3 > > > > Rationale/Explanation of issue: > > DPR is not sent to its peer when lost the election so ELECTION_LOST > > result code is not used. > > > > Requested change: > > Remove this result code. > ------_=_NextPart_001_01C1C523.AF4BD14F Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebe004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 26 Feb 2002 23:20:01 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebe005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 26 Feb 2002 23:20:01 +0200 Received: from esvir10nok.ntc.nokia.com ([172.21.143.42]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 26 Feb 2002 23:20:01 +0200 Received: from mgw-x3.nokia.com (unverified) by esvir10nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 26 Feb 2002 23:20:02 +0200 Received: from dzick.interlinknetworks.com (nat.interlinknetworks.com [198.108.5.3]) by mgw-x3.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1QLKWi20296 for ; Tue, 26 Feb 2002 23:20:33 +0200 (EET) Received: from interlinknetworks.com (localhost.localdomain [127.0.0.1]) by dzick.interlinknetworks.com (8.11.0/8.11.0) with ESMTP id g1QLIRD01134; Tue, 26 Feb 2002 16:18:27 -0500 content-class: urn:content-classes:message Subject: Re: [AAA-WG]: Issue 244: ELECTION_LOST result code Date: Tue, 26 Feb 2002 23:18:27 +0200 Message-ID: <3C7BFBA3.E447AEC2@interlinknetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AAA-WG]: Issue 244: ELECTION_LOST result code Thread-Index: AcG/C1nLz3BYt/qYTkmI3QdwB5UPag== From: To: Cc: Content-Transfer-Encoding: quoted-printable I don't understand why this is being rejected. Is the ELECTION_LOST result code used anymore? Don Z. john.loughney@nokia.com wrote: > This issue has been marked as a poosible reject. I agree & unless > someone speaks up, I will mark this as a reject. > > John > > Issue 244: ELECTION_LOST result code > Submitter name: Michael Chen > Submitter email address: cchen@erilab.com > Date first submitted: 19-Nov-01 > Reference: > Document: base-08 > Comment type: E > Priority: 1 > Section: Base: 5.4.3 > > Rationale/Explanation of issue: > DPR is not sent to its peer when lost the election so ELECTION_LOST > result code is not used. > > Requested change: > Remove this result code. ------_=_NextPart_001_01C1C523.AF4BD14F-- From owner-aaa-wg@merit.edu Wed Mar 6 10:48:55 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14042 for ; Wed, 6 Mar 2002 10:48:55 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id F27D19126F; Wed, 6 Mar 2002 10:47:21 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8F4299127C; Wed, 6 Mar 2002 10:47:20 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 334A09126F for ; Wed, 6 Mar 2002 10:47:17 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0FF225DDE4; Wed, 6 Mar 2002 10:47:17 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id EE6AD5DDDC for ; Wed, 6 Mar 2002 10:47:16 -0500 (EST) Received: from Interlinknetworks.com (nat.interlinknetworks.com [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with ESMTP id 96BA17A for ; Wed, 6 Mar 2002 10:47:16 -0500 (EST) Message-ID: <3C863A0E.3575AFA4@Interlinknetworks.com> Date: Wed, 06 Mar 2002 10:47:26 -0500 From: David Spence Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: AAA Working Group Subject: [AAA-WG]: [issue] Security model for peer discovery and redirect Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Subject: [issue] Security model for peer discovery and redirect Submitter name: David Spence Submitter email address: DSpence@Interlinknetworks.com Date first submitted: March 6, 2002 Reference: Document: Base Comment type: T Priority: S Section: Rationale/Explanation of issue: While I haven't studied studied base-10 in great detail yet, I believe there are still significant security issues with peer-to-peer connections that need to be addressed. Two of the models for using Diameter that I'm not particularly thrilled with and admittedly haven't devoted a whole lot of thought to in the past are the peer discovery and redirect models. Nevertheless, it is extremely important that if we include these models in Diameter, we need to make them work. The thing that both of these models share is that peer-to-peer connections are created dynamically. This raises two problems. The first is, what makes the connection originator feel comfy about seeking to establish the connection? The second is, what makes the connection recipient feel comfy about accepting the connection? Consider the redirect model. If Bob@donut.com dials in to wondernet.net, the wondernet AAA server, aaaf.wondernet.net, sends an authentication/ authorization request to his redirect agent, aaa.omniscient.com. Aaa.omniscient.com redirects him to aaah.donut.com. Aaaf.wondernet.net is comfy because he trusts aaa.omniscient.com. Aaah.donut.com receives a CER from aaaf.wondernet.net. Perhaps aaa.omniscient.com trusts aaah.donut.com, too. But that doesn't help him because the CER has nothing in it even claiming that the connection is being created because of a redirect from aaa.omniscient.com, let alone proving it. -->(1)A major weakness with the redirect model is that the recipient does not even know who made the referral. Now consider the server discovery model. Bob@donut.com dials in to wondernet.net, and the wondernet AAA server, aaaf.wondernet.net, does a DNS lookup to discover that the AAA server for donut.com is aaah.donut.com. What good does that do aaaf.wondernet.net? How does aaaf.wondernet.net even know whether wondernet and donut have a business relationship? If they do have a business relationship, then why is it so hard to configure aaah.donut.com into aaaf.wondernet.net's peer table? So what good is peer discovery? -->(2)A problem with peer discovery is that a server doing it must have an independent means of knowing what realms it may make peer connections to. Assuming aaaf.wondernet.net does have enough configuration information to feel comfy establishing a peer-to-peer connection with aaah.donut.com, we still have the same problem with had with the redirect model: How does aaah.donut.com know it's o.k. to receive a connection from aaaf.wondernet.net? In either model, if a Diameter server receives a CER from a Diameter node that is not hard configured into its peer table, then we need to ensure that some form of peer-to-peer security is in place. It cannot assume that such a connection is IPsec protected. So it must insist on TLS. But this is nowhere stated. -->(3)A Diameter node receiving a CER request from another Diameter node that is not hard configured into its peer table MUST reject the CER if it does not arrive on a TLS-secured transport connection. Some may assume that the successful establishment of a TLS connection provides sufficient warm fuzzies to both parties to the connection for them to want to bring up a peer-to-peer link and transfer Diameter messages over it. I am not convinced that that is a reasonable assumption except perhaps in some very constrained cases. These constraints need to be fully described in the security considerations section. -->(4)The limitations in the use of TLS to establish trust need to be understood and clearly stated. Requested change: I think the usefulness of the redirect and server discovery models ought to be reexamined in light of the security problems they introduce. It may be that removing redirect and server discovery from Diameter is the best solution. If the working group believes that redirect and server discovery are really needed and still useful when constrained to operate securely, then their use needs to the subject of a genuine security analysis. These capabilities are not present in RADIUS and they greatly complicate peer-to-peer security. In RADIUS a node will only exchange messages with other nodes with which it is configured to communicate. If Diameter introduces dynamic peer-to-peer connections, a new trust model must be created or else the entire AAA infrastructure is at risk. From owner-aaa-wg@merit.edu Wed Mar 6 10:55:59 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14274 for ; Wed, 6 Mar 2002 10:55:59 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 282AF9120D; Wed, 6 Mar 2002 10:55:49 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F06C091270; Wed, 6 Mar 2002 10:55:48 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id EE2B39120D for ; Wed, 6 Mar 2002 10:55:47 -0500 (EST) Received: by segue.merit.edu (Postfix) id C63555DE2A; Wed, 6 Mar 2002 10:55:47 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by segue.merit.edu (Postfix) with ESMTP id 20FA65DDDC for ; Wed, 6 Mar 2002 10:55:47 -0500 (EST) Received: from ipunplugged.com (catsandlogs.local.ipunplugged.com [192.168.4.29]) by mailgw.ipunplugged.com (8.9.3/8.9.3) with ESMTP id QAA20983; Wed, 6 Mar 2002 16:53:18 +0100 Message-ID: <3C8649E7.6080407@ipunplugged.com> Date: Wed, 06 Mar 2002 17:55:03 +0100 From: Johan Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020204 X-Accept-Language: en-us MIME-Version: 1.0 To: john.loughney@nokia.com Cc: fredrik.johansson@ipunplugged.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 244: ELECTION_LOST result code References: <0C1353ABB1DEB74DB067ADFF749C4EEFC64B44@esebe004.NOE.Nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit It was decided at the diameter bakeoff that when a connection lost the election a CEA with ELECTION_LOST as result code should be sent instead of a DPR which would imply that all connections with the peer was severed. Unless this has for some reason been changed afterwards ELECTION_LOST is used and must therefore remain. j john.loughney@nokia.com wrote: >Hi Fredrik, > >>I agree that this issue should be rejected. And I guess it >>has. The strange >>thing is that I can't find the Result Code ELECTION_LOST anywhere in >>base-10? Has it been deleted anyway? >> > >There was continued discussion on this, that it is not used anymore. >So, I have removed it. However, I just noticed one mail I did not >see - I've included the relevant mails. > >So, we are left with 3 possibilities: >1) ELECTION_LOST code removed from the spec >2) Restore ELECTION_LOST code to where it was in Base (Disconnect-Cause AVP) >3) Put ELECTION_LOST into the Result_Code AVP, probably under Transient Failures > >Your thoughts? >John > From owner-aaa-wg@merit.edu Wed Mar 6 10:59:37 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14444 for ; Wed, 6 Mar 2002 10:59:37 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 09B3191270; Wed, 6 Mar 2002 10:59:27 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CB95991272; Wed, 6 Mar 2002 10:59:26 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BF6B191270 for ; Wed, 6 Mar 2002 10:59:25 -0500 (EST) Received: by segue.merit.edu (Postfix) id A29D55DDE4; Wed, 6 Mar 2002 10:59:25 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id ED45A5DDDC for ; Wed, 6 Mar 2002 10:59:24 -0500 (EST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g26FxYZ02569 for ; Wed, 6 Mar 2002 17:59:34 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 6 Mar 2002 17:59:22 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 6 Mar 2002 17:59:23 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Issue 244: ELECTION_LOST result code Date: Wed, 6 Mar 2002 17:59:23 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64B47@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Issue 244: ELECTION_LOST result code Thread-Index: AcHFJ2FIVLu3v0FdSeqC5e5gxLz2fwAAGMfQ From: To: Cc: , X-OriginalArrivalTime: 06 Mar 2002 15:59:23.0827 (UTC) FILETIME=[E28B7030:01C1C527] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA14444 Johan, So 3) Put ELECTION_LOST into the Result_Code AVP, probably under Transient Failures is the corrent answer, correct? John > -----Original Message----- > From: ext Johan Johansson [mailto:johanj@ipunplugged.com] > Sent: 06 March, 2002 18:55 > To: Loughney John (NRC/Helsinki) > Cc: fredrik.johansson@ipunplugged.com; aaa-wg@merit.edu > Subject: Re: [AAA-WG]: Issue 244: ELECTION_LOST result code > > > It was decided at the diameter bakeoff that when a connection > lost the > election a CEA with ELECTION_LOST as result code should be > sent instead > of a DPR which would imply that all connections with the peer was > severed. Unless this has for some reason been changed afterwards > ELECTION_LOST is used and must therefore remain. > > j > > john.loughney@nokia.com wrote: > > >Hi Fredrik, > > > >>I agree that this issue should be rejected. And I guess it > >>has. The strange > >>thing is that I can't find the Result Code ELECTION_LOST anywhere in > >>base-10? Has it been deleted anyway? > >> > > > >There was continued discussion on this, that it is not used anymore. > >So, I have removed it. However, I just noticed one mail I did not > >see - I've included the relevant mails. > > > >So, we are left with 3 possibilities: > >1) ELECTION_LOST code removed from the spec > >2) Restore ELECTION_LOST code to where it was in Base > (Disconnect-Cause AVP) > >3) Put ELECTION_LOST into the Result_Code AVP, probably > under Transient Failures > > > >Your thoughts? > >John > > > > > > From owner-aaa-wg@merit.edu Wed Mar 6 11:15:02 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15529 for ; Wed, 6 Mar 2002 11:15:02 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 4A10E91271; Wed, 6 Mar 2002 11:14:51 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 17D6291272; Wed, 6 Mar 2002 11:14:51 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 11C7E91271 for ; Wed, 6 Mar 2002 11:14:50 -0500 (EST) Received: by segue.merit.edu (Postfix) id DFDCF5DDE4; Wed, 6 Mar 2002 11:14:49 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by segue.merit.edu (Postfix) with ESMTP id EE3E05DDDC for ; Wed, 6 Mar 2002 11:14:48 -0500 (EST) Received: from ipunplugged.com (catsandlogs.local.ipunplugged.com [192.168.4.29]) by mailgw.ipunplugged.com (8.9.3/8.9.3) with ESMTP id RAA21437; Wed, 6 Mar 2002 17:12:20 +0100 Message-ID: <3C864E5D.8040401@ipunplugged.com> Date: Wed, 06 Mar 2002 18:14:05 +0100 From: Johan Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020204 X-Accept-Language: en-us MIME-Version: 1.0 To: john.loughney@nokia.com Cc: fredrik.johansson@ipunplugged.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 244: ELECTION_LOST result code References: <0C1353ABB1DEB74DB067ADFF749C4EEFC64B47@esebe004.NOE.Nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Probably. I guess someone will pop up soon and claim that the socket is just torn down, which is what is in section 5.6 in the peer state machine. I'm not sure if this is just because Pat never got around to documenting the decision or if it was later overturned. The thinking around sending a CEA instead of just tearing down the socket was that it seemed more civilized and can't be misinterpreted as a proper network failure, not even momentarily. If this is no longer the consensus then it should be removed. Or rather not unremoved I guess. j john.loughney@nokia.com wrote: >Johan, > >So 3) Put ELECTION_LOST into the Result_Code AVP, probably > under Transient Failures > >is the corrent answer, correct? > >John > >>-----Original Message----- >>From: ext Johan Johansson [mailto:johanj@ipunplugged.com] >>Sent: 06 March, 2002 18:55 >>To: Loughney John (NRC/Helsinki) >>Cc: fredrik.johansson@ipunplugged.com; aaa-wg@merit.edu >>Subject: Re: [AAA-WG]: Issue 244: ELECTION_LOST result code >> >> >>It was decided at the diameter bakeoff that when a connection >>lost the >>election a CEA with ELECTION_LOST as result code should be >>sent instead >>of a DPR which would imply that all connections with the peer was >>severed. Unless this has for some reason been changed afterwards >>ELECTION_LOST is used and must therefore remain. >> >>j >> >>john.loughney@nokia.com wrote: >> >>>Hi Fredrik, >>> >>>>I agree that this issue should be rejected. And I guess it >>>>has. The strange >>>>thing is that I can't find the Result Code ELECTION_LOST anywhere in >>>>base-10? Has it been deleted anyway? >>>> >>>There was continued discussion on this, that it is not used anymore. >>>So, I have removed it. However, I just noticed one mail I did not >>>see - I've included the relevant mails. >>> >>>So, we are left with 3 possibilities: >>>1) ELECTION_LOST code removed from the spec >>>2) Restore ELECTION_LOST code to where it was in Base >>> >>(Disconnect-Cause AVP) >> >>>3) Put ELECTION_LOST into the Result_Code AVP, probably >>> >>under Transient Failures >> >>>Your thoughts? >>>John >>> >> >> >> > From owner-aaa-wg@merit.edu Wed Mar 6 11:24:27 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15948 for ; Wed, 6 Mar 2002 11:24:27 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7150591273; Wed, 6 Mar 2002 11:24:16 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3F15991275; Wed, 6 Mar 2002 11:24:16 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 515FD91273 for ; Wed, 6 Mar 2002 11:24:15 -0500 (EST) Received: by segue.merit.edu (Postfix) id 320895DE2A; Wed, 6 Mar 2002 11:24:15 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 1AE815DDE4 for ; Wed, 6 Mar 2002 11:24:15 -0500 (EST) Received: from Interlinknetworks.com (nat.interlinknetworks.com [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with ESMTP id D43017E; Wed, 6 Mar 2002 11:24:14 -0500 (EST) Message-ID: <3C8642B8.797C0D5@Interlinknetworks.com> Date: Wed, 06 Mar 2002 11:24:24 -0500 From: David Spence Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: aaa-wg Cc: Bob Kopacz , Tony Johansson Subject: Re: [AAA-WG]: [issue] Need more explanation about handling MN handoffs References: <000701c1c3fc$ff09ece0$f6512844@sanarb01.mi.comcast.net> Content-Type: multipart/mixed; boundary="------------2564374E97981D03A0CCA76E" Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. --------------2564374E97981D03A0CCA76E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I think this is a real showstopper issue. The problem goes to the core of how Diameter identifies nodes and does message forwarding. In order for Diameter MobileIPv4 to support handoffs correctly, the Diameter identities and realms of various Diameter nodes involved in the service need to be known. To solve this issue properly, changes may need to be made to the Mobile IPv4 protocol itself. Given the close interdependence of Mobile IPv4 when used to support CDMA2000 and the Diameter MobileIPv4 application, it puzzles me why "IP Mobility Support for IPv4" (RFC 3220) was allowed to progress to Proposed Standard independently of "Diameter Mobile IPv4 Application" (draft-ietf-aaa-diameter-mobileip-09.txt). Nevertheless, I believe that the only good way to solve the problems of Diameter MobileIPv4 is to add some data elements to the Mobile IPv4 protocol itself. Bob Kopacz wrote: > > Issue : Need more explanation about handling MN handoffs > Submitter name: Bob Kopacz > Submitter email address:bkopacz@interlinknetworks.com > Date first submitted: 03-04-2002 > Reference: > Document: draft-mobileip-09 > Comment type: Technical > Priority: 1 > Section: > > Rationale/Explanation of issue: > > I may be missing something significant here, but ... > > This issue has to do with how an AAAF and AAAH, when given a Home > Agent's IP address, derive the domain/realm/DiameterIdentity > information needed by the Diameter AAA servers. > > This issue may also have some bearing on the relationship between a > DiameterIdentity and a FQDN. > > Unfortunately I don't have a good solution to present, so I'm > indicating what the problems are, as indicated by "-->". It may > be that the solution is to enhance the Mobile IP protocol to > provide more information in the Registration Request. > > THE AAAF's PROBLEM: > ------------------ > Section 1.4. Allocation of Home Agent in Foreign Network, says > the following: > > > 1.4 Allocation of Home Agent in Foreign Network > > > > [...] > > > > In the event that the mobile node requests a home agent in the > > foreign network, and the AAAF authorizes its use, the AAAF MUST set > > the Home-Agent-In-Foreign-Network bit in the MIP-Feature-Vector AVP. > > This could happen when the AAA request is sent to "extend" a mobile > > node's current session. > > > > -->(1) I think some text needs to be added to describe how the AAAF > determines if the HA is in a foreign network. > > That is, I am guessing the method is along these lines: > > Suppose a MN initially connects, is allocated an HA, and later > undergoes a handoff to a new FA and new AAAF. Depending on the MN's > new point of attachment, the new FA and AAAF may or may not be in > the same foreign domain as before, or the foreign domain may > be same but the AAAFs are different, or the handoff may involve > the same AAAF as before. > > In the AMR, the new AAAF is provided with the MN user's NAI and the > HA's IP address. Say the MN user is "bob@donut.com" and the specified > HA IP address is 1.2.3.4. > > The new AAAF does a reverse DNS lookup of tbe HA's IP address, > 1.2.3.4, and the DNS response is that IP address 1.2.3.4 corresponds > to an FQDN of "homeagent86.westcoast.spinach.com". > > Now the AAAF extracts the realm part of the NAI, "donut.com", and > pre-pends a dot, coming up with ".donut.com". The AAAF then checks > if this ".donut.com" string is a trailing substring of the > "homeagent86.westcoast.spinach.com" FQDN. It isn't, so the AAAF > concludes the HA is in a foreign network and sends the > Home-Agent-In-Foreign-Network flag with a value of one. If the tail > of the FQDN matched ".donut.com", the AAAF would conclude the HA was > in the home network. > > -->(2) This may or may not be anywhere close to the AAAF's method. > At any rate, the method should be described in sufficient detail > for an AAAF implementation. > > -->(3) If this DNS reverse lookup is indeed the AAAF's method to > make this "home-agent-is-in-a-foreign-network" determination, then > this introduces a delay into the handoff, and should probably be > noted. > > THE AAAH's PROBLEM > ------------------ > Section 1.2 Inter-Realm Mobile IP, says the following: > > > > > 1.2 Inter-Realm Mobile IP > > > > [...] > > > > If the Mobile Node was successfully authenticated, the AAAH checks if > > the Home Agent was located in the foreign realm, by checking the > > Home-Agent-In-Foreign-Network flag of the MIP-Feature-Vector AVP. If > > the flag is enabled, then the Home Agent is located in the foreign > > realm then AAAH sends an HAR message to AAAF which contains a MIP- > > Reg-Request AVP. > > Continuing the example, suppose the AAAF has determined that the > HA is in a foreign network, and has forwarded the AMR to the home > realm. The AAAH receives the AMR, and the AMR indicates the HA's > address is 1.2.3.4, the Home-Agent-In-Foreign-Network flag is ON, > and the User-Name is "bob@donut.com". > > -->(4) Now the AAAH wants to send an HAR to the HA. But Diameter > routes by Destination-Realm and Destination-Host, not by IP address, > so the AAAH has to somehow come up with the HA's DiameterIdentity > for the Destination-Host AVP of the HAR, and the HA's realm for the > Destination-Realm of the HAR. > > AAAH's 1st Problem: How to discover the HA's DiameterIdentity: > > If the AAAH maintains session-state, then this HA identity > information can be part of the cached session-state information, > and there may be no problem. But there is a problem if either > (a) the AAAH is not session-stateful, or (b) the AAAH is > session-stateful but has no session-state info because the handoff > AMR is received by a different AAAH than the AAAH which received > the original AMR for the session. > > So if we have case (a) or (b), the hapless AAAH is holding the HA's > IP address, and needs to come up with the HA's realm and > DiameterIdentity. The method might be along these lines: > > The AAAH can do a reverse lookup of the IP address 1.2.3.4, and > again DNS returns an FQDN of "homeagent86.westcoast.spinach.com" > > *If* the DiameterIdentity is the same as the FQDN, then the AAAH > constructs the HAR's Destination-Host = > "homeagent86.westcoast.spinach.com". (An aside: I haven't kept up > with the recent DiameterIdentity thread, but I thought the > DiameterIdentity needed to be something like "FQDN+extra", so that > multiple Diameter applications could run on the same box. In > which case the FQDN isn't sufficient). > > AAAH's 2nd Problem: How to discover the HA's Realm: > > The AAAH still needs to derive the HAR's Destination-Realm, from > the FQDN. The realm is probably either "westcoast.spinach.com" > or "spinach.com". Does the AAAH have a way to know for sure, or > is the best-guess algorithm to say that the realm is what > follows the next-to-last dot of the FQDN, e.g. "spinach.com". > > -->(5) Again, this may or may not be anywhere close to what the > AAAH needs to do to surmise the HA's realm and identity. At any > rate, the method should be described in sufficient detail to > implement an AAAH. > > -->(6) If this DNS reverse lookup is indeed part of the AAAH's > method, then this introduces a delay (maybe a 2nd delay depending on > what the AAAF had to do) into the handoff, and should probably be > noted. > > -->(7) It seems the AAAF and AAAH are both starting from scratch > with the HA's IP address, and duplicating efforts and delays. Maybe > the AAAF's DNS-lookup results (or whatever useful knowledge the AAAF > possesses) could be passed along to the AAAH. --------------2564374E97981D03A0CCA76E Content-Type: text/x-vcard; charset=us-ascii; name="DSpence.vcf" Content-Description: Card for David Spence Content-Disposition: attachment; filename="DSpence.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:; tel;fax:+1 734 821 1235 tel;work:+1 734 821 1203 x-mozilla-html:FALSE url:http://www.interlinknetworks.com org:Interlink Networks, Inc. adr:;;775 Technology Dr., Suite 200;Ann Arbor;MI;48108;USA version:2.1 email;internet:DSpence@Interlinknetworks.com title:Architect fn:David Spence end:vcard --------------2564374E97981D03A0CCA76E-- From owner-aaa-wg@merit.edu Wed Mar 6 11:42:58 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17218 for ; Wed, 6 Mar 2002 11:42:58 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id C66D491276; Wed, 6 Mar 2002 11:42:47 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9A41B91277; Wed, 6 Mar 2002 11:42:47 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A065191276 for ; Wed, 6 Mar 2002 11:42:46 -0500 (EST) Received: by segue.merit.edu (Postfix) id 892AA5DE41; Wed, 6 Mar 2002 11:42:46 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 46F675DDE4 for ; Wed, 6 Mar 2002 11:42:46 -0500 (EST) Received: from Interlinknetworks.com (nat.interlinknetworks.com [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with ESMTP id F0C407E; Wed, 6 Mar 2002 11:42:45 -0500 (EST) Message-ID: <3C86470F.10C834FA@Interlinknetworks.com> Date: Wed, 06 Mar 2002 11:42:55 -0500 From: David Spence Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Walker, Jesse" Cc: "'Bernard Aboba'" , aaa-wg@merit.edu Subject: Re: [AAA-WG]: RE: Why NASREQ Key Distribution is insecure (fwd) References: <10C8636AE359D4119118009027AE9987120B834E@FMSMSX34> Content-Type: multipart/mixed; boundary="------------C9F3075A238BBB783A048BD7" Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. --------------C9F3075A238BBB783A048BD7 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I hesitate to bring it up, but what does all this mean for the key distribution problems of Diameter MobileIPv4 where we now have as many as seven entities involved (MN, old FA, old AAAF, new FA, new AAAF, HA, AAAH) belonging to four different parties (MN, old F, new F, H)? "Walker, Jesse" wrote: > > Thanks Bernard, > > This is a very good paper that will help people understand the issues. This > has been one of the most influential papers ever published to help form the > thinking about these protocols in the cryptographic community. This is some > of the most inspired and original work by two of the very best > cryptographers in the world. > > One thing to note about 3PP is, however, that almost as soon as it was > published somone pointed out a problem with it, even though the proof of > security is entirely valid! The problem arises because one of the > assumptions is wrong. The wrong assumption is that an adversary could use > the Test operation only once and then only at the "end of the game." Real > adversaries don't restrict themselves in this way. So Bellare and Rogaway > fixed this assumption and their proof and went on, although they never > published this. Victor Shoup has published one way to fix it in > http://shoup.net/papers/skey.pdf. > > The point is that key distribution is a damnably hard and subtle problem in > ways that are not apparent even to the very best experts in the world. My > recommendation to 802.11 has been and is that we need to take any one of > several protocols that the crypto community has confidence in and then adapt > it to our setting, and I make the same appeal now to AAA, because fixing > this problem is outside the scope of 802.11's charter, but they cannot > succeed in fixing their security without getting key distribution correct. > Trying to roll our own is just a disaster waiting to happen. > > -- Jesse > > -----Original Message----- > From: Bernard Aboba [mailto:aboba@internaut.com] > Sent: Monday, March 04, 2002 9:43 PM > To: aaa-wg@merit.edu > Cc: jesse.walker@intel.com > Subject: Re: Why NASREQ Key Distribution is insecure (fwd) > > Here is a paper by Bellare and Rogaway paper on provably > secure 3 way key distribution which may relate to this issue. > > http://www.drizzle.com/~aboba/AAA/3pkd.pdf > > On Mon, 4 Mar 2002, Bernard Aboba wrote: > > > This is followup documentation on the issue posted to the list > > earlier. > > > > --------------------------------------------------------------------- > > From: Jesse Walker : > > To: eap@frascone.com > > > > > > >Given that the AS and AP trust each other (assumed), why > > >is a reasonable cryptographic protocol (such as CMS or even IPSec) is > > >insufficient to protect the transfer of a STA-AP session key from the AS > to > > >the AP? > > > > There has been in fact ample discussion around exactly these points. There > > is, for instance, the whole key handoff discussion, of which AS-AP handoff > > is a special case. As a second example, there is the flap around the > > Arbaugh-Mishra 802.1X paper, which echos many of our key handoff > > discussions, and which we have also discussed. --------------C9F3075A238BBB783A048BD7 Content-Type: text/x-vcard; charset=us-ascii; name="DSpence.vcf" Content-Description: Card for David Spence Content-Disposition: attachment; filename="DSpence.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:; tel;fax:+1 734 821 1235 tel;work:+1 734 821 1203 x-mozilla-html:FALSE url:http://www.interlinknetworks.com org:Interlink Networks, Inc. adr:;;775 Technology Dr., Suite 200;Ann Arbor;MI;48108;USA version:2.1 email;internet:DSpence@Interlinknetworks.com title:Architect fn:David Spence end:vcard --------------C9F3075A238BBB783A048BD7-- From owner-aaa-wg@merit.edu Wed Mar 6 12:08:32 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18838 for ; Wed, 6 Mar 2002 12:08:32 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 53C1691278; Wed, 6 Mar 2002 12:08:19 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1D7F691279; Wed, 6 Mar 2002 12:08:19 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1F83B91278 for ; Wed, 6 Mar 2002 12:08:18 -0500 (EST) Received: by segue.merit.edu (Postfix) id EE0B05DE04; Wed, 6 Mar 2002 12:08:17 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id D7EF35DDE4 for ; Wed, 6 Mar 2002 12:08:17 -0500 (EST) Received: from Interlinknetworks.com (nat.interlinknetworks.com [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with ESMTP id 85AEB7E; Wed, 6 Mar 2002 12:08:17 -0500 (EST) Message-ID: <3C864D0A.66370EC@Interlinknetworks.com> Date: Wed, 06 Mar 2002 12:08:26 -0500 From: David Spence Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Bob Kopacz Cc: John Loughney , Stephen Farrell , Tony Johansson , aaa-wg Subject: Re: [AAA-WG]: [issue] Combine occurrence rules tables with message ABNF References: Content-Type: multipart/mixed; boundary="------------1EDBC89DBB6EBE57FE8C7F8D" Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. --------------1EDBC89DBB6EBE57FE8C7F8D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I support this issue because I don't like redundancies in standards even if the standards are consistently redundant instead of inconsistently redundant as in our case. I might be even bolder. Instead of publishing our own variant of ABNF and forcing the reader to understand it, how about doing away with the ABNF altogether and expanding the occurrence rules tables to indicate the message placement rules -- first fixed section, mid-section, end fixed section? Bob Kopacz wrote: > > Issue : Combine occurrence rules tables with message ABNF > Submitter name: Bob Kopacz > Submitter email address:bkopacz@interlinknetworks.com > Date first submitted: 03-05-2002 > Reference: > Document: all drafts > Comment type: Technical > Priority: 1 > Section: > > Rationale/Explanation of issue: > > 1. There are often conflicts between the message ABNF and the > [redundant] information in the occurrence rules tables. Combining > the message ABNF with the occurrence rules would create one location > for the message AVP occurrence information, and eliminate the > redundancies and neverending conflicts. > > 2. The current ABNF is a little tricky, in that the default number > of occurrences depends on the type of braces around the AVPs. So > replace the and the *'s with the explicit counts as in the > occurrence rules, e.g. 0, 0+, 0-1, etc. Then we don't need both the > {}braces and the []braces, as the numeric counts indicate required > versus optional. > > For example, the current ABNF for the AA-Mobile-Node-Request is: > > > ::= < Diameter Header: 260, REQ, PXY > > > < Session-Id > > > { Auth-Application-Id } > > { User-Name } > > { Destination-Realm } > > { Origin-Host } > > { Origin-Realm } > > { MIP-Reg-Request } > > { MIP-MN-AAA-Auth } > > [ Destination-Host ] > > [ Origin-State-Id ] > > [ MIP-Mobile-Node-Address ] > > [ MIP-Home-Agent-Address ] > > [ MIP-Feature-Vector ] > > [ MIP-Originating-Foreign-AAA ] > > [ Authorization-Lifetime ] > > [ Auth-Grace-Period ] > > [ Auth-Session-State ] > > [ MIP-FA-Challenge ] > > [ MIP-Candidate-Home-Agent-Host ] > > * [ AVP ] > > * [ Proxy-Info ] > > * [ Route-Record ] > > The occurrence rule tables could be absorbed into the message ABNF > (and eliminated), with a message ABNF that looks like: > > > ::= < Diameter Header: 260, REQ, PXY > > > 1 < Session-Id > > > 1 [ Auth-Application-Id ] > > 1 [ Destination-Realm ] > > 1 [ MIP-Reg-Request ] > > 1 [ MIP-MN-AAA-Auth ] > > 1 [ Origin-Host ] > > 1 [ Origin-Realm ] > > 1 [ User-Name ] > > 0-1 [ Authorization-Lifetime ] > > 0-1 [ Auth-Grace-Period ] > > 0-1 [ Auth-Session-State ] > > 0-1 [ Accounting-Multi-Session-Id ] > > 0-1 [ Destination-Host ] > > 0-1 [ MIP-Candidate-Home-Agent-Host ] > > 0-1 [ MIP-Originating-Foreign-AAA ] > > 0-1 [ MIP-FA-Challenge ] > > 0-1 [ MIP-Feature-Vector ] > > 0-1 [ MIP-Home-Agent-Address ] > > 0-1 [ MIP-Mobile-Node-Address ] > > 0-1 [ Original-State-Id ] > > 0+ [ Proxy-Info ] > > 0+ [ Route-Record ] > > 0 [ Acct-Application-Id ] > > 0 [ Error-Message ] > > 0 [ Error-Reporting-Host ] > > 0 [ MIP-FA-to-HA-Key ] > > 0 [ MIP-FA-to-HA-SPI ] > > 0 [ MIP-FA-to-MN-Key ] > > 0 [ MIP-FA-to-MN-SPI ] > > 0 [ MIP-Filter-Rule ] > > 0 [ MIP-Foreign-Agent-Host ] > > 0 [ MIP-HA-to-FA-Key ] > > 0 [ MIP-HA-to-MN-Key ] > > 0 [ MIP-Key-Lifetime ] > > 0 [ MIP-MN-to-FA-Key ] > > 0 [ MIP-MN-to-HA-Key ] > > 0 [ MIP-Reg-Reply ] > > 0 [ Redirect-Host ] > > 0 [ Redirect-Host-Usage ] > > 0 [ Redirect-Max-Cache-Time ] > > 0 [ Result-Code ] > > 0 [ Re-Auth-Request-Type ] > > 0 [ Session-Timeout ] > > 0+ [ AVP ] > > 3. This is not a significant change to the drafts. > > Requested Change: > > Do this in all the Diameter drafts. --------------1EDBC89DBB6EBE57FE8C7F8D Content-Type: text/x-vcard; charset=us-ascii; name="DSpence.vcf" Content-Description: Card for David Spence Content-Disposition: attachment; filename="DSpence.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:; tel;fax:+1 734 821 1235 tel;work:+1 734 821 1203 x-mozilla-html:FALSE url:http://www.interlinknetworks.com org:Interlink Networks, Inc. adr:;;775 Technology Dr., Suite 200;Ann Arbor;MI;48108;USA version:2.1 email;internet:DSpence@Interlinknetworks.com title:Architect fn:David Spence end:vcard --------------1EDBC89DBB6EBE57FE8C7F8D-- From owner-aaa-wg@merit.edu Wed Mar 6 12:13:17 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19230 for ; Wed, 6 Mar 2002 12:13:16 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id AC6A791279; Wed, 6 Mar 2002 12:13:06 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 825D99127A; Wed, 6 Mar 2002 12:13:06 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8253191279 for ; Wed, 6 Mar 2002 12:13:05 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6751D5DE04; Wed, 6 Mar 2002 12:13:05 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 2454A5DDE4 for ; Wed, 6 Mar 2002 12:13:05 -0500 (EST) Received: from Interlinknetworks.com (nat.interlinknetworks.com [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with ESMTP id DF59E7E; Wed, 6 Mar 2002 12:13:04 -0500 (EST) Message-ID: <3C864E2A.509A6E5A@Interlinknetworks.com> Date: Wed, 06 Mar 2002 12:13:14 -0500 From: David Spence Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Ext-Venkata.Ghadiyaram@nokia.com Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Can CER from unknown hosts cause Peer Table entries References: <9E3407CE45911B4097632389B77B202306D04A@esebe014.NOE.Nokia.com> Content-Type: multipart/mixed; boundary="------------DA43A2CE5636551BC9E25030" Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. --------------DA43A2CE5636551BC9E25030 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I think I understand. How about if I state this in terms of an issue and you can check and see if I have it right? Ext-Venkata.Ghadiyaram@nokia.com wrote: > > Hi, > > By peer table entry, I meant an entry that would allow to recreate a connection. As this is not possible, should the specification say, > "If a CER from and unknown peer is answered with a successful CEA, the lifetime of the peer entry is equal to the lifetime of the transport connection. In case of a transport failure, all the pending transactions destied to the unknown per can be discarded." > > Regards, > Kishore > > -----Original Message----- > From: ext David Spence [mailto:DSpence@Interlinknetworks.com] > Sent: 05. March 2002 18:39 > To: Ghadiyaram Venkata (EXT-TataConsultancy/Helsinki) > Cc: aaa-wg@merit.edu > Subject: Re: [AAA-WG]: Can CER from unknown hosts cause Peer Table > entries > > Ext-Venkata.Ghadiyaram@nokia.com wrote: > > > > Hi, > > > > Referring section 5.3 on capabilities-exchange which says, > > > > "If the local policy permits receiving CERs from unknown hosts, a successful CEA MAY be returned." > > I have the following queries, if someone can clarify. > > > > If a node accepts CER from an unknown host and returns a successful CEA, does it amount to a peer discovery and can an entry be made in the peer table. > > Yes, this means that you have either been "discovered" or redirected to. > You will need to decide whether you want to accept a connection from the > originator of the CER. I think there are definite security concerns here > which I will raise in a separate message. > > > If this is possible, I have further questions. The information present in a CER may not be sufficient to make a peer table entry. For example the CER does not contain the port on which the peer listens for connections, the transport protocols that the peer supports etc. > > If, by a peer table entry, you mean do you have enough information to create > an entry that would allow you to recreate the connection if the connection > you are establishing now gets broken, the answer is no. In this case, he > wanted to talk to you, so it's his responsiblity to re-establish the > connection. As far as the current connection is concerned, however, you > don't need any further information. You don't need the port number on which > he listens. You know what transport protocol is in use for this > connection. And whatever security needs to be established has already been > established, you hope, because, by CER/CEA time, the security stuff has > already happened. > > > > > Thanks in advance. > > > > Regards, > > Kishore > >... --------------DA43A2CE5636551BC9E25030 Content-Type: text/x-vcard; charset=us-ascii; name="DSpence.vcf" Content-Description: Card for David Spence Content-Disposition: attachment; filename="DSpence.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:; tel;fax:+1 734 821 1235 tel;work:+1 734 821 1203 x-mozilla-html:FALSE url:http://www.interlinknetworks.com org:Interlink Networks, Inc. adr:;;775 Technology Dr., Suite 200;Ann Arbor;MI;48108;USA version:2.1 email;internet:DSpence@Interlinknetworks.com title:Architect fn:David Spence end:vcard --------------DA43A2CE5636551BC9E25030-- From owner-aaa-wg@merit.edu Wed Mar 6 12:24:04 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20057 for ; Wed, 6 Mar 2002 12:24:04 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2A8A39127A; Wed, 6 Mar 2002 12:23:54 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F091E9127B; Wed, 6 Mar 2002 12:23:53 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CE8DF9127A for ; Wed, 6 Mar 2002 12:23:51 -0500 (EST) Received: by segue.merit.edu (Postfix) id 94FCD5DDA0; Wed, 6 Mar 2002 12:23:50 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 7CF6A5DD95 for ; Wed, 6 Mar 2002 12:23:50 -0500 (EST) Received: from Interlinknetworks.com (nat.interlinknetworks.com [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with ESMTP id 48BA37E for ; Wed, 6 Mar 2002 12:23:50 -0500 (EST) Message-ID: <3C8650AF.66FC43CA@Interlinknetworks.com> Date: Wed, 06 Mar 2002 12:23:59 -0500 From: David Spence Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: AAA Working Group Subject: [AAA-WG]: [issue] Allowance for temporary peer connections Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Subject: [issue] Allowance for temporary peer connections Submitter name: Ghadiyaram Venkata, David Spence Submitter email address: Ext-Venkata.Ghadiyaram@nokia.com, DSpence@Interlinknetworks.com Date first submitted: March 6, 2002 Reference: Document: Base Comment type: T Priority: 1 Section: Rationale/Explanation of issue A CER received from a previously unknown peer (such as would happen as a result of peer discovery or a redirect) does not contain complete information as to how the recipient could recreate the peer connection if it is lost. Requested change: Add the following text: "If a CER from and unknown peer is answered with a successful CEA, the lifetime of the peer entry is equal to the lifetime of the transport connection. In case of a transport failure, all the pending transactions destined to the unknown peer can be discarded." -- David Spence email: DSpence@Interlinknetworks.com Interlink Networks, Inc. phone: (734) 821-1203 775 Technology Drive, Suite 200 fax: (734) 821-1235 Ann Arbor, MI 48108 U.S.A. From owner-aaa-wg@merit.edu Wed Mar 6 12:25:00 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20112 for ; Wed, 6 Mar 2002 12:24:59 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 56AB59127B; Wed, 6 Mar 2002 12:24:44 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 248099127C; Wed, 6 Mar 2002 12:24:44 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1C55E9127B for ; Wed, 6 Mar 2002 12:24:43 -0500 (EST) Received: by segue.merit.edu (Postfix) id 01CCB5DDA0; Wed, 6 Mar 2002 12:24:43 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id DF0075DD95 for ; Wed, 6 Mar 2002 12:24:42 -0500 (EST) Received: from phoenix (nat.interlinknetworks.com [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with SMTP id 6FEA47E; Wed, 6 Mar 2002 12:24:42 -0500 (EST) From: "Bob Kopacz" To: "David Spence" Cc: "John Loughney" , "Stephen Farrell" , "Tony Johansson" , "aaa-wg" Subject: RE: [AAA-WG]: [issue] Combine occurrence rules tables with message ABNF Date: Wed, 6 Mar 2002 12:23:44 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <3C864D0A.66370EC@Interlinknetworks.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi David, > -----Original Message----- > From: David Spence [mailto:DSpence@Interlinknetworks.com] > Sent: Wednesday, March 06, 2002 12:08 PM > To: Bob Kopacz > Cc: John Loughney; Stephen Farrell; Tony Johansson; aaa-wg > Subject: Re: [AAA-WG]: [issue] Combine occurrence rules tables with > message ABNF > > I support this issue because I don't like redundancies in standards even if > the standards are consistently redundant instead of inconsistently redundant > as in our case. > > I might be even bolder. Instead of publishing our own variant of ABNF and > forcing the reader to understand it, how about doing away with the ABNF > altogether and expanding the occurrence rules tables to indicate the message > placement rules -- first fixed section, mid-section, end fixed section? This idea of moving the message placement defintions into the occurrence rules, rather than the occurrence rules into the message ABNF, has a couple of virtues: 1. It is more compact, as one can have a matrix with the AVPs as rows and the message types as columns, so all the rules for all the messages are in one table (actually two tables, one for Accounting). 2. Having all the rules for all the messages in one table makes it easy to compare what is in a request against what is in the answer. And for Mobile-IP, it makes it easy to see what comes in the AMR versus what goes out in the HAR. And for STRs/RARs/etc, one can easily spot inconsistencies where one type of answer forbids echoing of AVP X (e.g. User-Name), while another type of answer requires it. > Bob Kopacz wrote: > > > > Issue : Combine occurrence rules tables with message ABNF > > Submitter name: Bob Kopacz > > Submitter email address:bkopacz@interlinknetworks.com > > Date first submitted: 03-05-2002 > > Reference: > > Document: all drafts > > Comment type: Technical > > Priority: 1 > > Section: > > > > Rationale/Explanation of issue: > > > > 1. There are often conflicts between the message ABNF and the > > [redundant] information in the occurrence rules tables. Combining > > the message ABNF with the occurrence rules would create one location > > for the message AVP occurrence information, and eliminate the > > redundancies and neverending conflicts. > > > > 2. The current ABNF is a little tricky, in that the default number > > of occurrences depends on the type of braces around the AVPs. So > > replace the and the *'s with the explicit counts as in the > > occurrence rules, e.g. 0, 0+, 0-1, etc. Then we don't need both the > > {}braces and the []braces, as the numeric counts indicate required > > versus optional. > > > > For example, the current ABNF for the AA-Mobile-Node-Request is: > > > > > ::= < Diameter Header: 260, REQ, PXY > > > > < Session-Id > > > > { Auth-Application-Id } > > > { User-Name } > > > { Destination-Realm } > > > { Origin-Host } > > > { Origin-Realm } > > > { MIP-Reg-Request } > > > { MIP-MN-AAA-Auth } > > > [ Destination-Host ] > > > [ Origin-State-Id ] > > > [ MIP-Mobile-Node-Address ] > > > [ MIP-Home-Agent-Address ] > > > [ MIP-Feature-Vector ] > > > [ MIP-Originating-Foreign-AAA ] > > > [ Authorization-Lifetime ] > > > [ Auth-Grace-Period ] > > > [ Auth-Session-State ] > > > [ MIP-FA-Challenge ] > > > [ MIP-Candidate-Home-Agent-Host ] > > > * [ AVP ] > > > * [ Proxy-Info ] > > > * [ Route-Record ] > > > > The occurrence rule tables could be absorbed into the message ABNF > > (and eliminated), with a message ABNF that looks like: > > > > > ::= < Diameter Header: 260, REQ, PXY > > > > 1 < Session-Id > > > > 1 [ Auth-Application-Id ] > > > 1 [ Destination-Realm ] > > > 1 [ MIP-Reg-Request ] > > > 1 [ MIP-MN-AAA-Auth ] > > > 1 [ Origin-Host ] > > > 1 [ Origin-Realm ] > > > 1 [ User-Name ] > > > 0-1 [ Authorization-Lifetime ] > > > 0-1 [ Auth-Grace-Period ] > > > 0-1 [ Auth-Session-State ] > > > 0-1 [ Accounting-Multi-Session-Id ] > > > 0-1 [ Destination-Host ] > > > 0-1 [ MIP-Candidate-Home-Agent-Host ] > > > 0-1 [ MIP-Originating-Foreign-AAA ] > > > 0-1 [ MIP-FA-Challenge ] > > > 0-1 [ MIP-Feature-Vector ] > > > 0-1 [ MIP-Home-Agent-Address ] > > > 0-1 [ MIP-Mobile-Node-Address ] > > > 0-1 [ Original-State-Id ] > > > 0+ [ Proxy-Info ] > > > 0+ [ Route-Record ] > > > 0 [ Acct-Application-Id ] > > > 0 [ Error-Message ] > > > 0 [ Error-Reporting-Host ] > > > 0 [ MIP-FA-to-HA-Key ] > > > 0 [ MIP-FA-to-HA-SPI ] > > > 0 [ MIP-FA-to-MN-Key ] > > > 0 [ MIP-FA-to-MN-SPI ] > > > 0 [ MIP-Filter-Rule ] > > > 0 [ MIP-Foreign-Agent-Host ] > > > 0 [ MIP-HA-to-FA-Key ] > > > 0 [ MIP-HA-to-MN-Key ] > > > 0 [ MIP-Key-Lifetime ] > > > 0 [ MIP-MN-to-FA-Key ] > > > 0 [ MIP-MN-to-HA-Key ] > > > 0 [ MIP-Reg-Reply ] > > > 0 [ Redirect-Host ] > > > 0 [ Redirect-Host-Usage ] > > > 0 [ Redirect-Max-Cache-Time ] > > > 0 [ Result-Code ] > > > 0 [ Re-Auth-Request-Type ] > > > 0 [ Session-Timeout ] > > > 0+ [ AVP ] > > > > 3. This is not a significant change to the drafts. > > > > Requested Change: > > > > Do this in all the Diameter drafts. From owner-aaa-wg@merit.edu Thu Mar 7 10:02:41 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28387 for ; Thu, 7 Mar 2002 10:02:40 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7FB2291298; Thu, 7 Mar 2002 10:01:46 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 40F1A912A3; Thu, 7 Mar 2002 10:01:46 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2F0FE91298 for ; Thu, 7 Mar 2002 10:01:45 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0E7825DDAC; Thu, 7 Mar 2002 10:01:45 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 4A8E85DD98 for ; Thu, 7 Mar 2002 10:01:44 -0500 (EST) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g27F1QZ02156 for ; Thu, 7 Mar 2002 17:01:26 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 7 Mar 2002 17:01:15 +0200 Received: from esebe014.NOE.Nokia.com ([172.21.138.53]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Thu, 7 Mar 2002 17:01:15 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [AAA-WG]: Host-IP-Address AVP in CER and CEA Date: Thu, 7 Mar 2002 17:00:45 +0200 Message-ID: <9E3407CE45911B4097632389B77B202306D04E@esebe014.NOE.Nokia.com> Thread-Topic: Host-IP-Address AVP in CER and CEA Thread-Index: AcHF6WCAlRROnyXVEdatcAAADnz2vQ== From: To: X-OriginalArrivalTime: 07 Mar 2002 15:01:15.0596 (UTC) FILETIME=[EDCF60C0:01C1C5E8] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA28387 Hi, I have one query regarding the 1*{Host-IP-Address} AVP in CER and CEA commands. The IPAddress corresponding to the sender, is a part of the TCP connection or an SCTP association(all the potential addresses in case of a multihomed host). When this information can be obtained from the transport layer messages, is it not redundant to send it as part of CER/CEA. Regards, Kishore From owner-aaa-wg@merit.edu Thu Mar 7 11:01:38 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02639 for ; Thu, 7 Mar 2002 11:01:38 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D9B169129A; Thu, 7 Mar 2002 11:00:45 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A56799129B; Thu, 7 Mar 2002 11:00:45 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 973CB9129A for ; Thu, 7 Mar 2002 11:00:44 -0500 (EST) Received: by segue.merit.edu (Postfix) id 788685DE2A; Thu, 7 Mar 2002 11:00:44 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 90BBE5DDFE for ; Thu, 7 Mar 2002 11:00:43 -0500 (EST) Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g27G0qZ05771 for ; Thu, 7 Mar 2002 18:00:52 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 7 Mar 2002 18:00:41 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Thu, 7 Mar 2002 18:00:41 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: [issue] Allowance for temporary peer connections Date: Thu, 7 Mar 2002 18:00:41 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD8DFB5@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: [issue] Allowance for temporary peer connections Thread-Index: AcHFM8wFPoDjfzWCS0SIq41yQanRawAo7uIw From: To: , X-OriginalArrivalTime: 07 Mar 2002 16:00:41.0741 (UTC) FILETIME=[3B65EBD0:01C1C5F1] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA02639 David, Where should this be added to? John > -----Original Message----- > From: ext David Spence [mailto:DSpence@Interlinknetworks.com] > Sent: 06 March, 2002 19:24 > To: AAA Working Group > Subject: [AAA-WG]: [issue] Allowance for temporary peer connections > > > Subject: [issue] Allowance for temporary peer connections > > Submitter name: Ghadiyaram Venkata, David Spence > Submitter email address: Ext-Venkata.Ghadiyaram@nokia.com, > DSpence@Interlinknetworks.com > Date first submitted: March 6, 2002 > Reference: > Document: Base > Comment type: T > Priority: 1 > Section: > Rationale/Explanation of issue > > A CER received from a previously unknown peer (such as would > happen as a result of peer discovery or a redirect) does not contain > complete information as to how the recipient could recreate the peer > connection if it is lost. > > Requested change: > > Add the following text: > > "If a CER from and unknown peer is answered with a successful CEA, the > lifetime of the peer entry is equal to the lifetime of the transport > connection. In case of a transport failure, all the pending > transactions > destined to the unknown peer can be discarded." > > -- > David Spence email: > DSpence@Interlinknetworks.com > Interlink Networks, Inc. phone: (734) 821-1203 > 775 Technology Drive, Suite 200 fax: (734) 821-1235 > Ann Arbor, MI 48108 > U.S.A. > From owner-aaa-wg@merit.edu Thu Mar 7 11:10:03 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03307 for ; Thu, 7 Mar 2002 11:10:02 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 29A889129B; Thu, 7 Mar 2002 11:09:46 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EB8B09129C; Thu, 7 Mar 2002 11:09:45 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 07B919129B for ; Thu, 7 Mar 2002 11:09:44 -0500 (EST) Received: by segue.merit.edu (Postfix) id DEFF25DE4D; Thu, 7 Mar 2002 11:09:44 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 30A475DE41 for ; Thu, 7 Mar 2002 11:09:44 -0500 (EST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g27G9rZ11393 for ; Thu, 7 Mar 2002 18:09:53 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 7 Mar 2002 18:09:40 +0200 Received: from esebe014.NOE.Nokia.com ([172.21.138.53]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Thu, 7 Mar 2002 18:09:43 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: [issue] Allowance for temporary peer connections Date: Thu, 7 Mar 2002 18:09:08 +0200 Message-ID: <9E3407CE45911B4097632389B77B202306D04F@esebe014.NOE.Nokia.com> Thread-Topic: [AAA-WG]: [issue] Allowance for temporary peer connections Thread-Index: AcHFM8wFPoDjfzWCS0SIq41yQanRawAo7uIwAAavZGA= From: To: , , X-OriginalArrivalTime: 07 Mar 2002 16:09:43.0021 (UTC) FILETIME=[7E06B1D0:01C1C5F2] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA03307 Hi, In my view it should be added to section 5.3 Capabilities Exchange at the end of the paragraph on "CERs received from unknown peers ......" Ghadiyaram Venkata Kishore -----Original Message----- From: Loughney John (NRC/Helsinki) Sent: 07. March 2002 18:01 To: DSpence@Interlinknetworks.com; aaa-wg@merit.edu Subject: RE: [AAA-WG]: [issue] Allowance for temporary peer connections David, Where should this be added to? John > -----Original Message----- > From: ext David Spence [mailto:DSpence@Interlinknetworks.com] > Sent: 06 March, 2002 19:24 > To: AAA Working Group > Subject: [AAA-WG]: [issue] Allowance for temporary peer connections > > > Subject: [issue] Allowance for temporary peer connections > > Submitter name: Ghadiyaram Venkata, David Spence > Submitter email address: Ext-Venkata.Ghadiyaram@nokia.com, > DSpence@Interlinknetworks.com > Date first submitted: March 6, 2002 > Reference: > Document: Base > Comment type: T > Priority: 1 > Section: > Rationale/Explanation of issue > > A CER received from a previously unknown peer (such as would > happen as a result of peer discovery or a redirect) does not contain > complete information as to how the recipient could recreate the peer > connection if it is lost. > > Requested change: > > Add the following text: > > "If a CER from and unknown peer is answered with a successful CEA, the > lifetime of the peer entry is equal to the lifetime of the transport > connection. In case of a transport failure, all the pending > transactions > destined to the unknown peer can be discarded." > > -- > David Spence email: > DSpence@Interlinknetworks.com > Interlink Networks, Inc. phone: (734) 821-1203 > 775 Technology Drive, Suite 200 fax: (734) 821-1235 > Ann Arbor, MI 48108 > U.S.A. > From owner-aaa-wg@merit.edu Sat Mar 9 19:30:40 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19284 for ; Sat, 9 Mar 2002 19:30:40 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id CE46691206; Sat, 9 Mar 2002 19:21:09 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9A25791210; Sat, 9 Mar 2002 19:21:09 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 91EBF91206 for ; Sat, 9 Mar 2002 19:21:08 -0500 (EST) Received: by segue.merit.edu (Postfix) id 705C35DDE9; Sat, 9 Mar 2002 19:21:08 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from fep01-svc.swip.net (fep01.swip.net [130.244.199.129]) by segue.merit.edu (Postfix) with ESMTP id CBF575DD8F for ; Sat, 9 Mar 2002 19:21:07 -0500 (EST) Received: from ipunplugged.com ([213.100.60.212]) by fep01-svc.swip.net with ESMTP id <20020310002052.BMVB16705.fep01-svc.swip.net@ipunplugged.com> for ; Sun, 10 Mar 2002 01:20:52 +0100 Message-ID: <3C8AB4CD.6090403@ipunplugged.com> Date: Sun, 10 Mar 2002 02:20:13 +0100 From: Johan Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020204 X-Accept-Language: en-us MIME-Version: 1.0 To: AAA Working Group Subject: [AAA-WG]: [issue] Purpose of MIP-Foreign-Agent-Host Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Subject: [issue] Purpose of MIP-Foreign-Agent-Host Submitter name: Johan Johansson Submitter email address: johanj@ipunplugged.com Date first submitted: March 10, 2002 Reference: Document: Mip Comment type: T Priority: 2 Section: 4.8 + ABNFs and occurence rules Rationale/Explanation of issue The MIP-Foreign-Agent-Host avp is mandatory in both the HAR and the HAA. The only text covering this avp is The MIP-Foreign-Agent-Host AVP (AVP Code 330) is of type DiameterIdentity and contains the identity of the foreign agent. This AVP is copied from the value of the Origin-Host AVP in the AMR. If we start with its presence in the HAA, this can't possibly serve any purpose since the AAAH already knows the identity of the FA. It was after all the one who sent it to the HA in the first place. But why would the HA want it at all and badly enough for it to be mandatory in the HAR at that? The avp is of type DiameterIdentity which is a strong indication that it is for the consumption of a Diameter entity and not a mobile ip entity. If the mobile node is supposed to carry this information for some reason there is ample opportunity for the FA to provide it directly to the mobile node. The avp is not present in accounting messages. I am quite ignorant about CMS, but it seems unlikely that the HA could have a conceivable need to establish a DSA with the FA. The avp must come from somewhere though since it must have been actively introduced. Can someone please shed some light on why it was defined? Requested change: Explain the avp's use or remove it. j From owner-aaa-wg@merit.edu Sat Mar 9 22:40:13 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25595 for ; Sat, 9 Mar 2002 22:40:13 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id C7CFE91225; Sat, 9 Mar 2002 22:39:34 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 91AE791226; Sat, 9 Mar 2002 22:39:34 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9BB1391225 for ; Sat, 9 Mar 2002 22:39:33 -0500 (EST) Received: by segue.merit.edu (Postfix) id 72A225DDAF; Sat, 9 Mar 2002 22:39:33 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 0C3FE5DD8F for ; Sat, 9 Mar 2002 22:39:33 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g2A2weG04240 for ; Sat, 9 Mar 2002 18:58:40 -0800 Date: Sat, 9 Mar 2002 18:58:40 -0800 (PST) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: Updated AAA WG issues list Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk I've gone and updated the issues list. Here is the latest version: http://www.drizzle.com/~aboba/AAA/issues.html If there any issues that you believe are open that are listed as closed, let me know. Similar, if issues listed as open are resolved, send me some mail. -Bernard From owner-aaa-wg@merit.edu Mon Mar 11 01:59:21 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22148 for ; Mon, 11 Mar 2002 01:59:21 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7D08D9120E; Mon, 11 Mar 2002 01:58:49 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4CF7D91212; Mon, 11 Mar 2002 01:58:49 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D97E79120E for ; Mon, 11 Mar 2002 01:58:47 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0FBF25DE45; Mon, 11 Mar 2002 01:56:41 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 3518D5DDE0 for ; Mon, 11 Mar 2002 01:56:40 -0500 (EST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g2B6uXZ22901 for ; Mon, 11 Mar 2002 08:56:33 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 11 Mar 2002 08:56:22 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Mon, 11 Mar 2002 08:56:22 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [AAA-WG]: Issue 247 Date: Mon, 11 Mar 2002 08:56:22 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD38D5C@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Updated AAA WG issues list Thread-Index: AcHH5T9jg2iWgEMWQK+d3Kut1AEDfwA42tRg From: To: , X-OriginalArrivalTime: 11 Mar 2002 06:56:22.0561 (UTC) FILETIME=[DAA98910:01C1C8C9] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id BAA22148 Hi Bernard, I thought that I closed this for the base. Specifically, Requested change: I recommend that text specifying how to control sending watchdogs and management of the watchdog timer be stricken from the base spec, and that the base spec refer to the transport draft on this matter. This I did. Also, Remove from section 5.6.2 Events: ... Events were removed. Timers (except for Tc) were removed. Is there anything else left open? John Issue 247: Inconsistencies between the base and transport drafts Submitter name: Jonathan Wood Submitter email address: jonathan.wood@sun.com Date first submitted: 21-Nov-01 Reference: Document: base Comment type: E Priority: 1 Section: Base (version 8 alpha2), sections 5.6, 5.6.2, and 12 Rationale/Explanation of issue: The transport draft and the base spec are in conflict about sending watchdogs. The state machine in the base spec section 5.6 requires that watchdogs be sent on each expiration of the watchdog timer. However, the transport draft requires that a watchdog be send once on the first expiration of the watchdog timer. On the next expiration of the watchdog timer, the connection is put in the suspect state, and the connection is failed over. Also, section 5.6 states When the state machine below requests a transport connection with the peer, the state machine in [52] is invoked. Once the connection has been established, the state machine in this section is followed. This is not completely accurate. The state machine in the transport draft should be followed throughout the life of the connection as well to manage the connection. There are also some leftover timer descriptions in section 12 that are no longer relevant. Requested change: I recommend that text specifying how to control sending watchdogs and management of the watchdog timer be stricken from the base spec, and that the base spec refer to the transport draft on this matter. Specifically: 5.6 Peer State Machine (Modify 2nd paragraph) This state machine is closely coupled with the state machine described in [52], which is used to open, close, failover, probe, and reopen transport connections. Note in particular that [52] requires the use of watchdog messages to probe connections. For Diameter, DWR and DWA messages are to be used. Remove from R-Open: WatchDog-Timer R-Snd-DWR R-Open Remove from I-Open: WatchDog-Timer I-Snd-DWR I-Open Remove from section 5.6.2 Events: WatchDog-Timer The Watchdog timer expired, indicating that a DWR message is to be sent to the peer. Rcv-DWR A DWR message was received. Rcv-DWA A DWA message was received. Section 12.0 Diameter protocol related configurable parameters Recommend removing the following timers: Td timer The Td timer controls the termination of connections with peer in the SUSPECT state. The recommended value is 5 seconds. Ti timer The Ti timer controls the frequency the watchdog messages are to be sent to idle peers. The recommended value is 30 seconds. Tr timer The Tr timer controls the frequency the watchdog messages are to be sent to peers when there are pending requests, but not messages have been received from the peer. The recommended value is 10 seconds. Tw timer The Tw timer controls the changing of a peer to the SUSPECT state when no answer is received to a watchdog request. The recommended value is 5 seconds. What about the Tc timer? From owner-aaa-wg@merit.edu Mon Mar 11 02:01:36 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24343 for ; Mon, 11 Mar 2002 02:01:36 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 461B091234; Mon, 11 Mar 2002 02:00:53 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1811191236; Mon, 11 Mar 2002 02:00:53 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E385591234 for ; Mon, 11 Mar 2002 02:00:51 -0500 (EST) Received: by segue.merit.edu (Postfix) id C53C35DDE0; Mon, 11 Mar 2002 02:00:51 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by segue.merit.edu (Postfix) with ESMTP id 221CC5DDDB for ; Mon, 11 Mar 2002 02:00:51 -0500 (EST) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g2B71Ki12568 for ; Mon, 11 Mar 2002 09:01:20 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 11 Mar 2002 09:00:37 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Mon, 11 Mar 2002 09:00:37 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [AAA-WG]: Issue 303: Security model for peer discovery and redirect Date: Mon, 11 Mar 2002 09:00:37 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64BB3@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Updated AAA WG issues list Thread-Index: AcHH5T9jg2iWgEMWQK+d3Kut1AEDfwA5NPfw From: To: , X-OriginalArrivalTime: 11 Mar 2002 07:00:37.0835 (UTC) FILETIME=[72D141B0:01C1C8CA] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id CAA24343 Hi all, http://www.drizzle.com/~aboba/AAA/issues.html#Issue%20#303 Issue 303 is a quite a big change, in my opinion. I am somewhat hesitant about tackling this, so I thing the WG needs to discuss this. Security is, of course, extremely important. Does the workgroup see this a good solution? I'd appreciate comments on this. thanks, John PS - the requestion change is: I think the usefulness of the redirect and server discovery models ought to be reexamined in light of the security problems they introduce.It may be that removing redirect and server discovery from Diameter is the best solution. From owner-aaa-wg@merit.edu Mon Mar 11 02:02:51 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26007 for ; Mon, 11 Mar 2002 02:02:51 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1295C91212; Mon, 11 Mar 2002 02:02:32 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D4A0491223; Mon, 11 Mar 2002 02:02:31 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6F04291212 for ; Mon, 11 Mar 2002 02:02:30 -0500 (EST) Received: by segue.merit.edu (Postfix) id 542905DE4C; Mon, 11 Mar 2002 02:02:30 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id A415A5DDDB for ; Mon, 11 Mar 2002 02:02:29 -0500 (EST) Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g2B72dZ00362 for ; Mon, 11 Mar 2002 09:02:39 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 11 Mar 2002 09:02:28 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Mon, 11 Mar 2002 09:02:28 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [AAA-WG]: Issue 302: Combine occurrence rules tables with message ABNF - Comments? Date: Mon, 11 Mar 2002 09:02:28 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64BB4@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Updated AAA WG issues list Thread-Index: AcHH5T9jg2iWgEMWQK+d3Kut1AEDfwA5UPew From: To: , X-OriginalArrivalTime: 11 Mar 2002 07:02:28.0605 (UTC) FILETIME=[B4D76AD0:01C1C8CA] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id CAA26007 Hi all, Issue 302 proposes an editorial modification to the drafts, for ABNF usage. Does the workgroup feel that this will improve the documentation? John http://www.drizzle.com/~aboba/AAA/issues.html#Issue%20#302 From owner-aaa-wg@merit.edu Mon Mar 11 07:03:34 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05482 for ; Mon, 11 Mar 2002 07:03:34 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id ED84891213; Mon, 11 Mar 2002 07:02:58 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B164E91223; Mon, 11 Mar 2002 07:02:57 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 848EB91213 for ; Mon, 11 Mar 2002 07:02:56 -0500 (EST) Received: by segue.merit.edu (Postfix) id 620B75DE15; Mon, 11 Mar 2002 07:02:56 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from frascone.com (adsl-66-137-237-97.dsl.rcsntx.swbell.net [66.137.237.97]) by segue.merit.edu (Postfix) with SMTP id B52AF5DE14 for ; Mon, 11 Mar 2002 07:02:55 -0500 (EST) Received: (qmail 24142 invoked by uid 500); 11 Mar 2002 12:02:32 -0000 Date: Mon, 11 Mar 2002 06:02:32 -0600 From: David Frascone To: john.loughney@nokia.com Cc: aboba@internaut.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 303: Security model for peer discovery and redirect Message-ID: <20020311120232.GD22132@newman.frascone.com> Mail-Followup-To: john.loughney@nokia.com, aboba@internaut.com, aaa-wg@merit.edu References: <0C1353ABB1DEB74DB067ADFF749C4EEFC64BB3@esebe004.NOE.Nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEFC64BB3@esebe004.NOE.Nokia.com> User-Agent: Mutt/1.3.25i X-encrypt-payload: no Sender: owner-aaa-wg@merit.edu Precedence: bulk My vote would be to reject this issue. But, to address the possible security issues, perhaps we should allow implementations to decide whether they allow redirects. (In other words, server X might not allow redirects from realm Y) As far as server discovery goes . . . that smells like an implementation issue. . . . . -Dave On Monday, 11 Mar 2002, john.loughney@nokia.com wrote: > Hi all, > > http://www.drizzle.com/~aboba/AAA/issues.html#Issue%20#303 > > Issue 303 is a quite a big change, in my opinion. I am somewhat > hesitant about tackling this, so I thing the WG needs to discuss > this. Security is, of course, extremely important. Does the > workgroup see this a good solution? > > I'd appreciate comments on this. > > thanks, > John > > PS - the requestion change is: > > I think the usefulness of the redirect and server discovery models > ought to be reexamined in light of the security problems they > introduce.It may be that removing redirect and server discovery > from Diameter is the best solution. > -- David Frascone Don't just do something !!! Stand there !!! From owner-aaa-wg@merit.edu Mon Mar 11 07:14:49 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05721 for ; Mon, 11 Mar 2002 07:14:49 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 631F591235; Mon, 11 Mar 2002 07:12:55 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0BB0D9123E; Mon, 11 Mar 2002 07:12:54 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 577A691235 for ; Mon, 11 Mar 2002 07:12:50 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3C1FE5DE14; Mon, 11 Mar 2002 07:12:50 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by segue.merit.edu (Postfix) with ESMTP id 19D895DE00 for ; Mon, 11 Mar 2002 07:12:50 -0500 (EST) Received: from randy by rip.psg.com with local (Exim 4.00) id 16kOfT-000MWY-00; Mon, 11 Mar 2002 04:12:43 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: David Frascone Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 303: Security model for peer discovery and redirect References: <0C1353ABB1DEB74DB067ADFF749C4EEFC64BB3@esebe004.NOE.Nokia.com> <20020311120232.GD22132@newman.frascone.com> Message-Id: Date: Mon, 11 Mar 2002 04:12:43 -0800 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit security should not be an "implementation issue." authentication of a referred host by the host which receives their request would seem to be pretty basic security. on first blush, it seems to me that there are only three ways to solve this (but it's still early here) o trusted referrer gives referee a signed cert to be handed to the host to which they refer them o trusted referrer acts as a relay/proxy, with all the kink that gets us o never talk to folk with whom you do not have a configured relationship oh, and then there is hanging your butt out there in the breeze waiting to be killed randy From owner-aaa-wg@merit.edu Mon Mar 11 07:15:01 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05739 for ; Mon, 11 Mar 2002 07:15:01 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id AAD619123F; Mon, 11 Mar 2002 07:13:01 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6FFB49123E; Mon, 11 Mar 2002 07:13:01 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 76C329123F for ; Mon, 11 Mar 2002 07:12:56 -0500 (EST) Received: by segue.merit.edu (Postfix) id 535515DE15; Mon, 11 Mar 2002 07:12:56 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id CA7545DE00 for ; Mon, 11 Mar 2002 07:12:50 -0500 (EST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g2BCCvZ11854 for ; Mon, 11 Mar 2002 14:12:57 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 11 Mar 2002 14:12:46 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Mon, 11 Mar 2002 14:12:46 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Issue 303: Security model for peer discovery and redirect Date: Mon, 11 Mar 2002 14:12:45 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64BCE@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Issue 303: Security model for peer discovery and redirect Thread-Index: AcHI9KI4WX5EA2UHTcOegFuRaTZmRQAARhsQ From: To: Cc: , X-OriginalArrivalTime: 11 Mar 2002 12:12:46.0607 (UTC) FILETIME=[0E0911F0:01C1C8F6] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id HAA05739 Hi all, > My vote would be to reject this issue. > > But, to address the possible security issues, perhaps we should allow > implementations to decide whether they allow redirects. (In > other words, server X might not allow redirects from realm Y) Would required changes to the base spec or clarification elsewhere (applicability statement, bcp ...)? > As far as server discovery goes . . . that smells like an > implementation issue. . . . . Yes, especially since SLP & DNS are a MAY ... John From owner-aaa-wg@merit.edu Mon Mar 11 07:31:36 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06053 for ; Mon, 11 Mar 2002 07:31:35 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DF1E791237; Mon, 11 Mar 2002 07:30:19 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AF0E391238; Mon, 11 Mar 2002 07:30:19 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7A21591237 for ; Mon, 11 Mar 2002 07:30:18 -0500 (EST) Received: by segue.merit.edu (Postfix) id 434475DE52; Mon, 11 Mar 2002 07:30:18 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 90BFE5DE16 for ; Mon, 11 Mar 2002 07:30:17 -0500 (EST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g2BCURZ25334 for ; Mon, 11 Mar 2002 14:30:27 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 11 Mar 2002 14:30:14 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Mon, 11 Mar 2002 14:30:14 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Issue 303: Security model for peer discovery and redirect Date: Mon, 11 Mar 2002 14:30:14 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64BD1@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Issue 303: Security model for peer discovery and redirect Thread-Index: AcHI9lbTm9trVnCaSfymvDBZfDqqKgAAdCLQ From: To: , Cc: X-OriginalArrivalTime: 11 Mar 2002 12:30:14.0900 (UTC) FILETIME=[7EDDE340:01C1C8F8] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id HAA06053 Hi Randy, > security should not be an "implementation issue." authentication > of a referred host by the host which receives their request would > seem to be pretty basic security. My feeling was that Service Discovery is an implementation issue, partly because only Manual Configuation is Mandatory. The other 2 are MAYs. Of course, we should ensure that service discovery via SLP or DNS is secure. > on first blush, it seems to me that there are only three ways to > solve this (but it's still early here) > > o trusted referrer gives referee a signed cert to be handed to > the host to which they refer them > > o trusted referrer acts as a relay/proxy, with all the kink > that gets us > > o never talk to folk with whom you do not have a configured > relationship Agreed. John From owner-aaa-wg@merit.edu Mon Mar 11 07:42:29 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06245 for ; Mon, 11 Mar 2002 07:42:29 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B687E91239; Mon, 11 Mar 2002 07:41:13 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8684691242; Mon, 11 Mar 2002 07:41:13 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4504791239 for ; Mon, 11 Mar 2002 07:41:09 -0500 (EST) Received: by segue.merit.edu (Postfix) id 26BD65DE16; Mon, 11 Mar 2002 07:41:09 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by segue.merit.edu (Postfix) with ESMTP id F16935DE00 for ; Mon, 11 Mar 2002 07:41:08 -0500 (EST) Received: from randy by rip.psg.com with local (Exim 4.00) id 16kP6x-000NIx-00; Mon, 11 Mar 2002 04:41:07 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Cc: Subject: RE: [AAA-WG]: Issue 303: Security model for peer discovery and redirect References: <0C1353ABB1DEB74DB067ADFF749C4EEFC64BD1@esebe004.NOE.Nokia.com> Message-Id: Date: Mon, 11 Mar 2002 04:41:07 -0800 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > My feeling was that Service Discovery is an implementation issue, > partly because only Manual Configuation is Mandatory. The other > 2 are MAYs. Of course, we should ensure that service discovery > via SLP or DNS is secure. do i smell the issue being discussed elsewhere where we learn that the trust hierarchy of the dns does not infer authoritative trust in a host/service referred to from the dns? e.g. because i followed a secure dns chain down to an A record for foo.bar does not lead me to have any trust in the host/port i reach when i use that A record. randy From owner-aaa-wg@merit.edu Mon Mar 11 08:09:02 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06859 for ; Mon, 11 Mar 2002 08:09:02 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9B7BA9123A; Mon, 11 Mar 2002 08:08:40 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 655B49123B; Mon, 11 Mar 2002 08:08:40 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3A9959123A for ; Mon, 11 Mar 2002 08:08:39 -0500 (EST) Received: by segue.merit.edu (Postfix) id 17C4F5DE40; Mon, 11 Mar 2002 08:08:39 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 66B085DE00 for ; Mon, 11 Mar 2002 08:08:38 -0500 (EST) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g2BD8iZ24990 for ; Mon, 11 Mar 2002 15:08:44 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 11 Mar 2002 15:08:33 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Mon, 11 Mar 2002 15:08:33 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Issue 303: Security model for peer discovery and redirect Date: Mon, 11 Mar 2002 15:08:33 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64BD4@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Issue 303: Security model for peer discovery and redirect Thread-Index: AcHI+gficPEMCfvnRXSxTkaZcuW7JgAA58DA From: To: Cc: X-OriginalArrivalTime: 11 Mar 2002 13:08:33.0605 (UTC) FILETIME=[D9006F50:01C1C8FD] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA06859 Hi Randy, > > My feeling was that Service Discovery is an implementation issue, > > partly because only Manual Configuation is Mandatory. The other > > 2 are MAYs. Of course, we should ensure that service discovery > > via SLP or DNS is secure. > > do i smell the issue being discussed elsewhere where we learn that > the trust hierarchy of the dns does not infer authoritative trust > in a host/service referred to from the dns? > > e.g. because i followed a secure dns chain down to an A record for > foo.bar does not lead me to have any trust in the host/port i reach > when i use that A record. I agree completely. When using of DNS, let the buyer beware. John From owner-aaa-wg@merit.edu Mon Mar 11 08:29:27 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07286 for ; Mon, 11 Mar 2002 08:29:26 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2C6949123C; Mon, 11 Mar 2002 08:29:15 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EE6CE9123D; Mon, 11 Mar 2002 08:29:14 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E42969123C for ; Mon, 11 Mar 2002 08:29:13 -0500 (EST) Received: by segue.merit.edu (Postfix) id C95DE5DE00; Mon, 11 Mar 2002 08:29:13 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id 4A4A25DD96 for ; Mon, 11 Mar 2002 08:29:13 -0500 (EST) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA03914; Mon, 11 Mar 2002 06:29:11 -0700 (MST) Received: from qwer (qwer [129.157.142.111]) by hs-ehdb03-01.Germany.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g2BDT9b18126; Mon, 11 Mar 2002 14:29:09 +0100 (MET) Date: Mon, 11 Mar 2002 14:29:09 +0100 (MET) From: Erik Guttman X-Sender: erikg@qwer To: john.loughney@nokia.com Cc: randy@psg.com, aaa-wg@merit.edu Subject: RE: [AAA-WG]: Issue 303: Security model for peer discovery and redirect In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEFC64BD4@esebe004.NOE.Nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk John, Randy, On Mon, 11 Mar 2002 john.loughney@nokia.com wrote: > > > My feeling was that Service Discovery is an implementation issue, > > > partly because only Manual Configuation is Mandatory. The other > > > 2 are MAYs. Of course, we should ensure that service discovery > > > via SLP or DNS is secure. > > > > do i smell the issue being discussed elsewhere where we learn that > > the trust hierarchy of the dns does not infer authoritative trust > > in a host/service referred to from the dns? > > > > e.g. because i followed a secure dns chain down to an A record for > > foo.bar does not lead me to have any trust in the host/port i reach > > when i use that A record. > > I agree completely. When using of DNS, let the buyer beware. With SLP a client can trust a signed service advertisement from a server to the extent that the server has a private key and the client has a corresponding public key. Possession of the private key indicates authoritative trust in the server to advertise itself using SLP. SLP itself doesn't distribute keys, or certs - that is left to the administrators deploying SLP. This mechanism has been used, by at least one product. Erik From owner-aaa-wg@merit.edu Mon Mar 11 09:26:51 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09062 for ; Mon, 11 Mar 2002 09:26:51 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 56F929123E; Mon, 11 Mar 2002 09:25:49 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 20D0C91240; Mon, 11 Mar 2002 09:25:49 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E21989123E for ; Mon, 11 Mar 2002 09:25:47 -0500 (EST) Received: by segue.merit.edu (Postfix) id C0B6A5DE10; Mon, 11 Mar 2002 09:25:47 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 224C65DE0A for ; Mon, 11 Mar 2002 09:25:47 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g2BDidT25175; Mon, 11 Mar 2002 05:44:39 -0800 Date: Mon, 11 Mar 2002 05:44:39 -0800 (PST) From: Bernard Aboba To: john.loughney@nokia.com Cc: aaa-wg@merit.edu Subject: [AAA-WG]: Re: Issue 247 In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEFD38D5C@esebe004.NOE.Nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk OK. I will mark it as closed. On Mon, 11 Mar 2002 john.loughney@nokia.com wrote: > Hi Bernard, > > I thought that I closed this for the base. Specifically, > > Requested change: > > I recommend that text specifying how to control sending watchdogs and > management of the watchdog timer be stricken from the base spec, and > that the base spec refer to the transport draft on this matter. > > This I did. Also, > > Remove from section 5.6.2 Events: > ... > > Events were removed. Timers (except for Tc) were removed. > > Is there anything else left open? > > John > > > Issue 247: Inconsistencies between the base and transport drafts > Submitter name: Jonathan Wood > Submitter email address: jonathan.wood@sun.com > Date first submitted: 21-Nov-01 > Reference: > Document: base > Comment type: E > Priority: 1 > Section: Base (version 8 alpha2), sections 5.6, 5.6.2, and 12 > Rationale/Explanation of issue: > > The transport draft and the base spec are in conflict about > sending watchdogs. The state machine in the base spec section 5.6 > requires that watchdogs be sent on each expiration of the watchdog > timer. However, the transport draft requires that a watchdog be > send once on the first expiration of the watchdog timer. On the > next expiration of the watchdog timer, the connection is put in > the suspect state, and the connection is failed over. > > Also, section 5.6 states > > When the state machine below requests a > transport connection with the peer, the state machine in [52] is > invoked. Once the connection has been established, the state machine > in this section is followed. > > This is not completely accurate. The state machine in the transport > draft should be followed throughout the life of the connection as > well to manage the connection. > > There are also some leftover timer descriptions in section 12 that > are no longer relevant. > > Requested change: > > I recommend that text specifying how to control sending watchdogs and > management of the watchdog timer be stricken from the base spec, and > that the base spec refer to the transport draft on this matter. > > Specifically: > > 5.6 Peer State Machine > (Modify 2nd paragraph) > > This state machine is closely coupled with the state machine > described in [52], which is used to open, close, failover, probe, > and reopen transport connections. Note in particular that [52] > requires the use of watchdog messages to probe connections. For > Diameter, DWR and DWA messages are to be used. > > Remove from R-Open: > > WatchDog-Timer R-Snd-DWR R-Open > > Remove from I-Open: > > WatchDog-Timer I-Snd-DWR I-Open > > > Remove from section 5.6.2 Events: > > WatchDog-Timer The Watchdog timer expired, indicating that a DWR > message is to be sent to the peer. > > Rcv-DWR A DWR message was received. > > Rcv-DWA A DWA message was received. > > Section 12.0 Diameter protocol related configurable parameters > > Recommend removing the following timers: > > Td timer > The Td timer controls the termination of connections with peer > in the SUSPECT state. The recommended value is 5 seconds. > > Ti timer > The Ti timer controls the frequency the watchdog messages are > to be sent to idle peers. The recommended value is 30 seconds. > > Tr timer > The Tr timer controls the frequency the watchdog messages are > to be sent to peers when there are pending requests, but not > messages have been received from the peer. The recommended > value is 10 seconds. > > Tw timer > The Tw timer controls the changing of a peer to the SUSPECT > state when no answer is received to a watchdog request. The > recommended value is 5 seconds. > > What about the Tc timer? > From owner-aaa-wg@merit.edu Mon Mar 11 10:41:26 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11951 for ; Mon, 11 Mar 2002 10:41:26 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 414359124A; Mon, 11 Mar 2002 10:37:37 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 18FFE9124B; Mon, 11 Mar 2002 10:37:36 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B4E349124A for ; Mon, 11 Mar 2002 10:37:33 -0500 (EST) Received: by segue.merit.edu (Postfix) id 02C5E5DE90; Mon, 11 Mar 2002 10:37:32 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from EXCHSRV.stormventures.com (unknown [65.107.25.226]) by segue.merit.edu (Postfix) with ESMTP id F12715DE54 for ; Mon, 11 Mar 2002 10:36:29 -0500 (EST) Received: by EXCHSRV.stormventures.com with Internet Mail Service (5.5.2653.19) id ; Mon, 11 Mar 2002 07:36:15 -0800 Message-ID: From: "Pat R. Calhoun" To: "'Randy Bush'" , David Frascone Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: Issue 303: Security model for peer discovery and re direct Date: Mon, 11 Mar 2002 07:36:07 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1C912.76300F60" Sender: owner-aaa-wg@merit.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1C912.76300F60 Content-Type: text/plain -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Remember that a redirect makes lots of sense in the case where the redirect server is owned by a "broker". The broker would typically act as a certificate authority, and would ensure that all of the roaming consortium members have certificates that are signed by the CA. This provides the trust that is needed in the protocol. PatC - -----Original Message----- From: Randy Bush [mailto:randy@psg.com] Sent: Monday, March 11, 2002 4:13 AM To: David Frascone Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 303: Security model for peer discovery and redirect security should not be an "implementation issue." authentication of a referred host by the host which receives their request would seem to be pretty basic security. on first blush, it seems to me that there are only three ways to solve this (but it's still early here) o trusted referrer gives referee a signed cert to be handed to the host to which they refer them o trusted referrer acts as a relay/proxy, with all the kink that gets us o never talk to folk with whom you do not have a configured relationship oh, and then there is hanging your butt out there in the breeze waiting to be killed randy -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 7.0.3 for non-commercial use iQA/AwUBPIzO5jN1fXKoxmisEQIddgCg5xrYcr3Kf4FI/ZL14YPzldV+cXYAmwdC AmXYxG/Lgl69zFDd85lmtdJQ =xG3U -----END PGP SIGNATURE----- ------_=_NextPart_001_01C1C912.76300F60 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [AAA-WG]: Issue 303: Security model for peer discovery and = redirect

 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Remember that a redirect makes lots of sense in the = case where the
redirect server is owned by a "broker". = The broker would typically
act as a certificate authority, and would ensure = that all of the
roaming consortium members have certificates that = are signed by the
CA. This provides the trust that is needed in the = protocol.

PatC

- -----Original Message-----
From: Randy Bush [mailto:randy@psg.com]
Sent: Monday, March 11, 2002 4:13 AM
To: David Frascone
Cc: aaa-wg@merit.edu
Subject: Re: [AAA-WG]: Issue 303: Security model for = peer discovery
and redirect


security should not be an "implementation = issue."  authentication of
a referred host by the host which receives their = request would seem
to be pretty basic security.

on first blush, it seems to me that there are only = three ways to
solve this (but it's still early here)

  o trusted referrer gives referee a signed cert = to be handed to
    the host to which they refer = them

  o trusted referrer acts as a relay/proxy, with = all the kink
    that gets us

  o never talk to folk with whom you do not have = a configured
    relationship

oh, and then there is hanging your butt out there in = the breeze
waiting to be killed

randy

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use = <http://www.pgp.com>

iQA/AwUBPIzO5jN1fXKoxmisEQIddgCg5xrYcr3Kf4FI/ZL14YPzldV+cXYAmwd= C
AmXYxG/Lgl69zFDd85lmtdJQ
=3DxG3U
-----END PGP SIGNATURE-----

------_=_NextPart_001_01C1C912.76300F60-- From owner-aaa-wg@merit.edu Mon Mar 11 10:42:15 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11983 for ; Mon, 11 Mar 2002 10:42:15 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id AF6969124C; Mon, 11 Mar 2002 10:38:17 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7505291250; Mon, 11 Mar 2002 10:38:17 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2144A9124C for ; Mon, 11 Mar 2002 10:38:16 -0500 (EST) Received: by segue.merit.edu (Postfix) id EAE795DE12; Mon, 11 Mar 2002 10:38:15 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from EXCHSRV.stormventures.com (unknown [65.107.25.226]) by segue.merit.edu (Postfix) with ESMTP id A16EE5DE10 for ; Mon, 11 Mar 2002 10:38:15 -0500 (EST) Received: by EXCHSRV.stormventures.com with Internet Mail Service (5.5.2653.19) id ; Mon, 11 Mar 2002 07:38:15 -0800 Message-ID: From: "Pat R. Calhoun" To: "'john.loughney@nokia.com'" , aboba@internaut.com, aaa-wg@merit.edu Subject: RE: [AAA-WG]: Issue 302: Combine occurrence rules tables with mes sage ABNF - Comments? Date: Mon, 11 Mar 2002 07:38:06 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1C912.BD1BE200" Sender: owner-aaa-wg@merit.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1C912.BD1BE200 Content-Type: text/plain -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I think we are at a point where we need to worry about getting a document out... We can go back and forth on editorial issues 'til the cows come home, but is delaying the RFC really benefiting the Internet community? What I've heard in the past weeks is that others will soon take the matter in their own hands if the AAA WG doesn't come up with a PS soon. Food for thought. PatC - -----Original Message----- From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] Sent: Sunday, March 10, 2002 11:02 PM To: aboba@internaut.com; aaa-wg@merit.edu Subject: [AAA-WG]: Issue 302: Combine occurrence rules tables with message ABNF - Comments? Hi all, Issue 302 proposes an editorial modification to the drafts, for ABNF usage. Does the workgroup feel that this will improve the documentation? John http://www.drizzle.com/~aboba/AAA/issues.html#Issue%20#302 -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 7.0.3 for non-commercial use iQA/AwUBPIzPXTN1fXKoxmisEQJ4QgCg+IGb5BapfvYTXvMKMhhV7d/ojCgAn1dQ qZp+75VoioBBzIP8JAswCS/4 =mR4g -----END PGP SIGNATURE----- ------_=_NextPart_001_01C1C912.BD1BE200 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [AAA-WG]: Issue 302: Combine occurrence rules tables with = message ABNF - Comments?

 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I think we are at a point where we need to worry = about getting a
document out... We can go back and forth on = editorial issues 'til the
cows come home, but is delaying the RFC really = benefiting the
Internet community? What I've heard in the past = weeks is that others
will soon take the matter in their own hands if the = AAA WG doesn't
come up with a PS soon.

Food for thought.

PatC

- -----Original Message-----
From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]
Sent: Sunday, March 10, 2002 11:02 PM
To: aboba@internaut.com; aaa-wg@merit.edu
Subject: [AAA-WG]: Issue 302: Combine occurrence = rules tables with
message ABNF - Comments?


Hi all,

Issue 302 proposes an editorial modification to the = drafts,
for ABNF usage.  Does the workgroup feel that = this will
improve the documentation?

John

http://www.drizzle.com/~aboba/AAA/issues.html#Issue%20= #302

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use = <http://www.pgp.com>

iQA/AwUBPIzPXTN1fXKoxmisEQJ4QgCg+IGb5BapfvYTXvMKMhhV7d/ojCgAn1d= Q
qZp+75VoioBBzIP8JAswCS/4
=3DmR4g
-----END PGP SIGNATURE-----

------_=_NextPart_001_01C1C912.BD1BE200-- From owner-aaa-wg@merit.edu Mon Mar 11 12:34:36 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16712 for ; Mon, 11 Mar 2002 12:34:36 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 797F491247; Mon, 11 Mar 2002 12:34:25 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4B62191249; Mon, 11 Mar 2002 12:34:25 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1487091247 for ; Mon, 11 Mar 2002 12:34:24 -0500 (EST) Received: by segue.merit.edu (Postfix) id EDE205DE12; Mon, 11 Mar 2002 12:34:23 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from ocasey.baltimore.com (ocasey.baltimore.com [193.41.17.101]) by segue.merit.edu (Postfix) with ESMTP id 2C6035DDCF for ; Mon, 11 Mar 2002 12:34:23 -0500 (EST) Received: from Baltimore-FW1 ([172.19.1.1]) by ocasey.baltimore.com (8.11.6/8.9.3) with SMTP id g2BHXub10093 for ; Mon, 11 Mar 2002 17:33:56 GMT Received: from Baltimore-FW1 (wilde-i-1.ie.baltimore.com) by emeairlsw1.baltimore.com (Content Technologies SMTPRS 4.2.5) with SMTP id for ; Mon, 11 Mar 2002 17:28:36 +0000 Received: from baltimore.ie (wks140-4.ie.baltimore.com [10.153.4.140]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id OAA24725; Mon, 11 Mar 2002 14:57:09 GMT Message-ID: <3C8CC5CF.E85851E4@baltimore.ie> Date: Mon, 11 Mar 2002 14:57:19 +0000 From: Stephen Farrell Reply-To: stephen.farrell@baltimore.ie Organization: Baltimore Technologies Ltd. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Bernard Aboba Cc: aaa-wg@merit.edu, jari.arkko@kolumbus.fi Subject: Re: [AAA-WG]: Updated AAA WG issues list References: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Bernard, The list isn't in synch with cms-04. I think that only 278 ought remain (what do you think Jari?). Some details below, Cheers, Stephen. Issue 278: CMS issues This one contains a bunch of different things: "People who have read the CMS document do not clearly understand that PDS mechanisms are not intended to create actual security associations, but just to offload the computations to someone else." I tried to clarify the text in various places. "Secondly, the document does not explain what to do in case NO_CMS_THROUGH_PROXY is maliciously returned from somewhere else than in our own domain." I think that (some of?) the requested text was added prior to me taking over as editor. I think that this is also affected by the resolution of 221/291, but could well warrant additional clarification. "Thirdly, there's some spelling problems." Dun doze:-) To be closed: Issue 221: Why require CMS to send its expected AVPs? Issue 279: Base does not sufficiently explain what MAY encrypt means The resolution to both these was to remove the expected-* AVPs from CMS, and change the defintion of "MAY Encr" in both base and CMS. The agreed change in the CMS I-D is at the end of section 3.1: "Note: [BASE] includes the "MAY encr" column when describing AVPs. For the originator "MAY encr" as used in [BASE] means that if a message containing that AVP is to be sent via a proxy/agent (as opposed to directly) then the message MUST NOT be sent unless there is a DSA between the originator and the recipient OR the originator has locally trusted configuration that indicates that CMS need not be used." Issue 276 : Remove section 1.6 from the CMS appl The section 1.6 that was in -03 is removed from -04. (The -03 1.7 is now 1.6, a new 1.7 was added to clarify something that came up during editing.) Issue 291: Remove references to CMS-Cert in cms-sec-03 The string CMS-Cert doesn't occur in -04. -- ____________________________________________________________ Stephen Farrell Baltimore Technologies, tel: (direct line) +353 1 881 6716 39 Parkgate Street, fax: +353 1 881 7000 Dublin 8. mailto:stephen.farrell@baltimore.ie Ireland http://www.baltimore.com From owner-aaa-wg@merit.edu Mon Mar 11 13:06:12 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17911 for ; Mon, 11 Mar 2002 13:06:11 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id BCA409124B; Mon, 11 Mar 2002 13:05:59 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 907859124D; Mon, 11 Mar 2002 13:05:59 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8C7749124B for ; Mon, 11 Mar 2002 13:05:58 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6DF095DD99; Mon, 11 Mar 2002 13:05:58 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id CDD235DDCF for ; Mon, 11 Mar 2002 13:05:57 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g2BHOr305025; Mon, 11 Mar 2002 09:24:53 -0800 Date: Mon, 11 Mar 2002 09:24:53 -0800 (PST) From: Bernard Aboba To: Stephen Farrell Cc: aaa-wg@merit.edu, jari.arkko@kolumbus.fi Subject: Re: [AAA-WG]: Updated AAA WG issues list In-Reply-To: <3C8CC5CF.E85851E4@baltimore.ie> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Thanks for the update, Stephen. I will update the issues list accordingly. On Mon, 11 Mar 2002, Stephen Farrell wrote: > > Bernard, > > The list isn't in synch with cms-04. I think that only 278 > ought remain (what do you think Jari?). > > Some details below, > Cheers, > Stephen. > > Issue 278: CMS issues > > This one contains a bunch of different things: > > "People who have read the CMS document do not clearly understand > that PDS mechanisms are not intended to create actual security > associations, but just to offload the computations to someone else." > > I tried to clarify the text in various places. > > "Secondly, the document does not explain what to do in case > NO_CMS_THROUGH_PROXY is maliciously returned from somewhere > else than in our own domain." > > I think that (some of?) the requested text was added prior > to me taking over as editor. I think that this is also affected > by the resolution of 221/291, but could well warrant additional > clarification. > > "Thirdly, there's some spelling problems." > > Dun doze:-) > > > To be closed: > > Issue 221: Why require CMS to send its expected AVPs? > Issue 279: Base does not sufficiently explain what MAY encrypt means > > The resolution to both these was to remove the expected-* AVPs > from CMS, and change the defintion of "MAY Encr" in both base > and CMS. The agreed change in the CMS I-D is at the end > of section 3.1: > > "Note: [BASE] includes the "MAY encr" column when describing AVPs. For > the originator "MAY encr" as used in [BASE] means that if a message > containing that AVP is to be sent via a proxy/agent (as opposed to > directly) then the message MUST NOT be sent unless there is a DSA > between the originator and the recipient OR the originator has > locally trusted configuration that indicates that CMS need not be > used." > > Issue 276 : Remove section 1.6 from the CMS appl > > The section 1.6 that was in -03 is removed from -04. (The -03 > 1.7 is now 1.6, a new 1.7 was added to clarify something that > came up during editing.) > > Issue 291: Remove references to CMS-Cert in cms-sec-03 > > The string CMS-Cert doesn't occur in -04. > > > > From owner-aaa-wg@merit.edu Mon Mar 11 14:07:56 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19515 for ; Mon, 11 Mar 2002 14:07:55 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 561989125C; Mon, 11 Mar 2002 14:06:57 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 21F5D9125E; Mon, 11 Mar 2002 14:06:57 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C143B9125C for ; Mon, 11 Mar 2002 14:06:54 -0500 (EST) Received: by segue.merit.edu (Postfix) id A635E5DE12; Mon, 11 Mar 2002 14:06:54 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 927375DD99 for ; Mon, 11 Mar 2002 14:06:54 -0500 (EST) Received: from phoenix (nat.interlinknetworks.com [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with SMTP id CBE4E7A; Mon, 11 Mar 2002 14:06:53 -0500 (EST) From: "Bob Kopacz" To: "Tony Johansson" , "Bernard Aboba" Cc: "aaa-wg" Subject: RE: [AAA-WG]: Updated AAA WG issues list Date: Mon, 11 Mar 2002 14:05:55 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 In-Reply-To: Importance: Normal Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Tony and Bernard, If it's ok with Tony, you can remove Issue 292: "Handling of Home-Agent-In-Foreign-Network flag" from the issues list. This was an issue I submitted on 02-27-2002. After getting some feedback from Tony, and thinking it over more, I submitted Issue 299: "Need more explanation about handling MN handoffs" on 03-04-2002. To my mind, issue #299 supersedes issue#292. Bob K. From owner-aaa-wg@merit.edu Mon Mar 11 14:09:32 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19589 for ; Mon, 11 Mar 2002 14:09:32 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A7A9191252; Mon, 11 Mar 2002 14:09:16 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5A57391253; Mon, 11 Mar 2002 14:09:16 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 24EB291252 for ; Mon, 11 Mar 2002 14:09:14 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0708D5DE15; Mon, 11 Mar 2002 14:09:14 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by segue.merit.edu (Postfix) with ESMTP id D7AE95DD99 for ; Mon, 11 Mar 2002 14:09:13 -0500 (EST) Received: from randy by rip.psg.com with local (Exim 4.00) id 16kVAI-0008AJ-00; Mon, 11 Mar 2002 11:08:58 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Pat R. Calhoun" Cc: David Frascone , aaa-wg@merit.edu Subject: RE: [AAA-WG]: Issue 303: Security model for peer discovery and re direct References: Message-Id: Date: Mon, 11 Mar 2002 11:08:58 -0800 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > Remember that a redirect makes lots of sense in the case where the > redirect server is owned by a "broker". The broker would typically > act as a certificate authority, and would ensure that all of the > roaming consortium members have certificates that are signed by the > CA. This provides the trust that is needed in the protocol. so, if i do not have a signed cert of the host trying to contact me, the protocol will say that i MUST reject the connection? randy From owner-aaa-wg@merit.edu Mon Mar 11 14:50:15 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20717 for ; Mon, 11 Mar 2002 14:50:15 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 00C5D91253; Mon, 11 Mar 2002 14:50:07 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C0A0491254; Mon, 11 Mar 2002 14:50:06 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9609C91253 for ; Mon, 11 Mar 2002 14:50:05 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6E3F85DE3F; Mon, 11 Mar 2002 14:50:05 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from fep10-svc.swip.net (unknown [130.244.199.138]) by segue.merit.edu (Postfix) with ESMTP id BE1065DD96 for ; Mon, 11 Mar 2002 14:50:04 -0500 (EST) Received: from ipunplugged.com ([213.100.60.194]) by fep10-svc.swip.net with ESMTP id <20020311194844.BCLO1979.fep10-svc.swip.net@ipunplugged.com> for ; Mon, 11 Mar 2002 20:48:44 +0100 Message-ID: <3C8D185C.30003@ipunplugged.com> Date: Mon, 11 Mar 2002 20:49:32 +0000 From: Johan Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226 X-Accept-Language: en-us MIME-Version: 1.0 To: AAA Working Group Subject: [AAA-WG]: [issue] Session-Timeout vs Authorization-Lifetime vs MIP-Key-Lifetime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Subject: [issue] Session-Timeout vs Authorization-Lifetime vs MIP-Key-Lifetime Submitter name: Johan Johansson Submitter email address: johanj@ipunplugged.com Date first submitted: March 11, 2002 Reference: Document: Mobile IP Comment type: T Priority: 1 Section: 2.2, 2.3, 5.1, 8.1 Rationale/Explanation of issue: If there is to be any hope for interoperability the use of Session-Timeout must be defined in the MIP draft. The base draft defines Session-Timeout as 8.13 Session-Timeout AVP The Session-Timeout AVP (AVP Code 27) [RADIUS] is of type Unsigned32 and contains the maximum number of seconds of service to be provided to the user before termination of the session. When both the Session- Timeout and the Authorization-Lifetime AVPs are present in an answer message, the former MUST be equal to or greater than the value of the latter. --- A Session-Timeout AVP MAY be present in a re-authorization message, and contains the number of seconds from the beginning of the re-auth. A value of zero, or the absence of this AVP, means that this session has an unlimited number of seconds before termination. Section 8.9 of the base draft has this to say about Authorization-Lifetime: An Authorization-Lifetime AVP MAY be present in re-authorization messages, and contains the number of seconds the user is authorized to receive service from the time the re-auth answer message is received by the access device. The MIP draft contains no references to Session-Timeout beyond the occurence rules and the ABNFs and they are contradictory. The occurence rules of the MIP draft states +-----------------------+ | Command-Code | |-----+-----+-----+-----+ Attribute Name | AMR | AMA | HAR | HAA | ------------------------------|-----+-----+-----+-----+ Session-Timeout | 0 | 1 | 1 | 0 | The ABNFs for AMA and HAR list it as optional. Looking solely at the base draft the ABNF would seem to be correct. But this still does not settle the issue of the semantics of its presence. Section 5.1 of the mip draft states The Diameter Mobile IP application makes use of two timers - the Authorization-Lifetime AVP [DIAMBASE] and the MIP-Key-Lifetime AVP. The Authorization-Lifetime contains the number of seconds before the Mobile Node must issue a subsequent MIP registration request. The content of the Authorization-Lifetime AVP corresponds to the Lifetime field in the MIP header [MOBILEIP]. The MIP-Key-Lifetime AVP contains the number of seconds before session keys destined for the Mobility Agents and the Mobile Node expire. A value of zero indicates infinity (no timeout). If not zero, the value of the MIP-Key-Lifetime AVP MUST be at least equal to the value in the Authorization Lifetime AVP. If the application doesn't use Session-Timeout it should not be optional or mandatory but banned. The section quoted above inevitably leads to the the termination of the user session after at least Authorization-Lifetime seconds and at most Authorization-Lifetime + MIP-Key-Lifetime seconds. Requested change: Remove Session-Timeout from AMA and HAR. Modify the first paragraph of section 5.1 to: The Diameter Mobile IP application makes use of two timers - the Authorization-Lifetime AVP [DIAMBASE] and the MIP-Key-Lifetime AVP. The Session-Timeout AVP [DIAMBASE] does not apply to this application. j From owner-aaa-wg@merit.edu Mon Mar 11 14:52:34 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20798 for ; Mon, 11 Mar 2002 14:52:32 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E6D1491254; Mon, 11 Mar 2002 14:52:22 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B49ED91255; Mon, 11 Mar 2002 14:52:22 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B292C91254 for ; Mon, 11 Mar 2002 14:52:21 -0500 (EST) Received: by segue.merit.edu (Postfix) id 990275DDC9; Mon, 11 Mar 2002 14:52:21 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 271395DD96 for ; Mon, 11 Mar 2002 14:52:21 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g2BJBCN10937; Mon, 11 Mar 2002 11:11:12 -0800 Date: Mon, 11 Mar 2002 11:11:12 -0800 (PST) From: Bernard Aboba To: Bob Kopacz Cc: Tony Johansson , aaa-wg Subject: RE: [AAA-WG]: Updated AAA WG issues list In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Done. On Mon, 11 Mar 2002, Bob Kopacz wrote: > Hi Tony and Bernard, > > If it's ok with Tony, you can remove Issue 292: "Handling of > Home-Agent-In-Foreign-Network flag" from the issues list. This was an > issue I submitted on 02-27-2002. > > After getting some feedback from Tony, and thinking it over more, I > submitted Issue 299: "Need more explanation about handling MN handoffs" > on 03-04-2002. > > To my mind, issue #299 supersedes issue#292. > > Bob K. > > From owner-aaa-wg@merit.edu Mon Mar 11 15:11:12 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21492 for ; Mon, 11 Mar 2002 15:11:11 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id EE3CC91255; Mon, 11 Mar 2002 15:10:56 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BBFB091256; Mon, 11 Mar 2002 15:10:55 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8742A91255 for ; Mon, 11 Mar 2002 15:10:54 -0500 (EST) Received: by segue.merit.edu (Postfix) id 576475DDE0; Mon, 11 Mar 2002 15:10:54 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by segue.merit.edu (Postfix) with ESMTP id 1B01D5DD96 for ; Mon, 11 Mar 2002 15:10:54 -0500 (EST) Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.224.157]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g2BKAiS13069; Mon, 11 Mar 2002 14:10:44 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g2BKAiv05290; Mon, 11 Mar 2002 14:10:44 -0600 (CST) Received: from qpop.exu.ericsson.se (qpop [138.85.75.72]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id OAA27852; Mon, 11 Mar 2002 14:10:43 -0600 (CST) Received: from ericsson.com ([138.85.159.114]) by qpop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id OAA04907; Mon, 11 Mar 2002 14:10:43 -0600 (CST) Message-ID: <3C8D0EA8.D502F749@ericsson.com> Date: Mon, 11 Mar 2002 12:08:08 -0800 From: Tony Johansson X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Bernard Aboba Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: Updated AAA WG issues list References: Content-Type: multipart/alternative; boundary="------------DB4107D139B7A827CC59232A" Sender: owner-aaa-wg@merit.edu Precedence: bulk --------------DB4107D139B7A827CC59232A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Bernard and All, I'm sorry that I haven't sent an update earlier, but I'm been out of office last week. MIP Issues update: CLOSED (MIP-09) Issue #264 User-Name in Answer messages CLOSED (MIP-09) Issue #265 MIP-Reg-Reply AVP not required in AMA for Co-located MN CLOSED (MIP-09) Issue #266 Returning AAAF-Generated FA-HA Key to FA CLOSED (MIP-09) Issue #267 Minor corrections / clarifications to draft-mobileip-08 CLOSED (MIP-09) Issue #286 MIP-Home-Agent-Host AVP CLOSED (MIP-09) Issue #290 Handling of Accounting-Multi-Session-Id AVP Rejected Issue #292 Handling of Home-Agent-In-Foreign-Network flag Regards, Tony --------------DB4107D139B7A827CC59232A Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Bernard and All,

I'm sorry that I haven't sent an update earlier, but I'm been out of office last week.

MIP Issues update:

CLOSED (MIP-09)  Issue #264    User-Name in Answer messages
CLOSED (MIP-09)  Issue #265    MIP-Reg-Reply AVP not required
                               in AMA for Co-located MN
CLOSED (MIP-09)  Issue #266    Returning AAAF-Generated FA-HA
                               Key to FA
CLOSED (MIP-09)  Issue #267    Minor corrections / clarifications
                               to draft-mobileip-08
CLOSED (MIP-09)  Issue #286    MIP-Home-Agent-Host AVP
CLOSED (MIP-09)  Issue #290    Handling of
                               Accounting-Multi-Session-Id AVP
Rejected         Issue #292    Handling of
                               Home-Agent-In-Foreign-Network flag

Regards,

Tony
 
  --------------DB4107D139B7A827CC59232A-- From owner-aaa-wg@merit.edu Mon Mar 11 15:22:18 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21912 for ; Mon, 11 Mar 2002 15:22:18 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 0475091256; Mon, 11 Mar 2002 15:22:09 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C456C91258; Mon, 11 Mar 2002 15:22:08 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 97B1191256 for ; Mon, 11 Mar 2002 15:22:07 -0500 (EST) Received: by segue.merit.edu (Postfix) id 777ED5DDE5; Mon, 11 Mar 2002 15:22:07 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from palrel13.hp.com (unknown [156.153.255.238]) by segue.merit.edu (Postfix) with ESMTP id 599BB5DDCC for ; Mon, 11 Mar 2002 15:22:07 -0500 (EST) Received: from hpindsra.cup.hp.com (hpindsra.cup.hp.com [15.13.104.190]) by palrel13.hp.com (Postfix) with ESMTP id 08D384001BC for ; Mon, 11 Mar 2002 12:20:47 -0800 (PST) Received: from hpindsra (hpindsra [15.13.104.190]) by hpindsra.cup.hp.com with ESMTP (8.8.6 (PHNE_17190)/8.8.6 SMKit7.02) id MAA07694 for ; Mon, 11 Mar 2002 12:20:48 -0800 (PST) Date: Mon, 11 Mar 2002 12:20:46 -0800 (PST) From: Sivasundar Ramamurthy X-Sender: sramam@hpindsra To: AAA Working Group Subject: Re: [AAA-WG]: Re: Pending Issue about MIP-Key-Lifetime AVP (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk On Mon, 25 Feb 2002, Tony Johansson wrote: > New section: > > "5.1 Authorization Lifetime vs. MIP Key Lifetime > > The Diameter Mobile IP application makes use of two timers the > Authorization-Lifetime AVP [DIAMBASE] and the MIP-Key-Lifetime AVP. > > The Authorization-Lifetime contains the number of seconds before the > Mobile Node must issue a subsequent MIP registration request. The > content of Authorization-Lifetime AVP corresponds to the Lifetime > field in the MIP header [MOBILEIP]. > > The MIP-Key-Lifetime AVP contains the number of seconds before > session keys destined for the Home Agent and/or Foreign Agent expire. > > A value of zero indicates infinity (no timeout). The value of the > MIP-Key-Lifetime AVP MUST be at least equal to the value in the > Authorization Lifetime AVP. If the value is greater, it SHOULD be a > multiple of the value in the Authorization Lifetime AVP." > if the key lifetime is allowed to be greater than the authorization lifetime, then the authorization lifetime at the (stateful) AAA server will expire even as the MN is re-registering. This will happen since the MN "knows" to use AAA only to request keys; it will re-register (re-authenticate) directly with the HA during the time the keys are alive. Thus even while the MN is happily registered (authenticated), the (stateful) AAA server will see that its authorization lifetime has expired and will terminate its session and de-allocate the resources. Is'nt this a problem, considering that one of the resources allocated could be a dynamic home address which could then be allocated to some other MN? thanks! Siva From owner-aaa-wg@merit.edu Mon Mar 11 16:17:02 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24745 for ; Mon, 11 Mar 2002 16:17:02 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 194B991258; Mon, 11 Mar 2002 16:16:37 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D734E91259; Mon, 11 Mar 2002 16:16:36 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C4E4091258 for ; Mon, 11 Mar 2002 16:16:35 -0500 (EST) Received: by segue.merit.edu (Postfix) id A963E5DDE4; Mon, 11 Mar 2002 16:16:35 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from dzick.interlinknetworks.com (nat.interlinknetworks.com [198.108.5.3]) by segue.merit.edu (Postfix) with ESMTP id 5562C5DDCC for ; Mon, 11 Mar 2002 16:16:34 -0500 (EST) Received: from interlinknetworks.com (localhost.localdomain [127.0.0.1]) by dzick.interlinknetworks.com (8.11.0/8.11.0) with ESMTP id g2BL38Z01736 for ; Mon, 11 Mar 2002 16:03:08 -0500 Message-ID: <3C8D1B8B.9C8E2031@interlinknetworks.com> Date: Mon, 11 Mar 2002 16:03:07 -0500 From: Don Zick Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: aaa-wg@merit.edu Subject: [AAA-WG]: [issue] Diameter CMS Security - Remove DSA-TTL from PDSA message Content-Type: text/plain; charset=iso-8859-1 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id QAA24745 Submitter name: Don Zick Submitter email address: dzick@interlinknetworks.com Date first submitted: March 11, 2002 Reference: Document: cms Comment type: T Priority: 1 Section: Rationale/Explanation of issue A diameter agent may establish security associations on behalf of access devices. The access devices issue the PDSR message to request this. It is simpler for the access devices if they do not have to re-issue the PDSR because of DSA-TTL expiry. Also, the diameter agent may make use of the same DSA for more than one access device; in this case it doesn't make much sense for multiple access devices to be responsible for re-establishing the same DSA. Requested change: Replace text from section 1.3: The PDSA MUST contain the TTL setting agreed by the proxy agent for its DSA. This information will allow the access device to re-issue a PDSR prior to the proxy's DSA expiry if it needs the DSA to remain active. with this text: The proxy agent is responsible for re-establishing the DSA prior to expiration without any involvement by the access device. Also, remove DSA-TTL from PDSA ABNF definition. From owner-aaa-wg@merit.edu Mon Mar 11 16:18:15 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24785 for ; Mon, 11 Mar 2002 16:18:15 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3A72991259; Mon, 11 Mar 2002 16:17:59 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 063EE9125A; Mon, 11 Mar 2002 16:17:58 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id AD33991259 for ; Mon, 11 Mar 2002 16:17:57 -0500 (EST) Received: by segue.merit.edu (Postfix) id 83FF95DE15; Mon, 11 Mar 2002 16:17:57 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from dzick.interlinknetworks.com (nat.interlinknetworks.com [198.108.5.3]) by segue.merit.edu (Postfix) with ESMTP id 2E8BF5DE14 for ; Mon, 11 Mar 2002 16:17:57 -0500 (EST) Received: from interlinknetworks.com (localhost.localdomain [127.0.0.1]) by dzick.interlinknetworks.com (8.11.0/8.11.0) with ESMTP id g2BL4XZ01740 for ; Mon, 11 Mar 2002 16:04:33 -0500 Message-ID: <3C8D1BE1.2CEC0D20@interlinknetworks.com> Date: Mon, 11 Mar 2002 16:04:33 -0500 From: Don Zick Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: aaa-wg@merit.edu Subject: [AAA-WG]: Subject: [issue] Diameter CMS Security - Clarify DSA participants Content-Type: text/plain; charset=iso-8859-1 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id QAA24785 Submitter name: Don Zick Submitter email address: dzick@interlinknetworks.com Date first submitted: March 11, 2002 Reference: Document: cms Comment type: T Priority: 1 Section: Rationale/Explanation of issue It is not clear to me from reading the Diameter CMS Security draft if a DSA can be established between a diameter node and a diameter realm. Requested change: Please add text explaining that a DSA can only involve two diameter nodes. From owner-aaa-wg@merit.edu Mon Mar 11 16:58:19 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26685 for ; Mon, 11 Mar 2002 16:58:18 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DD3B09125A; Mon, 11 Mar 2002 16:58:10 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B313A9125B; Mon, 11 Mar 2002 16:58:10 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 847329125A for ; Mon, 11 Mar 2002 16:58:09 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5588B5DE16; Mon, 11 Mar 2002 16:57:20 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id CC5EA5DDCC for ; Mon, 11 Mar 2002 16:57:19 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g2BLG9w17942; Mon, 11 Mar 2002 13:16:09 -0800 Date: Mon, 11 Mar 2002 13:16:09 -0800 (PST) From: Bernard Aboba To: Tony Johansson Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: Updated AAA WG issues list In-Reply-To: <3C8D0EA8.D502F749@ericsson.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Thanks, Tony. Will revise the issues list to reflect this. On Mon, 11 Mar 2002, Tony Johansson wrote: > Hi Bernard and All, > > I'm sorry that I haven't sent an update earlier, but I'm been out of office > last week. > > MIP Issues update: > > CLOSED (MIP-09) Issue #264 User-Name in Answer messages > CLOSED (MIP-09) Issue #265 MIP-Reg-Reply AVP not required > in AMA for Co-located MN > CLOSED (MIP-09) Issue #266 Returning AAAF-Generated FA-HA > Key to FA > CLOSED (MIP-09) Issue #267 Minor corrections / clarifications > to draft-mobileip-08 > CLOSED (MIP-09) Issue #286 MIP-Home-Agent-Host AVP > CLOSED (MIP-09) Issue #290 Handling of > Accounting-Multi-Session-Id AVP > Rejected Issue #292 Handling of > Home-Agent-In-Foreign-Network flag > > Regards, > > Tony > > > From owner-aaa-wg@merit.edu Mon Mar 11 17:05:01 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27025 for ; Mon, 11 Mar 2002 17:05:00 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 287BA9125D; Mon, 11 Mar 2002 17:04:47 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EE6B59125E; Mon, 11 Mar 2002 17:04:46 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E24929125D for ; Mon, 11 Mar 2002 17:04:45 -0500 (EST) Received: by segue.merit.edu (Postfix) id C95C25DDCC; Mon, 11 Mar 2002 17:04:45 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from dzick.interlinknetworks.com (nat.interlinknetworks.com [198.108.5.3]) by segue.merit.edu (Postfix) with ESMTP id 7027F5DDB9 for ; Mon, 11 Mar 2002 17:04:45 -0500 (EST) Received: from interlinknetworks.com (localhost.localdomain [127.0.0.1]) by dzick.interlinknetworks.com (8.11.0/8.11.0) with ESMTP id g2BLnxZ01755 for ; Mon, 11 Mar 2002 16:49:59 -0500 Message-ID: <3C8D2687.92CF784D@interlinknetworks.com> Date: Mon, 11 Mar 2002 16:49:59 -0500 From: Don Zick Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: aaa-wg@merit.edu Subject: [AAA-WG]: [issue] Diameter CMS Security - Require AAA-Node-Cert in DSAR and DSAA Content-Type: text/plain; charset=iso-8859-1 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id RAA27025 Submitter name: Don Zick Submitter email address: dzick@interlinknetworks.com Date first submitted: March 11, 2002 Reference: Document: cms Comment type: T Priority: 1 Section: Rationale/Explanation of issue A single occurrence of the AAA-Node-Cert AVP should be required in the DSAR and the DSAA. The Diameter CMS Security draft states (in section 3): In order to encrypt AVPs for a recipient, the originating Diameter node must have a copy of the recipient's public key. There are many well-known key retrieval schemes (e.g. LDAP [CERTLDAP]), but this specification also allows for the transportation of certificates within Diameter AVPs, which is expected to simplify implementations. If inclusion of the AAA-Node-Cert AVP is optional then the expected simplification in implementations is lost because compliant implementations must be able to handle DSAR and DSAA messages that don't include the AAA-Node-Cert AVPs. Requested change: Please update the occurrence rules table and the ABNF definitions for the DSAR and DSAA to indicate that exactly 1 occurrence of the AAA-Node-Cert must be present. From owner-aaa-wg@merit.edu Mon Mar 11 17:07:44 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27134 for ; Mon, 11 Mar 2002 17:07:44 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 09CEF9125E; Mon, 11 Mar 2002 17:07:34 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CDBFC9125F; Mon, 11 Mar 2002 17:07:33 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CBBB79125E for ; Mon, 11 Mar 2002 17:07:32 -0500 (EST) Received: by segue.merit.edu (Postfix) id AC3E05DDCC; Mon, 11 Mar 2002 17:07:32 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 965435DDB9 for ; Mon, 11 Mar 2002 17:07:32 -0500 (EST) Received: from Interlinknetworks.com (nat.interlinknetworks.com [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with ESMTP id 5407D7C; Mon, 11 Mar 2002 17:07:32 -0500 (EST) Message-ID: <3C8D2AAF.94378FE7@Interlinknetworks.com> Date: Mon, 11 Mar 2002 17:07:43 -0500 From: David Spence Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: David Frascone Cc: john.loughney@nokia.com, aboba@internaut.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 303: Security model for peer discovery and redirect References: <0C1353ABB1DEB74DB067ADFF749C4EEFC64BB3@esebe004.NOE.Nokia.com> <20020311120232.GD22132@newman.frascone.com> Content-Type: multipart/mixed; boundary="------------511B89CB3A7B28C570C977E0" Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. --------------511B89CB3A7B28C570C977E0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I raised a number of specific security concerns in issue 303 and I don't think it is responsible to dismiss them summarily. I think each deserves some kind of response. I am actually very concerned that peer-to-peer security may be worse in Diameter than it is in RADIUS. RADIUS has real peer-to-peer security -- the shared secret! Yes, I know it's real bad security. But at least there's something real about it. Diameter may be run with no security -- and the server won't even know. Consider IPsec. The underlying problem with IPsec is that it isn't easy for a "Diameter node" (server or client process) to verify that IPsec is being used. This weakness can be exploited in a number of ways. Issue 303 mentioned one of them. If a peer-to-peer connection is being established dynamically due to peer discovery or the action of a redirect agent, it is rather likely that an IPsec tunnel does not exist. (If it did, you wouldn't need peer discovery or a redirect agent.) But I believe that the problems of relying on IPsec run deeper than that. Example 1: Consider the case of the ISP Fastgrowth.net. Fastgrowth has 12 NASes named nas01.fastgrowth.net through nas12.fastgrowth.net. Their Diameter server is named aaa1.fastgrowth.net. The configured peer table for this server contains entries for nas01 through nas99. IPsec is used for peer-to-peer security. When a new NAS is installed, the network administrator assigns it a name in the range nas01-nas99 and sets up an IPsec tunnel for it. Now an attacker in Elbonia wishes to attack Fastgrowth with the aid of a Diameter Attack Client he's cobbled together. He names his client nas13.fastgrowth.net (on a hunch) and attempts to bring up a peer-to-peer connection with aaa1.fastgrowth.net. As luck would have it, the name he chose is in aaa1's peer table. Of course there is no IPsec tunnel, but aaa1 doesn't know that. So aaa1 merrily brings up a connection with the impostor. That attack would have been much harder to pull off with RADIUS because of the burden of having to guess the shared secret. So much for IPsec. At least TLS doesn't have that problem. With TLS, you know you're secure. Maybe. Example 2: A group of small, regional ISPs spread across the northern U.S. from Lake Wobegone, Minnesota all the way to Blight, Idaho, has established a roaming consortium called the Northern Alliance. Consortium members establish peer-to-peer connections between their Diameter servers as needed using peer discovery. For security, they use TLS. Since most of their administrators are not security experts, they want to make sure they get it right. They choose Verisign as their CA. Now a group of outlaws in Wyoming starts up a small ISP of their own called Blackhats.net. They do not join the Northern Alliance. But their leader, Jesse James, applies to Verisign for a certificate for their Diameter server. Now, without bothering to join, they can send peer-to-peer connection requests to Diameter servers throughout the Northern Alliance. When the Diameter server for Sittingducks.net, the Lake Wobegone ISP, receives one of these requests, it examines the tendered TLS certificate and reads the fine print, which says, "To whom it may concern: We, Verisign, have verified the identity of one Jesse James by comparing his face to the photographs on the wall of the Post Office down the street. We are confident that the applicant for this certificate really is Jesse James and that he really is a principle of the Wyoming corporation Blackhats.net." So they merrily bring up the connection. Again, the attack would have failed with RADIUS because Jesse would never have guessed their shared secret "happytrails2U". Yes, I know the Northern Alliance could have done better. But we haven't exactly helped them by explaining in our Security Considerations how TLS should and should not be used to secure peer-to-peer connections. Now here's the real problem. The real problem is that Diameter, when used to support roaming in a multi-domain environment, relies on transitive trust. I trust the Diameter messages sent by all the good buddies of my good buddies because I trust my good buddies' trust. This means that if a successful peer-to-peer attack can be launched against any of the thousands of my buddies' buddies, then I am vulnerable. Example 3: The GrockPass Roaming Broker decides to upgrade the GrockPass Alliance from RADIUS to Diameter for all inter-domain AAA requests because of Diameter's superior security. GrockPass uses TLS security and they themselves run the CA for the alliance so there won't be any funny business. Only certificates signed by GrockPass are accepted by alliance members. One day Maxwell Smart, the system administrator for GoodVigilance.net, notices that their Diameter server has received a very large number of failed authentication requests from GrockPass affiliate Laxnet.com proxied through GrockPass. The failed authentication requests all come from nas13.laxnet.com and appear to be an attempt to mount a dictionary attack against the PAP passwords of the GoodVigilance dialin users. Max calls up his counterpart Dudley Hopewell at Laxnet. "Gee," Dudley says, "We don't even have a nas13." Dang those Elbonians. In this example, all the good vigilance of GoodVigilance and GrockPass could not protect them. That is why, if you are designing a multi-domain protocol, you SHOULD NOT make it rely on the intelligence and vigilance of all the domains' network administrators. Because even if an administrative domain believes in the intelligence and vigilance of its own administrator, what about all the other stupid, lazy administrators out there? At least let the vendors help out by making the application verify the security directly wherever possible. And where it's not possible, make sure the vendors understand the Security Considerations well enough to insert plenty of BIG BOLD WARNING MESSAGES in their GUIs to give their customers a little help. In conclusion, Diameter has the following peer-to-peer "features" that RADIUS lacks. 1) Dynamic peer-to-peer connections (ones that are not preconfigured). Both peer discovery and redirect agents require this. 2) Non-verifiable peer-to-peer security associations (IPsec). 3) The ability, by abusing TLS, to bring up authenticated, but unauthorized peer-to-peer connections. We need to be sure Diameter nodes can implement these features securely or else remove them. The two questions in each case are, how do I know I'm authorized to establish this connection and how can I authenticate the peer? If we can't answer these two questions satisfactorily, we should stick to configured peers with configured shared secrets. David Frascone wrote: > > My vote would be to reject this issue. > > But, to address the possible security issues, perhaps we should allow > implementations to decide whether they allow redirects. (In other words, > server X might not allow redirects from realm Y) > > As far as server discovery goes . . . that smells like an implementation > issue. . . . . > > -Dave > > On Monday, 11 Mar 2002, john.loughney@nokia.com wrote: > > Hi all, > > > > http://www.drizzle.com/~aboba/AAA/issues.html#Issue%20#303 > > > > Issue 303 is a quite a big change, in my opinion. I am somewhat > > hesitant about tackling this, so I thing the WG needs to discuss > > this. Security is, of course, extremely important. Does the > > workgroup see this a good solution? > > > > I'd appreciate comments on this. > > > > thanks, > > John > > > > PS - the requestion change is: > > > > I think the usefulness of the redirect and server discovery models > > ought to be reexamined in light of the security problems they > > introduce.It may be that removing redirect and server discovery > > from Diameter is the best solution. > > > > -- > David Frascone > > Don't just do something !!! Stand there !!! --------------511B89CB3A7B28C570C977E0 Content-Type: text/x-vcard; charset=us-ascii; name="DSpence.vcf" Content-Description: Card for David Spence Content-Disposition: attachment; filename="DSpence.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:; tel;fax:+1 734 821 1235 tel;work:+1 734 821 1203 x-mozilla-html:FALSE url:http://www.interlinknetworks.com org:Interlink Networks, Inc. adr:;;775 Technology Dr., Suite 200;Ann Arbor;MI;48108;USA version:2.1 email;internet:DSpence@Interlinknetworks.com title:Architect fn:David Spence end:vcard --------------511B89CB3A7B28C570C977E0-- From owner-aaa-wg@merit.edu Mon Mar 11 17:16:45 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27458 for ; Mon, 11 Mar 2002 17:16:44 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 381A69125F; Mon, 11 Mar 2002 17:16:28 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EA56D91260; Mon, 11 Mar 2002 17:16:27 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A2B579125F for ; Mon, 11 Mar 2002 17:16:26 -0500 (EST) Received: by segue.merit.edu (Postfix) id 86EE65DDE4; Mon, 11 Mar 2002 17:16:26 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 72BEF5DDB9 for ; Mon, 11 Mar 2002 17:16:26 -0500 (EST) Received: from Interlinknetworks.com (nat.interlinknetworks.com [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with ESMTP id 1ACD37C; Mon, 11 Mar 2002 17:16:26 -0500 (EST) Message-ID: <3C8D2CC5.DBC99EE3@Interlinknetworks.com> Date: Mon, 11 Mar 2002 17:16:37 -0500 From: David Spence Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Pat R. Calhoun" Cc: "'john.loughney@nokia.com'" , aboba@internaut.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 302: Combine occurrence rules tables with message ABNF - Comments? References: Content-Type: multipart/mixed; boundary="------------97CE7FBE2ADF1E64190A7C0F" Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. --------------97CE7FBE2ADF1E64190A7C0F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Well, admittedly, this issue is not critical. I was just thinking that while the WG is chewing on some of the *real* issues, the editors might quietly sit back and edit, that is, make the (still future) PS more readable. Remove the BS from the PS! > "Pat R. Calhoun" wrote: > > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > I think we are at a point where we need to worry about getting a > document out... We can go back and forth on editorial issues 'til the > cows come home, but is delaying the RFC really benefiting the > Internet community? What I've heard in the past weeks is that others > will soon take the matter in their own hands if the AAA WG doesn't > come up with a PS soon. > > Food for thought. > > PatC > > - -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: Sunday, March 10, 2002 11:02 PM > To: aboba@internaut.com; aaa-wg@merit.edu > Subject: [AAA-WG]: Issue 302: Combine occurrence rules tables with > message ABNF - Comments? > > Hi all, > > Issue 302 proposes an editorial modification to the drafts, > for ABNF usage. Does the workgroup feel that this will > improve the documentation? > > John > > http://www.drizzle.com/~aboba/AAA/issues.html#Issue%20#302 > > -----BEGIN PGP SIGNATURE----- > Version: PGPfreeware 7.0.3 for non-commercial use > > iQA/AwUBPIzPXTN1fXKoxmisEQJ4QgCg+IGb5BapfvYTXvMKMhhV7d/ojCgAn1dQ > qZp+75VoioBBzIP8JAswCS/4 > =mR4g > -----END PGP SIGNATURE----- --------------97CE7FBE2ADF1E64190A7C0F Content-Type: text/x-vcard; charset=us-ascii; name="DSpence.vcf" Content-Description: Card for David Spence Content-Disposition: attachment; filename="DSpence.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:; tel;fax:+1 734 821 1235 tel;work:+1 734 821 1203 x-mozilla-html:FALSE url:http://www.interlinknetworks.com org:Interlink Networks, Inc. adr:;;775 Technology Dr., Suite 200;Ann Arbor;MI;48108;USA version:2.1 email;internet:DSpence@Interlinknetworks.com title:Architect fn:David Spence end:vcard --------------97CE7FBE2ADF1E64190A7C0F-- From owner-aaa-wg@merit.edu Mon Mar 11 18:02:55 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28694 for ; Mon, 11 Mar 2002 18:02:55 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 0E16891262; Mon, 11 Mar 2002 18:01:37 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D00D691263; Mon, 11 Mar 2002 18:01:36 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 910D691262 for ; Mon, 11 Mar 2002 18:01:35 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6CD4E5DE12; Mon, 11 Mar 2002 18:01:35 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17]) by segue.merit.edu (Postfix) with ESMTP id CBDCC5DDB9 for ; Mon, 11 Mar 2002 18:01:34 -0500 (EST) Received: from gwzpc (sjc-vpn2-513.cisco.com [10.21.114.1]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA27672; Mon, 11 Mar 2002 15:00:54 -0800 (PST) Reply-To: From: "Glen Zorn" To: "Don Zick" , Subject: RE: [AAA-WG]: [issue] Diameter CMS Security - Require AAA-Node-Cert in DSAR and DSAA Date: Mon, 11 Mar 2002 15:00:54 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <3C8D2687.92CF784D@interlinknetworks.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Don Zick [mailto://dzick@interlinknetworks.com] writes: > A single occurrence of the AAA-Node-Cert AVP should be required in the > DSAR and the DSAA. > > The Diameter CMS Security draft states (in section 3): > In order to encrypt AVPs for a recipient, the originating Diameter > node must have a copy of the recipient's public key. There are many > well-known key retrieval schemes (e.g. LDAP [CERTLDAP]), but this > specification also allows for the transportation of certificates > within Diameter AVPs, which is expected to simplify implementations. > > If inclusion of the AAA-Node-Cert AVP is optional then the expected > simplification in implementations is lost because compliant > implementations must be able to handle DSAR and DSAA messages that don't > include the AAA-Node-Cert AVPs. I disagree: compliant implementations must be able to handle DSAR and DSAA messages that don't include the AAA-Node-Cert AVPs, but they do _not_ have to include e.g. an LDAP client and are therefore simpler. > > Requested change: > > Please update the occurrence rules table and the ABNF definitions for > the DSAR and DSAA to indicate that exactly 1 occurrence of the > AAA-Node-Cert must be present. > > > From owner-aaa-wg@merit.edu Mon Mar 11 18:49:50 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29679 for ; Mon, 11 Mar 2002 18:49:50 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 42E7C91264; Mon, 11 Mar 2002 18:43:59 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0A11491266; Mon, 11 Mar 2002 18:43:58 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5343791264 for ; Mon, 11 Mar 2002 18:43:55 -0500 (EST) Received: by segue.merit.edu (Postfix) id 385AB5DE2F; Mon, 11 Mar 2002 18:43:55 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from frascone.com (adsl-66-137-237-97.dsl.rcsntx.swbell.net [66.137.237.97]) by segue.merit.edu (Postfix) with SMTP id A037A5DDB9 for ; Mon, 11 Mar 2002 18:43:54 -0500 (EST) Received: (qmail 28530 invoked by uid 500); 11 Mar 2002 23:43:41 -0000 Date: Mon, 11 Mar 2002 17:43:41 -0600 From: David Frascone To: Randy Bush Cc: David Frascone , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 303: Security model for peer discovery and redirect Message-ID: <20020311234341.GE22132@newman.frascone.com> Mail-Followup-To: Randy Bush , David Frascone , aaa-wg@merit.edu References: <0C1353ABB1DEB74DB067ADFF749C4EEFC64BB3@esebe004.NOE.Nokia.com> <20020311120232.GD22132@newman.frascone.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.25i X-encrypt-payload: no Sender: owner-aaa-wg@merit.edu Precedence: bulk On Monday, 11 Mar 2002, Randy Bush wrote: > security should not be an "implementation issue." authentication > of a referred host by the host which receives their request would > seem to be pretty basic security. I didn't mean to imply that I was comfortable blowing off security. What I meant was, for different scenarios, whether or not to allow redirects and/or discovery should be a configurable setting (and therefor an implementation issue) For example, within your home realm, having your home server redirect you to a server with better load charastics would be a benefit. Now, for the really paranoid, a server could be configured to only accept redirects after a SA with the redirecting host was verified. (via TLS or IPSEC) Also, when a server is in a foreign realm, and is doing peer discovery, the entire realm is possibly suspect. So, any server found, whether by discovery or by pre-configured address is still possibly an "evil" machine. So, discovery in this case does not add any danger, IMHO. > > on first blush, it seems to me that there are only three ways to > solve this (but it's still early here) > > o trusted referrer gives referee a signed cert to be handed to > the host to which they refer them Heh . . I guess I should have read this before I preposed the same thing :) > o trusted referrer acts as a relay/proxy, with all the kink > that gets us > > o never talk to folk with whom you do not have a configured > relationship > > oh, and then there is hanging your butt out there in the breeze > waiting to be killed All of these issues really depend on the scenario . . . that's why I voted *no* to dropping the ability to do redirects and discovery. I think they are useful tools. But, I also agree that they are potentially dangerous. Perhaps we should (instead of killing the features) add a few paragraphs outlining the security threats, and how to avoid them, depending on the situation. -Dave From owner-aaa-wg@merit.edu Tue Mar 12 00:14:18 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07224 for ; Tue, 12 Mar 2002 00:14:18 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5D43E91269; Tue, 12 Mar 2002 00:14:05 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3327B9126A; Tue, 12 Mar 2002 00:14:05 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 20E9191269 for ; Tue, 12 Mar 2002 00:14:04 -0500 (EST) Received: by segue.merit.edu (Postfix) id F027D5DE03; Tue, 12 Mar 2002 00:14:03 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 785445DDAD for ; Tue, 12 Mar 2002 00:14:03 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g2C4WoV09482; Mon, 11 Mar 2002 20:32:50 -0800 Date: Mon, 11 Mar 2002 20:32:50 -0800 (PST) From: Bernard Aboba To: Don Zick Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: [issue] Diameter CMS Security - Remove DSA-TTL from PDSA message In-Reply-To: <3C8D1B8B.9C8E2031@interlinknetworks.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Assigned issue #307. On Mon, 11 Mar 2002, Don Zick wrote: > Submitter name: Don Zick > Submitter email address: dzick@interlinknetworks.com > Date first submitted: March 11, 2002 > Reference: > Document: cms > Comment type: T > Priority: 1 > Section: > Rationale/Explanation of issue > > A diameter agent may establish security associations on behalf of access > devices. The access devices issue the PDSR message to request this. It > is simpler for the access devices if they do not have to re-issue the > PDSR because of DSA-TTL expiry. Also, the diameter agent may make use of > the same DSA for more than one access device; in this case it doesn't > make much sense for multiple access devices to be responsible for > re-establishing the same DSA. > > Requested change: > > Replace text from section 1.3: > > The PDSA MUST > contain the TTL setting agreed by the proxy agent for its DSA. > This information will allow the access device to re-issue a PDSR > prior to the proxy's DSA expiry if it needs the DSA to remain > active. > > with this text: > > The proxy agent is responsible for re-establishing the DSA > prior to expiration without any involvement by the access > device. > > Also, remove DSA-TTL from PDSA ABNF definition. > From owner-aaa-wg@merit.edu Tue Mar 12 00:16:33 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07258 for ; Tue, 12 Mar 2002 00:16:33 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id BF0FA9126A; Tue, 12 Mar 2002 00:15:39 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 90D939126B; Tue, 12 Mar 2002 00:15:39 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D2EF79126A for ; Tue, 12 Mar 2002 00:15:36 -0500 (EST) Received: by segue.merit.edu (Postfix) id 983755DDB9; Tue, 12 Mar 2002 00:15:36 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 5C14A5DDAD for ; Tue, 12 Mar 2002 00:15:34 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g2C4YSo09563; Mon, 11 Mar 2002 20:34:29 -0800 Date: Mon, 11 Mar 2002 20:34:28 -0800 (PST) From: Bernard Aboba To: Johan Johansson Cc: AAA Working Group Subject: Re: [AAA-WG]: [issue] Session-Timeout vs Authorization-Lifetime vs MIP-Key-Lifetime In-Reply-To: <3C8D185C.30003@ipunplugged.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Assigned issue #306. On Mon, 11 Mar 2002, Johan Johansson wrote: > Subject: [issue] Session-Timeout vs Authorization-Lifetime vs > MIP-Key-Lifetime > > Submitter name: Johan Johansson > Submitter email address: johanj@ipunplugged.com > Date first submitted: March 11, 2002 > Reference: > Document: Mobile IP > Comment type: T > Priority: 1 > Section: 2.2, 2.3, 5.1, 8.1 > Rationale/Explanation of issue: > > If there is to be any hope for interoperability the use of > Session-Timeout must be defined in the MIP draft. > > The base draft defines Session-Timeout as > > 8.13 Session-Timeout AVP > > The Session-Timeout AVP (AVP Code 27) [RADIUS] is of type Unsigned32 > and contains the maximum number of seconds of service to be provided > to the user before termination of the session. When both the Session- > Timeout and the Authorization-Lifetime AVPs are present in an answer > message, the former MUST be equal to or greater than the value of the > latter. > > --- > > A Session-Timeout AVP MAY be present in a re-authorization message, > and contains the number of seconds from the beginning of the re-auth. > > A value of zero, or the absence of this AVP, means that this session > has an unlimited number of seconds before termination. > > Section 8.9 of the base draft has this to say about Authorization-Lifetime: > > An Authorization-Lifetime AVP MAY be present in re-authorization > messages, and contains the number of seconds the user is authorized > to receive service from the time the re-auth answer message is > received by the access device. > > The MIP draft contains no references to Session-Timeout beyond the > occurence rules and the ABNFs and they are contradictory. > > The occurence rules of the MIP draft states > > +-----------------------+ > | Command-Code | > |-----+-----+-----+-----+ > Attribute Name | AMR | AMA | HAR | HAA | > ------------------------------|-----+-----+-----+-----+ > Session-Timeout | 0 | 1 | 1 | 0 | > > The ABNFs for AMA and HAR list it as optional. Looking solely at the > base draft the ABNF would seem to be correct. > > But this still does not settle the issue of the semantics of its > presence. Section 5.1 of the mip draft states > > The Diameter Mobile IP application makes use of two timers - the > Authorization-Lifetime AVP [DIAMBASE] and the MIP-Key-Lifetime AVP. > > The Authorization-Lifetime contains the number of seconds before the > Mobile Node must issue a subsequent MIP registration request. The > content of the Authorization-Lifetime AVP corresponds to the Lifetime > field in the MIP header [MOBILEIP]. > > The MIP-Key-Lifetime AVP contains the number of seconds before > session keys destined for the Mobility Agents and the Mobile Node > expire. A value of zero indicates infinity (no timeout). If not zero, > the value of the MIP-Key-Lifetime AVP MUST be at least equal to the > value in the Authorization Lifetime AVP. > > If the application doesn't use Session-Timeout it should not be optional > or mandatory but banned. The section quoted above inevitably leads to > the the termination of the user session after at least > Authorization-Lifetime seconds and at most Authorization-Lifetime + > MIP-Key-Lifetime seconds. > > Requested change: > > Remove Session-Timeout from AMA and HAR. > > Modify the first paragraph of section 5.1 to: > > The Diameter Mobile IP application makes use of two timers - the > Authorization-Lifetime AVP [DIAMBASE] and the MIP-Key-Lifetime AVP. The > Session-Timeout AVP [DIAMBASE] does not apply to this application. > > j > > > From owner-aaa-wg@merit.edu Tue Mar 12 04:36:11 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18481 for ; Tue, 12 Mar 2002 04:36:06 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5716D91208; Tue, 12 Mar 2002 04:35:54 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 20EE99126B; Tue, 12 Mar 2002 04:35:54 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D819F91208 for ; Tue, 12 Mar 2002 04:35:52 -0500 (EST) Received: by segue.merit.edu (Postfix) id AD73B5DE02; Tue, 12 Mar 2002 04:35:52 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by segue.merit.edu (Postfix) with ESMTP id D01725DDAA for ; Tue, 12 Mar 2002 04:35:51 -0500 (EST) Received: from fredrikj (hotel-33.local.ipunplugged.com [192.168.8.33]) by mailgw.ipunplugged.com (8.9.3/8.9.3) with SMTP id KAA24316; Tue, 12 Mar 2002 10:31:04 +0100 From: "Fredrik Johansson" To: "Sivasundar Ramamurthy" , "AAA Working Group" , "Tony Johansson" Subject: RE: [AAA-WG]: Re: Pending Issue about MIP-Key-Lifetime AVP (fwd) Date: Tue, 12 Mar 2002 10:34:08 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: Importance: Normal Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit I believe we need some clarifications on what timers are to be used. I belive this can be done in two ways, using two or three of the lifetime AVPs. Alt 1. Use Authorization-Lifetime to indicate the MIP tunnel lifetime (i.e the value that goes into the mip registration reply packet) and the MIP-Key-Lifetime is the time of the keys and the session. Thus to extend the session and request new keys has to be done every MIP-Key-Lifetime seconds. In this alternative, the Session will have the same lifetime as the keys. I.e. the MN must make sure to request new keys some time before the actual time expires. Alt 2. Use three AVPs, one for the session, one for the keys and one for the mip tunnels. I.e. Let the session-lifetime AVP be the maximum lifetime of the session, the mip-key-lifetime is the lifetime of the session keys, and the authorization-lifetime avp is the length of the mip tunnel lifetime. This will mean that the MN will reauthenticate periodically with the HA at Authorization-Lifetime in order to update the tunnels, it will request new keys at MIP-Key-Lifetime, the Session-Lifetime will indicate when the diameter client/server will terminate the session. The Session lifetime MUST be greater or equal to the MIP-Key-Lifetime (preferable greater to allow the mobile some time to request new keys and extend the session). /Fredrik >-----Original Message----- >From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of >Sivasundar Ramamurthy >Sent: den 11 mars 2002 21:21 >To: AAA Working Group >Subject: Re: [AAA-WG]: Re: Pending Issue about MIP-Key-Lifetime AVP >(fwd) > > > >On Mon, 25 Feb 2002, Tony Johansson wrote: > >> New section: >> >> "5.1 Authorization Lifetime vs. MIP Key Lifetime >> >> The Diameter Mobile IP application makes use of two timers the >> Authorization-Lifetime AVP [DIAMBASE] and the MIP-Key-Lifetime AVP. >> >> The Authorization-Lifetime contains the number of seconds before the >> Mobile Node must issue a subsequent MIP registration request. The >> content of Authorization-Lifetime AVP corresponds to the Lifetime >> field in the MIP header [MOBILEIP]. >> >> The MIP-Key-Lifetime AVP contains the number of seconds before >> session keys destined for the Home Agent and/or Foreign Agent expire. >> >> A value of zero indicates infinity (no timeout). The value of the >> MIP-Key-Lifetime AVP MUST be at least equal to the value in the >> Authorization Lifetime AVP. If the value is greater, it SHOULD be a >> multiple of the value in the Authorization Lifetime AVP." >> > >if the key lifetime is allowed to be greater than the authorization >lifetime, then the authorization lifetime at the (stateful) AAA server >will expire even as the MN is re-registering. This will happen since >the MN "knows" to use AAA only to request keys; it will re-register >(re-authenticate) directly with the HA during the time the keys are >alive. > >Thus even while the MN is happily registered (authenticated), the >(stateful) AAA server will see that its authorization lifetime has >expired and will terminate its session and de-allocate the resources. >Is'nt this a problem, considering that one of the resources allocated >could be a dynamic home address which could then be allocated to some >other MN? > > >thanks! > >Siva > > > From owner-aaa-wg@merit.edu Tue Mar 12 06:41:34 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19450 for ; Tue, 12 Mar 2002 06:41:34 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DB1DB9126B; Tue, 12 Mar 2002 06:41:18 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A8E399126C; Tue, 12 Mar 2002 06:41:18 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6E0879126B for ; Tue, 12 Mar 2002 06:41:17 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4C1D85DE19; Tue, 12 Mar 2002 06:41:17 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from ocasey.baltimore.com (ocasey.baltimore.com [193.41.17.101]) by segue.merit.edu (Postfix) with ESMTP id 7EFAF5DDAA for ; Tue, 12 Mar 2002 06:41:16 -0500 (EST) Received: from Baltimore-FW1 ([172.19.1.1]) by ocasey.baltimore.com (8.11.6/8.9.3) with SMTP id g2CBfFb18682 for ; Tue, 12 Mar 2002 11:41:15 GMT Received: from Baltimore-FW1 (wilde-i-1.ie.baltimore.com) by emeairlsw1.baltimore.com (Content Technologies SMTPRS 4.2.5) with SMTP id for ; Tue, 12 Mar 2002 11:36:12 +0000 Received: from baltimore.ie (wks140-4.ie.baltimore.com [10.153.4.140]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id LAA07673; Tue, 12 Mar 2002 11:41:11 GMT Message-ID: <3C8DE961.5547EDA@baltimore.ie> Date: Tue, 12 Mar 2002 11:41:22 +0000 From: Stephen Farrell Reply-To: stephen.farrell@baltimore.ie Organization: Baltimore Technologies Ltd. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: gwz@cisco.com Cc: Don Zick , aaa-wg@merit.edu Subject: Re: [AAA-WG]: [issue] Diameter CMS Security - Require AAA-Node-Cert in DSAR and DSAA References: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Don, I'd be with Glen on this one and would rather not insist that certs must be present. Also, note that if all that's needed is encryption from Alice to Bod, and Alice sends a DSAR, there's no need for Alice to ever have a certificate of her own. Similarly, Bob's DSAA could (though I think it'd be unwise), omit Bob's cert if somehow Bob knows that Alice will have it via some other route. Stephen. Glen Zorn wrote: > > Don Zick [mailto://dzick@interlinknetworks.com] writes: > > > A single occurrence of the AAA-Node-Cert AVP should be required in the > > DSAR and the DSAA. > > > > The Diameter CMS Security draft states (in section 3): > > In order to encrypt AVPs for a recipient, the originating Diameter > > node must have a copy of the recipient's public key. There are many > > well-known key retrieval schemes (e.g. LDAP [CERTLDAP]), but this > > specification also allows for the transportation of certificates > > within Diameter AVPs, which is expected to simplify implementations. > > > > If inclusion of the AAA-Node-Cert AVP is optional then the expected > > simplification in implementations is lost because compliant > > implementations must be able to handle DSAR and DSAA messages that don't > > include the AAA-Node-Cert AVPs. > > I disagree: compliant implementations must be able to handle DSAR and DSAA > messages that don't > include the AAA-Node-Cert AVPs, but they do _not_ have to include e.g. an > LDAP client and are therefore simpler. > > > > > Requested change: > > > > Please update the occurrence rules table and the ABNF definitions for > > the DSAR and DSAA to indicate that exactly 1 occurrence of the > > AAA-Node-Cert must be present. > > > > > > -- ____________________________________________________________ Stephen Farrell Baltimore Technologies, tel: (direct line) +353 1 881 6716 39 Parkgate Street, fax: +353 1 881 7000 Dublin 8. mailto:stephen.farrell@baltimore.ie Ireland http://www.baltimore.com From owner-aaa-wg@merit.edu Tue Mar 12 06:43:15 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19475 for ; Tue, 12 Mar 2002 06:43:15 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DA3A19126C; Tue, 12 Mar 2002 06:42:58 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AE0EC9126D; Tue, 12 Mar 2002 06:42:58 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7F68B9126C for ; Tue, 12 Mar 2002 06:42:57 -0500 (EST) Received: by segue.merit.edu (Postfix) id 656EC5DE19; Tue, 12 Mar 2002 06:42:57 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from ocasey.baltimore.com (ocasey.baltimore.com [193.41.17.101]) by segue.merit.edu (Postfix) with ESMTP id 96DCE5DDAA for ; Tue, 12 Mar 2002 06:42:56 -0500 (EST) Received: from Baltimore-FW1 ([172.19.1.1]) by ocasey.baltimore.com (8.11.6/8.9.3) with SMTP id g2CBgub18718 for ; Tue, 12 Mar 2002 11:42:56 GMT Received: from Baltimore-FW1 (wilde-i-1.ie.baltimore.com) by emeairlsw1.baltimore.com (Content Technologies SMTPRS 4.2.5) with SMTP id for ; Tue, 12 Mar 2002 11:37:53 +0000 Received: from baltimore.ie (wks140-4.ie.baltimore.com [10.153.4.140]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id LAA07703; Tue, 12 Mar 2002 11:42:52 GMT Message-ID: <3C8DE9C7.2E8BCB79@baltimore.ie> Date: Tue, 12 Mar 2002 11:43:03 +0000 From: Stephen Farrell Reply-To: stephen.farrell@baltimore.ie Organization: Baltimore Technologies Ltd. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Don Zick Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Subject: [issue] Diameter CMS Security - Clarify DSA participants References: <3C8D1BE1.2CEC0D20@interlinknetworks.com> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Don, > Please add text explaining that a DSA can only involve two diameter > nodes. I don't know what you want. Why don't you suggest text to add? Stephen. -- ____________________________________________________________ Stephen Farrell Baltimore Technologies, tel: (direct line) +353 1 881 6716 39 Parkgate Street, fax: +353 1 881 7000 Dublin 8. mailto:stephen.farrell@baltimore.ie Ireland http://www.baltimore.com From owner-aaa-wg@merit.edu Tue Mar 12 06:49:17 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19579 for ; Tue, 12 Mar 2002 06:49:17 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7489591217; Tue, 12 Mar 2002 06:49:05 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4A96A9126D; Tue, 12 Mar 2002 06:49:05 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 17B1F91217 for ; Tue, 12 Mar 2002 06:49:04 -0500 (EST) Received: by segue.merit.edu (Postfix) id ED8415DE19; Tue, 12 Mar 2002 06:49:03 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from ocasey.baltimore.com (ocasey.baltimore.com [193.41.17.101]) by segue.merit.edu (Postfix) with ESMTP id 2D2725DDAA for ; Tue, 12 Mar 2002 06:49:03 -0500 (EST) Received: from Baltimore-FW1 ([172.19.1.1]) by ocasey.baltimore.com (8.11.6/8.9.3) with SMTP id g2CBn2b18813 for ; Tue, 12 Mar 2002 11:49:02 GMT Received: from Baltimore-FW1 (wilde-i-1.ie.baltimore.com) by emeairlsw1.baltimore.com (Content Technologies SMTPRS 4.2.5) with SMTP id for ; Tue, 12 Mar 2002 11:43:59 +0000 Received: from baltimore.ie (wks140-4.ie.baltimore.com [10.153.4.140]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id LAA07815; Tue, 12 Mar 2002 11:48:59 GMT Message-ID: <3C8DEB36.CB9A0A76@baltimore.ie> Date: Tue, 12 Mar 2002 11:49:10 +0000 From: Stephen Farrell Reply-To: stephen.farrell@baltimore.ie Organization: Baltimore Technologies Ltd. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Don Zick Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: [issue] Diameter CMS Security - Remove DSA-TTL from PDSA message References: <3C8D1B8B.9C8E2031@interlinknetworks.com> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Don, Reckon I'd be against this one at this stage (i.e. you might, but haven't, convinced me;-), > A diameter agent may establish security associations on behalf of access > devices. The access devices issue the PDSR message to request this. It > is simpler for the access devices if they do not have to re-issue the > PDSR because of DSA-TTL expiry. Presumably the access device that sent the PDSR only did so because it wants to be told (by an agent trusted via local configuration) that CMS will be used as appropriate. My take would be that without the TTL in the PDSA the agent would then need a way to signal to the access device that CMS is about to go "off". If true, that'd definitely not be simpler. So, to me the simplification sounds a little nebulous; I understand how the current scheme can work and so would rather stick with it. > Also, the diameter agent may make use of > the same DSA for more than one access device; in this case it doesn't > make much sense for multiple access devices to be responsible for > re-establishing the same DSA. There's no requirement that the agent in this case have many DSAs. If that were implied it would be wrong. The same TTL value can be used in many PDSA messages if appropriate. > > Requested change: > > Replace text from section 1.3: > > The PDSA MUST > contain the TTL setting agreed by the proxy agent for its DSA. > This information will allow the access device to re-issue a PDSR > prior to the proxy's DSA expiry if it needs the DSA to remain > active. > > with this text: > > The proxy agent is responsible for re-establishing the DSA > prior to expiration without any involvement by the access > device. If that were included, then what's the point of the PDSR/PDSA at all? Stephen. -- ____________________________________________________________ Stephen Farrell Baltimore Technologies, tel: (direct line) +353 1 881 6716 39 Parkgate Street, fax: +353 1 881 7000 Dublin 8. mailto:stephen.farrell@baltimore.ie Ireland http://www.baltimore.com From owner-aaa-wg@merit.edu Tue Mar 12 09:02:36 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21982 for ; Tue, 12 Mar 2002 09:02:36 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 31D6391274; Tue, 12 Mar 2002 09:02:22 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 54E1F91275; Tue, 12 Mar 2002 09:02:16 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E3CAB91274 for ; Tue, 12 Mar 2002 09:02:14 -0500 (EST) Received: by segue.merit.edu (Postfix) id C001E5DE46; Tue, 12 Mar 2002 09:02:14 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from dzick.interlinknetworks.com (nat.interlinknetworks.com [198.108.5.3]) by segue.merit.edu (Postfix) with ESMTP id A36DC5DDD6 for ; Tue, 12 Mar 2002 09:02:14 -0500 (EST) Received: from interlinknetworks.com (localhost.localdomain [127.0.0.1]) by dzick.interlinknetworks.com (8.11.0/8.11.0) with ESMTP id g2CE0aJ01205; Tue, 12 Mar 2002 09:00:36 -0500 Message-ID: <3C8E0A03.A4F0492B@interlinknetworks.com> Date: Tue, 12 Mar 2002 09:00:35 -0500 From: Don Zick Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: stephen.farrell@baltimore.ie Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: [issue] Diameter CMS Security - Remove DSA-TTL from PDSA message References: <3C8D1B8B.9C8E2031@interlinknetworks.com> <3C8DEB36.CB9A0A76@baltimore.ie> Content-Type: text/plain; charset=iso-8859-1 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id JAA21982 Hi Stephen, Comments inline. Don Stephen Farrell wrote: > Don, > > Reckon I'd be against this one at this stage (i.e. you might, but > haven't, convinced me;-), > > > A diameter agent may establish security associations on behalf of access > > devices. The access devices issue the PDSR message to request this. It > > is simpler for the access devices if they do not have to re-issue the > > PDSR because of DSA-TTL expiry. > > Presumably the access device that sent the PDSR only did so because it > wants to be told (by an agent trusted via local configuration) that CMS > will be used as appropriate. > > My take would be that without the TTL in the PDSA the agent would then > need a way to signal to the access device that CMS is about to go "off". > If true, that'd definitely not be simpler. > > So, to me the simplification sounds a little nebulous; I understand > how the current scheme can work and so would rather stick with it. In section 1.3 underneath Figure 3 an optimized approach is explained. With this approach the proxy is responsible for re-establishing the DSA prior to expiration without any involvement by the access device. There is no mechanism specified for this optimized approach to turn CMS "off". I thought it was necessary to bring down the connection between the access device and the server if the PDSR/PDSA negotiated settings are no longer valid. I don't know if I'd want to wait for the TTL to expire before re-negotiating PDSR/PDSA settings when there is a configuration change. I guess I was just trying to propose that DSA re-establishment always be handled in the way it is handled with the optimized approach. Do you think there are problems re-negotiating PDSR/PDSA settings with the optimized approach explained under figure 3? > > > > Also, the diameter agent may make use of > > the same DSA for more than one access device; in this case it doesn't > > make much sense for multiple access devices to be responsible for > > re-establishing the same DSA. > > There's no requirement that the agent in this case have many DSAs. If > that were implied it would be wrong. The same TTL value can be used > in many PDSA messages if appropriate. Okay > > > > > > Requested change: > > > > Replace text from section 1.3: > > > > The PDSA MUST > > contain the TTL setting agreed by the proxy agent for its DSA. > > This information will allow the access device to re-issue a PDSR > > prior to the proxy's DSA expiry if it needs the DSA to remain > > active. > > > > with this text: > > > > The proxy agent is responsible for re-establishing the DSA > > prior to expiration without any involvement by the access > > device. > > If that were included, then what's the point of the PDSR/PDSA at > all? It informs the server that the access device is configured to require CMS security. > > > Stephen. > > -- > ____________________________________________________________ > Stephen Farrell > Baltimore Technologies, tel: (direct line) +353 1 881 6716 > 39 Parkgate Street, fax: +353 1 881 7000 > Dublin 8. mailto:stephen.farrell@baltimore.ie > Ireland http://www.baltimore.com From owner-aaa-wg@merit.edu Tue Mar 12 09:18:53 2002 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22436 for ; Tue, 12 Mar 2002 09:18:53 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D685B9121B; Tue, 12 Mar 2002 09:18:21 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9228D91275; Tue, 12 Mar 2002 09:18:21 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 779EB9121B for ; Tue, 12 Mar 2002 09:18:20 -0500 (EST) Received: by segue.merit.edu (Postfix) id 59D1A5DDBA; Tue, 12 Mar 2002 09:18:20 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from dzick.interlinknetworks.com (nat.interlinknetworks.com [198.108.5.3]) by segue.merit.edu (Postfix) with ESMTP id 0E80B5DDA3 for ; Tue, 12 Mar 2002 09:18:20 -0500 (EST) Received: from interlinknetworks.com (localhost.localdomain [127.0.0.1]) by dzick.interlinknetworks.com (8.11.0/8.11.0) with ESMTP id g2CEG6J01228; Tue, 12 Mar 2002 09:16:06 -0500 Message-ID: <3C8E0DA5.662E736D@interlinknetworks.com> Date: Tue, 12 Mar 2002 09:16:06 -0500 From: Don Zick Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: gwz@cisco.com Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: [issue] Diameter CMS Security - Require AAA-Node-Cert in DSAR and DSAA References: Content-Type: text/plain; charset=iso-8859-1 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id JAA22436 Glen, I'm sorry I'm not understanding your point. If Diameter nodes have their own certs available, why not just always stick them in the DSAR/DSAA messages so that they're always available when needed? What is the drawback of doing this? If my implementation must be able to handle DSAR/DSAA messages without the AAA-Node-Cert AVP then don't I have to implement a scheme for retrieving the certificate information elsewhere? Don Glen Zorn wrote: > Don Zick [mailto://dzick@interlinknetworks.com] writes: > > > A single occurrence of the AAA-Node-Cert AVP should be required in the > > DSAR and the DSAA. > > > > The Diameter CMS Security draft states (in section 3): > > In order to encrypt AVPs for a recipient, the originating Diameter > > node must have a copy of the recipient's public key. There are many > > well-known key retrieval schemes (e.g. LDAP [CERTLDAP]), but this > > specification also allows for the transportation of certificates > > within Diameter AVPs, which is expected to simplify implementations. > > > > If inclusion of the AAA-Node-Cert AVP is optional then the expected > > simplification in implementations is lost because compliant > > implementations must be able to handle DSAR and DSAA messages that don't > > include the AAA-Node-Cert AVPs. > > I disagree: compliant implementations must be able to handle DSAR and DSAA > messages that don't > include the AAA-Node-Cert AVPs, but they do _not_ have to include e.g. an > LDAP client and are therefore simpler. > > > > > Requested change: > > > > Please update the occurrence rules table and the ABNF definitions for > > the DSAR and DSAA to indicate that exactly 1 occurrence of the > > AAA-Node-Cert must be present. > > > > > > From owner-aaa-wg@merit.edu Tue Mar 12 09:37:46 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23331 for ; Tue, 12 Mar 2002 09:37:46 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 46F4791276; Tue, 12 Mar 2002 09:37:34 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 18CA891277; Tue, 12 Mar 2002 09:37:34 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 10AE091276 for ; Tue, 12 Mar 2002 09:37:33 -0500 (EST) Received: by segue.merit.edu (Postfix) id E9BE15DDA3; Tue, 12 Mar 2002 09:37:32 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from dzick.interlinknetworks.com (nat.interlinknetworks.com [198.108.5.3]) by segue.merit.edu (Postfix) with ESMTP id A15945DD9B for ; Tue, 12 Mar 2002 09:37:32 -0500 (EST) Received: from interlinknetworks.com (localhost.localdomain [127.0.0.1]) by dzick.interlinknetworks.com (8.11.0/8.11.0) with ESMTP id g2CEb8E01028; Tue, 12 Mar 2002 09:37:08 -0500 Message-ID: <3C8E1293.A07C3A68@interlinknetworks.com> Date: Tue, 12 Mar 2002 09:37:07 -0500 From: Don Zick Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: stephen.farrell@baltimore.ie Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Subject: [issue] Diameter CMS Security - Clarify DSA participants References: <3C8D1BE1.2CEC0D20@interlinknetworks.com> <3C8DE9C7.2E8BCB79@baltimore.ie> Content-Type: text/plain; charset=iso-8859-1 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id JAA23331 Hi Stephen, Suggested Text: 4.1 Diameter-Security-Association-Request The Diameter-Security-Association-Request command, indicated by the Command-Code field set to 304 and the 'R' bit set in the message flags field, is sent by a Diameter node to establish a Diameter Security Association with another Diameter node. The only suggested change is adding "with another Diameter node" at the end of the sentence. Don Stephen Farrell wrote: > Don, > > > Please add text explaining that a DSA can only involve two diameter > > nodes. > > I don't know what you want. Why don't you suggest text to add? > > Stephen. > > -- > ____________________________________________________________ > Stephen Farrell > Baltimore Technologies, tel: (direct line) +353 1 881 6716 > 39 Parkgate Street, fax: +353 1 881 7000 > Dublin 8. mailto:stephen.farrell@baltimore.ie > Ireland http://www.baltimore.com From owner-aaa-wg@merit.edu Tue Mar 12 09:38:43 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23367 for ; Tue, 12 Mar 2002 09:38:42 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 06C1291277; Tue, 12 Mar 2002 09:38:33 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C4AB391278; Tue, 12 Mar 2002 09:38:32 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9E13E91277 for ; Tue, 12 Mar 2002 09:38:31 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7DA275DDA0; Tue, 12 Mar 2002 09:38:31 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id CD1785DD9B for ; Tue, 12 Mar 2002 09:38:30 -0500 (EST) Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g2CEcgZ03910 for ; Tue, 12 Mar 2002 16:38:42 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 12 Mar 2002 16:38:28 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 12 Mar 2002 16:38:28 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Issue 303: Security model for peer discovery and redirect Date: Tue, 12 Mar 2002 16:38:28 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64BFA@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Issue 303: Security model for peer discovery and redirect Thread-Index: AcHJSSX1Tae/0nJXQJyn2hWO8MqU1AAilCVQ From: To: , Cc: , X-OriginalArrivalTime: 12 Mar 2002 14:38:28.0747 (UTC) FILETIME=[932B85B0:01C1C9D3] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA23367 David, I think someone raised a valid point that we may wish to add text for the security implications of redirect. Would that be sufficient, or are you looking for more? John > -----Original Message----- > From: ext David Spence [mailto:DSpence@Interlinknetworks.com] > Sent: 12 March, 2002 00:08 > To: David Frascone > Cc: Loughney John (NRC/Helsinki); aboba@internaut.com; > aaa-wg@merit.edu > Subject: Re: [AAA-WG]: Issue 303: Security model for peer > discovery and > redirect > > > I raised a number of specific security concerns in issue 303 > and I don't > think it is responsible to dismiss them summarily. I think each > deserves some kind of response. I am actually very concerned that > peer-to-peer security may be worse in Diameter than it is in RADIUS. > RADIUS has real peer-to-peer security -- the shared secret! > Yes, I know > it's real bad security. But at least there's something real > about it. > Diameter may be run with no security -- and the server won't > even know. > > Consider IPsec. The underlying problem with IPsec is that it > isn't easy > for a "Diameter node" (server or client process) to verify > that IPsec is > being used. This weakness can be exploited in a number of > ways. Issue > 303 mentioned one of them. If a peer-to-peer connection is being > established dynamically due to peer discovery or the action of a > redirect agent, it is rather likely that an IPsec tunnel does > not exist. > (If it did, you wouldn't need peer discovery or a redirect > agent.) But > I believe that the problems of relying on IPsec run deeper than that. > > Example 1: > > Consider the case of the ISP Fastgrowth.net. Fastgrowth > has 12 NASes > named nas01.fastgrowth.net through nas12.fastgrowth.net. Their > Diameter server is named aaa1.fastgrowth.net. The configured peer > table for this server contains entries for nas01 through nas99. > IPsec is used for peer-to-peer security. When a new NAS is > installed, the network administrator assigns it a name in > the range > nas01-nas99 and sets up an IPsec tunnel for it. Now an > attacker in > Elbonia wishes to attack Fastgrowth with the aid of a > Diameter Attack > Client he's cobbled together. He names his client > nas13.fastgrowth.net (on a hunch) and attempts to bring up a > peer-to-peer connection with aaa1.fastgrowth.net. As luck > would have > it, the name he chose is in aaa1's peer table. Of course > there is no > IPsec tunnel, but aaa1 doesn't know that. So aaa1 merrily > brings up > a connection with the impostor. That attack would have been much > harder to pull off with RADIUS because of the burden of having to > guess the shared secret. > > So much for IPsec. At least TLS doesn't have that problem. > With TLS, > you know you're secure. Maybe. > > Example 2: > > A group of small, regional ISPs spread across the northern > U.S. from > Lake Wobegone, Minnesota all the way to Blight, Idaho, has > established a roaming consortium called the Northern Alliance. > Consortium members establish peer-to-peer connections > between their > Diameter servers as needed using peer discovery. For > security, they > use TLS. Since most of their administrators are not security > experts, they want to make sure they get it right. They choose > Verisign as their CA. Now a group of outlaws in Wyoming > starts up a > small ISP of their own called Blackhats.net. They do not join the > Northern Alliance. But their leader, Jesse James, applies to > Verisign for a certificate for their Diameter server. > Now, without > bothering to join, they can send peer-to-peer connection > requests to > Diameter servers throughout the Northern Alliance. When > the Diameter > server for Sittingducks.net, the Lake Wobegone ISP, > receives one of > these requests, it examines the tendered TLS certificate and reads > the fine print, which says, "To whom it may concern: We, Verisign, > have verified the identity of one Jesse James by comparing > his face > to the photographs on the wall of the Post Office down the > street. > We are confident that the applicant for this certificate really is > Jesse James and that he really is a principle of the Wyoming > corporation Blackhats.net." So they merrily bring up the > connection. > Again, the attack would have failed with RADIUS because > Jesse would > never have guessed their shared secret "happytrails2U". > > Yes, I know the Northern Alliance could have done better. But we > haven't exactly helped them by explaining in our Security > Considerations > how TLS should and should not be used to secure peer-to-peer > connections. > > Now here's the real problem. The real problem is that Diameter, when > used to support roaming in a multi-domain environment, relies on > transitive trust. I trust the Diameter messages sent by all the good > buddies of my good buddies because I trust my good buddies' > trust. This > means that if a successful peer-to-peer attack can be > launched against > any of the thousands of my buddies' buddies, then I am vulnerable. > > Example 3: > > The GrockPass Roaming Broker decides to upgrade the GrockPass > Alliance from RADIUS to Diameter for all inter-domain AAA requests > because of Diameter's superior security. GrockPass uses > TLS security > and they themselves run the CA for the alliance so there > won't be any > funny business. Only certificates signed by GrockPass are > accepted > by alliance members. One day Maxwell Smart, the system > administrator > for GoodVigilance.net, notices that their Diameter server has > received a very large number of failed authentication > requests from > GrockPass affiliate Laxnet.com proxied through GrockPass. > The failed > authentication requests all come from nas13.laxnet.com and > appear to > be an attempt to mount a dictionary attack against the PAP > passwords > of the GoodVigilance dialin users. Max calls up his counterpart > Dudley Hopewell at Laxnet. "Gee," Dudley says, "We don't > even have a > nas13." Dang those Elbonians. > > In this example, all the good vigilance of GoodVigilance and > GrockPass > could not protect them. That is why, if you are designing a > multi-domain protocol, you SHOULD NOT make it rely on the > intelligence > and vigilance of all the domains' network administrators. > Because even > if an administrative domain believes in the intelligence and > vigilance > of its own administrator, what about all the other stupid, lazy > administrators out there? At least let the vendors help out > by making > the application verify the security directly wherever possible. And > where it's not possible, make sure the vendors understand the > Security > Considerations well enough to insert plenty of BIG BOLD > WARNING MESSAGES > in their GUIs to give their customers a little help. > > In conclusion, Diameter has the following peer-to-peer > "features" that > RADIUS lacks. > > 1) Dynamic peer-to-peer connections (ones that are not > preconfigured). Both peer discovery and redirect > agents require > this. > > 2) Non-verifiable peer-to-peer security associations (IPsec). > > 3) The ability, by abusing TLS, to bring up authenticated, but > unauthorized peer-to-peer connections. > > We need to be sure Diameter nodes can implement these > features securely > or else remove them. The two questions in each case are, how > do I know > I'm authorized to establish this connection and how can I > authenticate > the peer? If we can't answer these two questions satisfactorily, we > should stick to configured peers with configured shared secrets. > > > David Frascone wrote: > > > > My vote would be to reject this issue. > > > > But, to address the possible security issues, perhaps we > should allow > > implementations to decide whether they allow redirects. > (In other words, > > server X might not allow redirects from realm Y) > > > > As far as server discovery goes . . . that smells like an > implementation > > issue. . . . . > > > > -Dave > > > > On Monday, 11 Mar 2002, john.loughney@nokia.com wrote: > > > Hi all, > > > > > > http://www.drizzle.com/~aboba/AAA/issues.html#Issue%20#303 > > > > > > Issue 303 is a quite a big change, in my opinion. I am somewhat > > > hesitant about tackling this, so I thing the WG needs to discuss > > > this. Security is, of course, extremely important. Does the > > > workgroup see this a good solution? > > > > > > I'd appreciate comments on this. > > > > > > thanks, > > > John > > > > > > PS - the requestion change is: > > > > > > I think the usefulness of the redirect and server discovery models > > > ought to be reexamined in light of the security problems they > > > introduce.It may be that removing redirect and server discovery > > > from Diameter is the best solution. > > > > > > > -- > > David Frascone > > > > Don't just do something !!! Stand there !!! > From owner-aaa-wg@merit.edu Tue Mar 12 09:41:47 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23471 for ; Tue, 12 Mar 2002 09:41:47 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id BB1F191278; Tue, 12 Mar 2002 09:41:35 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8AF4591279; Tue, 12 Mar 2002 09:41:35 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5C43991278 for ; Tue, 12 Mar 2002 09:41:34 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3C3E35DDA0; Tue, 12 Mar 2002 09:41:34 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from ocasey.baltimore.com (ocasey.baltimore.com [193.41.17.101]) by segue.merit.edu (Postfix) with ESMTP id 6ED875DD9B for ; Tue, 12 Mar 2002 09:41:33 -0500 (EST) Received: from Baltimore-FW1 ([172.19.1.1]) by ocasey.baltimore.com (8.11.6/8.9.3) with SMTP id g2CEfWb20837 for ; Tue, 12 Mar 2002 14:41:32 GMT Received: from Baltimore-FW1 (wilde-i-1.ie.baltimore.com) by emeairlsw1.baltimore.com (Content Technologies SMTPRS 4.2.5) with SMTP id for ; Tue, 12 Mar 2002 14:36:29 +0000 Received: from baltimore.ie (wks140-4.ie.baltimore.com [10.153.4.140]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id OAA10885; Tue, 12 Mar 2002 14:41:29 GMT Message-ID: <3C8E13A3.992A13B3@baltimore.ie> Date: Tue, 12 Mar 2002 14:41:39 +0000 From: Stephen Farrell Reply-To: stephen.farrell@baltimore.ie Organization: Baltimore Technologies Ltd. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Don Zick Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Subject: [issue] Diameter CMS Security - Clarify DSA participants References: <3C8D1BE1.2CEC0D20@interlinknetworks.com> <3C8DE9C7.2E8BCB79@baltimore.ie> <3C8E1293.A07C3A68@interlinknetworks.com> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Don, Ok now I understand, but I have to ask - do we really need that? I mean, with what else would a Diameter node establish a Diameter Security Association using the Diameter protocol? I've no objection to adding this when/if revising the draft though. Stephen. Don Zick wrote: > > Hi Stephen, > > Suggested Text: > > 4.1 Diameter-Security-Association-Request > > The Diameter-Security-Association-Request command, indicated by the > Command-Code field set to 304 and the 'R' bit set in the message > flags field, is sent by a Diameter node to establish a Diameter > Security Association with another Diameter node. > > The only suggested change is adding "with another Diameter node" at the > end of the sentence. > > Don > > Stephen Farrell wrote: > > > Don, > > > > > Please add text explaining that a DSA can only involve two diameter > > > nodes. > > > > I don't know what you want. Why don't you suggest text to add? > > > > Stephen. > > > > -- > > ____________________________________________________________ > > Stephen Farrell > > Baltimore Technologies, tel: (direct line) +353 1 881 6716 > > 39 Parkgate Street, fax: +353 1 881 7000 > > Dublin 8. mailto:stephen.farrell@baltimore.ie > > Ireland http://www.baltimore.com -- ____________________________________________________________ Stephen Farrell Baltimore Technologies, tel: (direct line) +353 1 881 6716 39 Parkgate Street, fax: +353 1 881 7000 Dublin 8. mailto:stephen.farrell@baltimore.ie Ireland http://www.baltimore.com From owner-aaa-wg@merit.edu Tue Mar 12 09:42:11 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23504 for ; Tue, 12 Mar 2002 09:42:11 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 643409127D; Tue, 12 Mar 2002 09:41:57 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 050989127C; Tue, 12 Mar 2002 09:41:56 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2561F9127A for ; Tue, 12 Mar 2002 09:41:53 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9B54E5DE1A; Tue, 12 Mar 2002 09:41:52 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 8130F5DD9B for ; Tue, 12 Mar 2002 09:41:51 -0500 (EST) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g2CEg3Z05963 for ; Tue, 12 Mar 2002 16:42:03 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 12 Mar 2002 16:41:50 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 12 Mar 2002 16:41:50 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Issue 303: Security model for peer discovery and redirect Date: Tue, 12 Mar 2002 16:41:50 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64BFB@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Issue 303: Security model for peer discovery and redirect Thread-Index: AcHJMEVpeWcNiSthQO+haJWY/87YugAo2LAw From: To: , Cc: , X-OriginalArrivalTime: 12 Mar 2002 14:41:50.0779 (UTC) FILETIME=[0B9728B0:01C1C9D4] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA23504 Hi Randy, > > Remember that a redirect makes lots of sense in the case where the > > redirect server is owned by a "broker". The broker would typically > > act as a certificate authority, and would ensure that all of the > > roaming consortium members have certificates that are signed by the > > CA. This provides the trust that is needed in the protocol. > > so, if i do not have a signed cert of the host trying to contact me, > the protocol will say that i MUST reject the connection? Is this something that we would need to mandate - or is it something we should advise on? I generally don't like these kind of MUST requirements, as it gets to a deployment issue, as opposed to an interoperability issue. If someone wants to hang their butt out in the open air ... Or are you suggesting that fundamentally this is an interoperability issue that MUST be enforced by the protocol? John From owner-aaa-wg@merit.edu Tue Mar 12 09:55:21 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23786 for ; Tue, 12 Mar 2002 09:55:20 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 6499991279; Tue, 12 Mar 2002 09:55:10 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 283089127A; Tue, 12 Mar 2002 09:55:10 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id EBA6F91279 for ; Tue, 12 Mar 2002 09:55:08 -0500 (EST) Received: by segue.merit.edu (Postfix) id D20385DD9B; Tue, 12 Mar 2002 09:55:08 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from ocasey.baltimore.com (ocasey.baltimore.com [193.41.17.101]) by segue.merit.edu (Postfix) with ESMTP id 3B5965DD8D for ; Tue, 12 Mar 2002 09:55:08 -0500 (EST) Received: from Baltimore-FW1 ([172.19.1.1]) by ocasey.baltimore.com (8.11.6/8.9.3) with SMTP id g2CEt7b21000 for ; Tue, 12 Mar 2002 14:55:07 GMT Received: from Baltimore-FW1 (wilde-i-1.ie.baltimore.com) by emeairlsw1.baltimore.com (Content Technologies SMTPRS 4.2.5) with SMTP id for ; Tue, 12 Mar 2002 14:50:04 +0000 Received: from baltimore.ie (wks140-4.ie.baltimore.com [10.153.4.140]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id OAA11094; Tue, 12 Mar 2002 14:55:03 GMT Message-ID: <3C8E16D1.84141DC1@baltimore.ie> Date: Tue, 12 Mar 2002 14:55:13 +0000 From: Stephen Farrell Reply-To: stephen.farrell@baltimore.ie Organization: Baltimore Technologies Ltd. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Don Zick Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: [issue] Diameter CMS Security - Remove DSA-TTL from PDSA message References: <3C8D1B8B.9C8E2031@interlinknetworks.com> <3C8DEB36.CB9A0A76@baltimore.ie> <3C8E0A03.A4F0492B@interlinknetworks.com> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Don, Are you saying that the DSA-TTL is better being optional in the ABNF, (rather than a MUST), because of the optimized case, where the value isn't needed by the access device? If so, I guess that's true, but I'd have though that leaving in the MUST is easier, even if the access device is going to ignore the value (e.g. in the optimized case), since the DSA-TTL is useful for cases where the access device ought to control things. (I.e. I'm still arguing to reject this one). Say if a device were to require only occasional, short-lived, "diverse peer", DSAs to be established. In that case, I'd say it'd be useful to allow the proxy to drop the DSA more rapidly, which can be done by including the DSA-TTL in the PDSA. I don't know if that matches any of the real use cases though. Regards, Stephen. Don Zick wrote: > > Hi Stephen, > > Comments inline. > > Don > > Stephen Farrell wrote: > > > Don, > > > > Reckon I'd be against this one at this stage (i.e. you might, but > > haven't, convinced me;-), > > > > > A diameter agent may establish security associations on behalf of access > > > devices. The access devices issue the PDSR message to request this. It > > > is simpler for the access devices if they do not have to re-issue the > > > PDSR because of DSA-TTL expiry. > > > > Presumably the access device that sent the PDSR only did so because it > > wants to be told (by an agent trusted via local configuration) that CMS > > will be used as appropriate. > > > > My take would be that without the TTL in the PDSA the agent would then > > need a way to signal to the access device that CMS is about to go "off". > > If true, that'd definitely not be simpler. > > > > So, to me the simplification sounds a little nebulous; I understand > > how the current scheme can work and so would rather stick with it. > > In section 1.3 underneath Figure 3 an optimized approach is explained. With > this approach the proxy is responsible for re-establishing the DSA prior to > expiration without any involvement by the access device. There is no > mechanism specified for this optimized approach to turn CMS "off". I thought > it was necessary to bring down the connection between the access device and > the server if the PDSR/PDSA negotiated settings are no longer valid. I don't > know if I'd want to wait for the TTL to expire before re-negotiating > PDSR/PDSA settings when there is a configuration change. I guess I was just > trying to propose that DSA re-establishment always be handled in the way it > is handled with the optimized approach. > > Do you think there are problems re-negotiating PDSR/PDSA settings with the > optimized approach explained under figure 3? > > > > > > > > Also, the diameter agent may make use of > > > the same DSA for more than one access device; in this case it doesn't > > > make much sense for multiple access devices to be responsible for > > > re-establishing the same DSA. > > > > There's no requirement that the agent in this case have many DSAs. If > > that were implied it would be wrong. The same TTL value can be used > > in many PDSA messages if appropriate. > > Okay > > > > > > > > > > > Requested change: > > > > > > Replace text from section 1.3: > > > > > > The PDSA MUST > > > contain the TTL setting agreed by the proxy agent for its DSA. > > > This information will allow the access device to re-issue a PDSR > > > prior to the proxy's DSA expiry if it needs the DSA to remain > > > active. > > > > > > with this text: > > > > > > The proxy agent is responsible for re-establishing the DSA > > > prior to expiration without any involvement by the access > > > device. > > > > If that were included, then what's the point of the PDSR/PDSA at > > all? > > It informs the server that the access device is configured to require > CMS security. > > > > > > > Stephen. > > > > -- > > ____________________________________________________________ > > Stephen Farrell > > Baltimore Technologies, tel: (direct line) +353 1 881 6716 > > 39 Parkgate Street, fax: +353 1 881 7000 > > Dublin 8. mailto:stephen.farrell@baltimore.ie > > Ireland http://www.baltimore.com -- ____________________________________________________________ Stephen Farrell Baltimore Technologies, tel: (direct line) +353 1 881 6716 39 Parkgate Street, fax: +353 1 881 7000 Dublin 8. mailto:stephen.farrell@baltimore.ie Ireland http://www.baltimore.com From owner-aaa-wg@merit.edu Tue Mar 12 09:59:15 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23831 for ; Tue, 12 Mar 2002 09:59:14 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 394979127A; Tue, 12 Mar 2002 09:58:54 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 092639127B; Tue, 12 Mar 2002 09:58:53 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DECAB9127A for ; Tue, 12 Mar 2002 09:58:52 -0500 (EST) Received: by segue.merit.edu (Postfix) id C042A5DDA0; Tue, 12 Mar 2002 09:58:52 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from dzick.interlinknetworks.com (nat.interlinknetworks.com [198.108.5.3]) by segue.merit.edu (Postfix) with ESMTP id 784355DD9B for ; Tue, 12 Mar 2002 09:58:52 -0500 (EST) Received: from interlinknetworks.com (localhost.localdomain [127.0.0.1]) by dzick.interlinknetworks.com (8.11.0/8.11.0) with ESMTP id g2CEvnE01111; Tue, 12 Mar 2002 09:57:49 -0500 Message-ID: <3C8E176C.AA092469@interlinknetworks.com> Date: Tue, 12 Mar 2002 09:57:48 -0500 From: Don Zick Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: stephen.farrell@baltimore.ie Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Subject: [issue] Diameter CMS Security - Clarify DSA participants References: <3C8D1BE1.2CEC0D20@interlinknetworks.com> <3C8DE9C7.2E8BCB79@baltimore.ie> <3C8E1293.A07C3A68@interlinknetworks.com> <3C8E13A3.992A13B3@baltimore.ie> Content-Type: text/plain; charset=iso-8859-1 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id JAA23831 Hi Stephen, I thought that in previous drafts that you could make an association between a Diameter node and a realm of Diameter servers. I've gotten confused and I just wanted to be 100% certain that a DSA is only between two Diameter nodes. The few extra words help clarify this point for me. Don Stephen Farrell wrote: > Don, > > Ok now I understand, but I have to ask - do we really need that? > > I mean, with what else would a Diameter node establish a > Diameter Security Association using the Diameter protocol? > > I've no objection to adding this when/if revising the draft > though. > > Stephen. > > Don Zick wrote: > > > > Hi Stephen, > > > > Suggested Text: > > > > 4.1 Diameter-Security-Association-Request > > > > The Diameter-Security-Association-Request command, indicated by the > > Command-Code field set to 304 and the 'R' bit set in the message > > flags field, is sent by a Diameter node to establish a Diameter > > Security Association with another Diameter node. > > > > The only suggested change is adding "with another Diameter node" at the > > end of the sentence. > > > > Don > > > > Stephen Farrell wrote: > > > > > Don, > > > > > > > Please add text explaining that a DSA can only involve two diameter > > > > nodes. > > > > > > I don't know what you want. Why don't you suggest text to add? > > > > > > Stephen. > > > > > > -- > > > ____________________________________________________________ > > > Stephen Farrell > > > Baltimore Technologies, tel: (direct line) +353 1 881 6716 > > > 39 Parkgate Street, fax: +353 1 881 7000 > > > Dublin 8. mailto:stephen.farrell@baltimore.ie > > > Ireland http://www.baltimore.com > > -- > ____________________________________________________________ > Stephen Farrell > Baltimore Technologies, tel: (direct line) +353 1 881 6716 > 39 Parkgate Street, fax: +353 1 881 7000 > Dublin 8. mailto:stephen.farrell@baltimore.ie > Ireland http://www.baltimore.com From owner-aaa-wg@merit.edu Tue Mar 12 10:24:42 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24316 for ; Tue, 12 Mar 2002 10:24:41 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9FCF791228; Tue, 12 Mar 2002 10:24:30 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6FC799122E; Tue, 12 Mar 2002 10:24:30 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4B17291228 for ; Tue, 12 Mar 2002 10:24:29 -0500 (EST) Received: by segue.merit.edu (Postfix) id 322B65DD9B; Tue, 12 Mar 2002 10:24:29 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from dzick.interlinknetworks.com (nat.interlinknetworks.com [198.108.5.3]) by segue.merit.edu (Postfix) with ESMTP id DDE005DD92 for ; Tue, 12 Mar 2002 10:24:28 -0500 (EST) Received: from interlinknetworks.com (localhost.localdomain [127.0.0.1]) by dzick.interlinknetworks.com (8.11.0/8.11.0) with ESMTP id g2CFMdE01137; Tue, 12 Mar 2002 10:22:40 -0500 Message-ID: <3C8E1D3F.CFD8348A@interlinknetworks.com> Date: Tue, 12 Mar 2002 10:22:39 -0500 From: Don Zick Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: stephen.farrell@baltimore.ie Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: [issue] Diameter CMS Security - Remove DSA-TTL from PDSA message References: <3C8D1B8B.9C8E2031@interlinknetworks.com> <3C8DEB36.CB9A0A76@baltimore.ie> <3C8E0A03.A4F0492B@interlinknetworks.com> <3C8E16D1.84141DC1@baltimore.ie> Content-Type: text/plain; charset=iso-8859-1 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id KAA24316 Stephen, All I'm saying is that if my server has to be able to completely manage the DSA-TTL for the optimized case then I don't see why it can't do the same for the non-optimized case. I think we have an opportunity to make things a little simpler for the access device by not requiring it to manage the DSA-TTL. Having said that, the proposed change certainly isn't required for things to work and I understand if such a request needs to be rejected at this point. Regards, Don Stephen Farrell wrote: > Don, > > Are you saying that the DSA-TTL is better being optional in the > ABNF, (rather than a MUST), because of the optimized case, where > the value isn't needed by the access device? > > If so, I guess that's true, but I'd have though that leaving in > the MUST is easier, even if the access device is going to ignore > the value (e.g. in the optimized case), since the DSA-TTL is > useful for cases where the access device ought to control things. > (I.e. I'm still arguing to reject this one). > > Say if a device were to require only occasional, short-lived, > "diverse peer", DSAs to be established. In that case, I'd say > it'd be useful to allow the proxy to drop the DSA more rapidly, > which can be done by including the DSA-TTL in the PDSA. I don't > know if that matches any of the real use cases though. > > Regards, > Stephen. > > Don Zick wrote: > > > > Hi Stephen, > > > > Comments inline. > > > > Don > > > > Stephen Farrell wrote: > > > > > Don, > > > > > > Reckon I'd be against this one at this stage (i.e. you might, but > > > haven't, convinced me;-), > > > > > > > A diameter agent may establish security associations on behalf of access > > > > devices. The access devices issue the PDSR message to request this. It > > > > is simpler for the access devices if they do not have to re-issue the > > > > PDSR because of DSA-TTL expiry. > > > > > > Presumably the access device that sent the PDSR only did so because it > > > wants to be told (by an agent trusted via local configuration) that CMS > > > will be used as appropriate. > > > > > > My take would be that without the TTL in the PDSA the agent would then > > > need a way to signal to the access device that CMS is about to go "off". > > > If true, that'd definitely not be simpler. > > > > > > So, to me the simplification sounds a little nebulous; I understand > > > how the current scheme can work and so would rather stick with it. > > > > In section 1.3 underneath Figure 3 an optimized approach is explained. With > > this approach the proxy is responsible for re-establishing the DSA prior to > > expiration without any involvement by the access device. There is no > > mechanism specified for this optimized approach to turn CMS "off". I thought > > it was necessary to bring down the connection between the access device and > > the server if the PDSR/PDSA negotiated settings are no longer valid. I don't > > know if I'd want to wait for the TTL to expire before re-negotiating > > PDSR/PDSA settings when there is a configuration change. I guess I was just > > trying to propose that DSA re-establishment always be handled in the way it > > is handled with the optimized approach. > > > > Do you think there are problems re-negotiating PDSR/PDSA settings with the > > optimized approach explained under figure 3? > > > > > > > > > > > > Also, the diameter agent may make use of > > > > the same DSA for more than one access device; in this case it doesn't > > > > make much sense for multiple access devices to be responsible for > > > > re-establishing the same DSA. > > > > > > There's no requirement that the agent in this case have many DSAs. If > > > that were implied it would be wrong. The same TTL value can be used > > > in many PDSA messages if appropriate. > > > > Okay > > > > > > > > > > > > > > > > Requested change: > > > > > > > > Replace text from section 1.3: > > > > > > > > The PDSA MUST > > > > contain the TTL setting agreed by the proxy agent for its DSA. > > > > This information will allow the access device to re-issue a PDSR > > > > prior to the proxy's DSA expiry if it needs the DSA to remain > > > > active. > > > > > > > > with this text: > > > > > > > > The proxy agent is responsible for re-establishing the DSA > > > > prior to expiration without any involvement by the access > > > > device. > > > > > > If that were included, then what's the point of the PDSR/PDSA at > > > all? > > > > It informs the server that the access device is configured to require > > CMS security. > > > > > > > > > > > Stephen. > > > > > > -- > > > ____________________________________________________________ > > > Stephen Farrell > > > Baltimore Technologies, tel: (direct line) +353 1 881 6716 > > > 39 Parkgate Street, fax: +353 1 881 7000 > > > Dublin 8. mailto:stephen.farrell@baltimore.ie > > > Ireland http://www.baltimore.com > > -- > ____________________________________________________________ > Stephen Farrell > Baltimore Technologies, tel: (direct line) +353 1 881 6716 > 39 Parkgate Street, fax: +353 1 881 7000 > Dublin 8. mailto:stephen.farrell@baltimore.ie > Ireland http://www.baltimore.com From owner-aaa-wg@merit.edu Tue Mar 12 10:25:53 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24350 for ; Tue, 12 Mar 2002 10:25:53 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2A5ED9122E; Tue, 12 Mar 2002 10:25:45 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F27929127C; Tue, 12 Mar 2002 10:25:44 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 644159122E for ; Tue, 12 Mar 2002 10:25:43 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4D9995DD8D; Tue, 12 Mar 2002 10:25:43 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by segue.merit.edu (Postfix) with ESMTP id 9F64D5DDA0 for ; Tue, 12 Mar 2002 10:25:42 -0500 (EST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g2CFPfB07120 for ; Tue, 12 Mar 2002 16:25:41 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Tue Mar 12 16:25:40 2002 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 12 Mar 2002 16:15:46 +0100 Message-ID: <21B25F729760D51198BF0002A56B386A01372F55@esealnt852> From: =?iso-8859-1?Q?Lollo_T=F6nnesson_=28QPK=29?= To: "'aaa-wg@merit.edu'" Subject: [AAA-WG]: Diameter, Vendor Specific Accounting Application: Acct-Applicatio n-Id and Vendor-Specific-Application-Id Date: Tue, 12 Mar 2002 16:24:32 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk The usage of Acct-Application-Id and Vendor-Specific-Application-Id for vendor specific accounting application is unclear. I'd like to specify a vendor specific accounting application by using ACR and ACA commands in the Diameter Base Protocol and add on some optional service specific AVPs. How do you specify the application Id in the ACR and ACA commands if you are using a vendor specific accounting application? Should Acct-Application-Id and/or Vendor-Specific-Application-Id be used? 1) Alternative 1: ::= < Diameter Header: 271, REQ, PXY > < Session-Id > { Acct-Application-Id } { Origin-Host } ....... Question: What Acct-Application-Id should be used? 2) Alternative 2: ::= < Diameter Header: 271, REQ, PXY > < Session-Id > { Acct-Application-Id } { Vendor-Specific-Application-Id } { Origin-Host } ....... Question: What Acct-Application-Id should be used? 3) Alternative 3: ::= < Diameter Header: 271, REQ, PXY > < Session-Id > { Vendor-Specific-Application-Id } { Origin-Host } ....... Question: Acct-Application-Id is defined as mandatory for ACR. Is it appropriate to replace the mandatory Acct-Application-Id with Vendor-Specific-Application-Id. This is not explicitly stated anywhere in the draft (09). According to 09 draft of the Diameter Base Protocol: * 6.10 Vendor-Specific-Application-Id AVP Format ::= < AVP Header: 260 > 1* [ Vendor-Id ] 0*1{ Auth-Application-Id } 0*1{ Acct-Application-Id } The vendor-Id is assigned by IANA. The Acct-Application-Id is defined by the vendor (private use). *Is chapter 1.2.4, 2.4 applicable for vendor specific accounting applications, i.e. that an Acct-Application-Id should be assigned by IANA? * According to e.g. chapter 6.10 in the base protocol, the Vendor-Specific-Application-Id AVP should be used for advertise support for vendor specific diameter applications, but this AVP is not mentioned in the ACR or ACA, only for CER and CEA (table in 10.1, 10.2) The only application Id AVP required for ACR and ACA are the Acct-Application-Id. ??: Implication: During capability exchange (CER/CEA) you advertise support for the vendor specific application but the vendor specific application id is not included in the ACR/ACA commands. Can this really be correct? ??: Should both the Acct-Application-Id and Vendor-Specific-Application-Id be part of CER/CEA? * Acct-Application-Id AVP is mandatory in ACR and ACA (9.7.1, 9.7.2, 10.2) Best regards Lollo From owner-aaa-wg@merit.edu Tue Mar 12 10:31:33 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24568 for ; Tue, 12 Mar 2002 10:31:33 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 673F89127C; Tue, 12 Mar 2002 10:30:51 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2EEDD9127F; Tue, 12 Mar 2002 10:30:51 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E01829127C for ; Tue, 12 Mar 2002 10:30:49 -0500 (EST) Received: by segue.merit.edu (Postfix) id C5FFE5DDA0; Tue, 12 Mar 2002 10:30:49 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from ocasey.baltimore.com (ocasey.baltimore.com [193.41.17.101]) by segue.merit.edu (Postfix) with ESMTP id 373AF5DD9B for ; Tue, 12 Mar 2002 10:30:49 -0500 (EST) Received: from Baltimore-FW1 ([172.19.1.1]) by ocasey.baltimore.com (8.11.6/8.9.3) with SMTP id g2CFUkb21569 for ; Tue, 12 Mar 2002 15:30:46 GMT Received: from Baltimore-FW1 (wilde-i-1.ie.baltimore.com) by emeairlsw1.baltimore.com (Content Technologies SMTPRS 4.2.5) with SMTP id for ; Tue, 12 Mar 2002 15:25:43 +0000 Received: from baltimore.ie (wks140-4.ie.baltimore.com [10.153.4.140]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id PAA11773; Tue, 12 Mar 2002 15:30:44 GMT Message-ID: <3C8E1F2E.C3055678@baltimore.ie> Date: Tue, 12 Mar 2002 15:30:54 +0000 From: Stephen Farrell Reply-To: stephen.farrell@baltimore.ie Organization: Baltimore Technologies Ltd. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Don Zick Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: [issue] Diameter CMS Security - Remove DSA-TTL from PDSA message References: <3C8D1B8B.9C8E2031@interlinknetworks.com> <3C8DEB36.CB9A0A76@baltimore.ie> <3C8E0A03.A4F0492B@interlinknetworks.com> <3C8E16D1.84141DC1@baltimore.ie> <3C8E1D3F.CFD8348A@interlinknetworks.com> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Don, Fine so. In the absence of further reasons to change, let's mark that a "reject" then. Stephen. Don Zick wrote: > > Stephen, > > All I'm saying is that if my server has to be able to completely manage the > DSA-TTL for the optimized case then I don't see why it can't do the same for the > non-optimized case. I think we have an opportunity to make things a little > simpler for the access device by not requiring it to manage the DSA-TTL. Having > said that, the proposed change certainly isn't required for things to work and I > understand if such a request needs to be rejected at this point. > > Regards, > Don > > Stephen Farrell wrote: > > > Don, > > > > Are you saying that the DSA-TTL is better being optional in the > > ABNF, (rather than a MUST), because of the optimized case, where > > the value isn't needed by the access device? > > > > If so, I guess that's true, but I'd have though that leaving in > > the MUST is easier, even if the access device is going to ignore > > the value (e.g. in the optimized case), since the DSA-TTL is > > useful for cases where the access device ought to control things. > > (I.e. I'm still arguing to reject this one). > > > > Say if a device were to require only occasional, short-lived, > > "diverse peer", DSAs to be established. In that case, I'd say > > it'd be useful to allow the proxy to drop the DSA more rapidly, > > which can be done by including the DSA-TTL in the PDSA. I don't > > know if that matches any of the real use cases though. > > > > Regards, > > Stephen. > > > > Don Zick wrote: > > > > > > Hi Stephen, > > > > > > Comments inline. > > > > > > Don > > > > > > Stephen Farrell wrote: > > > > > > > Don, > > > > > > > > Reckon I'd be against this one at this stage (i.e. you might, but > > > > haven't, convinced me;-), > > > > > > > > > A diameter agent may establish security associations on behalf of access > > > > > devices. The access devices issue the PDSR message to request this. It > > > > > is simpler for the access devices if they do not have to re-issue the > > > > > PDSR because of DSA-TTL expiry. > > > > > > > > Presumably the access device that sent the PDSR only did so because it > > > > wants to be told (by an agent trusted via local configuration) that CMS > > > > will be used as appropriate. > > > > > > > > My take would be that without the TTL in the PDSA the agent would then > > > > need a way to signal to the access device that CMS is about to go "off". > > > > If true, that'd definitely not be simpler. > > > > > > > > So, to me the simplification sounds a little nebulous; I understand > > > > how the current scheme can work and so would rather stick with it. > > > > > > In section 1.3 underneath Figure 3 an optimized approach is explained. With > > > this approach the proxy is responsible for re-establishing the DSA prior to > > > expiration without any involvement by the access device. There is no > > > mechanism specified for this optimized approach to turn CMS "off". I thought > > > it was necessary to bring down the connection between the access device and > > > the server if the PDSR/PDSA negotiated settings are no longer valid. I don't > > > know if I'd want to wait for the TTL to expire before re-negotiating > > > PDSR/PDSA settings when there is a configuration change. I guess I was just > > > trying to propose that DSA re-establishment always be handled in the way it > > > is handled with the optimized approach. > > > > > > Do you think there are problems re-negotiating PDSR/PDSA settings with the > > > optimized approach explained under figure 3? > > > > > > > > > > > > > > > > Also, the diameter agent may make use of > > > > > the same DSA for more than one access device; in this case it doesn't > > > > > make much sense for multiple access devices to be responsible for > > > > > re-establishing the same DSA. > > > > > > > > There's no requirement that the agent in this case have many DSAs. If > > > > that were implied it would be wrong. The same TTL value can be used > > > > in many PDSA messages if appropriate. > > > > > > Okay > > > > > > > > > > > > > > > > > > > > > Requested change: > > > > > > > > > > Replace text from section 1.3: > > > > > > > > > > The PDSA MUST > > > > > contain the TTL setting agreed by the proxy agent for its DSA. > > > > > This information will allow the access device to re-issue a PDSR > > > > > prior to the proxy's DSA expiry if it needs the DSA to remain > > > > > active. > > > > > > > > > > with this text: > > > > > > > > > > The proxy agent is responsible for re-establishing the DSA > > > > > prior to expiration without any involvement by the access > > > > > device. > > > > > > > > If that were included, then what's the point of the PDSR/PDSA at > > > > all? > > > > > > It informs the server that the access device is configured to require > > > CMS security. > > > > > > > > > > > > > > > Stephen. > > > > > > > > -- > > > > ____________________________________________________________ > > > > Stephen Farrell > > > > Baltimore Technologies, tel: (direct line) +353 1 881 6716 > > > > 39 Parkgate Street, fax: +353 1 881 7000 > > > > Dublin 8. mailto:stephen.farrell@baltimore.ie > > > > Ireland http://www.baltimore.com > > > > -- > > ____________________________________________________________ > > Stephen Farrell > > Baltimore Technologies, tel: (direct line) +353 1 881 6716 > > 39 Parkgate Street, fax: +353 1 881 7000 > > Dublin 8. mailto:stephen.farrell@baltimore.ie > > Ireland http://www.baltimore.com -- ____________________________________________________________ Stephen Farrell Baltimore Technologies, tel: (direct line) +353 1 881 6716 39 Parkgate Street, fax: +353 1 881 7000 Dublin 8. mailto:stephen.farrell@baltimore.ie Ireland http://www.baltimore.com From owner-aaa-wg@merit.edu Tue Mar 12 10:41:37 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24896 for ; Tue, 12 Mar 2002 10:41:37 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 612C49127E; Tue, 12 Mar 2002 10:41:22 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2B0009127F; Tue, 12 Mar 2002 10:41:22 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DA03C9127E for ; Tue, 12 Mar 2002 10:41:20 -0500 (EST) Received: by segue.merit.edu (Postfix) id B37EA5DD9B; Tue, 12 Mar 2002 10:41:20 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from ocasey.baltimore.com (ocasey.baltimore.com [193.41.17.101]) by segue.merit.edu (Postfix) with ESMTP id E74C65DD8D for ; Tue, 12 Mar 2002 10:41:19 -0500 (EST) Received: from Baltimore-FW1 ([172.19.1.1]) by ocasey.baltimore.com (8.11.6/8.9.3) with SMTP id g2CFfJb21832 for ; Tue, 12 Mar 2002 15:41:19 GMT Received: from Baltimore-FW1 (wilde-i-1.ie.baltimore.com) by emeairlsw1.baltimore.com (Content Technologies SMTPRS 4.2.5) with SMTP id for ; Tue, 12 Mar 2002 15:36:16 +0000 Received: from baltimore.ie (wks140-4.ie.baltimore.com [10.153.4.140]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id PAA12000; Tue, 12 Mar 2002 15:41:16 GMT Message-ID: <3C8E21A6.A627990C@baltimore.ie> Date: Tue, 12 Mar 2002 15:41:26 +0000 From: Stephen Farrell Reply-To: stephen.farrell@baltimore.ie Organization: Baltimore Technologies Ltd. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Don Zick Cc: gwz@cisco.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: [issue] Diameter CMS Security - Require AAA-Node-Cert in DSAR and DSAA References: <3C8E0DA5.662E736D@interlinknetworks.com> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Don, 1. Not all nodes that can be party to a DSA need have certificates - only signers or decryptors actually need them. Verifiers and encryptors don't (if they don't do the opposite operations, that is). If AAA-Node-Cert were mandatory, then every access device that wanted to encrypt using CMS would have to get a cert that it'd never use. 2. Currently both DSAR and DSAA have the same three AVPs for cert-stuff, in the same order (below). That ought to simplify coding. * { Local-CA-info } 0*1[ CA-Chain ] * [ AAA-Node-Cert ] 3. If someone develops a Diameter implementation that uses standard PKI libraries, its very likely that they can get certs from elsewhere too (e.g. local files, databases, ldap, etc.). There's no reason to insist that a AAA-Node-Cert always be present (it is however, advisable to include one if you've got one). 4. A DSA peer can basically accept a certificate it finds on the floor so long as it meets the PKI and specific naming rules contained/referenced in the CMS draft. That is, if a node can find a "better" cert than that supplied by the peer, that's ok too. This can and does happen - say if there are disjoint PKIs and the node in question has a cert for the same naming and key pair in each of the PKI. If its valid to find a good cert anywhere, it seems wrong to insist that some certificate is always sent in the protocol. I think that's sufficient reason to stick with the ABNF we've got. Stephen. Don Zick wrote: > > Glen, > > I'm sorry I'm not understanding your point. If Diameter nodes have their own > certs available, why not just always stick them in the DSAR/DSAA messages so > that they're always available when needed? What is the drawback of doing > this? If my implementation must be able to handle DSAR/DSAA messages without > the AAA-Node-Cert AVP then don't I have to implement a scheme for retrieving > the certificate information elsewhere? > > Don > > Glen Zorn wrote: > > > Don Zick [mailto://dzick@interlinknetworks.com] writes: > > > > > A single occurrence of the AAA-Node-Cert AVP should be required in the > > > DSAR and the DSAA. > > > > > > The Diameter CMS Security draft states (in section 3): > > > In order to encrypt AVPs for a recipient, the originating Diameter > > > node must have a copy of the recipient's public key. There are many > > > well-known key retrieval schemes (e.g. LDAP [CERTLDAP]), but this > > > specification also allows for the transportation of certificates > > > within Diameter AVPs, which is expected to simplify implementations. > > > > > > If inclusion of the AAA-Node-Cert AVP is optional then the expected > > > simplification in implementations is lost because compliant > > > implementations must be able to handle DSAR and DSAA messages that don't > > > include the AAA-Node-Cert AVPs. > > > > I disagree: compliant implementations must be able to handle DSAR and DSAA > > messages that don't > > include the AAA-Node-Cert AVPs, but they do _not_ have to include e.g. an > > LDAP client and are therefore simpler. > > > > > > > > Requested change: > > > > > > Please update the occurrence rules table and the ABNF definitions for > > > the DSAR and DSAA to indicate that exactly 1 occurrence of the > > > AAA-Node-Cert must be present. > > > > > > > > > -- ____________________________________________________________ Stephen Farrell Baltimore Technologies, tel: (direct line) +353 1 881 6716 39 Parkgate Street, fax: +353 1 881 7000 Dublin 8. mailto:stephen.farrell@baltimore.ie Ireland http://www.baltimore.com From owner-aaa-wg@merit.edu Tue Mar 12 11:04:42 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25616 for ; Tue, 12 Mar 2002 11:04:41 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id F27109127F; Tue, 12 Mar 2002 11:04:30 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BA17791280; Tue, 12 Mar 2002 11:04:29 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9DB839127F for ; Tue, 12 Mar 2002 11:04:28 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7A52D5DD9B; Tue, 12 Mar 2002 11:04:28 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from frascone.com (adsl-66-137-237-97.dsl.rcsntx.swbell.net [66.137.237.97]) by segue.merit.edu (Postfix) with SMTP id D25375DD8D for ; Tue, 12 Mar 2002 11:04:27 -0500 (EST) Received: (qmail 2090 invoked by uid 500); 12 Mar 2002 16:04:27 -0000 Date: Tue, 12 Mar 2002 10:04:27 -0600 From: David Frascone To: john.loughney@nokia.com Cc: randy@psg.com, pcalhoun@bstormnetworks.com, dave@frascone.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 303: Security model for peer discovery and redirect Message-ID: <20020312160427.GJ22132@newman.frascone.com> Mail-Followup-To: john.loughney@nokia.com, randy@psg.com, pcalhoun@bstormnetworks.com, dave@frascone.com, aaa-wg@merit.edu References: <0C1353ABB1DEB74DB067ADFF749C4EEFC64BFB@esebe004.NOE.Nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEFC64BFB@esebe004.NOE.Nokia.com> User-Agent: Mutt/1.3.25i X-encrypt-payload: no Sender: owner-aaa-wg@merit.edu Precedence: bulk I think advising is sufficient. (Actually, I think advising is a MUST, but mandating is a SHOULD NOT) :) -Dave On Tuesday, 12 Mar 2002, john.loughney@nokia.com wrote: > Hi Randy, > > > > Remember that a redirect makes lots of sense in the case where the > > > redirect server is owned by a "broker". The broker would typically > > > act as a certificate authority, and would ensure that all of the > > > roaming consortium members have certificates that are signed by the > > > CA. This provides the trust that is needed in the protocol. > > > > so, if i do not have a signed cert of the host trying to contact me, > > the protocol will say that i MUST reject the connection? > > Is this something that we would need to mandate - or is it something > we should advise on? I generally don't like these kind of MUST requirements, > as it gets to a deployment issue, as opposed to an interoperability > issue. If someone wants to hang their butt out in the open air ... > Or are you suggesting that fundamentally this is an interoperability > issue that MUST be enforced by the protocol? > > John > -- David Frascone George Orwell was an optimist. From owner-aaa-wg@merit.edu Tue Mar 12 11:23:54 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26152 for ; Tue, 12 Mar 2002 11:23:54 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 444D291281; Tue, 12 Mar 2002 11:23:33 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0FD4991282; Tue, 12 Mar 2002 11:23:32 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E9D0991281 for ; Tue, 12 Mar 2002 11:23:31 -0500 (EST) Received: by segue.merit.edu (Postfix) id CD6375DDAC; Tue, 12 Mar 2002 11:23:31 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by segue.merit.edu (Postfix) with ESMTP id AA5525DDAA for ; Tue, 12 Mar 2002 11:23:31 -0500 (EST) Received: from randy by rip.psg.com with local (Exim 4.00) id 16kp3c-000Ku8-00; Tue, 12 Mar 2002 08:23:24 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Cc: , , Subject: RE: [AAA-WG]: Issue 303: Security model for peer discovery and redirect References: <0C1353ABB1DEB74DB067ADFF749C4EEFC64BFB@esebe004.NOE.Nokia.com> Message-Id: Date: Tue, 12 Mar 2002 08:23:24 -0800 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit >> so, if i do not have a signed cert of the host trying to contact me, >> the protocol will say that i MUST reject the connection? > > Is this something that we would need to mandate - or is it something we > should advise on? I generally don't like these kind of MUST requirements, > as it gets to a deployment issue, as opposed to an interoperability issue. this is generally handled by o mandatory to implement o on by default, but configurable o recommended not to change default randy From owner-aaa-wg@merit.edu Tue Mar 12 11:25:24 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26190 for ; Tue, 12 Mar 2002 11:25:24 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A812B91282; Tue, 12 Mar 2002 11:25:03 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 71B8F91283; Tue, 12 Mar 2002 11:25:03 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5F8EF91282 for ; Tue, 12 Mar 2002 11:25:02 -0500 (EST) Received: by segue.merit.edu (Postfix) id 46DF15DDAC; Tue, 12 Mar 2002 11:25:02 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 30CCF5DDAA for ; Tue, 12 Mar 2002 11:25:02 -0500 (EST) Received: from Interlinknetworks.com (nat.interlinknetworks.com [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with ESMTP id CCDEE6C; Tue, 12 Mar 2002 11:25:01 -0500 (EST) Message-ID: <3C8E2BEA.A88C431E@Interlinknetworks.com> Date: Tue, 12 Mar 2002 11:25:14 -0500 From: David Spence Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: john.loughney@nokia.com Cc: dave@frascone.com, aboba@internaut.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 303: Security model for peer discovery and redirect References: <0C1353ABB1DEB74DB067ADFF749C4EEFC64BFA@esebe004.NOE.Nokia.com> Content-Type: multipart/mixed; boundary="------------FE1B9AA25B09826CC4BF010E" Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. --------------FE1B9AA25B09826CC4BF010E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit That would most definitely not be sufficient. It only addresses one of my points and quite inadequately at that. For the redirect model, you would also need to add text that says something like, "A Diameter node MUST NOT accept a proposed connection unless one of the following conditions are met." And then you have to get the conditions list right. One of the conditions would be that you have a hard configured entry for the peer in your peers table. Another might be that you received a CER over a TLS connection and the certificate met certain requirements which you also need to specify somewhere. In other words, there is no easy way out. Yes, I think peer-to-peer security can be fixed, but it will take some real work. john.loughney@nokia.com wrote: > > David, > > I think someone raised a valid point that we may wish to > add text for the security implications of redirect. > Would that be sufficient, or are you looking for more? > > John > > > -----Original Message----- > > From: ext David Spence [mailto:DSpence@Interlinknetworks.com] > > Sent: 12 March, 2002 00:08 > > To: David Frascone > > Cc: Loughney John (NRC/Helsinki); aboba@internaut.com; > > aaa-wg@merit.edu > > Subject: Re: [AAA-WG]: Issue 303: Security model for peer > > discovery and > > redirect > > > > > > I raised a number of specific security concerns in issue 303 > > and I don't > > think it is responsible to dismiss them summarily. I think each > > deserves some kind of response. I am actually very concerned that > > peer-to-peer security may be worse in Diameter than it is in RADIUS. > > RADIUS has real peer-to-peer security -- the shared secret! > > Yes, I know > > it's real bad security. But at least there's something real > > about it. > > Diameter may be run with no security -- and the server won't > > even know. > > > > Consider IPsec. The underlying problem with IPsec is that it > > isn't easy > > for a "Diameter node" (server or client process) to verify > > that IPsec is > > being used. This weakness can be exploited in a number of > > ways. Issue > > 303 mentioned one of them. If a peer-to-peer connection is being > > established dynamically due to peer discovery or the action of a > > redirect agent, it is rather likely that an IPsec tunnel does > > not exist. > > (If it did, you wouldn't need peer discovery or a redirect > > agent.) But > > I believe that the problems of relying on IPsec run deeper than that. > > > > Example 1: > > > > Consider the case of the ISP Fastgrowth.net. Fastgrowth > > has 12 NASes > > named nas01.fastgrowth.net through nas12.fastgrowth.net. Their > > Diameter server is named aaa1.fastgrowth.net. The configured peer > > table for this server contains entries for nas01 through nas99. > > IPsec is used for peer-to-peer security. When a new NAS is > > installed, the network administrator assigns it a name in > > the range > > nas01-nas99 and sets up an IPsec tunnel for it. Now an > > attacker in > > Elbonia wishes to attack Fastgrowth with the aid of a > > Diameter Attack > > Client he's cobbled together. He names his client > > nas13.fastgrowth.net (on a hunch) and attempts to bring up a > > peer-to-peer connection with aaa1.fastgrowth.net. As luck > > would have > > it, the name he chose is in aaa1's peer table. Of course > > there is no > > IPsec tunnel, but aaa1 doesn't know that. So aaa1 merrily > > brings up > > a connection with the impostor. That attack would have been much > > harder to pull off with RADIUS because of the burden of having to > > guess the shared secret. > > > > So much for IPsec. At least TLS doesn't have that problem. > > With TLS, > > you know you're secure. Maybe. > > > > Example 2: > > > > A group of small, regional ISPs spread across the northern > > U.S. from > > Lake Wobegone, Minnesota all the way to Blight, Idaho, has > > established a roaming consortium called the Northern Alliance. > > Consortium members establish peer-to-peer connections > > between their > > Diameter servers as needed using peer discovery. For > > security, they > > use TLS. Since most of their administrators are not security > > experts, they want to make sure they get it right. They choose > > Verisign as their CA. Now a group of outlaws in Wyoming > > starts up a > > small ISP of their own called Blackhats.net. They do not join the > > Northern Alliance. But their leader, Jesse James, applies to > > Verisign for a certificate for their Diameter server. > > Now, without > > bothering to join, they can send peer-to-peer connection > > requests to > > Diameter servers throughout the Northern Alliance. When > > the Diameter > > server for Sittingducks.net, the Lake Wobegone ISP, > > receives one of > > these requests, it examines the tendered TLS certificate and reads > > the fine print, which says, "To whom it may concern: We, Verisign, > > have verified the identity of one Jesse James by comparing > > his face > > to the photographs on the wall of the Post Office down the > > street. > > We are confident that the applicant for this certificate really is > > Jesse James and that he really is a principle of the Wyoming > > corporation Blackhats.net." So they merrily bring up the > > connection. > > Again, the attack would have failed with RADIUS because > > Jesse would > > never have guessed their shared secret "happytrails2U". > > > > Yes, I know the Northern Alliance could have done better. But we > > haven't exactly helped them by explaining in our Security > > Considerations > > how TLS should and should not be used to secure peer-to-peer > > connections. > > > > Now here's the real problem. The real problem is that Diameter, when > > used to support roaming in a multi-domain environment, relies on > > transitive trust. I trust the Diameter messages sent by all the good > > buddies of my good buddies because I trust my good buddies' > > trust. This > > means that if a successful peer-to-peer attack can be > > launched against > > any of the thousands of my buddies' buddies, then I am vulnerable. > > > > Example 3: > > > > The GrockPass Roaming Broker decides to upgrade the GrockPass > > Alliance from RADIUS to Diameter for all inter-domain AAA requests > > because of Diameter's superior security. GrockPass uses > > TLS security > > and they themselves run the CA for the alliance so there > > won't be any > > funny business. Only certificates signed by GrockPass are > > accepted > > by alliance members. One day Maxwell Smart, the system > > administrator > > for GoodVigilance.net, notices that their Diameter server has > > received a very large number of failed authentication > > requests from > > GrockPass affiliate Laxnet.com proxied through GrockPass. > > The failed > > authentication requests all come from nas13.laxnet.com and > > appear to > > be an attempt to mount a dictionary attack against the PAP > > passwords > > of the GoodVigilance dialin users. Max calls up his counterpart > > Dudley Hopewell at Laxnet. "Gee," Dudley says, "We don't > > even have a > > nas13." Dang those Elbonians. > > > > In this example, all the good vigilance of GoodVigilance and > > GrockPass > > could not protect them. That is why, if you are designing a > > multi-domain protocol, you SHOULD NOT make it rely on the > > intelligence > > and vigilance of all the domains' network administrators. > > Because even > > if an administrative domain believes in the intelligence and > > vigilance > > of its own administrator, what about all the other stupid, lazy > > administrators out there? At least let the vendors help out > > by making > > the application verify the security directly wherever possible. And > > where it's not possible, make sure the vendors understand the > > Security > > Considerations well enough to insert plenty of BIG BOLD > > WARNING MESSAGES > > in their GUIs to give their customers a little help. > > > > In conclusion, Diameter has the following peer-to-peer > > "features" that > > RADIUS lacks. > > > > 1) Dynamic peer-to-peer connections (ones that are not > > preconfigured). Both peer discovery and redirect > > agents require > > this. > > > > 2) Non-verifiable peer-to-peer security associations (IPsec). > > > > 3) The ability, by abusing TLS, to bring up authenticated, but > > unauthorized peer-to-peer connections. > > > > We need to be sure Diameter nodes can implement these > > features securely > > or else remove them. The two questions in each case are, how > > do I know > > I'm authorized to establish this connection and how can I > > authenticate > > the peer? If we can't answer these two questions satisfactorily, we > > should stick to configured peers with configured shared secrets. > > > > > > David Frascone wrote: > > > > > > My vote would be to reject this issue. > > > > > > But, to address the possible security issues, perhaps we > > should allow > > > implementations to decide whether they allow redirects. > > (In other words, > > > server X might not allow redirects from realm Y) > > > > > > As far as server discovery goes . . . that smells like an > > implementation > > > issue. . . . . > > > > > > -Dave > > > > > > On Monday, 11 Mar 2002, john.loughney@nokia.com wrote: > > > > Hi all, > > > > > > > > http://www.drizzle.com/~aboba/AAA/issues.html#Issue%20#303 > > > > > > > > Issue 303 is a quite a big change, in my opinion. I am somewhat > > > > hesitant about tackling this, so I thing the WG needs to discuss > > > > this. Security is, of course, extremely important. Does the > > > > workgroup see this a good solution? > > > > > > > > I'd appreciate comments on this. > > > > > > > > thanks, > > > > John > > > > > > > > PS - the requestion change is: > > > > > > > > I think the usefulness of the redirect and server discovery models > > > > ought to be reexamined in light of the security problems they > > > > introduce.It may be that removing redirect and server discovery > > > > from Diameter is the best solution. > > > > > > > > > > -- > > > David Frascone > > > > > > Don't just do something !!! Stand there !!! > > --------------FE1B9AA25B09826CC4BF010E Content-Type: text/x-vcard; charset=us-ascii; name="DSpence.vcf" Content-Description: Card for David Spence Content-Disposition: attachment; filename="DSpence.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:; tel;fax:+1 734 821 1235 tel;work:+1 734 821 1203 x-mozilla-html:FALSE url:http://www.interlinknetworks.com org:Interlink Networks, Inc. adr:;;775 Technology Dr., Suite 200;Ann Arbor;MI;48108;USA version:2.1 email;internet:DSpence@Interlinknetworks.com title:Architect fn:David Spence end:vcard --------------FE1B9AA25B09826CC4BF010E-- From owner-aaa-wg@merit.edu Tue Mar 12 11:31:35 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26481 for ; Tue, 12 Mar 2002 11:31:34 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id ADB7D91284; Tue, 12 Mar 2002 11:30:40 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6992F91285; Tue, 12 Mar 2002 11:30:40 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6B08D91284 for ; Tue, 12 Mar 2002 11:30:37 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1A49E5DDAD; Tue, 12 Mar 2002 11:30:37 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 055075DDAA for ; Tue, 12 Mar 2002 11:30:37 -0500 (EST) Received: from Interlinknetworks.com (nat.interlinknetworks.com [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with ESMTP id 8A9476C; Tue, 12 Mar 2002 11:30:32 -0500 (EST) Message-ID: <3C8E2D35.3755C527@Interlinknetworks.com> Date: Tue, 12 Mar 2002 11:30:45 -0500 From: David Spence Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: john.loughney@nokia.com Cc: randy@psg.com, pcalhoun@bstormnetworks.com, dave@frascone.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 303: Security model for peer discovery and redirect References: <0C1353ABB1DEB74DB067ADFF749C4EEFC64BFB@esebe004.NOE.Nokia.com> Content-Type: multipart/mixed; boundary="------------69977A4C06AA854DB6B43DC6" Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. --------------69977A4C06AA854DB6B43DC6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit This is a subcase of the one I just commented on. Again, it's a good start but insufficient. You not only need a signed cert but the cert needs to convey authorization -- not just authentication. So you need to describe what that means. And you really do need to do some enforcing in the protocol. Specifying that you need a signed cert says that IPsec is not sufficient protection in some cases. john.loughney@nokia.com wrote: > > Hi Randy, > > > > Remember that a redirect makes lots of sense in the case where the > > > redirect server is owned by a "broker". The broker would typically > > > act as a certificate authority, and would ensure that all of the > > > roaming consortium members have certificates that are signed by the > > > CA. This provides the trust that is needed in the protocol. > > > > so, if i do not have a signed cert of the host trying to contact me, > > the protocol will say that i MUST reject the connection? > > Is this something that we would need to mandate - or is it something > we should advise on? I generally don't like these kind of MUST requirements, > as it gets to a deployment issue, as opposed to an interoperability > issue. If someone wants to hang their butt out in the open air ... > Or are you suggesting that fundamentally this is an interoperability > issue that MUST be enforced by the protocol? > > John --------------69977A4C06AA854DB6B43DC6 Content-Type: text/x-vcard; charset=us-ascii; name="DSpence.vcf" Content-Description: Card for David Spence Content-Disposition: attachment; filename="DSpence.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:; tel;fax:+1 734 821 1235 tel;work:+1 734 821 1203 x-mozilla-html:FALSE url:http://www.interlinknetworks.com org:Interlink Networks, Inc. adr:;;775 Technology Dr., Suite 200;Ann Arbor;MI;48108;USA version:2.1 email;internet:DSpence@Interlinknetworks.com title:Architect fn:David Spence end:vcard --------------69977A4C06AA854DB6B43DC6-- From owner-aaa-wg@merit.edu Tue Mar 12 13:27:27 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00102 for ; Tue, 12 Mar 2002 13:27:27 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9188791287; Tue, 12 Mar 2002 13:27:16 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 50E1991288; Tue, 12 Mar 2002 13:27:16 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3ECE091287 for ; Tue, 12 Mar 2002 13:27:15 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1B9005DDBA; Tue, 12 Mar 2002 13:27:15 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from dzick.interlinknetworks.com (nat.interlinknetworks.com [198.108.5.3]) by segue.merit.edu (Postfix) with ESMTP id C731B5DD8E for ; Tue, 12 Mar 2002 13:27:14 -0500 (EST) Received: from interlinknetworks.com (localhost.localdomain [127.0.0.1]) by dzick.interlinknetworks.com (8.11.0/8.11.0) with ESMTP id g2CIJxE01254; Tue, 12 Mar 2002 13:19:59 -0500 Message-ID: <3C8E46CF.4A527B10@interlinknetworks.com> Date: Tue, 12 Mar 2002 13:19:59 -0500 From: Don Zick Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: stephen.farrell@baltimore.ie, aaa-wg@merit.edu Subject: [AAA-WG]: CMS Security questions Content-Type: text/plain; charset=iso-8859-1 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id NAA00102 Hi Stephen, Before I go hog-wild submitting any more issues could you please address the following questions concerning the Diameter CMS Security draft? 1. In section 3.1, it states: We use Diameter Security Association Request (DSAR) and Diameter Security Association Answer (DSAA) messages to establish a DSA, which specifies which AVPs should be encrypted, signed or both, as well as which public key(s) to use. Now that the expected-signed and expected-encrypted AVPs have been removed, shouldn't the text "which specifies which AVPs should be encrypted, signed or both" be removed? 2. The AVP occurrence rules table in section 8 shows that at most 1 AAA-Node-Cert AVP may appear in a DSAR or a DSAA. However, the ABNF definition for the DSAR and DSAA indicate that any number of AAA-Node-Cert AVPs may appear. Is the AVP occurrene rules table correct? If so, shouldn't "public key(s)" mentioned in item 1 really be "public key"? 3. In section 3.1, it states: - Its local policy allows the given TTL, realm, AVP protection expectations, certification status, and other parameters. Now that the expected-signed and expected-encrypted AVPs have been removed, shouldn't the text "AVP protection expectations" be removed? 4. In section 3.1 it states: ...the destination node returns the DSAA message which contains: ... - public key certificates for the Diameter servers in the realm... This goes back to question #2. Must a Diameter server know all of the certificates for all servers in its realm? Why is that useful when the Diameter node is only establishing a DSA with a single server? 5. In section 3.1 it states: The DSAA MUST include the CMS-Signed-Data, signed by a Diameter agent or server within the user's realm, to prevent an intermediate node from modifying the protection expectations for AVPs. Shouldn't this requirement be removed now that expected-signed and expected-encrypted AVPs have been removed? 6. In section 3.2 it states: For multiple Diameter servers within a realm that share a public key, each server's identity is encoded in the subjectAltName extension. This allows any server within a realm to decrypt AVPs intended for that realm. Why would a server that is not part of the DSA ever decrypt AVPs? Wouldn't there be potential problems with content encryption key reuse? 7. In section 4.4, the PDSR is defined. When an access device sends a PDSR to a local proxy, the local proxy will establish a DSA with a server in the DSAR-Target-Realm. If the access device sends an authentication request to the local proxy and the authentication request contains Destination-Realm but does not contain Destination-Host, must the local proxy add the Destination-Host AVP to the message to ensure that it is routed to the server in the Destination-Realm that has the DSA? If this is a requirement I think it should be stated explicitly. 8. Section 6.3 provides some example encodings for encrypted and signed AVPs. The examples indicate that different Diameter nodes can have different encryption and signing requirements. Aren't these examples misleading now that the expected-signed and expected-encrypted AVPs have been removed? (All Diameter nodes share the same encryption and signing requirements.) 9. The AVP occurrence rules table and ABNF message definitions have some inconsistencies: DSAR ABNF DSAR Occurrence rules table AAA-Node-Cert * 0-1 DSAA ABNF DSAA Occurrence rules table AAA-Node-Cert * 0-1 OCSP-Responses * 1+ Origin-Realm 0*1 1 Redirect-Host not listed 0+ Redirect-Host-Usage not listed 0-1 Redirect-Max- Cache-Time not listed 0-1 10. DSAA ABNF has Local-CA-info surrounded by curly brackets. I think square brackets are correct. 11.Origin-State-Id listed as Original-State-Id in AVP occurrence table. 12.Section 3.1 states: Once the DSA is in place, any Diameter messages created by a DSA peer that has a private key MUST contain a signature over all AVPs whose definition states that their 'P' bit MAY be set. I think the CMS-Encrypted-Data AVP is an exception to this rule. It only requires a signature if any of the encrypted AVPs contained in the CMS-Encrypted-Data AVP require signing. 13.Some typos: Section 1: "two different set of messages" "two different sets of messages" Section 1.2 "DSA would the NAS" "DSA would be the NAS" "initiate an DSAR" "initiate a DSAR" Section 1.3 "such an an aggregating relay" "such as an aggregating relay" "recelived" "received" Section 3.1 "MUST re-validated" "MUST be re-validated" "implemetors" "implementors" Section 5 "CAA" (in diagram) "CEA" "issues an DSAR message" "issues a DSAR message" Section 6.11 "lenght" "length" Thanks, Don From owner-aaa-wg@merit.edu Tue Mar 12 14:01:31 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01711 for ; Tue, 12 Mar 2002 14:01:31 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3EA4891288; Tue, 12 Mar 2002 14:00:22 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 062CF91289; Tue, 12 Mar 2002 14:00:21 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 49DC191288 for ; Tue, 12 Mar 2002 14:00:20 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1154F5DDCE; Tue, 12 Mar 2002 14:00:20 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by segue.merit.edu (Postfix) with ESMTP id 9EABB5DDBA for ; Tue, 12 Mar 2002 14:00:19 -0500 (EST) Received: from mr7.exu.ericsson.se (mr7att.ericy.com [138.85.224.158]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g2CJ0IS10242; Tue, 12 Mar 2002 13:00:19 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g2CJ0Iq07909; Tue, 12 Mar 2002 13:00:18 -0600 (CST) Received: from qpop.exu.ericsson.se (qpop [138.85.75.72]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id NAA01769; Tue, 12 Mar 2002 13:00:17 -0600 (CST) Received: from ericsson.com ([138.85.159.114]) by qpop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id NAA24416; Tue, 12 Mar 2002 13:00:15 -0600 (CST) Message-ID: <3C8E4FA4.E7DC8838@ericsson.com> Date: Tue, 12 Mar 2002 10:57:40 -0800 From: Tony Johansson X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Fredrik Johansson Cc: Sivasundar Ramamurthy , AAA Working Group Subject: Re: [AAA-WG]: Re: Pending Issue about MIP-Key-Lifetime AVP (fwd) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Fredrik and All, Alt 1 is the one we should use. Unfortunately, I missed to remove the Session-Timeout AVP in the occurrence rules table and in the ABNFs. I will clarify this on issue #306. Regards, /Tony Fredrik Johansson wrote: > I believe we need some clarifications on what timers are to be used. > > I belive this can be done in two ways, using two or three of the lifetime > AVPs. > > Alt 1. > Use Authorization-Lifetime to indicate the MIP tunnel lifetime (i.e the > value that goes into the mip registration reply packet) and the > MIP-Key-Lifetime is the time of the keys and the session. Thus to extend the > session and request new keys has to be done every MIP-Key-Lifetime seconds. > In this alternative, the Session will have the same lifetime as the keys. > I.e. the MN must make sure to request new keys some time before the actual > time expires. > > Alt 2. > Use three AVPs, one for the session, one for the keys and one for the mip > tunnels. I.e. Let the session-lifetime AVP be the maximum lifetime of the > session, the mip-key-lifetime is the lifetime of the session keys, and the > authorization-lifetime avp is the length of the mip tunnel lifetime. This > will mean that the MN will reauthenticate periodically with the HA at > Authorization-Lifetime in order to update the tunnels, it will request new > keys at MIP-Key-Lifetime, the Session-Lifetime will indicate when the > diameter client/server will terminate the session. The Session lifetime MUST > be greater or equal to the MIP-Key-Lifetime (preferable greater to allow the > mobile some time to request new keys and extend the session). > > > /Fredrik > > >-----Original Message----- > >From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of > >Sivasundar Ramamurthy > >Sent: den 11 mars 2002 21:21 > >To: AAA Working Group > >Subject: Re: [AAA-WG]: Re: Pending Issue about MIP-Key-Lifetime AVP > >(fwd) > > > > > > > >On Mon, 25 Feb 2002, Tony Johansson wrote: > > > >> New section: > >> > >> "5.1 Authorization Lifetime vs. MIP Key Lifetime > >> > >> The Diameter Mobile IP application makes use of two timers the > >> Authorization-Lifetime AVP [DIAMBASE] and the MIP-Key-Lifetime AVP. > >> > >> The Authorization-Lifetime contains the number of seconds before the > >> Mobile Node must issue a subsequent MIP registration request. The > >> content of Authorization-Lifetime AVP corresponds to the Lifetime > >> field in the MIP header [MOBILEIP]. > >> > >> The MIP-Key-Lifetime AVP contains the number of seconds before > >> session keys destined for the Home Agent and/or Foreign Agent expire. > >> > >> A value of zero indicates infinity (no timeout). The value of the > >> MIP-Key-Lifetime AVP MUST be at least equal to the value in the > >> Authorization Lifetime AVP. If the value is greater, it SHOULD be a > >> multiple of the value in the Authorization Lifetime AVP." > >> > > > >if the key lifetime is allowed to be greater than the authorization > >lifetime, then the authorization lifetime at the (stateful) AAA server > >will expire even as the MN is re-registering. This will happen since > >the MN "knows" to use AAA only to request keys; it will re-register > >(re-authenticate) directly with the HA during the time the keys are > >alive. > > > >Thus even while the MN is happily registered (authenticated), the > >(stateful) AAA server will see that its authorization lifetime has > >expired and will terminate its session and de-allocate the resources. > >Is'nt this a problem, considering that one of the resources allocated > >could be a dynamic home address which could then be allocated to some > >other MN? > > > > > >thanks! > > > >Siva > > > > > > From owner-aaa-wg@merit.edu Tue Mar 12 14:33:53 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03213 for ; Tue, 12 Mar 2002 14:33:53 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id CC30B9128A; Tue, 12 Mar 2002 14:33:32 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 99C6E9128B; Tue, 12 Mar 2002 14:33:32 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 673579128A for ; Tue, 12 Mar 2002 14:33:31 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4A50E5DDDF; Tue, 12 Mar 2002 14:33:31 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by segue.merit.edu (Postfix) with ESMTP id B91FC5DD8E for ; Tue, 12 Mar 2002 14:33:30 -0500 (EST) Received: from mr7.exu.ericsson.se (mr7u3.ericy.com [208.237.135.122]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g2CJINh17356; Tue, 12 Mar 2002 13:18:23 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g2CJIMq15221; Tue, 12 Mar 2002 13:18:22 -0600 (CST) Received: from qpop.exu.ericsson.se (qpop [138.85.75.72]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id NAA03612; Tue, 12 Mar 2002 13:18:22 -0600 (CST) Received: from ericsson.com ([138.85.159.114]) by qpop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id NAA24748; Tue, 12 Mar 2002 13:18:21 -0600 (CST) Message-ID: <3C8E53E1.B8D86E1F@ericsson.com> Date: Tue, 12 Mar 2002 11:15:46 -0800 From: Tony Johansson X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: AAA Working Group Cc: Johan Johansson , sramam@cup.hp.com, fredrik.johansson@ipunplugged.com Subject: Re: [AAA-WG]: [issue] Session-Timeout vs Authorization-Lifetime vs MIP-Key-Lifetime References: <3C8D185C.30003@ipunplugged.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit All, I would like to close this issue with the following changes: Remove the Session-Timeout AVP form the occurrence rules table and from the ABNFs in the AMA and HAR. Comments / objections? /Tony Johan Johansson wrote: > Subject: [issue] Session-Timeout vs Authorization-Lifetime vs > MIP-Key-Lifetime > > Submitter name: Johan Johansson > Submitter email address: johanj@ipunplugged.com > Date first submitted: March 11, 2002 > Reference: > Document: Mobile IP > Comment type: T > Priority: 1 > Section: 2.2, 2.3, 5.1, 8.1 > Rationale/Explanation of issue: > > If there is to be any hope for interoperability the use of > Session-Timeout must be defined in the MIP draft. > > The base draft defines Session-Timeout as > > 8.13 Session-Timeout AVP > > The Session-Timeout AVP (AVP Code 27) [RADIUS] is of type Unsigned32 > and contains the maximum number of seconds of service to be provided > to the user before termination of the session. When both the Session- > Timeout and the Authorization-Lifetime AVPs are present in an answer > message, the former MUST be equal to or greater than the value of the > latter. > > --- > > A Session-Timeout AVP MAY be present in a re-authorization message, > and contains the number of seconds from the beginning of the re-auth. > > A value of zero, or the absence of this AVP, means that this session > has an unlimited number of seconds before termination. > > Section 8.9 of the base draft has this to say about Authorization-Lifetime: > > An Authorization-Lifetime AVP MAY be present in re-authorization > messages, and contains the number of seconds the user is authorized > to receive service from the time the re-auth answer message is > received by the access device. > > The MIP draft contains no references to Session-Timeout beyond the > occurence rules and the ABNFs and they are contradictory. > > The occurence rules of the MIP draft states > > +-----------------------+ > | Command-Code | > |-----+-----+-----+-----+ > Attribute Name | AMR | AMA | HAR | HAA | > ------------------------------|-----+-----+-----+-----+ > Session-Timeout | 0 | 1 | 1 | 0 | > > The ABNFs for AMA and HAR list it as optional. Looking solely at the > base draft the ABNF would seem to be correct. > > But this still does not settle the issue of the semantics of its > presence. Section 5.1 of the mip draft states > > The Diameter Mobile IP application makes use of two timers - the > Authorization-Lifetime AVP [DIAMBASE] and the MIP-Key-Lifetime AVP. > > The Authorization-Lifetime contains the number of seconds before the > Mobile Node must issue a subsequent MIP registration request. The > content of the Authorization-Lifetime AVP corresponds to the Lifetime > field in the MIP header [MOBILEIP]. > > The MIP-Key-Lifetime AVP contains the number of seconds before > session keys destined for the Mobility Agents and the Mobile Node > expire. A value of zero indicates infinity (no timeout). If not zero, > the value of the MIP-Key-Lifetime AVP MUST be at least equal to the > value in the Authorization Lifetime AVP. > > If the application doesn't use Session-Timeout it should not be optional > or mandatory but banned. The section quoted above inevitably leads to > the the termination of the user session after at least > Authorization-Lifetime seconds and at most Authorization-Lifetime + > MIP-Key-Lifetime seconds. > > Requested change: > > Remove Session-Timeout from AMA and HAR. > > Modify the first paragraph of section 5.1 to: > > The Diameter Mobile IP application makes use of two timers - the > Authorization-Lifetime AVP [DIAMBASE] and the MIP-Key-Lifetime AVP. The > Session-Timeout AVP [DIAMBASE] does not apply to this application. > > j From owner-aaa-wg@merit.edu Tue Mar 12 14:45:24 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03774 for ; Tue, 12 Mar 2002 14:45:24 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 392B89128B; Tue, 12 Mar 2002 14:45:07 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A3ED99128C; Tue, 12 Mar 2002 14:45:06 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 52F339128B for ; Tue, 12 Mar 2002 14:45:04 -0500 (EST) Received: by segue.merit.edu (Postfix) id EC2E65DDDF; Tue, 12 Mar 2002 14:45:02 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by segue.merit.edu (Postfix) with ESMTP id 8EF745DD8E for ; Tue, 12 Mar 2002 14:45:02 -0500 (EST) Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.224.157]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g2CJj2S04049; Tue, 12 Mar 2002 13:45:02 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g2CJj1F25714; Tue, 12 Mar 2002 13:45:01 -0600 (CST) Received: from qpop.exu.ericsson.se (qpop [138.85.75.72]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id NAA06249; Tue, 12 Mar 2002 13:45:01 -0600 (CST) Received: from ericsson.com ([138.85.159.114]) by qpop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id NAA25205; Tue, 12 Mar 2002 13:44:59 -0600 (CST) Message-ID: <3C8E5A20.3F2CBDEC@ericsson.com> Date: Tue, 12 Mar 2002 11:42:24 -0800 From: Tony Johansson X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Bob Kopacz Cc: aaa-wg Subject: [AAA-WG]: Re: [issue] Minor corrections to mobileip-09 References: <000901c1c3e0$ebc60b80$f6512844@sanarb01.mi.comcast.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Bob, Thanks for the editorial catches. Please find my comments embedded. /Tony Bob Kopacz wrote: > Hi Tony, > > Issue : Minor corrections to mobileip-09 > Submitter name: Bob Kopacz > Submitter email address:bkopacz@interlinknetworks.com > Date first submitted: 03-04-2002 > Reference: > Document: draft-mobileip-09 > Comment type: Technical > Priority: 1 > Section: > > Rationale/Explanation of issue: > > Minor editing corrections. > > Requested change: > > - - - > > The NASREQ draft has a section "Legacy RADIUS Attributes" with text > along the lines of "The Diameter protocol reserves the AVP Codes 0-255 > for "legacy RADIUS" support. The following table contains the RADIUS > attributes supported by this Diameter application, their AVP code > values, types, possible flag values and whether the AVP MAY be > encrypted. RADIUS attributes not listed are not supported by the > Diameter protocol." > > After section 4.0 Mandatory AVPs, create a similar section 4.1 which > says something like the following (to indicate the subset of RADIUS > attributes a Diameter Mobile-IP client/server requires in its > dictionary): > > > 4.1 Supported Legacy RADIUS Attributes > > > > The Diameter protocol reserves the AVP Codes 0-255 for "legacy RADIUS" > > support. The base protocol defines the RADIUS attributes User-Name, > > Session-Timeout, Acct-Session-Time, Acct-Multi-Session-Id, Proxy-State, > > and Class, all supported by this Diameter application. This application > > supports these RADIUS attributes and no others. I'm not sure why this would be of any major help, since we do specify all AVP codes defined in this spec and those used from the Base in the ABNF's and in occurrence rules table. Others? > > > - - - > > In section 4.3 MIP-Mobile-Node-Address AVP > > > The Mobile-Node-Address AVP (AVP Code 333) is of type IPAddress and > ^^^^^^^^^^^^^^^^^^^ > Change to "MIP-Mobile-Node-Address" Check. > > > - - - > > In section 4.4 MIP-Home-Agent-Address AVP > > > The Home-Agent-Addess AVP (AVP Code 334) is of type IPAddress and > ^^^^^^^^^^^^^^^^^ > Change to "MIP-Home-Agent-Address" Check. > > > - - - > > In section 4.5 MIP-Feature-Vector AVP > > > Whenever the Foreign Agent sets either the Mobile-Node-Home-Address- > > Requested flag or the Home-Agent-Request flag to one, it MUST set the > ^^^^^^^^^^^^^^^^^^ > Change to "Home-Agent-Requested" Check. > > > - - - > > In the following, move the 5.5.1 section header down by one paragraph, > i.e. > > Change: > > > 5.5 Distributing the Foreign-Home Session Key > > > > 5.5.1 Home Agent in the home network > > > > If the home agent is in the home realm, then the AAAH has to generate > > the Foreign-Home session key. Otherwise, it is generated by the AAAF. > > > > In the cases when the AAAH generates the Foreign-Home session key, > > ... > > To: > > > 5.5 Distributing the Foreign-Home Session Key > > > > If the home agent is in the home realm, then the AAAH has to generate > > the Foreign-Home session key. Otherwise, it is generated by the AAAF. > > > > 5.5.1 Home Agent in the home network > > > > In the cases when the AAAH generates the Foreign-Home session key, > > ... > Okay. > > - - - > > In section 6.6 MIP-MN-to-HA-Key AVP > > > * [ AVP ].fi > > Remove ".fi" > Check. > > - - - > > In section 11.1 Normative References > > > [DIAMBASE] P. Calhoun, H. Akhtar, J. Arkko, E. Guttman, A. Rubens, > > "Diameter Base Protocol", draft-ietf-aaa-diameter-08.txt, > > IETF work in progress, November 2001. > > Change to draft-10 (or maybe draft-11 for the next revision) Check. > > > > > [MOBILEIP] C. Perkins, Editor. IP Mobility Support. > > RFC 2002, October 1996. > > RFC2002 has been obsoleted by RFC3220, January 2002. Check. > > > > > [CMS] P. Calhoun, W. Bulley, S. Farrell, "Diameter CMS Security > > Application", draft-ietf-aaa-diameter-cms-sec-03.txt, > > IETF work in progress, November 2001. > > Change to draft-ietf-aaa-diameter-cms-04.txt (or maybe -05 for next revision) Check. > > > > > [MIPKEYS] C. Perkins, P. Calhoun, "AAA Registration Keys for Mobile > > IP", draft-ietf-mobileip-aaa-key-08.txt, IETF work in > > progress, July 2001. > > The above has expired, but key-09, 26 February 2002, is out. Check. > > From owner-aaa-wg@merit.edu Tue Mar 12 14:52:01 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04033 for ; Tue, 12 Mar 2002 14:52:01 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7E02C9128C; Tue, 12 Mar 2002 14:51:49 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 51AD89128D; Tue, 12 Mar 2002 14:51:49 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 294E19128C for ; Tue, 12 Mar 2002 14:51:48 -0500 (EST) Received: by segue.merit.edu (Postfix) id 08F7B5DDAD; Tue, 12 Mar 2002 14:51:48 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by segue.merit.edu (Postfix) with ESMTP id 743025DD8E for ; Tue, 12 Mar 2002 14:51:47 -0500 (EST) Received: from mr7.exu.ericsson.se (mr7u3.ericy.com [208.237.135.122]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g2CJpkh07555; Tue, 12 Mar 2002 13:51:46 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g2CJpkq28136; Tue, 12 Mar 2002 13:51:46 -0600 (CST) Received: from qpop.exu.ericsson.se (qpop [138.85.75.72]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id NAA07027; Tue, 12 Mar 2002 13:51:45 -0600 (CST) Received: from ericsson.com ([138.85.159.114]) by qpop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id NAA25316; Tue, 12 Mar 2002 13:51:44 -0600 (CST) Message-ID: <3C8E5BB4.896AEBDC@ericsson.com> Date: Tue, 12 Mar 2002 11:49:09 -0800 From: Tony Johansson X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: David Spence Cc: AAA Working Group Subject: Re: [AAA-WG]: [issue] Possible new AVP for MobileIPv4 References: <3C83F19C.49C74123@Interlinknetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi David, I don't see any problem to add the Event-Timestamp AVP for accounting, if consider needed. I'll just wait to see your issue TBA first :) /Tony David Spence wrote: > Subject: [issue] Possible new AVP for MobileIPv4 > > Submitter name: David Spence > Submitter email address: DSpence@Interlinknetworks.com > Date first submitted: March 4, 2002 > Reference: > Document: MobileIPv4 > Comment type: T > Priority: 2 > Section: > Rationale/Explanation of issue: > > The following attribute is defined in RADIUS for use in accounting > messages. It might be useful in the MobileIPv4 application. > > CODE NAME RFC > ---- ---- ---- > 55 Event-Timestamp 2869 > > Requested change: > > Consider adding this attribute to MobileIPv4 as a Diameter AVP. > > Note: This AVP will need to be defined in NASREQ for RADIUS > compatibility. See issue TBA. > > -- > David Spence email: DSpence@Interlinknetworks.com > Interlink Networks, Inc. phone: (734) 821-1203 > 775 Technology Drive, Suite 200 fax: (734) 821-1235 > Ann Arbor, MI 48108 > U.S.A. From owner-aaa-wg@merit.edu Tue Mar 12 15:54:46 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06808 for ; Tue, 12 Mar 2002 15:54:45 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id C84E49128E; Tue, 12 Mar 2002 15:54:29 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 97F4C9128F; Tue, 12 Mar 2002 15:54:29 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 655C09128E for ; Tue, 12 Mar 2002 15:54:28 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3BAE75DE1D; Tue, 12 Mar 2002 15:54:28 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from dzick.interlinknetworks.com (nat.interlinknetworks.com [198.108.5.3]) by segue.merit.edu (Postfix) with ESMTP id 1A9175DDAA for ; Tue, 12 Mar 2002 15:54:28 -0500 (EST) Received: from interlinknetworks.com (localhost.localdomain [127.0.0.1]) by dzick.interlinknetworks.com (8.11.0/8.11.0) with ESMTP id g2CKgeE01337; Tue, 12 Mar 2002 15:42:40 -0500 Message-ID: <3C8E6840.A063F103@interlinknetworks.com> Date: Tue, 12 Mar 2002 15:42:40 -0500 From: Don Zick Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: stephen.farrell@baltimore.ie Cc: gwz@cisco.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: [issue] Diameter CMS Security - Require AAA-Node-Cert in DSAR and DSAA References: <3C8E0DA5.662E736D@interlinknetworks.com> <3C8E21A6.A627990C@baltimore.ie> Content-Type: text/plain; charset=iso-8859-1 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id PAA06808 Hi Stephen, I'm still struggling with this issue. I'm not quite ready to give up on it. Please see comments inline. Stephen Farrell wrote: > Don, > > 1. Not all nodes that can be party to a DSA need have > certificates - only signers or decryptors actually need > them. Verifiers and encryptors don't (if they don't do the > opposite operations, that is). If AAA-Node-Cert were > mandatory, then every access device that wanted to encrypt > using CMS would have to get a cert that it'd never use. When a DSA is established I think the participating Diameter nodes will always need to generate the CMS-Signed-Data AVP because most AVPs defined in the base draft have the 'P' bit set (including Origin-Host, Origin-Realm, Destination-Host, and Destination-Realm). Practically speaking, all nodes that participate in a Diameter DSA need a certificate. > > > 2. Currently both DSAR and DSAA have the same three AVPs for > cert-stuff, in the same order (below). That ought to simplify > coding. > > * { Local-CA-info } > 0*1[ CA-Chain ] > * [ AAA-Node-Cert ] > > 3. If someone develops a Diameter implementation that uses > standard PKI libraries, its very likely that they can get > certs from elsewhere too (e.g. local files, databases, ldap, > etc.). There's no reason to insist that a AAA-Node-Cert > always be present (it is however, advisable to include one > if you've got one). No doubt certs can be obtained elsewhere, but it requires that a database of certs be maintained and be made available to all Diameter nodes that can participate in a DSA. It seems much more scalable to only have to install a Diameter node's cert on the Diameter node. The reason for insisting that a AAA-Node-Cert always be present is that it is easier to implement and configure. > > > 4. A DSA peer can basically accept a certificate it finds > on the floor so long as it meets the PKI and specific naming > rules contained/referenced in the CMS draft. That is, > if a node can find a "better" cert than that supplied by the > peer, that's ok too. This can and does happen - say if there > are disjoint PKIs and the node in question has a cert for the > same naming and key pair in each of the PKI. If its valid > to find a good cert anywhere, it seems wrong to insist that > some certificate is always sent in the protocol. I still don't see what harm it would cause if the DSAR and DSAA always included the AAA-Node-Cert AVP. If a Diameter implementation wanted to look up certificate information in a database to find a "better" certificate nothing would prevent it from doing so, but it would never be required to do so. It may be valid to find a good cert anywhere but it makes life simpler if you know of one place where the cert can always be found. (Side note: If it is reasonable to maintain a store of certificates for Diameter nodes then I would suggest doing away with security associations altogether. Diameter nodes could generate the CMS-Encrypted-Data and CMS-Signed-Data AVPs when local policy indicates end-to-end security is enabled. Receiving nodes could cache the certificate information required to interpret a sender's encrypted and signed AVPs. I suggest this because I'm concerned about Mobile Node handoffs. Mobile Node handoffs require the use of multiple DSAs. The number of message exchanges required to process the handoff request and to potentially activate DSAs is problematic. I realize that this would be a very big change and I'm just mentioning it as a passing thought because I'm concerned about the complexity of Mobile Node handoffs.) > > > I think that's sufficient reason to stick with the ABNF we've > got. > > > Stephen. > > Don Zick wrote: > > > > Glen, > > > > I'm sorry I'm not understanding your point. If Diameter nodes have their own > > certs available, why not just always stick them in the DSAR/DSAA messages so > > that they're always available when needed? What is the drawback of doing > > this? If my implementation must be able to handle DSAR/DSAA messages without > > the AAA-Node-Cert AVP then don't I have to implement a scheme for retrieving > > the certificate information elsewhere? > > > > Don > > > > Glen Zorn wrote: > > > > > Don Zick [mailto://dzick@interlinknetworks.com] writes: > > > > > > > A single occurrence of the AAA-Node-Cert AVP should be required in the > > > > DSAR and the DSAA. > > > > > > > > The Diameter CMS Security draft states (in section 3): > > > > In order to encrypt AVPs for a recipient, the originating Diameter > > > > node must have a copy of the recipient's public key. There are many > > > > well-known key retrieval schemes (e.g. LDAP [CERTLDAP]), but this > > > > specification also allows for the transportation of certificates > > > > within Diameter AVPs, which is expected to simplify implementations. > > > > > > > > If inclusion of the AAA-Node-Cert AVP is optional then the expected > > > > simplification in implementations is lost because compliant > > > > implementations must be able to handle DSAR and DSAA messages that don't > > > > include the AAA-Node-Cert AVPs. > > > > > > I disagree: compliant implementations must be able to handle DSAR and DSAA > > > messages that don't > > > include the AAA-Node-Cert AVPs, but they do _not_ have to include e.g. an > > > LDAP client and are therefore simpler. > > > > > > > > > > > Requested change: > > > > > > > > Please update the occurrence rules table and the ABNF definitions for > > > > the DSAR and DSAA to indicate that exactly 1 occurrence of the > > > > AAA-Node-Cert must be present. > > > > > > > > > > > > > > -- > ____________________________________________________________ > Stephen Farrell > Baltimore Technologies, tel: (direct line) +353 1 881 6716 > 39 Parkgate Street, fax: +353 1 881 7000 > Dublin 8. mailto:stephen.farrell@baltimore.ie > Ireland http://www.baltimore.com From owner-aaa-wg@merit.edu Tue Mar 12 16:37:32 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08763 for ; Tue, 12 Mar 2002 16:37:32 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9B06291291; Tue, 12 Mar 2002 16:37:20 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 648D591292; Tue, 12 Mar 2002 16:37:20 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6CDAE91291 for ; Tue, 12 Mar 2002 16:37:19 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4EC4D5DDED; Tue, 12 Mar 2002 16:37:19 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 3B3425DD9F for ; Tue, 12 Mar 2002 16:37:19 -0500 (EST) Received: from Interlinknetworks.com (nat.interlinknetworks.com [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with ESMTP id E71FC7B; Tue, 12 Mar 2002 16:37:18 -0500 (EST) Message-ID: <3C8E751A.6F0A5E68@Interlinknetworks.com> Date: Tue, 12 Mar 2002 16:37:30 -0500 From: David Spence Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Bernard Aboba Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Updated AAA WG issues list References: Content-Type: multipart/mixed; boundary="------------8C708CE6157027E9F943A295" Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. --------------8C708CE6157027E9F943A295 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard, Here is the disposition of the issues listed as "NASREQ Open Issues" in the latest issues list. 188 NAS-Key-Binding and Ciphersuite Negotiation This issue was listed as resolved in nasreq-08 on the 2/11 issues list. Is there some reason to believe it was not resolved? 189 NAS-Session-Key and Initialization Vectors This issue was listed as resolved in nasreq-08 on the 2/11 issues list. Is there some reason to believe it was not resolved? 190 NAS-Session-Key and Session Master Keys This issue was listed as resolved in nasreq-08 on the 2/11 issues list. Is there some reason to believe it was not resolved? 246 Accounting-*-Extended-Octets numbers are inconsistent Resolved in nasreq-09. 251 References to ADIF in NASREQ-08 Resolved in nasreq-09. 255 Translation of RADIUS vendor-specific attributes Still pending. 264 User-Name in Answer messages Resolved in nasreq-09. 293 Relax Service-Type from REQUIRED to RECOMMENDED in nasreq New issue since the 2/11 issues list. Resolved in nasreq-09. 294 NASREQ Key Distribution insecure New issue since the 2/11 issues list. Still pending. 295 More NASREQ AVPs needed New issue since the 2/11 issues list. Still pending. 297 NASREQ-specific values for Termination-Cause AVP New issue since the 2/11 issues list. Still pending. 300 EAP corner conditions New issue since the 2/11 issues list. Still pending. Bernard Aboba wrote: > > I've gone and updated the issues list. Here is the latest version: > > http://www.drizzle.com/~aboba/AAA/issues.html > > If there any issues that you believe are open that are listed as closed, > let me know. Similar, if issues listed as open are resolved, send me some > mail. > > -Bernard --------------8C708CE6157027E9F943A295 Content-Type: text/x-vcard; charset=us-ascii; name="DSpence.vcf" Content-Description: Card for David Spence Content-Disposition: attachment; filename="DSpence.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:; tel;fax:+1 734 821 1235 tel;work:+1 734 821 1203 x-mozilla-html:FALSE url:http://www.interlinknetworks.com org:Interlink Networks, Inc. adr:;;775 Technology Dr., Suite 200;Ann Arbor;MI;48108;USA version:2.1 email;internet:DSpence@Interlinknetworks.com title:Architect fn:David Spence end:vcard --------------8C708CE6157027E9F943A295-- From owner-aaa-wg@merit.edu Tue Mar 12 20:28:30 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14544 for ; Tue, 12 Mar 2002 20:28:29 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7290091296; Tue, 12 Mar 2002 20:28:18 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4A56991297; Tue, 12 Mar 2002 20:28:18 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0D98991296 for ; Tue, 12 Mar 2002 20:28:16 -0500 (EST) Received: by segue.merit.edu (Postfix) id DE7835DDA6; Tue, 12 Mar 2002 20:28:16 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by segue.merit.edu (Postfix) with ESMTP id 9580E5DDD8 for ; Tue, 12 Mar 2002 20:28:16 -0500 (EST) Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.224.157]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g2D1SFS11455; Tue, 12 Mar 2002 19:28:15 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g2D1SFp17785; Tue, 12 Mar 2002 19:28:15 -0600 (CST) Received: from qpop.exu.ericsson.se (qpop [138.85.75.72]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id TAA08721; Tue, 12 Mar 2002 19:28:14 -0600 (CST) Received: from ericsson.com ([138.85.159.114]) by qpop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id TAA00551; Tue, 12 Mar 2002 19:28:13 -0600 (CST) Message-ID: <3C8EAA92.9B99D9ED@ericsson.com> Date: Tue, 12 Mar 2002 17:25:38 -0800 From: Tony Johansson X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: David Spence Cc: aaa-wg , Bob Kopacz Subject: Re: [AAA-WG]: [issue] Need more explanation about handling MN handoffs References: <000701c1c3fc$ff09ece0$f6512844@sanarb01.mi.comcast.net> <3C8642B8.797C0D5@Interlinknetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi David and All, I see two solutions: Alt 1) Add new Mobile IPv4 subtypes, like HA-NAI, FA-NAI (by using the MIER draft). Alt 2) Or solve it without any new requirements on Mobile IPv4. Like some what the proposed below, thus require the AAAF to look up the Home Agent realm and host identity, e.g. using reverse DNS look up. The AAAF could the pass the realm and the host identity to the AAAH. I certainly agree with you that Alt 1 would be the best solution. However, I have no idea how much extra delay that would cause. So, may be the only realistic way forward, within reasonable time, is Alt 2. Comments please /Tony David Spence wrote: > I think this is a real showstopper issue. > > The problem goes to the core of how Diameter identifies nodes and does > message forwarding. In order for Diameter MobileIPv4 to support handoffs > correctly, the Diameter identities and realms of various Diameter nodes > involved in the service need to be known. To solve this issue properly, > changes may need to be made to the Mobile IPv4 protocol itself. Given the > close interdependence of Mobile IPv4 when used to support CDMA2000 and the > Diameter MobileIPv4 application, it puzzles me why "IP Mobility Support for > IPv4" (RFC 3220) was allowed to progress to Proposed Standard independently > of "Diameter Mobile IPv4 Application" > (draft-ietf-aaa-diameter-mobileip-09.txt). Nevertheless, I believe that the > only good way to solve the problems of Diameter MobileIPv4 is to add some > data elements to the Mobile IPv4 protocol itself. > > Bob Kopacz wrote: > > > > Issue : Need more explanation about handling MN handoffs > > Submitter name: Bob Kopacz > > Submitter email address:bkopacz@interlinknetworks.com > > Date first submitted: 03-04-2002 > > Reference: > > Document: draft-mobileip-09 > > Comment type: Technical > > Priority: 1 > > Section: > > > > Rationale/Explanation of issue: > > > > I may be missing something significant here, but ... > > > > This issue has to do with how an AAAF and AAAH, when given a Home > > Agent's IP address, derive the domain/realm/DiameterIdentity > > information needed by the Diameter AAA servers. > > > > This issue may also have some bearing on the relationship between a > > DiameterIdentity and a FQDN. > > > > Unfortunately I don't have a good solution to present, so I'm > > indicating what the problems are, as indicated by "-->". It may > > be that the solution is to enhance the Mobile IP protocol to > > provide more information in the Registration Request. > > > > THE AAAF's PROBLEM: > > ------------------ > > Section 1.4. Allocation of Home Agent in Foreign Network, says > > the following: > > > > > 1.4 Allocation of Home Agent in Foreign Network > > > > > > [...] > > > > > > In the event that the mobile node requests a home agent in the > > > foreign network, and the AAAF authorizes its use, the AAAF MUST set > > > the Home-Agent-In-Foreign-Network bit in the MIP-Feature-Vector AVP. > > > This could happen when the AAA request is sent to "extend" a mobile > > > node's current session. > > > > > > > -->(1) I think some text needs to be added to describe how the AAAF > > determines if the HA is in a foreign network. > > > > That is, I am guessing the method is along these lines: > > > > Suppose a MN initially connects, is allocated an HA, and later > > undergoes a handoff to a new FA and new AAAF. Depending on the MN's > > new point of attachment, the new FA and AAAF may or may not be in > > the same foreign domain as before, or the foreign domain may > > be same but the AAAFs are different, or the handoff may involve > > the same AAAF as before. > > > > In the AMR, the new AAAF is provided with the MN user's NAI and the > > HA's IP address. Say the MN user is "bob@donut.com" and the specified > > HA IP address is 1.2.3.4. > > > > The new AAAF does a reverse DNS lookup of tbe HA's IP address, > > 1.2.3.4, and the DNS response is that IP address 1.2.3.4 corresponds > > to an FQDN of "homeagent86.westcoast.spinach.com". > > > > Now the AAAF extracts the realm part of the NAI, "donut.com", and > > pre-pends a dot, coming up with ".donut.com". The AAAF then checks > > if this ".donut.com" string is a trailing substring of the > > "homeagent86.westcoast.spinach.com" FQDN. It isn't, so the AAAF > > concludes the HA is in a foreign network and sends the > > Home-Agent-In-Foreign-Network flag with a value of one. If the tail > > of the FQDN matched ".donut.com", the AAAF would conclude the HA was > > in the home network. > > > > -->(2) This may or may not be anywhere close to the AAAF's method. > > At any rate, the method should be described in sufficient detail > > for an AAAF implementation. > > > > -->(3) If this DNS reverse lookup is indeed the AAAF's method to > > make this "home-agent-is-in-a-foreign-network" determination, then > > this introduces a delay into the handoff, and should probably be > > noted. > > > > THE AAAH's PROBLEM > > ------------------ > > Section 1.2 Inter-Realm Mobile IP, says the following: > > > > > > > > 1.2 Inter-Realm Mobile IP > > > > > > [...] > > > > > > If the Mobile Node was successfully authenticated, the AAAH checks if > > > the Home Agent was located in the foreign realm, by checking the > > > Home-Agent-In-Foreign-Network flag of the MIP-Feature-Vector AVP. If > > > the flag is enabled, then the Home Agent is located in the foreign > > > realm then AAAH sends an HAR message to AAAF which contains a MIP- > > > Reg-Request AVP. > > > > Continuing the example, suppose the AAAF has determined that the > > HA is in a foreign network, and has forwarded the AMR to the home > > realm. The AAAH receives the AMR, and the AMR indicates the HA's > > address is 1.2.3.4, the Home-Agent-In-Foreign-Network flag is ON, > > and the User-Name is "bob@donut.com". > > > > -->(4) Now the AAAH wants to send an HAR to the HA. But Diameter > > routes by Destination-Realm and Destination-Host, not by IP address, > > so the AAAH has to somehow come up with the HA's DiameterIdentity > > for the Destination-Host AVP of the HAR, and the HA's realm for the > > Destination-Realm of the HAR. > > > > AAAH's 1st Problem: How to discover the HA's DiameterIdentity: > > > > If the AAAH maintains session-state, then this HA identity > > information can be part of the cached session-state information, > > and there may be no problem. But there is a problem if either > > (a) the AAAH is not session-stateful, or (b) the AAAH is > > session-stateful but has no session-state info because the handoff > > AMR is received by a different AAAH than the AAAH which received > > the original AMR for the session. > > > > So if we have case (a) or (b), the hapless AAAH is holding the HA's > > IP address, and needs to come up with the HA's realm and > > DiameterIdentity. The method might be along these lines: > > > > The AAAH can do a reverse lookup of the IP address 1.2.3.4, and > > again DNS returns an FQDN of "homeagent86.westcoast.spinach.com" > > > > *If* the DiameterIdentity is the same as the FQDN, then the AAAH > > constructs the HAR's Destination-Host = > > "homeagent86.westcoast.spinach.com". (An aside: I haven't kept up > > with the recent DiameterIdentity thread, but I thought the > > DiameterIdentity needed to be something like "FQDN+extra", so that > > multiple Diameter applications could run on the same box. In > > which case the FQDN isn't sufficient). > > > > AAAH's 2nd Problem: How to discover the HA's Realm: > > > > The AAAH still needs to derive the HAR's Destination-Realm, from > > the FQDN. The realm is probably either "westcoast.spinach.com" > > or "spinach.com". Does the AAAH have a way to know for sure, or > > is the best-guess algorithm to say that the realm is what > > follows the next-to-last dot of the FQDN, e.g. "spinach.com". > > > > -->(5) Again, this may or may not be anywhere close to what the > > AAAH needs to do to surmise the HA's realm and identity. At any > > rate, the method should be described in sufficient detail to > > implement an AAAH. > > > > -->(6) If this DNS reverse lookup is indeed part of the AAAH's > > method, then this introduces a delay (maybe a 2nd delay depending on > > what the AAAF had to do) into the handoff, and should probably be > > noted. > > > > -->(7) It seems the AAAF and AAAH are both starting from scratch > > with the HA's IP address, and duplicating efforts and delays. Maybe > > the AAAF's DNS-lookup results (or whatever useful knowledge the AAAF > > possesses) could be passed along to the AAAH. From owner-aaa-wg@merit.edu Tue Mar 12 23:05:50 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18578 for ; Tue, 12 Mar 2002 23:05:50 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 62E909126F; Tue, 12 Mar 2002 23:05:40 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2AAD791299; Tue, 12 Mar 2002 23:05:40 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C56C09126F for ; Tue, 12 Mar 2002 23:05:38 -0500 (EST) Received: by segue.merit.edu (Postfix) id A5AEB5DDA8; Tue, 12 Mar 2002 23:05:38 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by segue.merit.edu (Postfix) with ESMTP id 43D955DD90 for ; Tue, 12 Mar 2002 23:05:38 -0500 (EST) Received: from mr5.exu.ericsson.se (mr5att.ericy.com [138.85.224.141]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g2D45bS07715; Tue, 12 Mar 2002 22:05:38 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g2D45bT10972; Tue, 12 Mar 2002 22:05:37 -0600 (CST) Received: from qpop.exu.ericsson.se (qpop [138.85.75.72]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id WAA22115; Tue, 12 Mar 2002 22:05:36 -0600 (CST) Received: from ericsson.com ([138.85.159.114]) by qpop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id WAA02648; Tue, 12 Mar 2002 22:05:36 -0600 (CST) Message-ID: <3C8ECF74.CFDDDF1A@ericsson.com> Date: Tue, 12 Mar 2002 20:03:00 -0800 From: Tony Johansson X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Bob Kopacz Cc: aaa-wg Subject: [AAA-WG]: Re: [issue] Securing the AAAH-generated session keys References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Bob and All, I really need help from the working group on this one. I'm not sure how we can solve this without requiring another round trip, either based on some clever DSAA result code or with a "half-baked" HAR as describe below. Unless, we can change the functionality and say that a user can only belong in one AAAH. Then it would be possible to keep info in the AAAH about the allocated HA and AAAF for CMS encryption of the HA-MN key without any extra round trips, when the MN moves to other AAAFs and requests to keep the HA. /Tony Bob Kopacz wrote: > Issue : Securing the AAAH-generated session keys > Submitter name: Bob Kopacz > Submitter email address:bkopacz@interlinknetworks.com > Date first submitted: 03-05-2002 > Reference: > Document: draft-mobileip-09 > Comment type: Technical > Priority: 1 > Section: > > Rationale/Explanation of issue: > > The draft-mobileip-09 was updated per issue#266. Issue#266 > addressed the case where the HA was in a foreign network, the > destination AAAF generated the FA-HA key, and the destination AAAF > wanted to use CMS to return the key to the FA in a secure manner. > Because the mobility agents may not support CMS (CMS is a SHOULD for > clients but a MUST for servers), the issue#266 solution was for the > destination AAAF (i.e. the HA's AAAF) to set up a DSA with the > originating AAAF (i.e. the FA's AAAF), and to pass the CMS-encrypted > FA-HA key to the originating AAAF within a CMS-Encrypted-Data AVP. > The key is thus hidden as it traverses the home domain and any > intermediary proxy/relay AAA servers. > > Issue#266 was retricted to the case of CMS-securing the > AAAF-generated session key. There is a similar need to CMS-secure > the AAAH-generated session keys, if there are intervening proxy > networks between the home network and the mobility agent's network. > > The proposal here is for an AAAH who wants to CMS-secure its > generated session keys, to set up a DSA with the mobility agent's > local AAAF, and to pass the CMS-secured keys to the AAAF a la > issue#266. > > AAAH-generated keys destined for the FA: An AAAH-generated FA-MN key > (and maybe an AAAH-generated FA-HA key) is returned to the FA in the > AMA, which possibly traverses intermediary proxies. The AAAH can > CMS-secure these keys by setting up a DSA with the FA's local AAAF, > and passing the CMS-encrypted keys to the AAAF a la issue#266. The > AAAH knows the identity of the originating AAAF because this is > kindly provided in the AMR's MIP-Originating-Foreign-AAA AVP. > > AAAH-generated keys destined for a foreign HA: The AAAH-generated > HA-MN key is forwarded in the HAR to the HA. If the HA resides in a > foreign network, the HAR may traverse intermediary proxies, and the > AAAH may want to CMS-secure this key. Unfortunately the AAAH > doesn't necessarily know who the destination AAAF is. The problem > here is that the AAAH wants to set up the DSA before forwarding the > HAR which carries the encrypted keys. In this case, I am currently > stuck and soliciting suggestions. (One goofy notion, whose only > virtue is that it works, is this: The AAAH sends a "half-baked" HAR > which doesn't contain the keys. The AAAF receives this half-baked > HAR, extracts the AAAH's identity from the half-baked HAR, sets up a > DSA with the AAAH, who resends a fully-baked HAR with the > CMS-encrypted keys. Unfortunately, this entails another round > trip.) > > Requested change: > > In section 5.0 Key Distribution Center > > > 5.0 Key Distribution Center > > > > [...] > > > > If the AAAH does not communicate directly with the foreign agent, and > > it does not wish for intermediate proxies to have access to the > > session keys, they SHOULD be protected using the CMS security > > application [CMS]. > > Change the first sentence to : > > "If the AAAH does not communicate directly with one or both > mobility agents,..." > > - - - > > In section 5.2 Key Material vs. Session Key > > > 5.2 Key Material vs. Session Key > > > > [...] > > > > The session keys destined for mobility agents may be encoded using > > the security association available between the AAA server and the > > agents (e.g. IPSec, TLS, CMS). > > Change the above sentence to: > > "The session keys destined for mobility agents may be encoded using > the security association available between the AAA server and the > agents (e.g. IPSec, TLS, CMS), or, if the AAAH suspects a foreign > mobility agent doesn't support CMS, by using the security > association available between the AAAH and the AAA server hosting > the mobility agent." > > - - - > > In section 5.3 Distributing the Mobile-Home Session Key > > > 5.3 Distributing the Mobile-Home Session Key > > > > [Need some text here to address the case where the HA is in a foreign > network, the HA doesn't support CMS, and the AAAH wants to set up a > DSA with the destination AAAF, and pass the CMS-encrypted HA-MN key > to the destination AAAF.] > > - - - > > In section 5.4 Distributing the Mobile-Foreign Session Key > > > 5.4 Distributing the Mobile-Foreign Session Key > > > > The Mobile-Foreign session key material is also generated by AAAH > > (upon request) and is added to the MIP-MN-to-FA-Key AVP, which is > > added to the HAR, and copied by the home agent into a Generalized MN- > > FA Key Reply Extension [MIPKEYS] to the Mobile IP Registration Reply > > message, using the SPI proposed by the Mobile Node in the MN-FA Key > > Request From AAA Subtype extension. Further, the home agent includes > > the SPI in the HAA's MIP-FA-to-MN-SPI AVP. The AAAH includes the > > session key in the MIP-FA-to-MN-Key AVP in the HAA, which contains > > the session key used by the foreign agent in the computation of the > > Mobile-Foreign authentication extension. > > > > Upon receipt of the HAA, the Diameter server responsible for key > > allocation creates the MIP-FA-to-HA Key AVP, using the SPI in the > > MIP-FA-to-HA-SPI. If the key is generated at the AAAF (home agent in > > foreign domain), it adds the MIP-FA-to-HA Key AVP to the HAA and > > sends it to the AAAH. Depending upon where the HA was located the > > AAAH either generates the MIP-FA-to-HA Key AVP itself or extracts the > > AVP from the HAA sent by the AAAF. The AAAH adds the MIP-FA-to-HA Key > > to the AMA. If the MIP-FA-to-MN-Key AVP was present in the AMA, the > > foreign agent MUST include the Mobile-Foreign authentication > > extension in the Registration Reply, using the newly distributed key. > > Append the following paragraph: > > "If the AAAH is returning an FA-HA or FA-MN key to the FA, and the > AAAH wants to secure these keys because the originating AAAF is not > a peer (there are intermediate proxies), the AAAH first sets up a > DSA with the originating AAAF, and passes the FA's key(s) within a > CMS-Encrypted-Data AVP in the AMA." From owner-aaa-wg@merit.edu Wed Mar 13 06:33:31 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02543 for ; Wed, 13 Mar 2002 06:33:31 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1836E912A0; Wed, 13 Mar 2002 06:32:46 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D1DA19129F; Wed, 13 Mar 2002 06:32:45 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B39679129E for ; Wed, 13 Mar 2002 06:32:44 -0500 (EST) Received: by segue.merit.edu (Postfix) id 948FF5DE10; Wed, 13 Mar 2002 06:32:44 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by segue.merit.edu (Postfix) with ESMTP id AC0AA5DD8C for ; Wed, 13 Mar 2002 06:32:43 -0500 (EST) Received: from ipunplugged.com (catsandlogs.local.ipunplugged.com [192.168.4.29]) by mailgw.ipunplugged.com (8.9.3/8.9.3) with ESMTP id MAA18193; Wed, 13 Mar 2002 12:30:05 +0100 Message-ID: <3C8F46C3.9070802@ipunplugged.com> Date: Wed, 13 Mar 2002 13:32:03 +0100 From: Johan Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020204 X-Accept-Language: en-us MIME-Version: 1.0 To: Tony Johansson Cc: AAA Working Group , sramam@cup.hp.com, fredrik.johansson@ipunplugged.com Subject: Re: [AAA-WG]: [issue] Session-Timeout vs Authorization-Lifetime vs MIP-Key-Lifetime References: <3C8D185C.30003@ipunplugged.com> <3C8E53E1.B8D86E1F@ericsson.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit I would prefer if you also added an explicit note that Session-Timeout does not apply to the Diameter Mobile IP application, but if you really don't like it that's acceptable too since that information is implicit in the fact that the avp is disallowed in the messages. But why not be as clear as possible? j Tony Johansson wrote: >All, > >I would like to close this issue with the following changes: > >Remove the Session-Timeout AVP form the occurrence rules table and from the >ABNFs in the AMA and HAR. > >Comments / objections? > >/Tony > >Johan Johansson wrote: > >>Subject: [issue] Session-Timeout vs Authorization-Lifetime vs >>MIP-Key-Lifetime >> >>Submitter name: Johan Johansson >>Submitter email address: johanj@ipunplugged.com >>Date first submitted: March 11, 2002 >>Reference: >>Document: Mobile IP >>Comment type: T >>Priority: 1 >>Section: 2.2, 2.3, 5.1, 8.1 >>Rationale/Explanation of issue: >> >>If there is to be any hope for interoperability the use of >>Session-Timeout must be defined in the MIP draft. >> >>The base draft defines Session-Timeout as >> >>8.13 Session-Timeout AVP >> >> The Session-Timeout AVP (AVP Code 27) [RADIUS] is of type Unsigned32 >> and contains the maximum number of seconds of service to be provided >> to the user before termination of the session. When both the Session- >> Timeout and the Authorization-Lifetime AVPs are present in an answer >> message, the former MUST be equal to or greater than the value of the >> latter. >> >>--- >> >> A Session-Timeout AVP MAY be present in a re-authorization message, >> and contains the number of seconds from the beginning of the re-auth. >> >> A value of zero, or the absence of this AVP, means that this session >> has an unlimited number of seconds before termination. >> >>Section 8.9 of the base draft has this to say about Authorization-Lifetime: >> >>An Authorization-Lifetime AVP MAY be present in re-authorization >> messages, and contains the number of seconds the user is authorized >> to receive service from the time the re-auth answer message is >> received by the access device. >> >>The MIP draft contains no references to Session-Timeout beyond the >>occurence rules and the ABNFs and they are contradictory. >> >>The occurence rules of the MIP draft states >> >> +-----------------------+ >> | Command-Code | >> |-----+-----+-----+-----+ >> Attribute Name | AMR | AMA | HAR | HAA | >> ------------------------------|-----+-----+-----+-----+ >> Session-Timeout | 0 | 1 | 1 | 0 | >> >>The ABNFs for AMA and HAR list it as optional. Looking solely at the >>base draft the ABNF would seem to be correct. >> >>But this still does not settle the issue of the semantics of its >>presence. Section 5.1 of the mip draft states >> >> The Diameter Mobile IP application makes use of two timers - the >> Authorization-Lifetime AVP [DIAMBASE] and the MIP-Key-Lifetime AVP. >> >> The Authorization-Lifetime contains the number of seconds before the >> Mobile Node must issue a subsequent MIP registration request. The >> content of the Authorization-Lifetime AVP corresponds to the Lifetime >> field in the MIP header [MOBILEIP]. >> >> The MIP-Key-Lifetime AVP contains the number of seconds before >> session keys destined for the Mobility Agents and the Mobile Node >> expire. A value of zero indicates infinity (no timeout). If not zero, >> the value of the MIP-Key-Lifetime AVP MUST be at least equal to the >> value in the Authorization Lifetime AVP. >> >>If the application doesn't use Session-Timeout it should not be optional >>or mandatory but banned. The section quoted above inevitably leads to >>the the termination of the user session after at least >>Authorization-Lifetime seconds and at most Authorization-Lifetime + >>MIP-Key-Lifetime seconds. >> >>Requested change: >> >>Remove Session-Timeout from AMA and HAR. >> >>Modify the first paragraph of section 5.1 to: >> >>The Diameter Mobile IP application makes use of two timers - the >>Authorization-Lifetime AVP [DIAMBASE] and the MIP-Key-Lifetime AVP. The >>Session-Timeout AVP [DIAMBASE] does not apply to this application. >> >>j >> > From owner-aaa-wg@merit.edu Wed Mar 13 14:01:38 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15166 for ; Wed, 13 Mar 2002 14:01:37 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 336DD91233; Wed, 13 Mar 2002 14:00:58 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F387C9123D; Wed, 13 Mar 2002 14:00:57 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 03CA891233 for ; Wed, 13 Mar 2002 14:00:56 -0500 (EST) Received: by segue.merit.edu (Postfix) id CE8AC5DE2A; Wed, 13 Mar 2002 14:00:56 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id B0B625DDC1 for ; Wed, 13 Mar 2002 14:00:56 -0500 (EST) Received: from Interlinknetworks.com (nat.interlinknetworks.com [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with ESMTP id 791A97F; Wed, 13 Mar 2002 14:00:56 -0500 (EST) Message-ID: <3C8FA1F5.6170F353@Interlinknetworks.com> Date: Wed, 13 Mar 2002 14:01:09 -0500 From: David Spence Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Tony Johansson Cc: aaa-wg , Bob Kopacz Subject: Re: [AAA-WG]: [issue] Need more explanation about handling MN handoffs References: <000701c1c3fc$ff09ece0$f6512844@sanarb01.mi.comcast.net> <3C8642B8.797C0D5@Interlinknetworks.com> <3C8EAA92.9B99D9ED@ericsson.com> Content-Type: multipart/mixed; boundary="------------A6785EEE497C205513FA6DB5" Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. --------------A6785EEE497C205513FA6DB5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I just don't know if alt 2 really works. You can map an IP address to a host name, but you have no assurance that the host name it maps to is a Diameter identity. There may be multiple host names that map to the IP address, and if so, how can you tell which one is the Diameter identity you're looking for? Further, even if you could determine the Diameter identity, there is no general algorithm for extracting the realm from it. That is why Diameter has both host name and realm AVPs. If we need to do something quickly in order to get a PS out, perhaps we could admit that the PS doesn't adequately address all the issues involved with supporting an HA in the foreign network and defer a thoughtful solution to some of these issues until after the PS is submitted. Tony Johansson wrote: > > Hi David and All, > > I see two solutions: > > Alt 1) Add new Mobile IPv4 subtypes, like HA-NAI, FA-NAI (by using the MIER > draft). > > Alt 2) Or solve it without any new requirements on Mobile IPv4. Like some what > the proposed below, thus require the AAAF to look up the Home Agent realm and > host identity, e.g. using reverse DNS look up. The AAAF could the pass the realm > and the host identity to the AAAH. > > I certainly agree with you that Alt 1 would be the best solution. However, I have > no idea how much extra delay that would cause. So, may be the only realistic way > forward, within reasonable time, is Alt 2. > > Comments please > > /Tony > > David Spence wrote: > > > I think this is a real showstopper issue. > > > > The problem goes to the core of how Diameter identifies nodes and does > > message forwarding. In order for Diameter MobileIPv4 to support handoffs > > correctly, the Diameter identities and realms of various Diameter nodes > > involved in the service need to be known. To solve this issue properly, > > changes may need to be made to the Mobile IPv4 protocol itself. Given the > > close interdependence of Mobile IPv4 when used to support CDMA2000 and the > > Diameter MobileIPv4 application, it puzzles me why "IP Mobility Support for > > IPv4" (RFC 3220) was allowed to progress to Proposed Standard independently > > of "Diameter Mobile IPv4 Application" > > (draft-ietf-aaa-diameter-mobileip-09.txt). Nevertheless, I believe that the > > only good way to solve the problems of Diameter MobileIPv4 is to add some > > data elements to the Mobile IPv4 protocol itself. > > > > Bob Kopacz wrote: > > > > > > Issue : Need more explanation about handling MN handoffs > > > Submitter name: Bob Kopacz > > > Submitter email address:bkopacz@interlinknetworks.com > > > Date first submitted: 03-04-2002 > > > Reference: > > > Document: draft-mobileip-09 > > > Comment type: Technical > > > Priority: 1 > > > Section: > > > > > > Rationale/Explanation of issue: > > > > > > I may be missing something significant here, but ... > > > > > > This issue has to do with how an AAAF and AAAH, when given a Home > > > Agent's IP address, derive the domain/realm/DiameterIdentity > > > information needed by the Diameter AAA servers. > > > > > > This issue may also have some bearing on the relationship between a > > > DiameterIdentity and a FQDN. > > > > > > Unfortunately I don't have a good solution to present, so I'm > > > indicating what the problems are, as indicated by "-->". It may > > > be that the solution is to enhance the Mobile IP protocol to > > > provide more information in the Registration Request. > > > > > > THE AAAF's PROBLEM: > > > ------------------ > > > Section 1.4. Allocation of Home Agent in Foreign Network, says > > > the following: > > > > > > > 1.4 Allocation of Home Agent in Foreign Network > > > > > > > > [...] > > > > > > > > In the event that the mobile node requests a home agent in the > > > > foreign network, and the AAAF authorizes its use, the AAAF MUST set > > > > the Home-Agent-In-Foreign-Network bit in the MIP-Feature-Vector AVP. > > > > This could happen when the AAA request is sent to "extend" a mobile > > > > node's current session. > > > > > > > > > > -->(1) I think some text needs to be added to describe how the AAAF > > > determines if the HA is in a foreign network. > > > > > > That is, I am guessing the method is along these lines: > > > > > > Suppose a MN initially connects, is allocated an HA, and later > > > undergoes a handoff to a new FA and new AAAF. Depending on the MN's > > > new point of attachment, the new FA and AAAF may or may not be in > > > the same foreign domain as before, or the foreign domain may > > > be same but the AAAFs are different, or the handoff may involve > > > the same AAAF as before. > > > > > > In the AMR, the new AAAF is provided with the MN user's NAI and the > > > HA's IP address. Say the MN user is "bob@donut.com" and the specified > > > HA IP address is 1.2.3.4. > > > > > > The new AAAF does a reverse DNS lookup of tbe HA's IP address, > > > 1.2.3.4, and the DNS response is that IP address 1.2.3.4 corresponds > > > to an FQDN of "homeagent86.westcoast.spinach.com". > > > > > > Now the AAAF extracts the realm part of the NAI, "donut.com", and > > > pre-pends a dot, coming up with ".donut.com". The AAAF then checks > > > if this ".donut.com" string is a trailing substring of the > > > "homeagent86.westcoast.spinach.com" FQDN. It isn't, so the AAAF > > > concludes the HA is in a foreign network and sends the > > > Home-Agent-In-Foreign-Network flag with a value of one. If the tail > > > of the FQDN matched ".donut.com", the AAAF would conclude the HA was > > > in the home network. > > > > > > -->(2) This may or may not be anywhere close to the AAAF's method. > > > At any rate, the method should be described in sufficient detail > > > for an AAAF implementation. > > > > > > -->(3) If this DNS reverse lookup is indeed the AAAF's method to > > > make this "home-agent-is-in-a-foreign-network" determination, then > > > this introduces a delay into the handoff, and should probably be > > > noted. > > > > > > THE AAAH's PROBLEM > > > ------------------ > > > Section 1.2 Inter-Realm Mobile IP, says the following: > > > > > > > > > > > 1.2 Inter-Realm Mobile IP > > > > > > > > [...] > > > > > > > > If the Mobile Node was successfully authenticated, the AAAH checks if > > > > the Home Agent was located in the foreign realm, by checking the > > > > Home-Agent-In-Foreign-Network flag of the MIP-Feature-Vector AVP. If > > > > the flag is enabled, then the Home Agent is located in the foreign > > > > realm then AAAH sends an HAR message to AAAF which contains a MIP- > > > > Reg-Request AVP. > > > > > > Continuing the example, suppose the AAAF has determined that the > > > HA is in a foreign network, and has forwarded the AMR to the home > > > realm. The AAAH receives the AMR, and the AMR indicates the HA's > > > address is 1.2.3.4, the Home-Agent-In-Foreign-Network flag is ON, > > > and the User-Name is "bob@donut.com". > > > > > > -->(4) Now the AAAH wants to send an HAR to the HA. But Diameter > > > routes by Destination-Realm and Destination-Host, not by IP address, > > > so the AAAH has to somehow come up with the HA's DiameterIdentity > > > for the Destination-Host AVP of the HAR, and the HA's realm for the > > > Destination-Realm of the HAR. > > > > > > AAAH's 1st Problem: How to discover the HA's DiameterIdentity: > > > > > > If the AAAH maintains session-state, then this HA identity > > > information can be part of the cached session-state information, > > > and there may be no problem. But there is a problem if either > > > (a) the AAAH is not session-stateful, or (b) the AAAH is > > > session-stateful but has no session-state info because the handoff > > > AMR is received by a different AAAH than the AAAH which received > > > the original AMR for the session. > > > > > > So if we have case (a) or (b), the hapless AAAH is holding the HA's > > > IP address, and needs to come up with the HA's realm and > > > DiameterIdentity. The method might be along these lines: > > > > > > The AAAH can do a reverse lookup of the IP address 1.2.3.4, and > > > again DNS returns an FQDN of "homeagent86.westcoast.spinach.com" > > > > > > *If* the DiameterIdentity is the same as the FQDN, then the AAAH > > > constructs the HAR's Destination-Host = > > > "homeagent86.westcoast.spinach.com". (An aside: I haven't kept up > > > with the recent DiameterIdentity thread, but I thought the > > > DiameterIdentity needed to be something like "FQDN+extra", so that > > > multiple Diameter applications could run on the same box. In > > > which case the FQDN isn't sufficient). > > > > > > AAAH's 2nd Problem: How to discover the HA's Realm: > > > > > > The AAAH still needs to derive the HAR's Destination-Realm, from > > > the FQDN. The realm is probably either "westcoast.spinach.com" > > > or "spinach.com". Does the AAAH have a way to know for sure, or > > > is the best-guess algorithm to say that the realm is what > > > follows the next-to-last dot of the FQDN, e.g. "spinach.com". > > > > > > -->(5) Again, this may or may not be anywhere close to what the > > > AAAH needs to do to surmise the HA's realm and identity. At any > > > rate, the method should be described in sufficient detail to > > > implement an AAAH. > > > > > > -->(6) If this DNS reverse lookup is indeed part of the AAAH's > > > method, then this introduces a delay (maybe a 2nd delay depending on > > > what the AAAF had to do) into the handoff, and should probably be > > > noted. > > > > > > -->(7) It seems the AAAF and AAAH are both starting from scratch > > > with the HA's IP address, and duplicating efforts and delays. Maybe > > > the AAAF's DNS-lookup results (or whatever useful knowledge the AAAF > > > possesses) could be passed along to the AAAH. --------------A6785EEE497C205513FA6DB5 Content-Type: text/x-vcard; charset=us-ascii; name="DSpence.vcf" Content-Description: Card for David Spence Content-Disposition: attachment; filename="DSpence.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:; tel;fax:+1 734 821 1235 tel;work:+1 734 821 1203 x-mozilla-html:FALSE url:http://www.interlinknetworks.com org:Interlink Networks, Inc. adr:;;775 Technology Dr., Suite 200;Ann Arbor;MI;48108;USA version:2.1 email;internet:DSpence@Interlinknetworks.com title:Architect fn:David Spence end:vcard --------------A6785EEE497C205513FA6DB5-- From owner-aaa-wg@merit.edu Wed Mar 13 15:40:01 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18659 for ; Wed, 13 Mar 2002 15:40:01 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 8CFE091245; Wed, 13 Mar 2002 15:39:46 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 56C219125B; Wed, 13 Mar 2002 15:39:46 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2802291245 for ; Wed, 13 Mar 2002 15:39:45 -0500 (EST) Received: by segue.merit.edu (Postfix) id 06A845DD9E; Wed, 13 Mar 2002 15:39:45 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from imr1.ericy.com (unknown [208.237.135.240]) by segue.merit.edu (Postfix) with ESMTP id 7D5855DD9A for ; Wed, 13 Mar 2002 15:39:44 -0500 (EST) Received: from mr6.exu.ericsson.se (mr6u3.ericy.com [208.237.135.123]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g2DKcGh09290; Wed, 13 Mar 2002 14:38:16 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g2DKcGT11600; Wed, 13 Mar 2002 14:38:16 -0600 (CST) Received: from qpop.exu.ericsson.se (qpop [138.85.75.72]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id OAA27932; Wed, 13 Mar 2002 14:38:15 -0600 (CST) Received: from ericsson.com ([138.85.159.114]) by qpop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id OAA14092; Wed, 13 Mar 2002 14:38:14 -0600 (CST) Message-ID: <3C8FB819.4E884248@ericsson.com> Date: Wed, 13 Mar 2002 12:35:37 -0800 From: Tony Johansson X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: David Spence Cc: aaa-wg , Bob Kopacz Subject: Re: [AAA-WG]: [issue] Need more explanation about handling MN handoffs References: <000701c1c3fc$ff09ece0$f6512844@sanarb01.mi.comcast.net> <3C8642B8.797C0D5@Interlinknetworks.com> <3C8EAA92.9B99D9ED@ericsson.com> <3C8FA1F5.6170F353@Interlinknetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi David, David Spence wrote: > I just don't know if alt 2 really works. You can map an IP address to a > host name, but you have no assurance that the host name it maps to is a > Diameter identity. Why not ? The Diameter identity is a FQDN, which can you can map an IP address to. Right ?! from base-10: "The DiameterIdentity format is derived from the OctetString AVP Base Format. It uses the UTF-8 encoding and has the same requirements as the UTF8String: DiameterIdentity = fqdn A Diameter node must be uniquely identified by its DiameterIdentity, which contains the fqdn of the Diameter node. If multiple Diameter nodes run on the same host, each Diameter node MUST be assigned a unique DiameterIdentity. If a Diameter node can be identified by several FQDNs, one single FQDN should be picked at startup, and used as the only DiameterIdentity for that node, whatever the connection it is sent on. TheDiameterIdentity value is used to uniquely identify a Diameter node for purposes of duplicate connection and routing loop detection." So, from Bob's example below you would be able to get the fqdn host name from a reverse DNS loop up, i.e. "homeagent86.westcoast.spinach.com", which you then can use to create the Destination-Host AVP = homeagent86.westcoast.spinach.com and the Destination-Realm AVP = westcoast.spinach.com, since the lookup is based on longest-match-from-the-right. Right? /Tony > There may be multiple host names that map to the IP > address, and if so, how can you tell which one is the Diameter identity > you're looking for? Further, even if you could determine the Diameter > identity, there is no general algorithm for extracting the realm from it. > That is why Diameter has both host name and realm AVPs. > > If we need to do something quickly in order to get a PS out, perhaps we > could admit that the PS doesn't adequately address all the issues involved > with supporting an HA in the foreign network and defer a thoughtful solution > to some of these issues until after the PS is submitted. > > Tony Johansson wrote: > > > > Hi David and All, > > > > I see two solutions: > > > > Alt 1) Add new Mobile IPv4 subtypes, like HA-NAI, FA-NAI (by using the MIER > > draft). > > > > Alt 2) Or solve it without any new requirements on Mobile IPv4. Like some what > > the proposed below, thus require the AAAF to look up the Home Agent realm and > > host identity, e.g. using reverse DNS look up. The AAAF could the pass the realm > > and the host identity to the AAAH. > > > > I certainly agree with you that Alt 1 would be the best solution. However, I have > > no idea how much extra delay that would cause. So, may be the only realistic way > > forward, within reasonable time, is Alt 2. > > > > Comments please > > > > /Tony > > > > David Spence wrote: > > > > > I think this is a real showstopper issue. > > > > > > The problem goes to the core of how Diameter identifies nodes and does > > > message forwarding. In order for Diameter MobileIPv4 to support handoffs > > > correctly, the Diameter identities and realms of various Diameter nodes > > > involved in the service need to be known. To solve this issue properly, > > > changes may need to be made to the Mobile IPv4 protocol itself. Given the > > > close interdependence of Mobile IPv4 when used to support CDMA2000 and the > > > Diameter MobileIPv4 application, it puzzles me why "IP Mobility Support for > > > IPv4" (RFC 3220) was allowed to progress to Proposed Standard independently > > > of "Diameter Mobile IPv4 Application" > > > (draft-ietf-aaa-diameter-mobileip-09.txt). Nevertheless, I believe that the > > > only good way to solve the problems of Diameter MobileIPv4 is to add some > > > data elements to the Mobile IPv4 protocol itself. > > > > > > Bob Kopacz wrote: > > > > > > > > Issue : Need more explanation about handling MN handoffs > > > > Submitter name: Bob Kopacz > > > > Submitter email address:bkopacz@interlinknetworks.com > > > > Date first submitted: 03-04-2002 > > > > Reference: > > > > Document: draft-mobileip-09 > > > > Comment type: Technical > > > > Priority: 1 > > > > Section: > > > > > > > > Rationale/Explanation of issue: > > > > > > > > I may be missing something significant here, but ... > > > > > > > > This issue has to do with how an AAAF and AAAH, when given a Home > > > > Agent's IP address, derive the domain/realm/DiameterIdentity > > > > information needed by the Diameter AAA servers. > > > > > > > > This issue may also have some bearing on the relationship between a > > > > DiameterIdentity and a FQDN. > > > > > > > > Unfortunately I don't have a good solution to present, so I'm > > > > indicating what the problems are, as indicated by "-->". It may > > > > be that the solution is to enhance the Mobile IP protocol to > > > > provide more information in the Registration Request. > > > > > > > > THE AAAF's PROBLEM: > > > > ------------------ > > > > Section 1.4. Allocation of Home Agent in Foreign Network, says > > > > the following: > > > > > > > > > 1.4 Allocation of Home Agent in Foreign Network > > > > > > > > > > [...] > > > > > > > > > > In the event that the mobile node requests a home agent in the > > > > > foreign network, and the AAAF authorizes its use, the AAAF MUST set > > > > > the Home-Agent-In-Foreign-Network bit in the MIP-Feature-Vector AVP. > > > > > This could happen when the AAA request is sent to "extend" a mobile > > > > > node's current session. > > > > > > > > > > > > > -->(1) I think some text needs to be added to describe how the AAAF > > > > determines if the HA is in a foreign network. > > > > > > > > That is, I am guessing the method is along these lines: > > > > > > > > Suppose a MN initially connects, is allocated an HA, and later > > > > undergoes a handoff to a new FA and new AAAF. Depending on the MN's > > > > new point of attachment, the new FA and AAAF may or may not be in > > > > the same foreign domain as before, or the foreign domain may > > > > be same but the AAAFs are different, or the handoff may involve > > > > the same AAAF as before. > > > > > > > > In the AMR, the new AAAF is provided with the MN user's NAI and the > > > > HA's IP address. Say the MN user is "bob@donut.com" and the specified > > > > HA IP address is 1.2.3.4. > > > > > > > > The new AAAF does a reverse DNS lookup of tbe HA's IP address, > > > > 1.2.3.4, and the DNS response is that IP address 1.2.3.4 corresponds > > > > to an FQDN of "homeagent86.westcoast.spinach.com". > > > > > > > > Now the AAAF extracts the realm part of the NAI, "donut.com", and > > > > pre-pends a dot, coming up with ".donut.com". The AAAF then checks > > > > if this ".donut.com" string is a trailing substring of the > > > > "homeagent86.westcoast.spinach.com" FQDN. It isn't, so the AAAF > > > > concludes the HA is in a foreign network and sends the > > > > Home-Agent-In-Foreign-Network flag with a value of one. If the tail > > > > of the FQDN matched ".donut.com", the AAAF would conclude the HA was > > > > in the home network. > > > > > > > > -->(2) This may or may not be anywhere close to the AAAF's method. > > > > At any rate, the method should be described in sufficient detail > > > > for an AAAF implementation. > > > > > > > > -->(3) If this DNS reverse lookup is indeed the AAAF's method to > > > > make this "home-agent-is-in-a-foreign-network" determination, then > > > > this introduces a delay into the handoff, and should probably be > > > > noted. > > > > > > > > THE AAAH's PROBLEM > > > > ------------------ > > > > Section 1.2 Inter-Realm Mobile IP, says the following: > > > > > > > > > > > > > > 1.2 Inter-Realm Mobile IP > > > > > > > > > > [...] > > > > > > > > > > If the Mobile Node was successfully authenticated, the AAAH checks if > > > > > the Home Agent was located in the foreign realm, by checking the > > > > > Home-Agent-In-Foreign-Network flag of the MIP-Feature-Vector AVP. If > > > > > the flag is enabled, then the Home Agent is located in the foreign > > > > > realm then AAAH sends an HAR message to AAAF which contains a MIP- > > > > > Reg-Request AVP. > > > > > > > > Continuing the example, suppose the AAAF has determined that the > > > > HA is in a foreign network, and has forwarded the AMR to the home > > > > realm. The AAAH receives the AMR, and the AMR indicates the HA's > > > > address is 1.2.3.4, the Home-Agent-In-Foreign-Network flag is ON, > > > > and the User-Name is "bob@donut.com". > > > > > > > > -->(4) Now the AAAH wants to send an HAR to the HA. But Diameter > > > > routes by Destination-Realm and Destination-Host, not by IP address, > > > > so the AAAH has to somehow come up with the HA's DiameterIdentity > > > > for the Destination-Host AVP of the HAR, and the HA's realm for the > > > > Destination-Realm of the HAR. > > > > > > > > AAAH's 1st Problem: How to discover the HA's DiameterIdentity: > > > > > > > > If the AAAH maintains session-state, then this HA identity > > > > information can be part of the cached session-state information, > > > > and there may be no problem. But there is a problem if either > > > > (a) the AAAH is not session-stateful, or (b) the AAAH is > > > > session-stateful but has no session-state info because the handoff > > > > AMR is received by a different AAAH than the AAAH which received > > > > the original AMR for the session. > > > > > > > > So if we have case (a) or (b), the hapless AAAH is holding the HA's > > > > IP address, and needs to come up with the HA's realm and > > > > DiameterIdentity. The method might be along these lines: > > > > > > > > The AAAH can do a reverse lookup of the IP address 1.2.3.4, and > > > > again DNS returns an FQDN of "homeagent86.westcoast.spinach.com" > > > > > > > > *If* the DiameterIdentity is the same as the FQDN, then the AAAH > > > > constructs the HAR's Destination-Host = > > > > "homeagent86.westcoast.spinach.com". (An aside: I haven't kept up > > > > with the recent DiameterIdentity thread, but I thought the > > > > DiameterIdentity needed to be something like "FQDN+extra", so that > > > > multiple Diameter applications could run on the same box. In > > > > which case the FQDN isn't sufficient). > > > > > > > > AAAH's 2nd Problem: How to discover the HA's Realm: > > > > > > > > The AAAH still needs to derive the HAR's Destination-Realm, from > > > > the FQDN. The realm is probably either "westcoast.spinach.com" > > > > or "spinach.com". Does the AAAH have a way to know for sure, or > > > > is the best-guess algorithm to say that the realm is what > > > > follows the next-to-last dot of the FQDN, e.g. "spinach.com". > > > > > > > > -->(5) Again, this may or may not be anywhere close to what the > > > > AAAH needs to do to surmise the HA's realm and identity. At any > > > > rate, the method should be described in sufficient detail to > > > > implement an AAAH. > > > > > > > > -->(6) If this DNS reverse lookup is indeed part of the AAAH's > > > > method, then this introduces a delay (maybe a 2nd delay depending on > > > > what the AAAF had to do) into the handoff, and should probably be > > > > noted. > > > > > > > > -->(7) It seems the AAAF and AAAH are both starting from scratch > > > > with the HA's IP address, and duplicating efforts and delays. Maybe > > > > the AAAF's DNS-lookup results (or whatever useful knowledge the AAAF > > > > possesses) could be passed along to the AAAH. From owner-aaa-wg@merit.edu Wed Mar 13 16:31:45 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20226 for ; Wed, 13 Mar 2002 16:31:45 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 08E1F912A8; Wed, 13 Mar 2002 16:29:51 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B5F85912A7; Wed, 13 Mar 2002 16:29:50 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3391991283 for ; Wed, 13 Mar 2002 16:29:47 -0500 (EST) Received: by segue.merit.edu (Postfix) id 152525DDC1; Wed, 13 Mar 2002 16:29:47 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from fep01-svc.swip.net (fep01.swip.net [130.244.199.129]) by segue.merit.edu (Postfix) with ESMTP id 3D14B5DD9A for ; Wed, 13 Mar 2002 16:29:46 -0500 (EST) Received: from ipunplugged.com ([213.100.60.194]) by fep01-svc.swip.net with ESMTP id <20020313212926.IMDC28449.fep01-svc.swip.net@ipunplugged.com>; Wed, 13 Mar 2002 22:29:26 +0100 Message-ID: <3C8FC4EA.5050206@ipunplugged.com> Date: Wed, 13 Mar 2002 22:30:18 +0100 From: Johan Johansson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.8+) Gecko/20020202 X-Accept-Language: en-us MIME-Version: 1.0 To: Tony Johansson Cc: David Spence , aaa-wg , Bob Kopacz Subject: Re: [AAA-WG]: [issue] Need more explanation about handling MN handoffs References: <000701c1c3fc$ff09ece0$f6512844@sanarb01.mi.comcast.net> <3C8642B8.797C0D5@Interlinknetworks.com> <3C8EAA92.9B99D9ED@ericsson.com> <3C8FA1F5.6170F353@Interlinknetworks.com> <3C8FB819.4E884248@ericsson.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Tony Johansson wrote: >>I just don't know if alt 2 really works. You can map an IP address to a >>host name, but you have no assurance that the host name it maps to is a >>Diameter identity. >> > >Why not ? The Diameter identity is a FQDN, which can you can map an IP address to. >Right ?! > Yes, but the problem is in the other direction. To put it in mathematical terms: the mapping from FQDN to IP address is not injective and thus can not be inverted. In other words, which of the possible 3 FQDNs for IP address X is the correct identity? j From owner-aaa-wg@merit.edu Wed Mar 13 16:48:15 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20808 for ; Wed, 13 Mar 2002 16:48:15 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 502E391286; Wed, 13 Mar 2002 16:48:06 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1DEBB91295; Wed, 13 Mar 2002 16:48:06 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1853591286 for ; Wed, 13 Mar 2002 16:47:54 -0500 (EST) Received: by segue.merit.edu (Postfix) id E194D5DDBC; Wed, 13 Mar 2002 16:47:53 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by segue.merit.edu (Postfix) with ESMTP id 7BBFE5DD9A for ; Wed, 13 Mar 2002 16:47:53 -0500 (EST) Received: from mr5.exu.ericsson.se (mr5att.ericy.com [138.85.224.141]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g2DLlpS15244; Wed, 13 Mar 2002 15:47:51 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g2DLlpG20425; Wed, 13 Mar 2002 15:47:51 -0600 (CST) Received: from qpop.exu.ericsson.se (qpop [138.85.75.72]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id PAA05063; Wed, 13 Mar 2002 15:47:50 -0600 (CST) Received: from ericsson.com ([138.85.159.114]) by qpop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id PAA15219; Wed, 13 Mar 2002 15:47:49 -0600 (CST) Message-ID: <3C8FC868.97F69394@ericsson.com> Date: Wed, 13 Mar 2002 13:45:12 -0800 From: Tony Johansson X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Johan Johansson Cc: David Spence , aaa-wg , Bob Kopacz Subject: Re: [AAA-WG]: [issue] Need more explanation about handling MN handoffs References: <000701c1c3fc$ff09ece0$f6512844@sanarb01.mi.comcast.net> <3C8642B8.797C0D5@Interlinknetworks.com> <3C8EAA92.9B99D9ED@ericsson.com> <3C8FA1F5.6170F353@Interlinknetworks.com> <3C8FB819.4E884248@ericsson.com> <3C8FC4EA.5050206@ipunplugged.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Johan Johansson wrote: > Tony Johansson wrote: > > >>I just don't know if alt 2 really works. You can map an IP address to a > >>host name, but you have no assurance that the host name it maps to is a > >>Diameter identity. > >> > > > >Why not ? The Diameter identity is a FQDN, which can you can map an IP address to. > >Right ?! > > > Yes, but the problem is in the other direction. > > To put it in mathematical terms: the mapping from FQDN to IP address is > not injective and thus can not be inverted. In other words, which of the > possible 3 FQDNs for IP address X is the correct identity? Okay, but will somebody actually need 3 different FQDNs for the same IP address?! At least, I don't see why we would need multiple FQDNs to the same IP address in an HA. So, how about adding a statement in the MIP-09 that you can only have one FQDN per IP address in an HA. Would that be okay? /Tony > > > j From owner-aaa-wg@merit.edu Wed Mar 13 16:53:37 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20990 for ; Wed, 13 Mar 2002 16:53:36 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 33E7391295; Wed, 13 Mar 2002 16:53:16 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 037D2912A2; Wed, 13 Mar 2002 16:53:15 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id EFB6891295 for ; Wed, 13 Mar 2002 16:53:14 -0500 (EST) Received: by segue.merit.edu (Postfix) id D2F985DDBC; Wed, 13 Mar 2002 16:53:14 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by segue.merit.edu (Postfix) with ESMTP id E847D5DD9A for ; Wed, 13 Mar 2002 16:53:13 -0500 (EST) Received: from JSCHNIZL-W2K1.cisco.com (rtp-vpn1-32.cisco.com [10.82.224.32]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id NAA22877; Wed, 13 Mar 2002 13:53:09 -0800 (PST) Message-Id: <4.3.2.7.2.20020313164554.0358caa8@diablo.cisco.com> X-Sender: jschnizl@diablo.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 13 Mar 2002 16:52:37 -0500 To: Johan Johansson From: John Schnizlein Subject: Re: [AAA-WG]: [issue] Need more explanation about handling MN handoffs Cc: In-Reply-To: <3C8FC4EA.5050206@ipunplugged.com> References: <000701c1c3fc$ff09ece0$f6512844@sanarb01.mi.comcast.net> <3C8642B8.797C0D5@Interlinknetworks.com> <3C8EAA92.9B99D9ED@ericsson.com> <3C8FA1F5.6170F353@Interlinknetworks.com> <3C8FB819.4E884248@ericsson.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-aaa-wg@merit.edu Precedence: bulk Since RFC 1912 says "For every IP address, there should be a matching PTR record in the in-addr.arpa domain." And RFC 1133 says "PTR’s should use official names and not aliases.", it seems reasonable to expect an IP address to map to just one host name. Where do the other two come from? John At 04:30 PM 3/13/2002, Johan Johansson wrote: >Tony Johansson wrote: > >>>I just don't know if alt 2 really works. >>>You can map an IP address to a host name, but you have no >>>assurance that the host name it maps to is a Diameter identity. >> >>Why not ? The Diameter identity is a FQDN, >>which can you can map an IP address to. >>Right ?! >Yes, but the problem is in the other direction. > >To put it in mathematical terms: the mapping from FQDN to IP address is not injective and thus can not be inverted. In other words, which of the possible 3 FQDNs for IP address X is the correct identity? From owner-aaa-wg@merit.edu Wed Mar 13 17:06:04 2002 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21386 for ; Wed, 13 Mar 2002 17:06:03 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E1EC3912A2; Wed, 13 Mar 2002 17:05:26 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B3930912A4; Wed, 13 Mar 2002 17:05:26 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id AB9FD912A2 for ; Wed, 13 Mar 2002 17:05:25 -0500 (EST) Received: by segue.merit.edu (Postfix) id 935F45DDDF; Wed, 13 Mar 2002 17:05:25 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from fep02-svc.swip.net (fep02.swip.net [130.244.199.130]) by segue.merit.edu (Postfix) with ESMTP id C273E5DD9A for ; Wed, 13 Mar 2002 17:05:24 -0500 (EST) Received: from ipunplugged.com ([213.100.60.194]) by fep02-svc.swip.net with ESMTP id <20020313220522.HXGC24657.fep02-svc.swip.net@ipunplugged.com>; Wed, 13 Mar 2002 23:05:22 +0100 Message-ID: <3C8FCD58.1060901@ipunplugged.com> Date: Wed, 13 Mar 2002 23:06:16 +0100 From: Johan Johansson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.8+) Gecko/20020202 X-Accept-Language: en-us MIME-Version: 1.0 To: John Schnizlein Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: [issue] Need more explanation about handling MN handoffs References: <000701c1c3fc$ff09ece0$f6512844@sanarb01.mi.comcast.net> <3C8642B8.797C0D5@Interlinknetworks.com> <3C8EAA92.9B99D9ED@ericsson.com> <3C8FA1F5.6170F353@Interlinknetworks.com> <3C8FB819.4E884248@ericsson.com> <4.3.2.7.2.20020313164554.0358caa8@diablo.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit This whole multiple FQDN business was introduced in the discussion on Diameter identity to allow multiple Diameter processes on the same host. Of course, if we as Tony suggests in another email make the restriction that if a machine is running a HA Diameter process it must not run any other Diameter process, we are safe. I would prefer not to make this restriction but if it is the only way to make this work we don't have much choice. j John Schnizlein wrote: >Since RFC 1912 says "For every IP address, >there should be a matching PTR record in the in-addr.arpa domain." >And RFC 1133 says "PTR's should use official names and not aliases.", >it seems reasonable to expect an IP address to map to just one host name. > >Where do the other two come from? > >John > >At 04:30 PM 3/13/2002, Johan Johansson wrote: > >>Tony Johansson wrote: >> >>>>I just don't know if alt 2 really works. >>>>You can map an IP address to a host name, but you have no >>>>assurance that the host name it maps to is a Diameter identity. >>>> >>>Why not ? The Diameter identity is a FQDN, >>>which can you can map an IP address to. >>>Right ?! >>> >>Yes, but the problem is in the other direction. >> >>To put it in mathematical terms: the mapping from FQDN to IP address is not injective and thus can not be inverted. In other words, which of the possible 3 FQDNs for IP address X is the correct identity? >> > From owner-aaa-wg@merit.edu Wed Mar 13 17:41:08 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22748 for ; Wed, 13 Mar 2002 17:41:08 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5DB57912A7; Wed, 13 Mar 2002 17:40:56 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 29558912A9; Wed, 13 Mar 2002 17:40:56 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id F2F29912A7 for ; Wed, 13 Mar 2002 17:40:54 -0500 (EST) Received: by segue.merit.edu (Postfix) id CFA9F5DDBC; Wed, 13 Mar 2002 17:40:54 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by segue.merit.edu (Postfix) with ESMTP id 9D4125DDA4 for ; Wed, 13 Mar 2002 17:40:54 -0500 (EST) Received: from mr7.exu.ericsson.se (mr7att.ericy.com [138.85.224.158]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g2DMesS05307; Wed, 13 Mar 2002 16:40:54 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g2DMerM20339; Wed, 13 Mar 2002 16:40:53 -0600 (CST) Received: from qpop.exu.ericsson.se (qpop [138.85.75.72]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id QAA10373; Wed, 13 Mar 2002 16:40:53 -0600 (CST) Received: from ericsson.com ([138.85.159.114]) by qpop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id QAA16165; Wed, 13 Mar 2002 16:40:52 -0600 (CST) Message-ID: <3C8FD4D6.2E009513@ericsson.com> Date: Wed, 13 Mar 2002 14:38:14 -0800 From: Tony Johansson X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Johan Johansson Cc: John Schnizlein , aaa-wg@merit.edu Subject: Re: [AAA-WG]: [issue] Need more explanation about handling MN handoffs References: <000701c1c3fc$ff09ece0$f6512844@sanarb01.mi.comcast.net> <3C8642B8.797C0D5@Interlinknetworks.com> <3C8EAA92.9B99D9ED@ericsson.com> <3C8FA1F5.6170F353@Interlinknetworks.com> <3C8FB819.4E884248@ericsson.com> <4.3.2.7.2.20020313164554.0358caa8@diablo.cisco.com> <3C8FCD58.1060901@ipunplugged.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Johan Johansson wrote: > This whole multiple FQDN business was introduced in the discussion on > Diameter identity to allow multiple Diameter processes on the same host. > Of course, if we as Tony suggests in another email make the restriction > that if a machine is running a HA Diameter process it must not run any > other Diameter process, we are safe. I would prefer not to make this > restriction Why would you prefer not to do this restriction? Would you really run multiple Diameter processes in an HA?! > but if it is the only way to make this work we don't have > much choice. > > j > > John Schnizlein wrote: > > >Since RFC 1912 says "For every IP address, > >there should be a matching PTR record in the in-addr.arpa domain." > >And RFC 1133 says "PTR's should use official names and not aliases.", > >it seems reasonable to expect an IP address to map to just one host name. > > > >Where do the other two come from? > > > >John > > > >At 04:30 PM 3/13/2002, Johan Johansson wrote: > > > >>Tony Johansson wrote: > >> > >>>>I just don't know if alt 2 really works. > >>>>You can map an IP address to a host name, but you have no > >>>>assurance that the host name it maps to is a Diameter identity. > >>>> > >>>Why not ? The Diameter identity is a FQDN, > >>>which can you can map an IP address to. > >>>Right ?! > >>> > >>Yes, but the problem is in the other direction. > >> > >>To put it in mathematical terms: the mapping from FQDN to IP address is not injective and thus can not be inverted. In other words, which of the possible 3 FQDNs for IP address X is the correct identity? > >> > > From owner-aaa-wg@merit.edu Wed Mar 13 17:43:48 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22855 for ; Wed, 13 Mar 2002 17:43:48 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A72CC912A9; Wed, 13 Mar 2002 17:43:28 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 78DA9912AA; Wed, 13 Mar 2002 17:43:28 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3A104912A9 for ; Wed, 13 Mar 2002 17:43:27 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1D2485DDBC; Wed, 13 Mar 2002 17:43:27 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from cisco.com (titans.cisco.com [161.44.72.74]) by segue.merit.edu (Postfix) with ESMTP id E5D255DDA4 for ; Wed, 13 Mar 2002 17:43:25 -0500 (EST) Received: from knox6046.cisco.com (knox6046.cisco.com [161.44.216.46]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id RAA00249; Wed, 13 Mar 2002 17:43:21 -0500 (EST) Received: (from srich@localhost) by knox6046.cisco.com (8.11.6/8.11.6) id g2DMhKa04932; Wed, 13 Mar 2002 17:43:20 -0500 From: Steve Rich MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15503.54792.664946.439688@knox6046.cisco.com> Date: Wed, 13 Mar 2002 17:43:20 -0500 To: Tony Johansson Cc: Johan Johansson , John Schnizlein , aaa-wg@merit.edu Subject: Re: [AAA-WG]: [issue] Need more explanation about handling MN handoffs In-Reply-To: <3C8FD4D6.2E009513@ericsson.com> References: <000701c1c3fc$ff09ece0$f6512844@sanarb01.mi.comcast.net> <3C8642B8.797C0D5@Interlinknetworks.com> <3C8EAA92.9B99D9ED@ericsson.com> <3C8FA1F5.6170F353@Interlinknetworks.com> <3C8FB819.4E884248@ericsson.com> <4.3.2.7.2.20020313164554.0358caa8@diablo.cisco.com> <3C8FCD58.1060901@ipunplugged.com> <3C8FD4D6.2E009513@ericsson.com> X-Mailer: VM 7.01 under Emacs 21.1.1 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Maybe not for an HA per se, but I can see the need/desire to run multiple Diameter servers on a single host. I would hope that a restriction of this nature not be imposed. Thanks, sjr Tony Johansson writes: > > > Johan Johansson wrote: > > > This whole multiple FQDN business was introduced in the discussion on > > Diameter identity to allow multiple Diameter processes on the same host. > > Of course, if we as Tony suggests in another email make the restriction > > that if a machine is running a HA Diameter process it must not run any > > other Diameter process, we are safe. I would prefer not to make this > > restriction > > Why would you prefer not to do this restriction? Would you really run multiple Diameter processes in an HA?! > > > but if it is the only way to make this work we don't have > > much choice. > > > > j > > > > John Schnizlein wrote: > > > > >Since RFC 1912 says "For every IP address, > > >there should be a matching PTR record in the in-addr.arpa domain." > > >And RFC 1133 says "PTR's should use official names and not aliases.", > > >it seems reasonable to expect an IP address to map to just one host name. > > > > > >Where do the other two come from? > > > > > >John > > > > > >At 04:30 PM 3/13/2002, Johan Johansson wrote: > > > > > >>Tony Johansson wrote: > > >> > > >>>>I just don't know if alt 2 really works. > > >>>>You can map an IP address to a host name, but you have no > > >>>>assurance that the host name it maps to is a Diameter identity. > > >>>> > > >>>Why not ? The Diameter identity is a FQDN, > > >>>which can you can map an IP address to. > > >>>Right ?! > > >>> > > >>Yes, but the problem is in the other direction. > > >> > > >>To put it in mathematical terms: the mapping from FQDN to IP address is not injective and thus can not be inverted. In other words, which of the possible 3 FQDNs for IP address X is the correct identity? > > >> > > > > From owner-aaa-wg@merit.edu Wed Mar 13 18:08:00 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23919 for ; Wed, 13 Mar 2002 18:07:59 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 343C0912AA; Wed, 13 Mar 2002 18:07:50 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F1DE8912AB; Wed, 13 Mar 2002 18:07:49 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D39F5912AA for ; Wed, 13 Mar 2002 18:07:48 -0500 (EST) Received: by segue.merit.edu (Postfix) id A99DB5DDA4; Wed, 13 Mar 2002 18:07:48 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from palrel11.hp.com (palrel11.hp.com [156.153.255.246]) by segue.merit.edu (Postfix) with ESMTP id 8B2AF5DD9B for ; Wed, 13 Mar 2002 18:07:48 -0500 (EST) Received: from hpindsra.cup.hp.com (hpindsra.cup.hp.com [15.13.104.190]) by palrel11.hp.com (Postfix) with ESMTP id 2108B600922 for ; Wed, 13 Mar 2002 15:07:48 -0800 (PST) Received: from hpindsra (hpindsra [15.13.104.190]) by hpindsra.cup.hp.com with ESMTP (8.8.6 (PHNE_17190)/8.8.6 SMKit7.02) id PAA10768 for ; Wed, 13 Mar 2002 15:07:50 -0800 (PST) Date: Wed, 13 Mar 2002 15:07:49 -0800 (PST) From: Sivasundar Ramamurthy X-Sender: sramam@hpindsra To: AAA Working Group Subject: [AAA-WG]: [issue] MN starting at Home Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Hello, I am not sure if this scenario has been considered by the Mobile IP application draft. Some MN might employ the policy to turn off security in data communication when at home. But the HA advertisement alone may not enough for the MN to "decide" it is at home, since it could be spoofed. So when the MN is starting at home, it would still rely on a de-registration request and a successful reply in order to verify that it IS at home. Assuming that this approach is reasonable, an MN starting at home would recieve HA advertisments and would still send a de-registration request to the HA. But since it does not have any keys to the HA, the MN will make a AAA request, which can be processed by the HA only via AAA (just like a request from a co-located MN). Does the draft implicity says that the HA cannot send AMR if the request is not for a co-located MN (and not for de-registration)? If yes, can we change it? If no, can we define some protocol by which the AAAH can respond to such AMRs with an AMA, just like when the co-located flag was turned on in the MIP-Feature-Vector? thanks! Siva From owner-aaa-wg@merit.edu Wed Mar 13 18:21:12 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24344 for ; Wed, 13 Mar 2002 18:21:11 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id AFB51912AB; Wed, 13 Mar 2002 18:21:00 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 793BF912AC; Wed, 13 Mar 2002 18:21:00 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5AF8B912AB for ; Wed, 13 Mar 2002 18:20:59 -0500 (EST) Received: by segue.merit.edu (Postfix) id 303595DDE1; Wed, 13 Mar 2002 18:20:59 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from palrel13.hp.com (palrel13.hp.com [156.153.255.238]) by segue.merit.edu (Postfix) with ESMTP id 10FD15DD9B for ; Wed, 13 Mar 2002 18:20:59 -0500 (EST) Received: from hpindsra.cup.hp.com (hpindsra.cup.hp.com [15.13.104.190]) by palrel13.hp.com (Postfix) with ESMTP id 9CD5A4001C1; Wed, 13 Mar 2002 15:20:58 -0800 (PST) Received: from hpindsra (hpindsra [15.13.104.190]) by hpindsra.cup.hp.com with ESMTP (8.8.6 (PHNE_17190)/8.8.6 SMKit7.02) id PAA10827; Wed, 13 Mar 2002 15:20:53 -0800 (PST) Date: Wed, 13 Mar 2002 15:20:52 -0800 (PST) From: Sivasundar Ramamurthy X-Sender: sramam@hpindsra To: Tony Johansson Cc: AAA Working Group , Johan Johansson , fredrik.johansson@ipunplugged.com Subject: Re: [AAA-WG]: [issue] Session-Timeout vs Authorization-Lifetime vs MIP-Key-Lifetime In-Reply-To: <3C8E53E1.B8D86E1F@ericsson.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Hello, This goes back to one of my previous emails (with a few corrections :-) -------------------------------------------------------------------------- if the key lifetime is allowed to be greater than the authorization lifetime (plus grace period), then the authorization at the (stateful) AAA server will expire even as the MN is re-registering. This will happen since the MN "knows" to use AAA only to request keys; it will re-register (re-authenticate) directly with the HA during the time the keys are alive. Thus even while the MN is happily registered (authenticated), the (stateful) AAA server will see that its authorization lifetime (plus grace period) has expired and will terminate its session and de-allocate the resources. Is'nt this a problem? -------------------------------------------------------------------------- [ I am interpreting the "cleaning up resources of the session" in section 8.10 as "terminating the session" ] If I am correct, then do we make an exception for Mobile IP sessions so that AAA servers will terminate sessions only when only when the key-lifetime expires? thanks! Siva From owner-aaa-wg@merit.edu Wed Mar 13 18:31:35 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24510 for ; Wed, 13 Mar 2002 18:31:35 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1455F912AC; Wed, 13 Mar 2002 18:30:51 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CBE13912AD; Wed, 13 Mar 2002 18:30:50 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 89177912AC for ; Wed, 13 Mar 2002 18:30:49 -0500 (EST) Received: by segue.merit.edu (Postfix) id 63ECC5DDCB; Wed, 13 Mar 2002 18:30:49 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from imr1.ericy.com (unknown [208.237.135.240]) by segue.merit.edu (Postfix) with ESMTP id 0BC105DD9B for ; Wed, 13 Mar 2002 18:30:49 -0500 (EST) Received: from mr5.exu.ericsson.se (mr5u3.ericy.com [208.237.135.124]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g2DNUkh29363; Wed, 13 Mar 2002 17:30:46 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g2DNUkG11474; Wed, 13 Mar 2002 17:30:46 -0600 (CST) Received: from qpop.exu.ericsson.se (qpop [138.85.75.72]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id RAA15069; Wed, 13 Mar 2002 17:30:45 -0600 (CST) Received: from ericsson.com ([138.85.159.114]) by qpop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id RAA17018; Wed, 13 Mar 2002 17:30:44 -0600 (CST) Message-ID: <3C8FE087.11C674A6@ericsson.com> Date: Wed, 13 Mar 2002 15:28:07 -0800 From: Tony Johansson X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Steve Rich Cc: Johan Johansson , John Schnizlein , aaa-wg@merit.edu Subject: Re: [AAA-WG]: [issue] Need more explanation about handling MN handoffs References: <000701c1c3fc$ff09ece0$f6512844@sanarb01.mi.comcast.net> <3C8642B8.797C0D5@Interlinknetworks.com> <3C8EAA92.9B99D9ED@ericsson.com> <3C8FA1F5.6170F353@Interlinknetworks.com> <3C8FB819.4E884248@ericsson.com> <4.3.2.7.2.20020313164554.0358caa8@diablo.cisco.com> <3C8FCD58.1060901@ipunplugged.com> <3C8FD4D6.2E009513@ericsson.com> <15503.54792.664946.439688@knox6046.cisco.com> Content-Type: multipart/alternative; boundary="------------88CA66A7F8CFCE422F156704" Sender: owner-aaa-wg@merit.edu Precedence: bulk --------------88CA66A7F8CFCE422F156704 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I agree. I ONLY want to impose this for the HA, with something like the following new section: "1.9 DiameterIdentity discovery of the Home Agent This application requires that the Home Agent MUST only have one FQDN per IP address. This is required to guarantee that the AAAF and AAAH can determine the DiameterIdentity of the Home Agent, since only the Home Agents IP address will be known in all subsequent re-authentications through the AAA infrastructure." If we can't agree on this restriction, then the AAAF and AAAH will have a hard time to find the right HA and route the requests to the right HA when the MN do handoffs. Regards, /Tony Steve Rich wrote: > Maybe not for an HA per se, but I can see the need/desire to run > multiple Diameter servers on a single host. > > I would hope that a restriction of this nature not be imposed. > > Thanks, > sjr > > Tony Johansson writes: > > > > > > Johan Johansson wrote: > > > > > This whole multiple FQDN business was introduced in the discussion on > > > Diameter identity to allow multiple Diameter processes on the same host. > > > Of course, if we as Tony suggests in another email make the restriction > > > that if a machine is running a HA Diameter process it must not run any > > > other Diameter process, we are safe. I would prefer not to make this > > > restriction > > > > Why would you prefer not to do this restriction? Would you really run multiple Diameter processes in an HA?! > > > > > but if it is the only way to make this work we don't have > > > much choice. > > > > > > j > > > > > > John Schnizlein wrote: > > > > > > >Since RFC 1912 says "For every IP address, > > > >there should be a matching PTR record in the in-addr.arpa domain." > > > >And RFC 1133 says "PTR's should use official names and not aliases.", > > > >it seems reasonable to expect an IP address to map to just one host name. > > > > > > > >Where do the other two come from? > > > > > > > >John > > > > > > > >At 04:30 PM 3/13/2002, Johan Johansson wrote: > > > > > > > >>Tony Johansson wrote: > > > >> > > > >>>>I just don't know if alt 2 really works. > > > >>>>You can map an IP address to a host name, but you have no > > > >>>>assurance that the host name it maps to is a Diameter identity. > > > >>>> > > > >>>Why not ? The Diameter identity is a FQDN, > > > >>>which can you can map an IP address to. > > > >>>Right ?! > > > >>> > > > >>Yes, but the problem is in the other direction. > > > >> > > > >>To put it in mathematical terms: the mapping from FQDN to IP address is not injective and thus can not be inverted. In other words, which of the possible 3 FQDNs for IP address X is the correct identity? > > > >> > > > > > > --------------88CA66A7F8CFCE422F156704 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit I agree. I ONLY want to impose this for the HA, with something like the following new section:

"1.9 DiameterIdentity discovery of the Home Agent

This application requires that the Home Agent MUST only have one FQDN per IP address. This is required to guarantee that the AAAF and AAAH can determine the DiameterIdentity of the Home Agent, since only the Home Agents IP address will be known in all subsequent re-authentications through the AAA infrastructure."

If we can't agree on this restriction, then the  AAAF and AAAH will have a hard time to find the right HA and route the requests to the right HA when the MN do handoffs.

Regards,

/Tony

Steve Rich wrote:

Maybe not for an HA per se, but I can see the need/desire to run
multiple Diameter servers on a single host.

I would hope that a restriction of this nature not be imposed.

Thanks,
sjr

Tony Johansson writes:
 >
 >
 > Johan Johansson wrote:
 >
 > > This whole multiple FQDN business was introduced in the discussion on
 > > Diameter identity to allow multiple Diameter processes on the same host.
 > > Of course, if we as Tony suggests in another email make the restriction
 > > that if a machine is running a HA Diameter process it must not run any
 > > other Diameter process, we are safe. I would prefer not to make this
 > > restriction
 >
 > Why would you prefer not to do this restriction? Would you really run multiple Diameter processes in an HA?!
 >
 > > but if it is the only way to make this work we don't have
 > > much choice.
 > >
 > > j
 > >
 > > John Schnizlein wrote:
 > >
 > > >Since RFC 1912 says "For every IP address,
 > > >there should be a matching PTR record in the in-addr.arpa domain."
 > > >And RFC 1133 says "PTR's should use official names and not aliases.",
 > > >it seems reasonable to expect an IP address to map to just one host name.
 > > >
 > > >Where do the other two come from?
 > > >
 > > >John
 > > >
 > > >At 04:30 PM 3/13/2002, Johan Johansson wrote:
 > > >
 > > >>Tony Johansson wrote:
 > > >>
 > > >>>>I just don't know if alt 2 really works.
 > > >>>>You can map an IP address to a host name, but you have no
 > > >>>>assurance that the host name it maps to is a Diameter identity.
 > > >>>>
 > > >>>Why not ? The Diameter identity is a FQDN,
 > > >>>which can you can map an IP address to.
 > > >>>Right ?!
 > > >>>
 > > >>Yes, but the problem is in the other direction.
 > > >>
 > > >>To put it in mathematical terms: the mapping from FQDN to IP address is not injective and thus can not be inverted. In other words, which of the possible 3 FQDNs for IP address X is the correct identity?
 > > >>
 > > >
 >

--------------88CA66A7F8CFCE422F156704-- From owner-aaa-wg@merit.edu Wed Mar 13 19:06:39 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25343 for ; Wed, 13 Mar 2002 19:06:39 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A432E912AE; Wed, 13 Mar 2002 19:06:16 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 71D11912AF; Wed, 13 Mar 2002 19:06:16 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 69E33912AE for ; Wed, 13 Mar 2002 19:06:15 -0500 (EST) Received: by segue.merit.edu (Postfix) id 496975DDCB; Wed, 13 Mar 2002 19:06:15 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from fep01-svc.swip.net (unknown [130.244.199.129]) by segue.merit.edu (Postfix) with ESMTP id AF95C5DD9B for ; Wed, 13 Mar 2002 19:06:14 -0500 (EST) Received: from ipunplugged.com ([213.100.60.194]) by fep01-svc.swip.net with ESMTP id <20020314000613.IYEA28449.fep01-svc.swip.net@ipunplugged.com>; Thu, 14 Mar 2002 01:06:13 +0100 Message-ID: <3C8FE9AA.5040507@ipunplugged.com> Date: Thu, 14 Mar 2002 01:07:06 +0100 From: Johan Johansson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.8+) Gecko/20020202 X-Accept-Language: en-us MIME-Version: 1.0 To: Tony Johansson Cc: Steve Rich , John Schnizlein , aaa-wg@merit.edu Subject: Re: [AAA-WG]: [issue] Need more explanation about handling MN handoffs References: <000701c1c3fc$ff09ece0$f6512844@sanarb01.mi.comcast.net> <3C8642B8.797C0D5@Interlinknetworks.com> <3C8EAA92.9B99D9ED@ericsson.com> <3C8FA1F5.6170F353@Interlinknetworks.com> <3C8FB819.4E884248@ericsson.com> <4.3.2.7.2.20020313164554.0358caa8@diablo.cisco.com> <3C8FCD58.1060901@ipunplugged.com> <3C8FD4D6.2E009513@ericsson.com> <15503.54792.664946.439688@knox6046.cisco.com> <3C8FE087.11C674A6@ericsson.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit It's getting pretty late here so I'll temporarily ignore your previous question Tony, but for now, are there any suggestions on how to solve what Bob called the "AAAH's 2nd Problem", i.e. how is the realm deduced from this? For ha4.ericsson.com there is apparently no problem, but what about ha2.eab.ericsson.com? Do we mandate this to be eab.ericsson.com or do we mandate this to be ericsson.com or do we do something completely different? Picking eab.ericsson.com would have the advantage that if you use longest match from right to lookup routes you would still get a match on ericsson.com. I really wish an effort to get an extension into MobileIP had been made when we discussed this the first time in October. Now, just as half a year ago, *any* other solution is preferred due to time constraints. I think that any of the suboptimal solutions we must come up with should at the very least not limit future modifications of the protocol to solve the problem the right way. Or do we play by a completely new set of rules if we change the version number in messages to 2? j Tony Johansson wrote: > I agree. I ONLY want to impose this for the HA, with something like > the following new section: > > "1.9 DiameterIdentity discovery of the Home Agent > > This application requires that the Home Agent MUST only have one FQDN > per IP address. This is required to guarantee that the AAAF and AAAH > can determine the DiameterIdentity of the Home Agent, since only the > Home Agents IP address will be known in all subsequent > re-authentications through the AAA infrastructure." > > If we can't agree on this restriction, then the AAAF and AAAH will > have a hard time to find the right HA and route the requests to the > right HA when the MN do handoffs. > > Regards, > > /Tony > > Steve Rich wrote: > >> Maybe not for an HA per se, but I can see the need/desire to run >> multiple Diameter servers on a single host. >> >> I would hope that a restriction of this nature not be imposed. >> >> Thanks, >> sjr >> >> Tony Johansson writes: >> > >> > >> > Johan Johansson wrote: >> > >> > > This whole multiple FQDN business was introduced in the >> discussion on >> > > Diameter identity to allow multiple Diameter processes on the >> same host. >> > > Of course, if we as Tony suggests in another email make the >> restriction >> > > that if a machine is running a HA Diameter process it must not >> run any >> > > other Diameter process, we are safe. I would prefer not to make >> this >> > > restriction >> > >> > Why would you prefer not to do this restriction? Would you really >> run multiple Diameter processes in an HA?! >> > >> > > but if it is the only way to make this work we don't have >> > > much choice. >> > > >> > > j >> > > >> > > John Schnizlein wrote: >> > > >> > > >Since RFC 1912 says "For every IP address, >> > > >there should be a matching PTR record in the in-addr.arpa domain." >> > > >And RFC 1133 says "PTR's should use official names and not >> aliases.", >> > > >it seems reasonable to expect an IP address to map to just one >> host name. >> > > > >> > > >Where do the other two come from? >> > > > >> > > >John >> > > > >> > > >At 04:30 PM 3/13/2002, Johan Johansson wrote: >> > > > >> > > >>Tony Johansson wrote: >> > > >> >> > > >>>>I just don't know if alt 2 really works. >> > > >>>>You can map an IP address to a host name, but you have no >> > > >>>>assurance that the host name it maps to is a Diameter identity. >> > > >>>> >> > > >>>Why not ? The Diameter identity is a FQDN, >> > > >>>which can you can map an IP address to. >> > > >>>Right ?! >> > > >>> >> > > >>Yes, but the problem is in the other direction. >> > > >> >> > > >>To put it in mathematical terms: the mapping from FQDN to IP >> address is not injective and thus can not be inverted. In other >> words, which of the possible 3 FQDNs for IP address X is the correct >> identity? >> > > >> >> > > > >> > >> From owner-aaa-wg@merit.edu Wed Mar 13 22:28:33 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29312 for ; Wed, 13 Mar 2002 22:28:32 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 462C6912B3; Wed, 13 Mar 2002 22:27:35 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0589C912BC; Wed, 13 Mar 2002 22:27:34 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9D6B2912B3 for ; Wed, 13 Mar 2002 22:27:28 -0500 (EST) Received: by segue.merit.edu (Postfix) id 843455DDBC; Wed, 13 Mar 2002 22:27:28 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by segue.merit.edu (Postfix) with ESMTP id 4F6565DD9B for ; Wed, 13 Mar 2002 22:27:28 -0500 (EST) Received: from mr7.exu.ericsson.se (mr7att.ericy.com [138.85.224.158]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g2E3RRS15397 for ; Wed, 13 Mar 2002 21:27:27 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g2E3RRC10885 for ; Wed, 13 Mar 2002 21:27:27 -0600 (CST) Received: from qpop.exu.ericsson.se (qpop [138.85.75.72]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id VAA05694; Wed, 13 Mar 2002 21:27:24 -0600 (CST) Received: from ericsson.com ([138.85.159.114]) by qpop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id VAA20262; Wed, 13 Mar 2002 21:27:24 -0600 (CST) Message-ID: <3C9017FE.874BE993@ericsson.com> Date: Wed, 13 Mar 2002 19:24:46 -0800 From: Tony Johansson X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "'aaa-wg@merit.edu'" Cc: Lollo =?iso-8859-1?Q?T=F6nnesson?= (QPK) Subject: [AAA-WG]: Issue: Acct-Application-Id and Vendor-Specific-Application-Id in ACR References: <21B25F729760D51198BF0002A56B386A01372F55@esealnt852> Content-Type: multipart/alternative; boundary="------------7AE56F627F1C23117748819F" Sender: owner-aaa-wg@merit.edu Precedence: bulk --------------7AE56F627F1C23117748819F Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Submitter name: Tony Johansson (originally Lollo Tonnesson) Submitter email address: tony.johannson@ericsson.com Date first submitted: March 13, 2002 Reference: Document: Base Comment type: E Priority: 1 Section: 9.7.1 Accounting-Request Rationale/Explanation of issue Lollo Tönnesson (QPK) wrote: > The usage of Acct-Application-Id and > Vendor-Specific-Application-Id for vendor specific > accounting application is unclear. > > I'd like to specify a vendor specific accounting application > by using ACR and ACA commands in the Diameter Base Protocol > and add on some optional service specific AVPs. > > How do you specify the application Id in the ACR and ACA commands if you > are using a vendor specific accounting application? Should > Acct-Application-Id and/or Vendor-Specific-Application-Id be used? > > 1) Alternative 1: > ::= < Diameter Header: 271, REQ, PXY > > < Session-Id > > { Acct-Application-Id } > { Origin-Host } > ....... > Question: What Acct-Application-Id should be used? > > 2) Alternative 2: > ::= < Diameter Header: 271, REQ, PXY > > < Session-Id > > { Acct-Application-Id } > { Vendor-Specific-Application-Id } > { Origin-Host } > ....... > Question: What Acct-Application-Id should be used? > > 3) Alternative 3: > ::= < Diameter Header: 271, REQ, PXY > > < Session-Id > > { Vendor-Specific-Application-Id } > { Origin-Host } > ....... > Question: Acct-Application-Id is defined as mandatory for ACR. > Is it appropriate to replace the mandatory > Acct-Application-Id with Vendor-Specific-Application-Id. > This is not explicitly stated anywhere in the draft (09). > > According to 09 draft of the Diameter Base Protocol: > > * 6.10 Vendor-Specific-Application-Id > > AVP Format > ::= < AVP Header: 260 > > 1* [ Vendor-Id ] > 0*1{ Auth-Application-Id } > 0*1{ Acct-Application-Id } > The vendor-Id is assigned by IANA. > The Acct-Application-Id is defined by the vendor (private use). > > *Is chapter 1.2.4, 2.4 applicable for vendor specific > accounting applications, i.e. that an Acct-Application-Id > should be assigned by IANA? > > * According to e.g. chapter 6.10 in the base protocol, the > Vendor-Specific-Application-Id AVP should be used for advertise > support for vendor specific diameter applications, but this AVP > is not mentioned in the ACR or ACA, only for CER and CEA (table in 10.1, 10.2) > The only application Id AVP required for ACR and ACA are the > Acct-Application-Id. > ??: Implication: During capability exchange (CER/CEA) you advertise > support for the vendor specific application but the vendor > specific application id is not included in the ACR/ACA commands. > Can this really be correct? > ??: Should both the Acct-Application-Id and > Vendor-Specific-Application-Id be part of CER/CEA? > > * Acct-Application-Id AVP is mandatory in ACR and ACA (9.7.1, 9.7.2, 10.2) > > Best regards Lollo Requested change: Change the ABNF in 9.7.1 Accounting-Request from: ::= < Diameter Header: 271, REQ, PXY > < Session-Id > {...} { Acct-Application-Id } [...] To: ::= < Diameter Header: 271, REQ, PXY > < Session-Id > { ... } [ Acct-Application-Id ] [ ... ] Since you may run only the base protocol, your own vendor specifc application and no relay agent support. In such a case your ACR messages will only include the Vendor-Specific-Application-Id and no Acct-Application-Id. --------------7AE56F627F1C23117748819F Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Submitter name: Tony Johansson (originally Lollo Tonnesson)
Submitter email address: tony.johannson@ericsson.com
Date first submitted: March 13, 2002
Reference:
Document: Base
Comment type: E
Priority: 1
Section: 9.7.1  Accounting-Request

Rationale/Explanation of issue
 

Lollo Tönnesson (QPK) wrote:

The usage of Acct-Application-Id and
Vendor-Specific-Application-Id for vendor specific
accounting application is unclear.

I'd like to specify a vendor specific accounting application
by using ACR and ACA commands in the Diameter Base Protocol
and add on some optional service specific AVPs.

How do you specify the application Id in the ACR and ACA commands if you
are using a vendor specific accounting application? Should
Acct-Application-Id and/or Vendor-Specific-Application-Id be used?

1) Alternative 1:
      <ACR> ::= < Diameter Header: 271, REQ, PXY >
                < Session-Id >
                { Acct-Application-Id }
                { Origin-Host }
                 .......
  Question: What Acct-Application-Id should be used?

2) Alternative 2:
      <ACR> ::= < Diameter Header: 271, REQ, PXY >
                < Session-Id >
                { Acct-Application-Id }
                { Vendor-Specific-Application-Id }
                { Origin-Host }
                 .......
  Question: What Acct-Application-Id should be used?

3) Alternative 3:
      <ACR> ::= < Diameter Header: 271, REQ, PXY >
                < Session-Id >
                { Vendor-Specific-Application-Id }
                { Origin-Host }
                 .......
  Question: Acct-Application-Id is defined as mandatory for ACR.
           Is it appropriate to replace the mandatory
           Acct-Application-Id with Vendor-Specific-Application-Id.
           This is not explicitly stated anywhere in the draft (09).

According to 09 draft of the Diameter Base Protocol:

* 6.10 Vendor-Specific-Application-Id

 AVP Format
      <Vendor-Specific-Application-Id> ::= < AVP Header: 260 >
                                        1* [ Vendor-Id ]
                                        0*1{ Auth-Application-Id }
                                        0*1{ Acct-Application-Id }
The vendor-Id is assigned by IANA.
The Acct-Application-Id is defined by the vendor (private use).

*Is chapter 1.2.4, 2.4 applicable for vendor specific
accounting applications, i.e. that an Acct-Application-Id
should be assigned by IANA?

* According to e.g. chapter 6.10 in the base protocol, the
Vendor-Specific-Application-Id AVP should be used for advertise
support for vendor specific diameter applications, but this AVP
is not mentioned in the ACR or ACA, only for CER and CEA (table in 10.1, 10.2)
The only application Id AVP required for ACR and ACA are the
Acct-Application-Id.
??: Implication: During capability exchange (CER/CEA) you advertise
support for the vendor specific application but the vendor
specific application id is not included in the ACR/ACA commands.
Can this really be correct?
??: Should both the Acct-Application-Id and
Vendor-Specific-Application-Id be part of CER/CEA?

* Acct-Application-Id AVP is mandatory in ACR and ACA (9.7.1, 9.7.2, 10.2)

Best regards Lollo

Requested change:

Change the ABNF in 9.7.1  Accounting-Request

from:

 <ACR> ::= < Diameter Header: 271, REQ, PXY >
                < Session-Id >
                {...}
                { Acct-Application-Id }
                [...]

To:

 <ACR> ::= < Diameter Header: 271, REQ, PXY >
                < Session-Id >
                { ... }
                [ Acct-Application-Id ]
                [ ... ]

Since you may run only the base protocol, your own vendor specifc application and no relay agent
support. In such a case your ACR messages will only include the Vendor-Specific-Application-Id and no Acct-Application-Id.
  --------------7AE56F627F1C23117748819F-- From owner-aaa-wg@merit.edu Thu Mar 14 04:58:12 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13847 for ; Thu, 14 Mar 2002 04:58:12 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id F3F1B912BA; Thu, 14 Mar 2002 04:57:52 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BB7BD912BC; Thu, 14 Mar 2002 04:57:51 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8AFD8912BA for ; Thu, 14 Mar 2002 04:57:50 -0500 (EST) Received: by segue.merit.edu (Postfix) id 715CE5DE19; Thu, 14 Mar 2002 04:57:30 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from ocasey.baltimore.com (ocasey.baltimore.com [193.41.17.101]) by segue.merit.edu (Postfix) with ESMTP id 980B35DD9B for ; Thu, 14 Mar 2002 04:57:29 -0500 (EST) Received: from Baltimore-FW1 ([172.19.1.1]) by ocasey.baltimore.com (8.11.6/8.9.3) with SMTP id g2E9vDb09592 for ; Thu, 14 Mar 2002 09:57:13 GMT Received: from Baltimore-FW1 (wilde-i-1.ie.baltimore.com) by emeairlsw1.baltimore.com (Content Technologies SMTPRS 4.2.5) with SMTP id for ; Thu, 14 Mar 2002 09:52:09 +0000 Received: from baltimore.ie (wks140-4.ie.baltimore.com [10.153.4.140]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id JAA09685; Thu, 14 Mar 2002 09:57:06 GMT Message-ID: <3C9073FE.8C961041@baltimore.ie> Date: Thu, 14 Mar 2002 09:57:18 +0000 From: Stephen Farrell Reply-To: stephen.farrell@baltimore.ie Organization: Baltimore Technologies Ltd. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Don Zick Cc: gwz@cisco.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: [issue] Diameter CMS Security - Require AAA-Node-Cert in DSAR and DSAA References: <3C8E0DA5.662E736D@interlinknetworks.com> <3C8E21A6.A627990C@baltimore.ie> <3C8E6840.A063F103@interlinknetworks.com> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Don, > I'm still struggling with this issue. I'm not quite ready to give up on it. > Please see comments inline. Sure, but IMO point 1 below is the show-stopper. Much as I like to see people needing certs (i.e. the things our poducts do a very nice job of producing:-), it would be a mistake to insist that every Diameter node that wants to use CMS has to have a cert. The encryptor-only use case is a real one and therefore we can't force such nodes to have to include all the s/w, configuration and administration (not to mention the couple of dollars) needed to end up with a certificate they then include in a DSAR for no reason whatsoever. Stephen. > > Stephen Farrell wrote: > > > Don, > > > > 1. Not all nodes that can be party to a DSA need have > > certificates - only signers or decryptors actually need > > them. Verifiers and encryptors don't (if they don't do the > > opposite operations, that is). If AAA-Node-Cert were > > mandatory, then every access device that wanted to encrypt > > using CMS would have to get a cert that it'd never use. > -- ____________________________________________________________ Stephen Farrell Baltimore Technologies, tel: (direct line) +353 1 881 6716 39 Parkgate Street, fax: +353 1 881 7000 Dublin 8. mailto:stephen.farrell@baltimore.ie Ireland http://www.baltimore.com From owner-aaa-wg@merit.edu Thu Mar 14 06:05:50 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14739 for ; Thu, 14 Mar 2002 06:05:49 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B5BB5912C1; Thu, 14 Mar 2002 06:03:11 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 78327912BF; Thu, 14 Mar 2002 06:03:11 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 84F94912BE for ; Thu, 14 Mar 2002 06:02:54 -0500 (EST) Received: by segue.merit.edu (Postfix) id 614845DE19; Thu, 14 Mar 2002 06:02:54 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from ocasey.baltimore.com (ocasey.baltimore.com [193.41.17.101]) by segue.merit.edu (Postfix) with ESMTP id 9146F5DD9B for ; Thu, 14 Mar 2002 06:02:53 -0500 (EST) Received: from Baltimore-FW1 ([172.19.1.1]) by ocasey.baltimore.com (8.11.6/8.9.3) with SMTP id g2EB2mb10581 for ; Thu, 14 Mar 2002 11:02:48 GMT Received: from Baltimore-FW1 (wilde-i-1.ie.baltimore.com) by emeairlsw1.baltimore.com (Content Technologies SMTPRS 4.2.5) with SMTP id for ; Thu, 14 Mar 2002 10:57:44 +0000 Received: from baltimore.ie (wks140-4.ie.baltimore.com [10.153.4.140]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id LAA11080; Thu, 14 Mar 2002 11:02:44 GMT Message-ID: <3C908361.DE44FDEE@baltimore.ie> Date: Thu, 14 Mar 2002 11:02:57 +0000 From: Stephen Farrell Reply-To: stephen.farrell@baltimore.ie Organization: Baltimore Technologies Ltd. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Don Zick , Bernard Aboba Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: CMS Security questions References: <3C8E46CF.4A527B10@interlinknetworks.com> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Don, Thanks for these. Let's create an omnibus issue for 'em all. Responses embedded below. Bernard - will you make this a new CMS issue? (Also #307 can, I believe, be closed/rejected, given Don's mail [1]). Stephen. [1] http://www.merit.edu/mail.archives/aaa-wg/msg03431.html Submitter name: Stephen Farrell Submitter email address: stephen.farrell@baltimore.ie Date first submitted: March 14, 2002 Reference: Document: CMS Comment type: T/E Priority: 1 Section: various Rationale/Explanation of issue: Don Zick wrote: > > Hi Stephen, > > Before I go hog-wild submitting any more issues could you please address > the following questions concerning the Diameter CMS Security draft? > > 1. In section 3.1, it states: > > We use Diameter Security Association Request (DSAR) and Diameter > Security Association Answer (DSAA) messages to establish a DSA, > which > specifies which AVPs should be encrypted, signed or both, as well > as > which public key(s) to use. > > Now that the expected-signed and expected-encrypted AVPs have been > removed, shouldn't the text "which specifies which AVPs should be > encrypted, signed or both" be removed? Yes. Will do. > > 2. The AVP occurrence rules table in section 8 shows that at most 1 > AAA-Node-Cert AVP may appear in a DSAR or a DSAA. However, the > ABNF definition for the DSAR and DSAA indicate that any number > of AAA-Node-Cert AVPs may appear. Is the AVP occurrene rules > table correct? If so, shouldn't "public key(s)" mentioned in > item 1 really be "public key"? We do want to allow >1 certificate to be included (we're just insisting they all be verifiable from a single CA-Chain). So, I'd go for changing the avp occurrence rule and leaving the text and abnf alone. > 3. In section 3.1, it states: > > - Its local policy allows the given TTL, realm, AVP protection > expectations, certification status, and other parameters. > > Now that the expected-signed and expected-encrypted AVPs have been > removed, shouldn't the text "AVP protection expectations" be removed? Yes. > 4. In section 3.1 it states: > > ...the destination node returns the DSAA message which contains: > ... > - public key certificates for the Diameter servers in the > realm... > > This goes back to question #2. Must a Diameter server know all of > the certificates for all servers in its realm? Why is that useful > when the Diameter node is only establishing a DSA with a single > server? Fixed with #2. > > 5. In section 3.1 it states: > > The DSAA MUST include the CMS-Signed-Data, signed by a Diameter > agent > or server within the user's realm, to prevent an intermediate node > from modifying the protection expectations for AVPs. > > Shouldn't this requirement be removed now that expected-signed and > expected-encrypted AVPs have been removed? Hmm...That's a reasonable point, but I'd (somewhat less than entirely convincingly) argue to stick with the DSAA MUST be signed position for the following reasons: - A node producing a DSAA really has to have a private key for anything useful to subsequently happen, therefore requiring the signature doesn't require any additional code or administration, just the few additional CPU cycles required for signing this message. - The signed AVPs from the DSAA (in particular the DSA-TTL) can't be modified by intermediaies, though that's not much of a threat compared to modifying expected-* AVPs, I agree. - It provides some assurance that the originator of the message is the entity that (the CA said) has the relevant private key. However, for this to be better, a random challenge should be added to the DSAR and (that or a digest of the DSAR) reflected back in the DSAA as a signed AVP (I was thinking of proposing this as an addition to -04 but didn't). > > 6. In section 3.2 it states: > > For multiple Diameter servers within a realm that share a public > key, > each server's identity is encoded in the subjectAltName extension. > This allows any server within a realm to decrypt AVPs intended for > that realm. > > Why would a server that is not part of the DSA ever decrypt AVPs? Various forms of load-balancing I guess. > Wouldn't there be potential problems with content encryption key > reuse? Yes. As with reboots, so nothing new there. > 7. In section 4.4, the PDSR is defined. When an access device sends > a PDSR to a local proxy, the local proxy will establish a DSA with > a server in the DSAR-Target-Realm. If the access device sends an > authentication request to the local proxy and the authentication > request contains Destination-Realm but does not contain > Destination-Host, must the local proxy add the Destination-Host > AVP to the message to ensure that it is routed to the server in > the Destination-Realm that has the DSA? If this is a requirement > I think it should be stated explicitly. I guess we do need more text here and will add that. I guess I should change "authentication request" to "any Diameter message" in the above though? > 8. Section 6.3 provides some example encodings for encrypted and > signed AVPs. The examples indicate that different Diameter > nodes can have different encryption and signing requirements. > Aren't these examples misleading now that the expected-signed > and expected-encrypted AVPs have been removed? (All Diameter > nodes share the same encryption and signing requirements.) The examples are based on requirements on AVPs which can be determined from the RFC or by an astrologer. So I disagree that this is related to the expected-* removal. > 9. The AVP occurrence rules table and ABNF message definitions > have some inconsistencies: > > DSAR ABNF DSAR Occurrence rules table > AAA-Node-Cert * 0-1 Was the above meant to be in your mail? > DSAA ABNF DSAA Occurrence rules table > AAA-Node-Cert * 0-1 should be 0+ > OCSP-Responses * 1+ should be 0+ > Origin-Realm 0*1 1 > Redirect-Host not listed 0+ > Redirect-Host-Usage not listed 0-1 > Redirect-Max- > Cache-Time not listed 0-1 I don't know what's right for these. Want to suggest something? > 10. DSAA ABNF has Local-CA-info surrounded by curly brackets. I > think square brackets are correct. Disagree. Doesn't *{foo} mean "one or more", whereas *[foo] means "zero or more". One or more is what's wanted. > > 11.Origin-State-Id listed as Original-State-Id in AVP occurrence table. I'm guessing that Origin-State-Id is the right name? > 12.Section 3.1 states: > > Once the DSA is in place, any Diameter messages created by a DSA > peer > that has a private key MUST contain a signature over all AVPs whose > > definition states that their 'P' bit MAY be set. > > I think the CMS-Encrypted-Data AVP is an exception to this rule. It > only requires a signature if any of the encrypted AVPs contained in > the CMS-Encrypted-Data AVP require signing. Good point. I'll add text indicating this. > 13.Some typos: > > Section 1: "two different set of messages" > "two different sets of messages" > > Section 1.2 "DSA would the NAS" > "DSA would be the NAS" > > "initiate an DSAR" > "initiate a DSAR" > > Section 1.3 "such an an aggregating relay" > "such as an aggregating relay" > > "recelived" > "received" > > Section 3.1 "MUST re-validated" > "MUST be re-validated" > > "implemetors" > "implementors" > > Section 5 "CAA" (in diagram) > "CEA" > > "issues an DSAR message" > "issues a DSAR message" > > Section 6.11 "lenght" > "length" > Thanks, Stephen. -- ____________________________________________________________ Stephen Farrell Baltimore Technologies, tel: (direct line) +353 1 881 6716 39 Parkgate Street, fax: +353 1 881 7000 Dublin 8. mailto:stephen.farrell@baltimore.ie Ireland http://www.baltimore.com From owner-aaa-wg@merit.edu Thu Mar 14 07:09:20 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15462 for ; Thu, 14 Mar 2002 07:09:20 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A2F12912C0; Thu, 14 Mar 2002 07:09:07 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 787E4912C2; Thu, 14 Mar 2002 07:09:07 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 607E6912C0 for ; Thu, 14 Mar 2002 07:09:06 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3B5215DE19; Thu, 14 Mar 2002 07:09:06 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by segue.merit.edu (Postfix) with ESMTP id 05C625DDC1 for ; Thu, 14 Mar 2002 07:09:05 -0500 (EST) Received: from ipunplugged.com (catsandlogs.local.ipunplugged.com [192.168.4.29]) by mailgw.ipunplugged.com (8.9.3/8.9.3) with ESMTP id NAA10386; Thu, 14 Mar 2002 13:03:52 +0100 Message-ID: <3C90A026.6010705@ipunplugged.com> Date: Thu, 14 Mar 2002 14:05:42 +0100 From: Johan Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020204 X-Accept-Language: en-us MIME-Version: 1.0 To: Sivasundar Ramamurthy Cc: Tony Johansson , AAA Working Group , fredrik.johansson@ipunplugged.com Subject: Re: [AAA-WG]: [issue] Session-Timeout vs Authorization-Lifetime vs MIP-Key-Lifetime References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Sivasundar Ramamurthy wrote: >-------------------------------------------------------------------------- >if the key lifetime is allowed to be greater than the authorization >lifetime (plus grace period), then the authorization at the (stateful) >AAA server will expire even as the MN is re-registering. This will >happen since the MN "knows" to use AAA only to request keys; it will >re-register (re-authenticate) directly with the HA during the time the >keys are alive. > >Thus even while the MN is happily registered (authenticated), the >(stateful) AAA server will see that its authorization lifetime (plus >grace period) has expired and will terminate its session and >de-allocate the resources. Is'nt this a problem? > >-------------------------------------------------------------------------- > >[ I am interpreting the "cleaning up resources of the session" in >section 8.10 as "terminating the session" ] > >If I am correct, then do we make an exception for Mobile IP sessions >so that AAA servers will terminate sessions only when only when the >key-lifetime expires? > Alternatively you can say that the AAA server sends the "Diameter authorization lifetime" as the lifetime of the keys. There *is* a certain terminological mixing taking place here which is confusing, but as far as I've been able to conclude this is the intention: Authorization-Lifetime: As you say, this would be the interval with which mobile ip reauthentications would take place and does not /should not involve Diameter Mip-Key-Lifetime: The interval with which Diameter reauthorizations must be done to get valid keys to perform the next mobile ip authentication. It would seem that in the Mobile IP application Authorization-Grace-Period should be added to the MIP-Key-Lifetime. Alternatively it could be added to the value in Authorization-Lifetime before it is processed by the Mobile IP machinery. The draft doesn't say which (avp only mentioned in ABNFs and occurence rules), but my vote is on the first alternative. j From owner-aaa-wg@merit.edu Thu Mar 14 09:02:19 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17186 for ; Thu, 14 Mar 2002 09:02:19 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7F308912C3; Thu, 14 Mar 2002 09:00:14 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F28EE912C8; Thu, 14 Mar 2002 09:00:13 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A65BC912C3 for ; Thu, 14 Mar 2002 09:00:09 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4B0975DE23; Thu, 14 Mar 2002 09:00:09 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from dzick.interlinknetworks.com (nat.interlinknetworks.com [198.108.5.3]) by segue.merit.edu (Postfix) with ESMTP id C5C975DD9B for ; Thu, 14 Mar 2002 09:00:08 -0500 (EST) Received: from interlinknetworks.com (localhost.localdomain [127.0.0.1]) by dzick.interlinknetworks.com (8.11.0/8.11.0) with ESMTP id g2EDwT001204; Thu, 14 Mar 2002 08:58:30 -0500 Message-ID: <3C90AC84.90450447@interlinknetworks.com> Date: Thu, 14 Mar 2002 08:58:29 -0500 From: Don Zick Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: stephen.farrell@baltimore.ie Cc: gwz@cisco.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: [issue] Diameter CMS Security - Require AAA-Node-Cert in DSAR and DSAA References: <3C8E0DA5.662E736D@interlinknetworks.com> <3C8E21A6.A627990C@baltimore.ie> <3C8E6840.A063F103@interlinknetworks.com> <3C9073FE.8C961041@baltimore.ie> Content-Type: text/plain; charset=iso-8859-1 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id JAA17186 Hi Stephen, Okay, so the point I was missing is that if a node doesn't have a private key it can still perform encryption but cannot sign. Would you agree with this text? "If a DSA peer is to sign or decrypt AVPs then it MUST send a certificate to its DSA peer when the DSA is established." Don Stephen Farrell wrote: > Don, > > > I'm still struggling with this issue. I'm not quite ready to give up on it. > > Please see comments inline. > > Sure, but IMO point 1 below is the show-stopper. Much as I like to > see people needing certs (i.e. the things our poducts do a very > nice job of producing:-), it would be a mistake to insist that every > Diameter node that wants to use CMS has to have a cert. > > The encryptor-only use case is a real one and therefore we can't > force such nodes to have to include all the s/w, configuration and > administration (not to mention the couple of dollars) needed to > end up with a certificate they then include in a DSAR for no > reason whatsoever. > > Stephen. > > > > > Stephen Farrell wrote: > > > > > Don, > > > > > > 1. Not all nodes that can be party to a DSA need have > > > certificates - only signers or decryptors actually need > > > them. Verifiers and encryptors don't (if they don't do the > > > opposite operations, that is). If AAA-Node-Cert were > > > mandatory, then every access device that wanted to encrypt > > > using CMS would have to get a cert that it'd never use. > > > > -- > ____________________________________________________________ > Stephen Farrell > Baltimore Technologies, tel: (direct line) +353 1 881 6716 > 39 Parkgate Street, fax: +353 1 881 7000 > Dublin 8. mailto:stephen.farrell@baltimore.ie > Ireland http://www.baltimore.com From owner-aaa-wg@merit.edu Thu Mar 14 09:06:10 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17251 for ; Thu, 14 Mar 2002 09:06:10 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 73B96912C4; Thu, 14 Mar 2002 09:06:01 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3BA36912C5; Thu, 14 Mar 2002 09:06:01 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id EC923912C4 for ; Thu, 14 Mar 2002 09:05:59 -0500 (EST) Received: by segue.merit.edu (Postfix) id D41C75DDFF; Thu, 14 Mar 2002 09:05:59 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from ocasey.baltimore.com (ocasey.baltimore.com [193.41.17.101]) by segue.merit.edu (Postfix) with ESMTP id 1484F5DDB5 for ; Thu, 14 Mar 2002 09:05:59 -0500 (EST) Received: from Baltimore-FW1 ([172.19.1.1]) by ocasey.baltimore.com (8.11.6/8.9.3) with SMTP id g2EE5wb12894 for ; Thu, 14 Mar 2002 14:05:58 GMT Received: from Baltimore-FW1 (wilde-i-1.ie.baltimore.com) by emeairlsw1.baltimore.com (Content Technologies SMTPRS 4.2.5) with SMTP id for ; Thu, 14 Mar 2002 14:00:54 +0000 Received: from baltimore.ie (wks140-4.ie.baltimore.com [10.153.4.140]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id OAA14949; Thu, 14 Mar 2002 14:05:55 GMT Message-ID: <3C90AE4F.5AE76F36@baltimore.ie> Date: Thu, 14 Mar 2002 14:06:07 +0000 From: Stephen Farrell Reply-To: stephen.farrell@baltimore.ie Organization: Baltimore Technologies Ltd. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Don Zick Cc: gwz@cisco.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: [issue] Diameter CMS Security - Require AAA-Node-Cert in DSAR and DSAA References: <3C8E0DA5.662E736D@interlinknetworks.com> <3C8E21A6.A627990C@baltimore.ie> <3C8E6840.A063F103@interlinknetworks.com> <3C9073FE.8C961041@baltimore.ie> <3C90AC84.90450447@interlinknetworks.com> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit I could buy that sentence with any of MUST/SHOULD/MAY, but lets take what you've proposed for now. So the summary is: no change to the abnf, and add this new MUST where the AVP is defined (section 6.6). Any other inputs before we (ask Bernard to) add this as another CMS issue (so that I include it when editing)? Stephen. Don Zick wrote: > > Hi Stephen, > > Okay, so the point I was missing is that if a node doesn't have a private key it > can still perform encryption but cannot sign. Would you agree with this text? > > "If a DSA peer is to sign or decrypt AVPs then it MUST send a certificate to > its DSA peer when the DSA is established." > > Don > > Stephen Farrell wrote: > > > Don, > > > > > I'm still struggling with this issue. I'm not quite ready to give up on it. > > > Please see comments inline. > > > > Sure, but IMO point 1 below is the show-stopper. Much as I like to > > see people needing certs (i.e. the things our poducts do a very > > nice job of producing:-), it would be a mistake to insist that every > > Diameter node that wants to use CMS has to have a cert. > > > > The encryptor-only use case is a real one and therefore we can't > > force such nodes to have to include all the s/w, configuration and > > administration (not to mention the couple of dollars) needed to > > end up with a certificate they then include in a DSAR for no > > reason whatsoever. > > > > Stephen. > > > > > > > > Stephen Farrell wrote: > > > > > > > Don, > > > > > > > > 1. Not all nodes that can be party to a DSA need have > > > > certificates - only signers or decryptors actually need > > > > them. Verifiers and encryptors don't (if they don't do the > > > > opposite operations, that is). If AAA-Node-Cert were > > > > mandatory, then every access device that wanted to encrypt > > > > using CMS would have to get a cert that it'd never use. > > > > > > > -- > > ____________________________________________________________ > > Stephen Farrell > > Baltimore Technologies, tel: (direct line) +353 1 881 6716 > > 39 Parkgate Street, fax: +353 1 881 7000 > > Dublin 8. mailto:stephen.farrell@baltimore.ie > > Ireland http://www.baltimore.com -- ____________________________________________________________ Stephen Farrell Baltimore Technologies, tel: (direct line) +353 1 881 6716 39 Parkgate Street, fax: +353 1 881 7000 Dublin 8. mailto:stephen.farrell@baltimore.ie Ireland http://www.baltimore.com From owner-aaa-wg@merit.edu Thu Mar 14 09:18:28 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17408 for ; Thu, 14 Mar 2002 09:18:28 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 004C3912C6; Thu, 14 Mar 2002 09:18:10 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C813F912C7; Thu, 14 Mar 2002 09:18:09 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9ADEA912C6 for ; Thu, 14 Mar 2002 09:18:08 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5C15A5DDC8; Thu, 14 Mar 2002 09:18:08 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from dzick.interlinknetworks.com (nat.interlinknetworks.com [198.108.5.3]) by segue.merit.edu (Postfix) with ESMTP id 408FA5DDB5 for ; Thu, 14 Mar 2002 09:18:08 -0500 (EST) Received: from interlinknetworks.com (localhost.localdomain [127.0.0.1]) by dzick.interlinknetworks.com (8.11.0/8.11.0) with ESMTP id g2EEG0001229; Thu, 14 Mar 2002 09:16:00 -0500 Message-ID: <3C90B09F.A9B4C6CF@interlinknetworks.com> Date: Thu, 14 Mar 2002 09:15:59 -0500 From: Don Zick Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: stephen.farrell@baltimore.ie Cc: gwz@cisco.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: [issue] Diameter CMS Security - Require AAA-Node-Cert in DSAR and DSAA References: <3C8E0DA5.662E736D@interlinknetworks.com> <3C8E21A6.A627990C@baltimore.ie> <3C8E6840.A063F103@interlinknetworks.com> <3C9073FE.8C961041@baltimore.ie> <3C90AC84.90450447@interlinknetworks.com> <3C90AE4F.5AE76F36@baltimore.ie> Content-Type: text/plain; charset=iso-8859-1 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id JAA17408 Hi Stephen, I don't have any other issues regarding the AAA-Node-Cert AVP occurrence rules. Thanks, Don Stephen Farrell wrote: > I could buy that sentence with any of MUST/SHOULD/MAY, but lets > take what you've proposed for now. > > So the summary is: no change to the abnf, and add this new MUST > where the AVP is defined (section 6.6). > > Any other inputs before we (ask Bernard to) add this as another > CMS issue (so that I include it when editing)? > > Stephen. > > Don Zick wrote: > > > > Hi Stephen, > > > > Okay, so the point I was missing is that if a node doesn't have a private key it > > can still perform encryption but cannot sign. Would you agree with this text? > > > > "If a DSA peer is to sign or decrypt AVPs then it MUST send a certificate to > > its DSA peer when the DSA is established." > > > > Don > > > > Stephen Farrell wrote: > > > > > Don, > > > > > > > I'm still struggling with this issue. I'm not quite ready to give up on it. > > > > Please see comments inline. > > > > > > Sure, but IMO point 1 below is the show-stopper. Much as I like to > > > see people needing certs (i.e. the things our poducts do a very > > > nice job of producing:-), it would be a mistake to insist that every > > > Diameter node that wants to use CMS has to have a cert. > > > > > > The encryptor-only use case is a real one and therefore we can't > > > force such nodes to have to include all the s/w, configuration and > > > administration (not to mention the couple of dollars) needed to > > > end up with a certificate they then include in a DSAR for no > > > reason whatsoever. > > > > > > Stephen. > > > > > > > > > > > Stephen Farrell wrote: > > > > > > > > > Don, > > > > > > > > > > 1. Not all nodes that can be party to a DSA need have > > > > > certificates - only signers or decryptors actually need > > > > > them. Verifiers and encryptors don't (if they don't do the > > > > > opposite operations, that is). If AAA-Node-Cert were > > > > > mandatory, then every access device that wanted to encrypt > > > > > using CMS would have to get a cert that it'd never use. > > > > > > > > > > -- > > > ____________________________________________________________ > > > Stephen Farrell > > > Baltimore Technologies, tel: (direct line) +353 1 881 6716 > > > 39 Parkgate Street, fax: +353 1 881 7000 > > > Dublin 8. mailto:stephen.farrell@baltimore.ie > > > Ireland http://www.baltimore.com > > -- > ____________________________________________________________ > Stephen Farrell > Baltimore Technologies, tel: (direct line) +353 1 881 6716 > 39 Parkgate Street, fax: +353 1 881 7000 > Dublin 8. mailto:stephen.farrell@baltimore.ie > Ireland http://www.baltimore.com From owner-aaa-wg@merit.edu Thu Mar 14 12:12:04 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22955 for ; Thu, 14 Mar 2002 12:12:04 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E1306912D0; Thu, 14 Mar 2002 12:11:53 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B0840912D1; Thu, 14 Mar 2002 12:11:53 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C9597912D0 for ; Thu, 14 Mar 2002 12:11:52 -0500 (EST) Received: by segue.merit.edu (Postfix) id AE11C5DDFD; Thu, 14 Mar 2002 12:11:52 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 98EA65DD92 for ; Thu, 14 Mar 2002 12:11:52 -0500 (EST) Received: from Interlinknetworks.com (nat.interlinknetworks.com [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with ESMTP id 59C5F7F; Thu, 14 Mar 2002 12:11:52 -0500 (EST) Message-ID: <3C90D9E5.432E2C66@Interlinknetworks.com> Date: Thu, 14 Mar 2002 12:12:05 -0500 From: David Spence Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Tony Johansson Cc: aaa-wg , Bob Kopacz Subject: Re: [AAA-WG]: [issue] Need more explanation about handling MN handoffs References: <000701c1c3fc$ff09ece0$f6512844@sanarb01.mi.comcast.net> <3C8642B8.797C0D5@Interlinknetworks.com> <3C8EAA92.9B99D9ED@ericsson.com> <3C8FA1F5.6170F353@Interlinknetworks.com> <3C8FB819.4E884248@ericsson.com> Content-Type: multipart/mixed; boundary="------------2498613CABCC3A68F21A9CA4" Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. --------------2498613CABCC3A68F21A9CA4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Tony Johansson wrote: > > Hi David, > > David Spence wrote: > > > I just don't know if alt 2 really works. You can map an IP address to a > > host name, but you have no assurance that the host name it maps to is a > > Diameter identity. > > Why not ? The Diameter identity is a FQDN, which can you can map an IP address to. > Right ?! Wrong. There may be a many-to-one mapping of host names to IP address. Each IP address typically has a single PTR record that points to a single host name. From that host name, there is no general mechanism to discover other host names that point to the same IP address. So it may not be possible to locate the host name you're looking for given the IP address. Even if you could retrieve a whole list of host names that map to an IP address, how would you know which of them is the Diameter identity you're looking for? > > from base-10: > > "The DiameterIdentity format is derived from the OctetString AVP > Base Format. It uses the UTF-8 encoding and has the same > requirements as the UTF8String: > > DiameterIdentity = fqdn > > A Diameter node must be uniquely identified by its > DiameterIdentity, which contains the fqdn of the Diameter node. > If multiple Diameter nodes run on the same host, each Diameter > node MUST be assigned a unique DiameterIdentity. If a Diameter > node can be identified by several FQDNs, one single FQDN should > be picked at startup, and used as the only DiameterIdentity for > that node, whatever the connection it is sent on. TheDiameterIdentity > value is used to uniquely identify a Diameter > node for purposes of duplicate connection and routing loop > detection." > > So, from Bob's example below you would be able to get the fqdn host name from a reverse > DNS loop up, i.e. "homeagent86.westcoast.spinach.com", which you then can use to create > the Destination-Host AVP = homeagent86.westcoast.spinach.com and the Destination-Realm > AVP = westcoast.spinach.com, since the lookup is based on longest-match-from-the-right. > Right? Wrong again unless the base spec mandates that the longest-match-from-the-right convention MUST be followed. It might simplify Diameter if we made that requirement. > > /Tony > > > There may be multiple host names that map to the IP > > address, and if so, how can you tell which one is the Diameter identity > > you're looking for? Further, even if you could determine the Diameter > > identity, there is no general algorithm for extracting the realm from it. > > That is why Diameter has both host name and realm AVPs. > > > > If we need to do something quickly in order to get a PS out, perhaps we > > could admit that the PS doesn't adequately address all the issues involved > > with supporting an HA in the foreign network and defer a thoughtful solution > > to some of these issues until after the PS is submitted. > > > > Tony Johansson wrote: > > > > > > Hi David and All, > > > > > > I see two solutions: > > > > > > Alt 1) Add new Mobile IPv4 subtypes, like HA-NAI, FA-NAI (by using the MIER > > > draft). > > > > > > Alt 2) Or solve it without any new requirements on Mobile IPv4. Like some what > > > the proposed below, thus require the AAAF to look up the Home Agent realm and > > > host identity, e.g. using reverse DNS look up. The AAAF could the pass the realm > > > and the host identity to the AAAH. > > > > > > I certainly agree with you that Alt 1 would be the best solution. However, I have > > > no idea how much extra delay that would cause. So, may be the only realistic way > > > forward, within reasonable time, is Alt 2. > > > > > > Comments please > > > > > > /Tony > > > > > > David Spence wrote: > > > > > > > I think this is a real showstopper issue. > > > > > > > > The problem goes to the core of how Diameter identifies nodes and does > > > > message forwarding. In order for Diameter MobileIPv4 to support handoffs > > > > correctly, the Diameter identities and realms of various Diameter nodes > > > > involved in the service need to be known. To solve this issue properly, > > > > changes may need to be made to the Mobile IPv4 protocol itself. Given the > > > > close interdependence of Mobile IPv4 when used to support CDMA2000 and the > > > > Diameter MobileIPv4 application, it puzzles me why "IP Mobility Support for > > > > IPv4" (RFC 3220) was allowed to progress to Proposed Standard independently > > > > of "Diameter Mobile IPv4 Application" > > > > (draft-ietf-aaa-diameter-mobileip-09.txt). Nevertheless, I believe that the > > > > only good way to solve the problems of Diameter MobileIPv4 is to add some > > > > data elements to the Mobile IPv4 protocol itself. > > > > > > > > Bob Kopacz wrote: > > > > > > > > > > Issue : Need more explanation about handling MN handoffs > > > > > Submitter name: Bob Kopacz > > > > > Submitter email address:bkopacz@interlinknetworks.com > > > > > Date first submitted: 03-04-2002 > > > > > Reference: > > > > > Document: draft-mobileip-09 > > > > > Comment type: Technical > > > > > Priority: 1 > > > > > Section: > > > > > > > > > > Rationale/Explanation of issue: > > > > > > > > > > I may be missing something significant here, but ... > > > > > > > > > > This issue has to do with how an AAAF and AAAH, when given a Home > > > > > Agent's IP address, derive the domain/realm/DiameterIdentity > > > > > information needed by the Diameter AAA servers. > > > > > > > > > > This issue may also have some bearing on the relationship between a > > > > > DiameterIdentity and a FQDN. > > > > > > > > > > Unfortunately I don't have a good solution to present, so I'm > > > > > indicating what the problems are, as indicated by "-->". It may > > > > > be that the solution is to enhance the Mobile IP protocol to > > > > > provide more information in the Registration Request. > > > > > > > > > > THE AAAF's PROBLEM: > > > > > ------------------ > > > > > Section 1.4. Allocation of Home Agent in Foreign Network, says > > > > > the following: > > > > > > > > > > > 1.4 Allocation of Home Agent in Foreign Network > > > > > > > > > > > > [...] > > > > > > > > > > > > In the event that the mobile node requests a home agent in the > > > > > > foreign network, and the AAAF authorizes its use, the AAAF MUST set > > > > > > the Home-Agent-In-Foreign-Network bit in the MIP-Feature-Vector AVP. > > > > > > This could happen when the AAA request is sent to "extend" a mobile > > > > > > node's current session. > > > > > > > > > > > > > > > > -->(1) I think some text needs to be added to describe how the AAAF > > > > > determines if the HA is in a foreign network. > > > > > > > > > > That is, I am guessing the method is along these lines: > > > > > > > > > > Suppose a MN initially connects, is allocated an HA, and later > > > > > undergoes a handoff to a new FA and new AAAF. Depending on the MN's > > > > > new point of attachment, the new FA and AAAF may or may not be in > > > > > the same foreign domain as before, or the foreign domain may > > > > > be same but the AAAFs are different, or the handoff may involve > > > > > the same AAAF as before. > > > > > > > > > > In the AMR, the new AAAF is provided with the MN user's NAI and the > > > > > HA's IP address. Say the MN user is "bob@donut.com" and the specified > > > > > HA IP address is 1.2.3.4. > > > > > > > > > > The new AAAF does a reverse DNS lookup of tbe HA's IP address, > > > > > 1.2.3.4, and the DNS response is that IP address 1.2.3.4 corresponds > > > > > to an FQDN of "homeagent86.westcoast.spinach.com". > > > > > > > > > > Now the AAAF extracts the realm part of the NAI, "donut.com", and > > > > > pre-pends a dot, coming up with ".donut.com". The AAAF then checks > > > > > if this ".donut.com" string is a trailing substring of the > > > > > "homeagent86.westcoast.spinach.com" FQDN. It isn't, so the AAAF > > > > > concludes the HA is in a foreign network and sends the > > > > > Home-Agent-In-Foreign-Network flag with a value of one. If the tail > > > > > of the FQDN matched ".donut.com", the AAAF would conclude the HA was > > > > > in the home network. > > > > > > > > > > -->(2) This may or may not be anywhere close to the AAAF's method. > > > > > At any rate, the method should be described in sufficient detail > > > > > for an AAAF implementation. > > > > > > > > > > -->(3) If this DNS reverse lookup is indeed the AAAF's method to > > > > > make this "home-agent-is-in-a-foreign-network" determination, then > > > > > this introduces a delay into the handoff, and should probably be > > > > > noted. > > > > > > > > > > THE AAAH's PROBLEM > > > > > ------------------ > > > > > Section 1.2 Inter-Realm Mobile IP, says the following: > > > > > > > > > > > > > > > > > 1.2 Inter-Realm Mobile IP > > > > > > > > > > > > [...] > > > > > > > > > > > > If the Mobile Node was successfully authenticated, the AAAH checks if > > > > > > the Home Agent was located in the foreign realm, by checking the > > > > > > Home-Agent-In-Foreign-Network flag of the MIP-Feature-Vector AVP. If > > > > > > the flag is enabled, then the Home Agent is located in the foreign > > > > > > realm then AAAH sends an HAR message to AAAF which contains a MIP- > > > > > > Reg-Request AVP. > > > > > > > > > > Continuing the example, suppose the AAAF has determined that the > > > > > HA is in a foreign network, and has forwarded the AMR to the home > > > > > realm. The AAAH receives the AMR, and the AMR indicates the HA's > > > > > address is 1.2.3.4, the Home-Agent-In-Foreign-Network flag is ON, > > > > > and the User-Name is "bob@donut.com". > > > > > > > > > > -->(4) Now the AAAH wants to send an HAR to the HA. But Diameter > > > > > routes by Destination-Realm and Destination-Host, not by IP address, > > > > > so the AAAH has to somehow come up with the HA's DiameterIdentity > > > > > for the Destination-Host AVP of the HAR, and the HA's realm for the > > > > > Destination-Realm of the HAR. > > > > > > > > > > AAAH's 1st Problem: How to discover the HA's DiameterIdentity: > > > > > > > > > > If the AAAH maintains session-state, then this HA identity > > > > > information can be part of the cached session-state information, > > > > > and there may be no problem. But there is a problem if either > > > > > (a) the AAAH is not session-stateful, or (b) the AAAH is > > > > > session-stateful but has no session-state info because the handoff > > > > > AMR is received by a different AAAH than the AAAH which received > > > > > the original AMR for the session. > > > > > > > > > > So if we have case (a) or (b), the hapless AAAH is holding the HA's > > > > > IP address, and needs to come up with the HA's realm and > > > > > DiameterIdentity. The method might be along these lines: > > > > > > > > > > The AAAH can do a reverse lookup of the IP address 1.2.3.4, and > > > > > again DNS returns an FQDN of "homeagent86.westcoast.spinach.com" > > > > > > > > > > *If* the DiameterIdentity is the same as the FQDN, then the AAAH > > > > > constructs the HAR's Destination-Host = > > > > > "homeagent86.westcoast.spinach.com". (An aside: I haven't kept up > > > > > with the recent DiameterIdentity thread, but I thought the > > > > > DiameterIdentity needed to be something like "FQDN+extra", so that > > > > > multiple Diameter applications could run on the same box. In > > > > > which case the FQDN isn't sufficient). > > > > > > > > > > AAAH's 2nd Problem: How to discover the HA's Realm: > > > > > > > > > > The AAAH still needs to derive the HAR's Destination-Realm, from > > > > > the FQDN. The realm is probably either "westcoast.spinach.com" > > > > > or "spinach.com". Does the AAAH have a way to know for sure, or > > > > > is the best-guess algorithm to say that the realm is what > > > > > follows the next-to-last dot of the FQDN, e.g. "spinach.com". > > > > > > > > > > -->(5) Again, this may or may not be anywhere close to what the > > > > > AAAH needs to do to surmise the HA's realm and identity. At any > > > > > rate, the method should be described in sufficient detail to > > > > > implement an AAAH. > > > > > > > > > > -->(6) If this DNS reverse lookup is indeed part of the AAAH's > > > > > method, then this introduces a delay (maybe a 2nd delay depending on > > > > > what the AAAF had to do) into the handoff, and should probably be > > > > > noted. > > > > > > > > > > -->(7) It seems the AAAF and AAAH are both starting from scratch > > > > > with the HA's IP address, and duplicating efforts and delays. Maybe > > > > > the AAAF's DNS-lookup results (or whatever useful knowledge the AAAF > > > > > possesses) could be passed along to the AAAH. --------------2498613CABCC3A68F21A9CA4 Content-Type: text/x-vcard; charset=us-ascii; name="DSpence.vcf" Content-Description: Card for David Spence Content-Disposition: attachment; filename="DSpence.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:; tel;fax:+1 734 821 1235 tel;work:+1 734 821 1203 x-mozilla-html:FALSE url:http://www.interlinknetworks.com org:Interlink Networks, Inc. adr:;;775 Technology Dr., Suite 200;Ann Arbor;MI;48108;USA version:2.1 email;internet:DSpence@Interlinknetworks.com title:Architect fn:David Spence end:vcard --------------2498613CABCC3A68F21A9CA4-- From owner-aaa-wg@merit.edu Thu Mar 14 14:17:56 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26701 for ; Thu, 14 Mar 2002 14:17:55 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3D73D912D7; Thu, 14 Mar 2002 14:17:38 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 06FCD912D8; Thu, 14 Mar 2002 14:17:37 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 537F9912D7 for ; Thu, 14 Mar 2002 14:17:34 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1FE1F5DDCC; Thu, 14 Mar 2002 14:17:34 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by segue.merit.edu (Postfix) with ESMTP id D526E5DD99 for ; Thu, 14 Mar 2002 14:17:33 -0500 (EST) Received: from mr5.exu.ericsson.se (mr5att.ericy.com [138.85.224.141]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g2EJHWS06083; Thu, 14 Mar 2002 13:17:32 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g2EJHU915665; Thu, 14 Mar 2002 13:17:30 -0600 (CST) Received: from qpop.exu.ericsson.se (qpop [138.85.75.72]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id NAA04569; Thu, 14 Mar 2002 13:17:28 -0600 (CST) Received: from ericsson.com ([138.85.159.114]) by qpop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id NAA04265; Thu, 14 Mar 2002 13:17:27 -0600 (CST) Message-ID: <3C90F6A9.263557@ericsson.com> Date: Thu, 14 Mar 2002 11:14:49 -0800 From: Tony Johansson X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: David Spence Cc: aaa-wg , Bob Kopacz , "Pat R. Calhoun" Subject: Re: [AAA-WG]: [issue] Need more explanation about handling MN handoffs References: <000701c1c3fc$ff09ece0$f6512844@sanarb01.mi.comcast.net> <3C8642B8.797C0D5@Interlinknetworks.com> <3C8EAA92.9B99D9ED@ericsson.com> <3C8FA1F5.6170F353@Interlinknetworks.com> <3C8FB819.4E884248@ericsson.com> <3C90D9E5.432E2C66@Interlinknetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit In the continued mail discussion yesterday I proposed the following resriction in the HA: "1.9 DiameterIdentity discovery of the Home Agent This application requires that the Home Agent MUST only have one FQDN per IP address. This is required to guarantee that the AAAF and AAAH can determine the DiameterIdentity of the Home Agent, since only the Home Agents IP address will be known in all subsequent re-authentications through the AAA infrastructure." However, I just got reminded that you may have multiple interfaces on the HA, ie. one Diameter client interface and one HA interface. So, in such a case a reverse DNS lookup on the HAs IP address wouldn't really point you to the right FQDN anyway :( So, do we need to add some new requirements on Mobile IP to get this right? The Mobile IP GNAI draft (http://search.ietf.org/internet-drafts/draft-ietf-mobileip-gnaie-05.txt) would acctually fit very well to our needs. The draft defines two new extensions to Mobile IP, FA_NAI and HA_NAI. Adding one more "HA_Diameter_NAI" to this draft and we would have all info needed in the Diameter infrastructure without any extra DNS look up delays... The NAI structure would also give use the hostname and realm (hostname@realm) problem solved. The BIG question is how long time it would take to get this done in the MIPwg? Pat, any comments on this ? /Tony David Spence wrote: > Tony Johansson wrote: > > > > Hi David, > > > > David Spence wrote: > > > > > I just don't know if alt 2 really works. You can map an IP address to a > > > host name, but you have no assurance that the host name it maps to is a > > > Diameter identity. > > > > Why not ? The Diameter identity is a FQDN, which can you can map an IP address to. > > Right ?! > > Wrong. There may be a many-to-one mapping of host names to IP address. > Each IP address typically has a single PTR record that points to a single > host name. From that host name, there is no general mechanism to discover > other host names that point to the same IP address. So it may not be > possible to locate the host name you're looking for given the IP address. > Even if you could retrieve a whole list of host names that map to an IP > address, how would you know which of them is the Diameter identity you're > looking for? > > > > > from base-10: > > > > "The DiameterIdentity format is derived from the OctetString AVP > > Base Format. It uses the UTF-8 encoding and has the same > > requirements as the UTF8String: > > > > DiameterIdentity = fqdn > > > > A Diameter node must be uniquely identified by its > > DiameterIdentity, which contains the fqdn of the Diameter node. > > If multiple Diameter nodes run on the same host, each Diameter > > node MUST be assigned a unique DiameterIdentity. If a Diameter > > node can be identified by several FQDNs, one single FQDN should > > be picked at startup, and used as the only DiameterIdentity for > > that node, whatever the connection it is sent on. TheDiameterIdentity > > value is used to uniquely identify a Diameter > > node for purposes of duplicate connection and routing loop > > detection." > > > > So, from Bob's example below you would be able to get the fqdn host name from a reverse > > DNS loop up, i.e. "homeagent86.westcoast.spinach.com", which you then can use to create > > the Destination-Host AVP = homeagent86.westcoast.spinach.com and the Destination-Realm > > AVP = westcoast.spinach.com, since the lookup is based on longest-match-from-the-right. > > Right? > > Wrong again unless the base spec mandates that the > longest-match-from-the-right convention MUST be followed. It might simplify > Diameter if we made that requirement. > > > > > /Tony > > > > > There may be multiple host names that map to the IP > > > address, and if so, how can you tell which one is the Diameter identity > > > you're looking for? Further, even if you could determine the Diameter > > > identity, there is no general algorithm for extracting the realm from it. > > > That is why Diameter has both host name and realm AVPs. > > > > > > If we need to do something quickly in order to get a PS out, perhaps we > > > could admit that the PS doesn't adequately address all the issues involved > > > with supporting an HA in the foreign network and defer a thoughtful solution > > > to some of these issues until after the PS is submitted. > > > > > > Tony Johansson wrote: > > > > > > > > Hi David and All, > > > > > > > > I see two solutions: > > > > > > > > Alt 1) Add new Mobile IPv4 subtypes, like HA-NAI, FA-NAI (by using the MIER > > > > draft). > > > > > > > > Alt 2) Or solve it without any new requirements on Mobile IPv4. Like some what > > > > the proposed below, thus require the AAAF to look up the Home Agent realm and > > > > host identity, e.g. using reverse DNS look up. The AAAF could the pass the realm > > > > and the host identity to the AAAH. > > > > > > > > I certainly agree with you that Alt 1 would be the best solution. However, I have > > > > no idea how much extra delay that would cause. So, may be the only realistic way > > > > forward, within reasonable time, is Alt 2. > > > > > > > > Comments please > > > > > > > > /Tony > > > > > > > > David Spence wrote: > > > > > > > > > I think this is a real showstopper issue. > > > > > > > > > > The problem goes to the core of how Diameter identifies nodes and does > > > > > message forwarding. In order for Diameter MobileIPv4 to support handoffs > > > > > correctly, the Diameter identities and realms of various Diameter nodes > > > > > involved in the service need to be known. To solve this issue properly, > > > > > changes may need to be made to the Mobile IPv4 protocol itself. Given the > > > > > close interdependence of Mobile IPv4 when used to support CDMA2000 and the > > > > > Diameter MobileIPv4 application, it puzzles me why "IP Mobility Support for > > > > > IPv4" (RFC 3220) was allowed to progress to Proposed Standard independently > > > > > of "Diameter Mobile IPv4 Application" > > > > > (draft-ietf-aaa-diameter-mobileip-09.txt). Nevertheless, I believe that the > > > > > only good way to solve the problems of Diameter MobileIPv4 is to add some > > > > > data elements to the Mobile IPv4 protocol itself. > > > > > > > > > > Bob Kopacz wrote: > > > > > > > > > > > > Issue : Need more explanation about handling MN handoffs > > > > > > Submitter name: Bob Kopacz > > > > > > Submitter email address:bkopacz@interlinknetworks.com > > > > > > Date first submitted: 03-04-2002 > > > > > > Reference: > > > > > > Document: draft-mobileip-09 > > > > > > Comment type: Technical > > > > > > Priority: 1 > > > > > > Section: > > > > > > > > > > > > Rationale/Explanation of issue: > > > > > > > > > > > > I may be missing something significant here, but ... > > > > > > > > > > > > This issue has to do with how an AAAF and AAAH, when given a Home > > > > > > Agent's IP address, derive the domain/realm/DiameterIdentity > > > > > > information needed by the Diameter AAA servers. > > > > > > > > > > > > This issue may also have some bearing on the relationship between a > > > > > > DiameterIdentity and a FQDN. > > > > > > > > > > > > Unfortunately I don't have a good solution to present, so I'm > > > > > > indicating what the problems are, as indicated by "-->". It may > > > > > > be that the solution is to enhance the Mobile IP protocol to > > > > > > provide more information in the Registration Request. > > > > > > > > > > > > THE AAAF's PROBLEM: > > > > > > ------------------ > > > > > > Section 1.4. Allocation of Home Agent in Foreign Network, says > > > > > > the following: > > > > > > > > > > > > > 1.4 Allocation of Home Agent in Foreign Network > > > > > > > > > > > > > > [...] > > > > > > > > > > > > > > In the event that the mobile node requests a home agent in the > > > > > > > foreign network, and the AAAF authorizes its use, the AAAF MUST set > > > > > > > the Home-Agent-In-Foreign-Network bit in the MIP-Feature-Vector AVP. > > > > > > > This could happen when the AAA request is sent to "extend" a mobile > > > > > > > node's current session. > > > > > > > > > > > > > > > > > > > -->(1) I think some text needs to be added to describe how the AAAF > > > > > > determines if the HA is in a foreign network. > > > > > > > > > > > > That is, I am guessing the method is along these lines: > > > > > > > > > > > > Suppose a MN initially connects, is allocated an HA, and later > > > > > > undergoes a handoff to a new FA and new AAAF. Depending on the MN's > > > > > > new point of attachment, the new FA and AAAF may or may not be in > > > > > > the same foreign domain as before, or the foreign domain may > > > > > > be same but the AAAFs are different, or the handoff may involve > > > > > > the same AAAF as before. > > > > > > > > > > > > In the AMR, the new AAAF is provided with the MN user's NAI and the > > > > > > HA's IP address. Say the MN user is "bob@donut.com" and the specified > > > > > > HA IP address is 1.2.3.4. > > > > > > > > > > > > The new AAAF does a reverse DNS lookup of tbe HA's IP address, > > > > > > 1.2.3.4, and the DNS response is that IP address 1.2.3.4 corresponds > > > > > > to an FQDN of "homeagent86.westcoast.spinach.com". > > > > > > > > > > > > Now the AAAF extracts the realm part of the NAI, "donut.com", and > > > > > > pre-pends a dot, coming up with ".donut.com". The AAAF then checks > > > > > > if this ".donut.com" string is a trailing substring of the > > > > > > "homeagent86.westcoast.spinach.com" FQDN. It isn't, so the AAAF > > > > > > concludes the HA is in a foreign network and sends the > > > > > > Home-Agent-In-Foreign-Network flag with a value of one. If the tail > > > > > > of the FQDN matched ".donut.com", the AAAF would conclude the HA was > > > > > > in the home network. > > > > > > > > > > > > -->(2) This may or may not be anywhere close to the AAAF's method. > > > > > > At any rate, the method should be described in sufficient detail > > > > > > for an AAAF implementation. > > > > > > > > > > > > -->(3) If this DNS reverse lookup is indeed the AAAF's method to > > > > > > make this "home-agent-is-in-a-foreign-network" determination, then > > > > > > this introduces a delay into the handoff, and should probably be > > > > > > noted. > > > > > > > > > > > > THE AAAH's PROBLEM > > > > > > ------------------ > > > > > > Section 1.2 Inter-Realm Mobile IP, says the following: > > > > > > > > > > > > > > > > > > > > 1.2 Inter-Realm Mobile IP > > > > > > > > > > > > > > [...] > > > > > > > > > > > > > > If the Mobile Node was successfully authenticated, the AAAH checks if > > > > > > > the Home Agent was located in the foreign realm, by checking the > > > > > > > Home-Agent-In-Foreign-Network flag of the MIP-Feature-Vector AVP. If > > > > > > > the flag is enabled, then the Home Agent is located in the foreign > > > > > > > realm then AAAH sends an HAR message to AAAF which contains a MIP- > > > > > > > Reg-Request AVP. > > > > > > > > > > > > Continuing the example, suppose the AAAF has determined that the > > > > > > HA is in a foreign network, and has forwarded the AMR to the home > > > > > > realm. The AAAH receives the AMR, and the AMR indicates the HA's > > > > > > address is 1.2.3.4, the Home-Agent-In-Foreign-Network flag is ON, > > > > > > and the User-Name is "bob@donut.com". > > > > > > > > > > > > -->(4) Now the AAAH wants to send an HAR to the HA. But Diameter > > > > > > routes by Destination-Realm and Destination-Host, not by IP address, > > > > > > so the AAAH has to somehow come up with the HA's DiameterIdentity > > > > > > for the Destination-Host AVP of the HAR, and the HA's realm for the > > > > > > Destination-Realm of the HAR. > > > > > > > > > > > > AAAH's 1st Problem: How to discover the HA's DiameterIdentity: > > > > > > > > > > > > If the AAAH maintains session-state, then this HA identity > > > > > > information can be part of the cached session-state information, > > > > > > and there may be no problem. But there is a problem if either > > > > > > (a) the AAAH is not session-stateful, or (b) the AAAH is > > > > > > session-stateful but has no session-state info because the handoff > > > > > > AMR is received by a different AAAH than the AAAH which received > > > > > > the original AMR for the session. > > > > > > > > > > > > So if we have case (a) or (b), the hapless AAAH is holding the HA's > > > > > > IP address, and needs to come up with the HA's realm and > > > > > > DiameterIdentity. The method might be along these lines: > > > > > > > > > > > > The AAAH can do a reverse lookup of the IP address 1.2.3.4, and > > > > > > again DNS returns an FQDN of "homeagent86.westcoast.spinach.com" > > > > > > > > > > > > *If* the DiameterIdentity is the same as the FQDN, then the AAAH > > > > > > constructs the HAR's Destination-Host = > > > > > > "homeagent86.westcoast.spinach.com". (An aside: I haven't kept up > > > > > > with the recent DiameterIdentity thread, but I thought the > > > > > > DiameterIdentity needed to be something like "FQDN+extra", so that > > > > > > multiple Diameter applications could run on the same box. In > > > > > > which case the FQDN isn't sufficient). > > > > > > > > > > > > AAAH's 2nd Problem: How to discover the HA's Realm: > > > > > > > > > > > > The AAAH still needs to derive the HAR's Destination-Realm, from > > > > > > the FQDN. The realm is probably either "westcoast.spinach.com" > > > > > > or "spinach.com". Does the AAAH have a way to know for sure, or > > > > > > is the best-guess algorithm to say that the realm is what > > > > > > follows the next-to-last dot of the FQDN, e.g. "spinach.com". > > > > > > > > > > > > -->(5) Again, this may or may not be anywhere close to what the > > > > > > AAAH needs to do to surmise the HA's realm and identity. At any > > > > > > rate, the method should be described in sufficient detail to > > > > > > implement an AAAH. > > > > > > > > > > > > -->(6) If this DNS reverse lookup is indeed part of the AAAH's > > > > > > method, then this introduces a delay (maybe a 2nd delay depending on > > > > > > what the AAAF had to do) into the handoff, and should probably be > > > > > > noted. > > > > > > > > > > > > -->(7) It seems the AAAF and AAAH are both starting from scratch > > > > > > with the HA's IP address, and duplicating efforts and delays. Maybe > > > > > > the AAAF's DNS-lookup results (or whatever useful knowledge the AAAF > > > > > > possesses) could be passed along to the AAAH. From owner-aaa-wg@merit.edu Thu Mar 14 14:28:56 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27281 for ; Thu, 14 Mar 2002 14:28:56 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 08EDC912D8; Thu, 14 Mar 2002 14:28:44 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C6686912D9; Thu, 14 Mar 2002 14:28:43 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B27FE912D8 for ; Thu, 14 Mar 2002 14:28:42 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8F9F55DE1C; Thu, 14 Mar 2002 14:28:42 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by segue.merit.edu (Postfix) with ESMTP id B078E5DD99 for ; Thu, 14 Mar 2002 14:28:41 -0500 (EST) Received: from fredrikj (hotel-33.local.ipunplugged.com [192.168.8.33]) by mailgw.ipunplugged.com (8.9.3/8.9.3) with SMTP id UAA19098; Thu, 14 Mar 2002 20:23:54 +0100 From: "Fredrik Johansson" To: "Sivasundar Ramamurthy" , "AAA Working Group" Subject: RE: [AAA-WG]: [issue] MN starting at Home Date: Thu, 14 Mar 2002 20:27:01 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: Importance: Normal Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi, I guess there are a couple ways of doing this. alt 1. the HA sends the AMR and receives the AMA and then issues a disconnect at the same time as it replies to the MN. alt2. the AAAH will notice that the lifetime of the session is set to 0, thus we interpret this as a deregistration (correct me if I'm wrong but 0 isn't used for something else, is it?) alt3. define a new flag in the mip-feature-vector that tells the AAAH that it is a deregistration but you still would like the mn to be authenticated. Any preferences? /fredrik >-----Original Message----- >From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of >Sivasundar Ramamurthy >Sent: den 14 mars 2002 00:08 >To: AAA Working Group >Subject: [AAA-WG]: [issue] MN starting at Home > > > >Hello, > >I am not sure if this scenario has been considered by the Mobile IP >application draft. > >Some MN might employ the policy to turn off security in data >communication when at home. But the HA advertisement alone may not >enough for the MN to "decide" it is at home, since it could be >spoofed. So when the MN is starting at home, it would still rely on a >de-registration request and a successful reply in order to verify that >it IS at home. > >Assuming that this approach is reasonable, an MN starting at home >would recieve HA advertisments and would still send a de-registration >request to the HA. But since it does not have any keys to the HA, the >MN will make a AAA request, which can be processed by the HA only via >AAA (just like a request from a co-located MN). > >Does the draft implicity says that the HA cannot send AMR if the >request is not for a co-located MN (and not for de-registration)? If >yes, can we change it? > >If no, can we define some protocol by which the AAAH can respond to >such AMRs with an AMA, just like when the co-located flag was turned >on in the MIP-Feature-Vector? > > > >thanks! > >Siva > > > > > > > From owner-aaa-wg@merit.edu Thu Mar 14 14:42:31 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27893 for ; Thu, 14 Mar 2002 14:42:31 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9D415912D9; Thu, 14 Mar 2002 14:42:19 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 68A79912DA; Thu, 14 Mar 2002 14:42:19 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7531C912D9 for ; Thu, 14 Mar 2002 14:42:18 -0500 (EST) Received: by segue.merit.edu (Postfix) id 562F65DDD9; Thu, 14 Mar 2002 14:42:18 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 7F8AE5DDC2 for ; Thu, 14 Mar 2002 14:42:17 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g2EJ0x622966 for ; Thu, 14 Mar 2002 11:00:59 -0800 Date: Thu, 14 Mar 2002 11:00:59 -0800 (PST) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: [issue] Support for Originating-Line-Info AVP missing from NASREQ Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: 2001-3-18 Reference: Document: nasreq-09 Comment type: T Priority: 1 Section: Rationale/Explanation of issue: The Diameter NASREQ application currently does not support the RADIUS Originating-Line-Info AVP, attribute #94. Below is information provided by Nenad Trifunovic relating to the definition of that AVP. ---------- Forwarded message ---------- Date: Thu, 14 Mar 2002 09:25 -0800 (PST) From: Nenad Trifunovic To: Bernard Aboba Subject: Re: Spec for the Originating-Line-Info AVP Hello, After some inquiry I got this pointer: http://www.nanpa.com/number_resource_info/ani_ii_assignments.html. so, people can synchronize to these secret numbers (although winning lotto numbers seem to be much more in demand :-) ). regards, nenad Forwarded message: _________________________________________________________________ Date: Wed, 06 Mar 2002 15:09 -0800 (PST) From: Nenad Trifunovic To: Bernard Aboba Subject: Re: Spec for the Originating-Line-Info AVP Hello, It appears that the only additional information I can provide is: Value The Value field is two octets (00-99). ANSI T1.113 and BELLCORE 394 can be used for additional information about those values and their use. Regards, nenad p.s. this is my private copy for those values (i don't know how well it matches ANSI T1.113 or BELLCORE 394 since i only found references to them). 00 Plain Old Telephone Service (POTS) - non-coi service requiring no special treatment with ANI identified. 01 Multiparty Line (more than 2) or Operator Number Identification (ONI) 02 ANI Failure 03 ANI Observed 04 ONI Observed 05 ANI Failure Observed 06 Hotel/Motel without room identification 07 Coinless, Hospital, Inmate, etc. 08 InterLATA Restricted 09 Unassigned 10 Test Call 11 Unassigned 12-19 Not assignable - conflict with international outpulsing code 20 Automatic Identified Outward Dialing (AIOD) 21-22 Unassigned 23 Coin or non-coin (identified line) Line Status Unknown 24 800 Service Call 25-26 Unassigned 27 Coin 28 Unassigned 29 Prison/Inmate Service 30-32 Intercept. 30 Intercept (blank) - for calls to unassigned DN 31 Intercept (trouble) - for calls to DNs that have been manually placed in trouble-busy state by Telco Personnel 32 Intercept (regular) - for calls to recently changed or disconnect numbers 33 Unassigned 34 Telco Operator Handled Call 35-39 Unassigned 40-49 Unrestricted Use - locally determined by carrier 50-51 Unassigned 52 Outward Wide Area Telecommunications Service (OUTWATS) 53-59 Unassigned 60 Telecommunications Relay Service (TRS) 61 Cellular Service (Type 1) 62 Cellular Service (Type 2) 63 Cellular Service (Roaming) 64-65 Unassigned 66 Telecommunications Relay Services (TRS) 67 Telecommunications Relay Services (TRS) 68 InterLATA Restricted - Hotel Line 69 Unassigned 70 Private Pay-stations 71-77 Unassigned 78 InterLATA Restricted - Coinless Line, etc. 79 Unassigned 80-89 Reserved for Future Expansion 90-92 Unassigned 93 Access for private virtual network types of service 94 Unassigned 95 Test Call 96-99 Unassigned Forwarded message: _________________________________________________________________ Date: Thu, 28 Feb 2002 12:32 -0800 (PST) From: Nenad Trifunovic To: Bernard Aboba CC: david@mitton.com, randy@psg.com Subject: Re: Spec for the Originating-Line-Info AVP Hello, Thank you for your interest in the Originating-Line-Info attribute. I have some notes about it, but it will take few days to sort them out. I'll try to send more information by the middle of the next week. Regards, nenad p.s. just to keep your interest: 1.0 Introduction Signaling System 7 (SS7) network is used in Public Switched Telephone Network (PSTN) for call management. SS7 messages carry a number of information elements related to a particular circuit switched call. The originating line information (OLI) information element indicates the nature and/or characteristics of the line from which a call originated (e.g. payphone, hotel, cellular). Telephone companies are starting to offer OLI to their customers as an option over Primary Rate Interface (PRI). Internet Service Providers (ISPs) can use OLI in addition to Called-Station-Id and Calling-Station-Id attributes to differentiate customer calls and define different services. 2.0 Originating-Line-Info Attribute A summary of the Originating-Line-Info attribute format is shown below. The fields are transmitted from left to right. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 94 for Originating-Line-Info. Length 4 Value The Value field is two octets and can have one of the following values: 00 Plain Old Telephone Service (POTS) - non-coin service requiring no special treatment with ANI identified. >Date: Wed, 27 Feb 2002 08:46 -0800 (PST) >From: Bernard Aboba >To: Nenad.Trifunovic@wcom.com >CC: david@mitton.com, > randy@psg.com >Subject: Spec for the Originating-Line-Info AVP > >The IANA RADIUS allocation page: > >http://www.iana.org/assignments/radius-types > >discloses allocation of attribute #94 to >Originating-Line-Info, with you as author. > >Is there a spec for this? We are looking to support all the existing >RADIUS attributes in Diameter NASREQ. > From owner-aaa-wg@merit.edu Thu Mar 14 15:10:34 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28932 for ; Thu, 14 Mar 2002 15:10:33 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9E394912ED; Thu, 14 Mar 2002 15:09:43 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 69715912EC; Thu, 14 Mar 2002 15:09:43 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id EE190912E7 for ; Thu, 14 Mar 2002 15:09:38 -0500 (EST) Received: by segue.merit.edu (Postfix) id D0BDF5DDCC; Thu, 14 Mar 2002 15:09:38 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id B993E5DDC2 for ; Thu, 14 Mar 2002 15:09:38 -0500 (EST) Received: from Interlinknetworks.com (nat.interlinknetworks.com [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with ESMTP id 6DFDA86; Thu, 14 Mar 2002 15:09:38 -0500 (EST) Message-ID: <3C91038E.B08564BC@Interlinknetworks.com> Date: Thu, 14 Mar 2002 15:09:50 -0500 From: David Spence Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Bernard Aboba Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: [issue] Support for Originating-Line-Info AVP missing from NASREQ References: Content-Type: multipart/mixed; boundary="------------E8C36D2C05E39983F2C8A7C6" Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. --------------E8C36D2C05E39983F2C8A7C6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit The only thing missing is the "Requested change:" section. I assume it begins, "Add the attribute." Here are some questions. 1. What are the AVP flag rules? M=MUST, P=MAY, V=MUST NOT, MAY Encr= Y? 2. Do I list http://www.nanpa.com/number_resource_info/ani_ii_assignments.html as a normative reference? 3. I assume type is enumerated. How much detail on the AVP values do I include? Only the reference? An abbreviated list of current values? ani_ii_assignments.html in its entirety? 4. Which messages may this AVP occur in? AAR, DER, ACR, and ACA? 5. How many times may this AVP occur? 0-1? Bernard Aboba wrote: > > Submitter name: Bernard Aboba > Submitter email address: aboba@internaut.com > Date first submitted: 2001-3-18 > Reference: > Document: nasreq-09 > Comment type: T > Priority: 1 > Section: > Rationale/Explanation of issue: > The Diameter NASREQ application currently does not support the > RADIUS Originating-Line-Info AVP, attribute #94. Below is information > provided by Nenad Trifunovic relating to the definition of that AVP. > > ---------- Forwarded message ---------- > Date: Thu, 14 Mar 2002 09:25 -0800 (PST) > From: Nenad Trifunovic > To: Bernard Aboba > Subject: Re: Spec for the Originating-Line-Info AVP > > Hello, > > After some inquiry I got this pointer: > > http://www.nanpa.com/number_resource_info/ani_ii_assignments.html. > > so, people can synchronize to these secret numbers (although winning > lotto numbers seem to be much more in demand :-) ). > > regards, > nenad > > Forwarded message: > _________________________________________________________________ > Date: Wed, 06 Mar 2002 15:09 -0800 (PST) > From: Nenad Trifunovic > To: Bernard Aboba > Subject: Re: Spec for the Originating-Line-Info AVP > > Hello, > > It appears that the only additional information I can provide > is: > > Value > > The Value field is two octets (00-99). ANSI T1.113 and > BELLCORE 394 can be used for additional information about > those values and their use. > > Regards, > nenad > > p.s. > this is my private copy for those values (i don't know how well > it matches ANSI T1.113 or BELLCORE 394 since i only found references > to them). > > 00 Plain Old Telephone Service (POTS) - non-coi service > requiring no special treatment with ANI identified. > > 01 Multiparty Line (more than 2) or Operator Number > Identification (ONI) > > 02 ANI Failure > > 03 ANI Observed > > 04 ONI Observed > > 05 ANI Failure Observed > > 06 Hotel/Motel without room identification > > 07 Coinless, Hospital, Inmate, etc. > > 08 InterLATA Restricted > > 09 Unassigned > > 10 Test Call > > 11 Unassigned > > 12-19 Not assignable - conflict with international outpulsing code > > 20 Automatic Identified Outward Dialing (AIOD) > > 21-22 Unassigned > > 23 Coin or non-coin (identified line) Line Status Unknown > > 24 800 Service Call > > 25-26 Unassigned > > 27 Coin > > 28 Unassigned > > 29 Prison/Inmate Service > > 30-32 Intercept. > > 30 Intercept (blank) - for calls to unassigned DN > > 31 Intercept (trouble) - for calls to DNs that have been > manually placed in trouble-busy state by Telco Personnel > > 32 Intercept (regular) - for calls to recently changed or > disconnect numbers > > 33 Unassigned > > 34 Telco Operator Handled Call > > 35-39 Unassigned > > 40-49 Unrestricted Use - locally determined by carrier > > 50-51 Unassigned > > 52 Outward Wide Area Telecommunications Service (OUTWATS) > > 53-59 Unassigned > > 60 Telecommunications Relay Service (TRS) > > 61 Cellular Service (Type 1) > > 62 Cellular Service (Type 2) > > 63 Cellular Service (Roaming) > > 64-65 Unassigned > > 66 Telecommunications Relay Services (TRS) > > 67 Telecommunications Relay Services (TRS) > > 68 InterLATA Restricted - Hotel Line > > 69 Unassigned > > 70 Private Pay-stations > > 71-77 Unassigned > > 78 InterLATA Restricted - Coinless Line, etc. > > 79 Unassigned > > 80-89 Reserved for Future Expansion > > 90-92 Unassigned > > 93 Access for private virtual network types of service > > 94 Unassigned > > 95 Test Call > > 96-99 Unassigned > > Forwarded message: > _________________________________________________________________ > Date: Thu, 28 Feb 2002 12:32 -0800 (PST) > From: Nenad Trifunovic > To: Bernard Aboba > CC: david@mitton.com, > randy@psg.com > Subject: Re: Spec for the Originating-Line-Info AVP > > Hello, > > Thank you for your interest in the Originating-Line-Info attribute. > I have some notes about it, but it will take few days to sort them > out. I'll try to send more information by the middle of the next > week. > > Regards, > nenad > > p.s. > just to keep your interest: > > 1.0 Introduction > > Signaling System 7 (SS7) network is used in Public Switched Telephone > Network (PSTN) for call management. SS7 messages carry a number of > information elements related to a particular circuit switched call. > The originating line information (OLI) information element indicates > the nature and/or characteristics of the line from which a call > originated (e.g. payphone, hotel, cellular). Telephone companies are > starting to offer OLI to their customers as an option over Primary > Rate Interface (PRI). Internet Service Providers (ISPs) can use OLI in > addition to Called-Station-Id and Calling-Station-Id attributes to > differentiate customer calls and define different services. > > 2.0 Originating-Line-Info Attribute > > A summary of the Originating-Line-Info attribute format is shown > below. The fields are transmitted from left to right. > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type | Length | Value | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Type > > 94 for Originating-Line-Info. > > Length > > 4 > > Value > > The Value field is two octets and can have one of the following > values: > > 00 Plain Old Telephone Service (POTS) - non-coin service > requiring no > special treatment with ANI identified. > > >Date: Wed, 27 Feb 2002 08:46 -0800 (PST) > >From: Bernard Aboba > >To: Nenad.Trifunovic@wcom.com > >CC: david@mitton.com, > > randy@psg.com > >Subject: Spec for the Originating-Line-Info AVP > > > >The IANA RADIUS allocation page: > > > >http://www.iana.org/assignments/radius-types > > > >discloses allocation of attribute #94 to > >Originating-Line-Info, with you as author. > > > >Is there a spec for this? We are looking to support all the existing > >RADIUS attributes in Diameter NASREQ. > > --------------E8C36D2C05E39983F2C8A7C6 Content-Type: text/x-vcard; charset=us-ascii; name="DSpence.vcf" Content-Description: Card for David Spence Content-Disposition: attachment; filename="DSpence.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:; tel;fax:+1 734 821 1235 tel;work:+1 734 821 1203 x-mozilla-html:FALSE url:http://www.interlinknetworks.com org:Interlink Networks, Inc. adr:;;775 Technology Dr., Suite 200;Ann Arbor;MI;48108;USA version:2.1 email;internet:DSpence@Interlinknetworks.com title:Architect fn:David Spence end:vcard --------------E8C36D2C05E39983F2C8A7C6-- From owner-aaa-wg@merit.edu Thu Mar 14 15:10:34 2002 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28942 for ; Thu, 14 Mar 2002 15:10:34 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B0B0D912DB; Thu, 14 Mar 2002 15:08:35 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 75CF2912E7; Thu, 14 Mar 2002 15:08:35 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 75F3F912DB for ; Thu, 14 Mar 2002 15:08:31 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5B2225DDCC; Thu, 14 Mar 2002 15:08:31 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from palrel12.hp.com (palrel12.hp.com [156.153.255.237]) by segue.merit.edu (Postfix) with ESMTP id 2EB255DDC2 for ; Thu, 14 Mar 2002 15:08:31 -0500 (EST) Received: from hpindsra.cup.hp.com (hpindsra.cup.hp.com [15.13.104.190]) by palrel12.hp.com (Postfix) with ESMTP id 6EB5F600334; Thu, 14 Mar 2002 12:08:27 -0800 (PST) Received: from hpindsra (hpindsra [15.13.104.190]) by hpindsra.cup.hp.com with ESMTP (8.8.6 (PHNE_17190)/8.8.6 SMKit7.02) id MAA12043; Thu, 14 Mar 2002 12:08:28 -0800 (PST) Date: Thu, 14 Mar 2002 12:08:27 -0800 (PST) From: Sivasundar Ramamurthy X-Sender: sramam@hpindsra To: Fredrik Johansson Cc: AAA Working Group Subject: RE: [AAA-WG]: [issue] MN starting at Home In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi, There are two issues/problems to solve here. 1. Letting the AAAH know that the purpose of the AMR is only to authenticate the MN and to get a key, and _not_ to provide any service to the MN. 2. Making the AAAH process the AMR just like when the co-located flag was set in the Feature-Vector. That is, the AAAH can directly return an AMA to the HA instead of the normal AMR-HAR-HAA-AMA message cycle (which will all be exchanged between the HA and the AAAH!). Alt 2 or 3 can be used to acheive this. Alt 3 might be the cleaner way since this _seems_ to be a Mobile IP specific issue :-) thanks, Siva > > I guess there are a couple ways of doing this. > > alt 1. > the HA sends the AMR and receives the AMA and then issues a disconnect at > the same time as it replies to the MN. > > alt2. > the AAAH will notice that the lifetime of the session is set to 0, thus we > interpret this as a deregistration (correct me if I'm wrong but 0 isn't used > for something else, is it?) > > alt3. > define a new flag in the mip-feature-vector that tells the AAAH that it is a > deregistration but you still would like the mn to be authenticated. > > Any preferences? > > /fredrik > > >-----Original Message----- > >From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of > >Sivasundar Ramamurthy > >Sent: den 14 mars 2002 00:08 > >To: AAA Working Group > >Subject: [AAA-WG]: [issue] MN starting at Home > > > > > > > >Hello, > > > >I am not sure if this scenario has been considered by the Mobile IP > >application draft. > > > >Some MN might employ the policy to turn off security in data > >communication when at home. But the HA advertisement alone may not > >enough for the MN to "decide" it is at home, since it could be > >spoofed. So when the MN is starting at home, it would still rely on a > >de-registration request and a successful reply in order to verify that > >it IS at home. > > > >Assuming that this approach is reasonable, an MN starting at home > >would recieve HA advertisments and would still send a de-registration > >request to the HA. But since it does not have any keys to the HA, the > >MN will make a AAA request, which can be processed by the HA only via > >AAA (just like a request from a co-located MN). > > > >Does the draft implicity says that the HA cannot send AMR if the > >request is not for a co-located MN (and not for de-registration)? If > >yes, can we change it? > > > >If no, can we define some protocol by which the AAAH can respond to > >such AMRs with an AMA, just like when the co-located flag was turned > >on in the MIP-Feature-Vector? > > > > > > > >thanks! > > > >Siva > > > > > > > > > > > > > > > > Thanks, Siva ==================================== Sivasundar Ramamurthy (She-va-su-ndar Ra-ma-moor-thee) Engineer, Mobile IP Project Hewlett Packard (408) 447 7255 ==================================== From owner-aaa-wg@merit.edu Thu Mar 14 16:20:02 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01274 for ; Thu, 14 Mar 2002 16:20:02 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7D3A9912DF; Thu, 14 Mar 2002 16:17:13 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 35554912E0; Thu, 14 Mar 2002 16:17:06 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 04558912DF for ; Thu, 14 Mar 2002 16:15:55 -0500 (EST) Received: by segue.merit.edu (Postfix) id DDAF05DDDE; Thu, 14 Mar 2002 16:15:55 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id C7FF35DDA2 for ; Thu, 14 Mar 2002 16:15:55 -0500 (EST) Received: from Interlinknetworks.com (nat.interlinknetworks.com [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with ESMTP id 9876D81; Thu, 14 Mar 2002 16:15:55 -0500 (EST) Message-ID: <3C911318.D6E8F19A@Interlinknetworks.com> Date: Thu, 14 Mar 2002 16:16:08 -0500 From: David Spence Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Bernard Aboba Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Updated AAA WG issues list References: Content-Type: multipart/mixed; boundary="------------66ED77C09D872A15860C0428" Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. --------------66ED77C09D872A15860C0428 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I submitted two issues that are not included on the list: Ambiguities in AVP Flag rules tables http://www.merit.edu/mail.archives/aaa-wg/2002-02/msg00147.html I believe this issue was resolved in both base-09 and cms-sec-04. Fix conflicting AVP codes in NASREQ http://www.merit.edu/mail.archives/aaa-wg/2002-02/msg00187.html I included the requested change in nasreq-09. This issue is important to document because I changed the AVP codes of two previously defined AVPs which will affect all implementations based on nasreq-08. Also, I requested on 3/1/2002 that issue 218, "ABNF/Table inconsistencies", be moved from resolved to open. It is listed as resolved in Base-08, MIP-08, NASREQ-08, and CMS-03. I discovered, however, that it was definitely not fixed in nasreq-08. It is fixed in nasreq-09, but I would like the other editors to confirm whether or not it is fixed in the other drafts before we list it as resolved. Bernard Aboba wrote: > > I've gone and updated the issues list. Here is the latest version: > > http://www.drizzle.com/~aboba/AAA/issues.html > > If there any issues that you believe are open that are listed as closed, > let me know. Similar, if issues listed as open are resolved, send me some > mail. > > -Bernard --------------66ED77C09D872A15860C0428 Content-Type: text/x-vcard; charset=us-ascii; name="DSpence.vcf" Content-Description: Card for David Spence Content-Disposition: attachment; filename="DSpence.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:; tel;fax:+1 734 821 1235 tel;work:+1 734 821 1203 x-mozilla-html:FALSE url:http://www.interlinknetworks.com org:Interlink Networks, Inc. adr:;;775 Technology Dr., Suite 200;Ann Arbor;MI;48108;USA version:2.1 email;internet:DSpence@Interlinknetworks.com title:Architect fn:David Spence end:vcard --------------66ED77C09D872A15860C0428-- From owner-aaa-wg@merit.edu Thu Mar 14 19:33:23 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05865 for ; Thu, 14 Mar 2002 19:33:23 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 6ABF691206; Thu, 14 Mar 2002 19:33:06 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2E0E2912E8; Thu, 14 Mar 2002 19:33:06 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3A07A91206 for ; Thu, 14 Mar 2002 19:33:05 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1CE985DDC0; Thu, 14 Mar 2002 19:33:05 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 8F49A5DDBC for ; Thu, 14 Mar 2002 19:33:04 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g2ENpih06548; Thu, 14 Mar 2002 15:51:44 -0800 Date: Thu, 14 Mar 2002 15:51:44 -0800 (PST) From: Bernard Aboba To: David Spence Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Updated AAA WG issues list In-Reply-To: <3C911318.D6E8F19A@Interlinknetworks.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Thanks. I've updated the issues list accordingly. On Thu, 14 Mar 2002, David Spence wrote: > I submitted two issues that are not included on the list: > > Ambiguities in AVP Flag rules tables > http://www.merit.edu/mail.archives/aaa-wg/2002-02/msg00147.html > I believe this issue was resolved in both base-09 and cms-sec-04. > > Fix conflicting AVP codes in NASREQ > http://www.merit.edu/mail.archives/aaa-wg/2002-02/msg00187.html > I included the requested change in nasreq-09. > > This issue is important to document because I changed the AVP codes > of two previously defined AVPs which will affect all implementations > based on nasreq-08. > > Also, I requested on 3/1/2002 that issue 218, "ABNF/Table inconsistencies", > be moved from resolved to open. It is listed as resolved in Base-08, > MIP-08, NASREQ-08, and CMS-03. I discovered, however, that it was > definitely not fixed in nasreq-08. It is fixed in nasreq-09, but I would > like the other editors to confirm whether or not it is fixed in the other > drafts before we list it as resolved. > > Bernard Aboba wrote: > > > > I've gone and updated the issues list. Here is the latest version: > > > > http://www.drizzle.com/~aboba/AAA/issues.html > > > > If there any issues that you believe are open that are listed as closed, > > let me know. Similar, if issues listed as open are resolved, send me some > > mail. > > > > -Bernard From owner-aaa-wg@merit.edu Thu Mar 14 19:58:35 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06335 for ; Thu, 14 Mar 2002 19:58:34 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id BF99B912E8; Thu, 14 Mar 2002 19:58:22 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 89072912E9; Thu, 14 Mar 2002 19:58:22 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5A9D0912E8 for ; Thu, 14 Mar 2002 19:58:21 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2F4B45DDC9; Thu, 14 Mar 2002 19:57:56 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 9DD045DDC2 for ; Thu, 14 Mar 2002 19:57:55 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g2F0GVk07963 for ; Thu, 14 Mar 2002 16:16:31 -0800 Date: Thu, 14 Mar 2002 16:16:31 -0800 (PST) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: Getting to done... Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Judging by the status of the issues list, I believe that we are within sight of completing work on the Diameter Base, Transport and MIP documents. The current gameplan is to have only one more WG last call on these documents, to complete 4/15/02. This means that time is running out on reviewing these documents. If you haven't read the latest drafts in depth and sent *all* your comments in, you need to do this NOW. One of the goals of IETF 53 is to resolve all open issues on these documents, so that at the end of completion of WG last call (approximately 4/15/02), we will be ready to forward documents to the IESG. In the spirit of various states that are assigning the same book to everyone to read, I would like to suggest that members of the AAA WG add the Diameter Base, Transport and MIP drafts to their reading lists, and complete a read through prior to AAA WG meeting at IETF 53, posting your issues to the mailing list. I will keep the issues list updated as the issues come in, and we will cover all the open issues at IETF 53. Since this is effectively your last opportunity to comment on Base, Transport and MIP documents, please spend that extra bit of effort in your read through. It should be expected that many of the comments will be editorial -- don't be hesitant about pointing out spelling mistakes, etc. Also, as usual we are open to technical comments as well, though given the advanced status of the specification, the bar is very high for major changes at this point. Given that the Diameter Base, Transport and MIP specs are eagerly awaited by our partners in 3GPP and 3GPP2, time is running out to complete the specifications in a timely way. Let's make this next pass through the Base, Transport and MIP documents our last. From owner-aaa-wg@merit.edu Thu Mar 14 20:33:13 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07076 for ; Thu, 14 Mar 2002 20:33:12 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7ACD3912E9; Thu, 14 Mar 2002 20:32:55 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D6939912EA; Thu, 14 Mar 2002 20:32:54 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A4E54912E9 for ; Thu, 14 Mar 2002 20:32:40 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7C79F5DDC0; Thu, 14 Mar 2002 20:32:40 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by segue.merit.edu (Postfix) with ESMTP id E9D0B5DDBC for ; Thu, 14 Mar 2002 20:32:39 -0500 (EST) Received: from mr5.exu.ericsson.se (mr5u3.ericy.com [208.237.135.124]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g2F1Wah03216; Thu, 14 Mar 2002 19:32:36 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g2F1WZJ28257; Thu, 14 Mar 2002 19:32:35 -0600 (CST) Received: from qpop.exu.ericsson.se (qpop [138.85.75.72]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id TAA08459; Thu, 14 Mar 2002 19:32:35 -0600 (CST) Received: from ericsson.com ([138.85.159.114]) by qpop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id TAA10745; Thu, 14 Mar 2002 19:32:34 -0600 (CST) Message-ID: <3C914E93.4B0C7C61@ericsson.com> Date: Thu, 14 Mar 2002 17:29:55 -0800 From: Tony Johansson X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Johan Johansson Cc: Sivasundar Ramamurthy , AAA Working Group , fredrik.johansson@ipunplugged.com Subject: Re: [AAA-WG]: [issue] Session-Timeout vs Authorization-Lifetime vs MIP-Key-Lifetime References: <3C90A026.6010705@ipunplugged.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Johan Johansson wrote: > Sivasundar Ramamurthy wrote: > > >-------------------------------------------------------------------------- > >if the key lifetime is allowed to be greater than the authorization > >lifetime (plus grace period), then the authorization at the (stateful) > >AAA server will expire even as the MN is re-registering. This will > >happen since the MN "knows" to use AAA only to request keys; it will > >re-register (re-authenticate) directly with the HA during the time the > >keys are alive. > > > >Thus even while the MN is happily registered (authenticated), the > >(stateful) AAA server will see that its authorization lifetime (plus > >grace period) has expired and will terminate its session and > >de-allocate the resources. Is'nt this a problem? > > > >-------------------------------------------------------------------------- > > > >[ I am interpreting the "cleaning up resources of the session" in > >section 8.10 as "terminating the session" ] > > > >If I am correct, then do we make an exception for Mobile IP sessions > >so that AAA servers will terminate sessions only when only when the > >key-lifetime expires? > > > Alternatively you can say that the AAA server sends the "Diameter > authorization lifetime" as the lifetime of the keys. There *is* a > certain terminological mixing taking place here which is confusing, but > as far as I've been able to conclude this is the intention: > > Authorization-Lifetime: As you say, this would be the interval with > which mobile ip reauthentications would take place and does not /should > not involve Diameter > > Mip-Key-Lifetime: The interval with which Diameter reauthorizations must > be done to get valid keys to perform the next mobile ip authentication. > > It would seem that in the Mobile IP application > Authorization-Grace-Period should be added to the MIP-Key-Lifetime. > Alternatively it could be added to the value in Authorization-Lifetime > before it is processed by the Mobile IP machinery. The draft doesn't say > which (avp only mentioned in ABNFs and occurence rules), but my vote is > on the first alternative. The MIP ONLY makes use of two timers the MIP-Key-Lifetime AVP and the Authorization-Lifetime AVP, as stated in mip-09 section 5.1 Authorization Lifetime vs. MIP Key Lifetime. Unfortunately, I missed to remove the Session-Timeout AVP in the Authorization-Grace-Period from the draft when I updated it. I'm sorry for this confusion. If no objections, they will be removed in the next version. /Tony > > > j From owner-aaa-wg@merit.edu Thu Mar 14 20:58:13 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07655 for ; Thu, 14 Mar 2002 20:58:12 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 24D0B912EA; Thu, 14 Mar 2002 20:58:01 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E459D912EB; Thu, 14 Mar 2002 20:58:00 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BA176912EA for ; Thu, 14 Mar 2002 20:57:59 -0500 (EST) Received: by segue.merit.edu (Postfix) id 937C05DDBC; Thu, 14 Mar 2002 20:57:49 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by segue.merit.edu (Postfix) with ESMTP id 0BE385DDBB for ; Thu, 14 Mar 2002 20:57:49 -0500 (EST) Received: from mr7.exu.ericsson.se (mr7u3.ericy.com [208.237.135.122]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g2F1vXh07941; Thu, 14 Mar 2002 19:57:33 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g2F1vXY29215; Thu, 14 Mar 2002 19:57:33 -0600 (CST) Received: from qpop.exu.ericsson.se (qpop [138.85.75.72]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id TAA10352; Thu, 14 Mar 2002 19:57:32 -0600 (CST) Received: from ericsson.com ([138.85.159.114]) by qpop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id TAA11095; Thu, 14 Mar 2002 19:57:31 -0600 (CST) Message-ID: <3C91546D.D2FC1FC6@ericsson.com> Date: Thu, 14 Mar 2002 17:54:53 -0800 From: Tony Johansson X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Sivasundar Ramamurthy Cc: AAA Working Group Subject: Re: [AAA-WG]: [issue] MN starting at Home References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Siva, please find comments embedded... /Tony Sivasundar Ramamurthy wrote: > Hello, > > I am not sure if this scenario has been considered by the Mobile IP > application draft. > > Some MN might employ the policy to turn off security in data > communication when at home. But the HA advertisement alone may not > enough for the MN to "decide" it is at home, since it could be > spoofed. So when the MN is starting at home, it would still rely on a > de-registration request and a successful reply in order to verify that > it IS at home. > > Assuming that this approach is reasonable, an MN starting at home > would recieve HA advertisments and would still send a de-registration > request to the HA. But since it does not have any keys to the HA, the > MN will make a AAA request, which can be processed by the HA only via > AAA (just like a request from a co-located MN). Well, you can not have a HA without a valid SA (i.e. MN-HA session keys). Thus, if your SA has expired you must re-register in order to keep the HA. So, your assumption above is not really possible within the scope of this draft. > > Does the draft implicity says that the HA cannot send AMR if the > request is not for a co-located MN (and not for de-registration)? If > yes, can we change it? > > If no, can we define some protocol by which the AAAH can respond to > such AMRs with an AMA, just like when the co-located flag was turned > on in the MIP-Feature-Vector? > > thanks! > > Siva From owner-aaa-wg@merit.edu Thu Mar 14 21:36:41 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08759 for ; Thu, 14 Mar 2002 21:36:40 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E29ED912EC; Thu, 14 Mar 2002 21:36:29 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9C507912EF; Thu, 14 Mar 2002 21:36:29 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7592A912EC for ; Thu, 14 Mar 2002 21:36:28 -0500 (EST) Received: by segue.merit.edu (Postfix) id 53E5F5DDBC; Thu, 14 Mar 2002 21:36:28 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from palrel11.hp.com (palrel11.hp.com [156.153.255.246]) by segue.merit.edu (Postfix) with ESMTP id 346595DDBB for ; Thu, 14 Mar 2002 21:36:28 -0500 (EST) Received: from hpindsra.cup.hp.com (hpindsra.cup.hp.com [15.13.104.190]) by palrel11.hp.com (Postfix) with ESMTP id 71B34600282; Thu, 14 Mar 2002 18:36:24 -0800 (PST) Received: from hpindsra (hpindsra [15.13.104.190]) by hpindsra.cup.hp.com with ESMTP (8.8.6 (PHNE_17190)/8.8.6 SMKit7.02) id SAA12774; Thu, 14 Mar 2002 18:36:23 -0800 (PST) Date: Thu, 14 Mar 2002 18:36:22 -0800 (PST) From: Sivasundar Ramamurthy X-Sender: sramam@hpindsra To: Tony Johansson Cc: AAA Working Group Subject: Re: [AAA-WG]: [issue] MN starting at Home In-Reply-To: <3C91546D.D2FC1FC6@ericsson.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi Tony, > please find comments embedded... > > /Tony > > Sivasundar Ramamurthy wrote: > > > Hello, > > > > I am not sure if this scenario has been considered by the Mobile IP > > application draft. > > > > Some MN might employ the policy to turn off security in data > > communication when at home. But the HA advertisement alone may not > > enough for the MN to "decide" it is at home, since it could be > > spoofed. So when the MN is starting at home, it would still rely on a > > de-registration request and a successful reply in order to verify that > > it IS at home. > > > > > Assuming that this approach is reasonable, an MN starting at home > > would recieve HA advertisments and would still send a de-registration > > request to the HA. But since it does not have any keys to the HA, the > > MN will make a AAA request, which can be processed by the HA only via > > AAA (just like a request from a co-located MN). > > Well, you can not have a HA without a valid SA (i.e. MN-HA session keys). > Thus, if your SA has expired you must re-register in order to keep the HA. But a MN can be configured with a static HA and to use AAA to get a MN-HA SA, right? If so, the scenario I am referring to is for such an MN that starts (boots up) at home and hears its HA adverts. It will rely on a de-reg request to confirm that it IS at home. But since it just booted up, it has no keys to the HA and will thus make the request a AAA request. Am I missing something that makes this scenario not possible? thanks, Siva > So, your assumption above is not really possible within the scope of this > draft. > > > > > > Does the draft implicity says that the HA cannot send AMR if the > > request is not for a co-located MN (and not for de-registration)? If > > yes, can we change it? > > > > If no, can we define some protocol by which the AAAH can respond to > > such AMRs with an AMA, just like when the co-located flag was turned > > on in the MIP-Feature-Vector? > > > > thanks! > > > > Siva > > From owner-aaa-wg@merit.edu Thu Mar 14 22:12:56 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09997 for ; Thu, 14 Mar 2002 22:12:55 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 18C0F912EF; Thu, 14 Mar 2002 22:12:44 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D6427912F0; Thu, 14 Mar 2002 22:12:43 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C467B912EF for ; Thu, 14 Mar 2002 22:12:42 -0500 (EST) Received: by segue.merit.edu (Postfix) id A20A85DDC0; Thu, 14 Mar 2002 22:12:42 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 5D2D45DDBB for ; Thu, 14 Mar 2002 22:12:42 -0500 (EST) Received: from Interlinknetworks.com (nat.interlinknetworks.com [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with ESMTP id 1BADB84 for ; Thu, 14 Mar 2002 22:12:42 -0500 (EST) Message-ID: <3C9166B5.E946DCC1@Interlinknetworks.com> Date: Thu, 14 Mar 2002 22:12:54 -0500 From: David Spence Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: AAA Working Group Subject: [AAA-WG]: [issue] RADIUS/Diameter Protocol Interactions Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Subject: [issue] RADIUS/Diameter Protocol Interactions Submitter name: David Spence Submitter email address: DSpence@Interlinknetworks.com Date first submitted: March 14, 2002 Reference: Document: NASREQ Comment type: T Priority: S Section: 9 Rationale/Explanation of issue: Section 9 of the nasreq draft addresses RADIUS/Diameter Protocol Interactions. This issue documents protocol interaction questions that still need to be addressed in section 9. 1. I believe there are errors regarding the generation of Origin-Host AVP when translating a RADIUS request to a Diameter request. 2. How do we translate a RADIUS accounting request with an Acct-Status-Type of Accounting-On or Accounting-Off? 3. How do we deal with the requirement that accounting AVPs be included in Accounting-Answer (ACA) messages when gatewaying between RADIUS and Diameter? (By the way, I've forgotten why do accounting AVPs appear in ACAs?) 4. Discuss how to translate a Diameter request not requiring authentication into a RADIUS request. 5. Specify what a gateway should do if it receives an Authorization-Lifetime AVP in a Diameter AA-Answer (AAA) message and needs to generate a RADIUS Access-Accept. The result will not be pretty. 6. Specify how a gateway should process a Diameter Re-Auth-Request. It will have to generate an answer saying that re-auth is not possible. 7. Specify how a gateway should process a Diameter Abort-Session-Request (ASR) message. It will have to generate an answer saying that aborting the session is not possible. 8. In Diameter, the Reply-Message AVP may have a value field longer than 253 bytes. If so, it will have to be split into multiple Reply-Message attributes when creating the corresponding RADIUS message. However the converse -- recombining multiple Reply-Message attributes into a single Reply-Message AVP -- is not required. There may be other attributes that fall into the same category. Generally, any Diameter AVP with a type based on octet string where the AVP Code is less than 256 and the length of the AVP data field is greater than 253 will need to be split into multiple RADIUS attributes. 9. When processing a Diameter AA-Request (AAR) message containing a Session-Timeout AVP or an Idle-Timeout AVP, drop these attributes when generating the corresponding RADIUS Access-Request. These attributes are allowed in Diameter requests as a hint to the server but are not allowed in RADIUS requests. 10. Explain how to encapsulate and decapsulate the RADIUS Vendor-Specific attribute. (This item is the same as issue 255.) 11. Add an explicit list of RADIUS attributes that MUST NOT appear in a Diameter message. There are several of these that have been superseded by Diameter AVPs of one sort or another. In some cases there is already text in section 9 explaining how to handle these attributes. We need to make sure all are covered. The following is the list of attributes I *think* should be excluded from Diameter. CODE NAME RADIUS RFC ------ ---- ---------- 3 CHAP-Password RFC 2865 26 Vendor-Specific RFC 2865 40 Acct-Status-Type RFC 2866 42 Acct-Input-Octets RFC 2866 43 Acct-Output-Octets RFC 2866 47 Acct-Input-Packets RFC 2866 48 Acct-Output-Packets RFC 2866 49 Acct-Terminate-Cause RFC 2866 52 Acct-Input-Gigawords RFC 2869 53 Acct-Output-Gigawords RFC 2869 80 Message-Authenticator RFC 2869 Requested change: Just do it! -- David Spence email: DSpence@Interlinknetworks.com Interlink Networks, Inc. phone: (734) 821-1203 775 Technology Drive, Suite 200 fax: (734) 821-1235 Ann Arbor, MI 48108 U.S.A. From owner-aaa-wg@merit.edu Thu Mar 14 22:19:44 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10119 for ; Thu, 14 Mar 2002 22:19:44 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3133D9121D; Thu, 14 Mar 2002 22:19:28 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0351C912F0; Thu, 14 Mar 2002 22:19:27 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 175B79121D for ; Thu, 14 Mar 2002 22:19:27 -0500 (EST) Received: by segue.merit.edu (Postfix) id F18495DDC0; Thu, 14 Mar 2002 22:19:26 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id DD6A35DDBB for ; Thu, 14 Mar 2002 22:19:26 -0500 (EST) Received: from Interlinknetworks.com (nat.interlinknetworks.com [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with ESMTP id 5E6B784 for ; Thu, 14 Mar 2002 22:19:26 -0500 (EST) Message-ID: <3C91684A.40546E35@Interlinknetworks.com> Date: Thu, 14 Mar 2002 22:19:38 -0500 From: David Spence Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: AAA Working Group Subject: [AAA-WG]: [issue] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Subject: [issue] Fix NASREQ references Submitter name: David Spence Submitter email address: DSpence@Interlinknetworks.com Date first submitted: March 14, 2002 Reference: Document: NASREQ Comment type: E Priority: S Section: Rationale/Explanation of issue: Requested change: Classify all references as normative/nonnormative. -- David Spence email: DSpence@Interlinknetworks.com Interlink Networks, Inc. phone: (734) 821-1203 775 Technology Drive, Suite 200 fax: (734) 821-1235 Ann Arbor, MI 48108 U.S.A. From owner-aaa-wg@merit.edu Thu Mar 14 22:48:36 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11817 for <aaa-archive@odin.ietf.org>; Thu, 14 Mar 2002 22:48:36 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 0EC4B91225; Thu, 14 Mar 2002 22:48:20 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6FCE3912F0; Thu, 14 Mar 2002 22:48:19 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9A70F91225 for <aaa-wg@trapdoor.merit.edu>; Thu, 14 Mar 2002 22:48:17 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7CEA45DDC4; Thu, 14 Mar 2002 22:48:17 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by segue.merit.edu (Postfix) with ESMTP id E71645DDB3 for <aaa-wg@merit.edu>; Thu, 14 Mar 2002 22:48:16 -0500 (EST) Received: from mr5.exu.ericsson.se (mr5u3.ericy.com [208.237.135.124]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g2F3mGh00006; Thu, 14 Mar 2002 21:48:16 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g2F3mGJ12862; Thu, 14 Mar 2002 21:48:16 -0600 (CST) Received: from qpop.exu.ericsson.se (qpop [138.85.75.72]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id VAA19323; Thu, 14 Mar 2002 21:48:15 -0600 (CST) Received: from ericsson.com ([138.85.159.114]) by qpop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id VAA12626; Thu, 14 Mar 2002 21:48:14 -0600 (CST) Message-ID: <3C916E60.87511B9B@ericsson.com> Date: Thu, 14 Mar 2002 19:45:36 -0800 From: Tony Johansson <tony.johansson@ericsson.com> X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Sivasundar Ramamurthy <sramam@cup.hp.com> Cc: AAA Working Group <aaa-wg@merit.edu> Subject: Re: [AAA-WG]: [issue] MN starting at Home References: <Pine.HPX.4.10.10203141814100.11769-100000@hpindsra> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Sivasundar Ramamurthy wrote: > Hi Tony, > > > please find comments embedded... > > > > /Tony > > > > Sivasundar Ramamurthy wrote: > > > > > Hello, > > > > > > I am not sure if this scenario has been considered by the Mobile IP > > > application draft. > > > > > > Some MN might employ the policy to turn off security in data > > > communication when at home. But the HA advertisement alone may not > > > enough for the MN to "decide" it is at home, since it could be > > > spoofed. So when the MN is starting at home, it would still rely on a > > > de-registration request and a successful reply in order to verify that > > > it IS at home. > > > > > > > > Assuming that this approach is reasonable, an MN starting at home > > > would recieve HA advertisments and would still send a de-registration > > > request to the HA. But since it does not have any keys to the HA, the > > > MN will make a AAA request, which can be processed by the HA only via > > > AAA (just like a request from a co-located MN). > > > > Well, you can not have a HA without a valid SA (i.e. MN-HA session keys). > > Thus, if your SA has expired you must re-register in order to keep the HA. > > But a MN can be configured with a static HA and to use AAA to get > a MN-HA SA, right? No, if you have a static HA configured you would also have a static MN-HA SA. Thus, Mobile IPv4. In the Diameter and Mobile IPv4 case, the MN may request to get a specific HA, but the AAAH may overrun that request and assign another HA. So, the MN does not really know its assigned HA until the AAAH has approved it and distributed session keys (SAs). IMHO, it would be wrong to say that the MN can really know its HA without a valid MN-HA SA in the case of Diameter and Mobile IPv4. /Tony > > > If so, the scenario I am referring to is for such an MN that starts > (boots up) at home and hears its HA adverts. It will rely on a de-reg > request to confirm that it IS at home. > But since it just booted up, it > has no keys to the HA and will thus make the request a AAA request. > > > Am I missing something that makes this scenario not possible? > > thanks, > > Siva > > > So, your assumption above is not really possible within the scope of this > > draft. > > > > > > > > > > Does the draft implicity says that the HA cannot send AMR if the > > > request is not for a co-located MN (and not for de-registration)? If > > > yes, can we change it? > > > > > > If no, can we define some protocol by which the AAAH can respond to > > > such AMRs with an AMA, just like when the co-located flag was turned > > > on in the MIP-Feature-Vector? > > > > > > thanks! > > > > > > Siva > > > > From owner-aaa-wg@merit.edu Fri Mar 15 05:26:46 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25501 for <aaa-archive@odin.ietf.org>; Fri, 15 Mar 2002 05:26:46 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D24279122A; Fri, 15 Mar 2002 05:26:30 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9E2AF912F1; Fri, 15 Mar 2002 05:26:30 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7777C9122A for <aaa-wg@trapdoor.merit.edu>; Fri, 15 Mar 2002 05:26:29 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5736C5DE0D; Fri, 15 Mar 2002 05:26:29 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by segue.merit.edu (Postfix) with ESMTP id 3C1F05DDF7 for <aaa-wg@merit.edu>; Fri, 15 Mar 2002 05:26:27 -0500 (EST) Received: from ipunplugged.com (catsandlogs.local.ipunplugged.com [192.168.4.29]) by mailgw.ipunplugged.com (8.9.3/8.9.3) with ESMTP id LAA32553; Fri, 15 Mar 2002 11:21:39 +0100 Message-ID: <3C91D9BA.8060000@ipunplugged.com> Date: Fri, 15 Mar 2002 12:23:38 +0100 From: Johan Johansson <johanj@ipunplugged.com> User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020204 X-Accept-Language: en-us MIME-Version: 1.0 To: Tony Johansson <tony.johansson@ericsson.com> Cc: Sivasundar Ramamurthy <sramam@cup.hp.com>, AAA Working Group <aaa-wg@merit.edu>, fredrik.johansson@ipunplugged.com Subject: Re: [AAA-WG]: [issue] Session-Timeout vs Authorization-Lifetime vs MIP-Key-Lifetime References: <Pine.HPX.4.10.10203121135330.8820-100000@hpindsra> <3C90A026.6010705@ipunplugged.com> <3C914E93.4B0C7C61@ericsson.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Tony Johansson wrote: >> >>It would seem that in the Mobile IP application >>Authorization-Grace-Period should be added to the MIP-Key-Lifetime. >>Alternatively it could be added to the value in Authorization-Lifetime >>before it is processed by the Mobile IP machinery. The draft doesn't say >>which (avp only mentioned in ABNFs and occurence rules), but my vote is >>on the first alternative. >> > >The MIP ONLY makes use of two timers the MIP-Key-Lifetime AVP and the >Authorization-Lifetime AVP, as stated in mip-09 section 5.1 Authorization >Lifetime vs. MIP Key Lifetime. Unfortunately, I missed to remove the >Session-Timeout AVP in the Authorization-Grace-Period from the draft when I >updated it. > >I'm sorry for this confusion. If no objections, they will be removed in the >next version. > No, no, getting rid of the grace period sounds like a dream come true. j From owner-aaa-wg@merit.edu Fri Mar 15 07:27:14 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27268 for <aaa-archive@odin.ietf.org>; Fri, 15 Mar 2002 07:27:14 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 60DE2912F1; Fri, 15 Mar 2002 07:26:59 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 38721912F2; Fri, 15 Mar 2002 07:26:59 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id EC01D912F1 for <aaa-wg@trapdoor.merit.edu>; Fri, 15 Mar 2002 07:26:57 -0500 (EST) Received: by segue.merit.edu (Postfix) id C869F5DDBB; Fri, 15 Mar 2002 07:26:57 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by segue.merit.edu (Postfix) with ESMTP id E034A5DD94 for <aaa-wg@merit.edu>; Fri, 15 Mar 2002 07:26:56 -0500 (EST) Received: from fredrikj (hotel-33.local.ipunplugged.com [192.168.8.33]) by mailgw.ipunplugged.com (8.9.3/8.9.3) with SMTP id NAA02787; Fri, 15 Mar 2002 13:22:12 +0100 From: "Fredrik Johansson" <fredrik.johansson@ipunplugged.com> To: "Tony Johansson" <tony.johansson@ericsson.com>, "Sivasundar Ramamurthy" <sramam@cup.hp.com> Cc: "AAA Working Group" <aaa-wg@merit.edu> Subject: RE: [AAA-WG]: [issue] MN starting at Home Date: Fri, 15 Mar 2002 13:25:19 +0100 Message-ID: <MJEMJBGGCLLDLFFAHLJKAEDMEBAA.fredrik.johansson@ipunplugged.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <3C916E60.87511B9B@ericsson.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Tony, see comments inline. /fredrik >-----Original Message----- >From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of >Tony Johansson >Sent: den 15 mars 2002 04:46 >To: Sivasundar Ramamurthy >Cc: AAA Working Group >Subject: Re: [AAA-WG]: [issue] MN starting at Home > > > > >Sivasundar Ramamurthy wrote: > >> Hi Tony, >> >> > please find comments embedded... >> > >> > /Tony >> > >> > Sivasundar Ramamurthy wrote: >> > >> > > Hello, >> > > >> > > I am not sure if this scenario has been considered by the Mobile IP >> > > application draft. >> > > >> > > Some MN might employ the policy to turn off security in data >> > > communication when at home. But the HA advertisement alone may not >> > > enough for the MN to "decide" it is at home, since it could be >> > > spoofed. So when the MN is starting at home, it would still rely on a >> > > de-registration request and a successful reply in order to >verify that >> > > it IS at home. >> > >> > > >> > > Assuming that this approach is reasonable, an MN starting at home >> > > would recieve HA advertisments and would still send a de-registration >> > > request to the HA. But since it does not have any keys to the HA, the >> > > MN will make a AAA request, which can be processed by the HA only via >> > > AAA (just like a request from a co-located MN). >> > >> > Well, you can not have a HA without a valid SA (i.e. MN-HA >session keys). >> > Thus, if your SA has expired you must re-register in order to >keep the HA. >> >> But a MN can be configured with a static HA and to use AAA to get >> a MN-HA SA, right? > >No, if you have a static HA configured you would also have a >static MN-HA SA. >Thus, Mobile IPv4. Why, it must be possible to have a "fallback HA" configured. Just consider the co-located case, how would the MN register if it doesn't have a "default" HA? It doesn't speak Diameter and it has no FA to send the request to. i.e. it has to send the request directly to a HA. > >In the Diameter and Mobile IPv4 case, the MN may request to get a >specific HA, >but the AAAH may overrun that request and assign another HA. So, >the MN does not >really know its assigned HA until the AAAH has approved it and distributed >session keys (SAs). > >IMHO, it would be wrong to say that the MN can really know its HA without a >valid MN-HA SA in the case of Diameter and Mobile IPv4. No, why shouldn't it get session keys for the session with the use of diameter as in a FA registered MN? > > > >/Tony > >> >> >> If so, the scenario I am referring to is for such an MN that starts >> (boots up) at home and hears its HA adverts. It will rely on a de-reg >> request to confirm that it IS at home. > >> But since it just booted up, it >> has no keys to the HA and will thus make the request a AAA request. > >> >> >> Am I missing something that makes this scenario not possible? >> >> thanks, >> >> Siva >> >> > So, your assumption above is not really possible within the >scope of this >> > draft. >> > >> > >> > > >> > > Does the draft implicity says that the HA cannot send AMR if the >> > > request is not for a co-located MN (and not for de-registration)? If >> > > yes, can we change it? >> > > >> > > If no, can we define some protocol by which the AAAH can respond to >> > > such AMRs with an AMA, just like when the co-located flag was turned >> > > on in the MIP-Feature-Vector? >> > > >> > > thanks! >> > > >> > > Siva >> > >> > From owner-aaa-wg@merit.edu Fri Mar 15 10:35:16 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01713 for <aaa-archive@lists.ietf.org>; Fri, 15 Mar 2002 10:35:15 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9A34C9122C; Fri, 15 Mar 2002 10:35:02 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 64147912F7; Fri, 15 Mar 2002 10:35:02 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2D2A29122C for <aaa-wg@trapdoor.merit.edu>; Fri, 15 Mar 2002 10:35:01 -0500 (EST) Received: by segue.merit.edu (Postfix) id 07BE45DDE9; Fri, 15 Mar 2002 10:35:01 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 5326D5DDAB for <aaa-wg@merit.edu>; Fri, 15 Mar 2002 10:35:00 -0500 (EST) Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g2FFZAZ22737 for <aaa-wg@merit.edu>; Fri, 15 Mar 2002 17:35:10 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id <T59a7773dcaac158f22077@esvir02nok.ntc.nokia.com>; Fri, 15 Mar 2002 17:34:59 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 15 Mar 2002 17:34:58 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Getting to done... Date: Fri, 15 Mar 2002 17:34:58 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64C4D@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Getting to done... Thread-Index: AcHLvI0Koz54E8b7R2GO2HVcKHfWAQAeigyA From: <john.loughney@nokia.com> To: <aboba@internaut.com>, <aaa-wg@merit.edu> X-OriginalArrivalTime: 15 Mar 2002 15:34:58.0993 (UTC) FILETIME=[F7274210:01C1CC36] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA01713 Hi Bernard, Speaking with a my editor's hat on, I'd like to say, however, that we should focus on show stoppers, things which could cause interoperability problems. Minor editorial concerns can be addressed, but new features, etc. should not (in my opinion) be considered. thanks, John > -----Original Message----- > From: ext Bernard Aboba [mailto:aboba@internaut.com] > Sent: 15 March, 2002 02:17 > To: aaa-wg@merit.edu > Subject: [AAA-WG]: Getting to done... > > > Judging by the status of the issues list, I believe that we are within > sight of completing work on the Diameter Base, Transport and MIP > documents. The current gameplan is to have only one more WG > last call on these documents, to complete 4/15/02. > > This means that time is running out on reviewing these > documents. If you > haven't read the latest drafts in depth and sent *all* your > comments in, > you need to do this NOW. One of the goals of IETF 53 is to resolve all > open issues on these documents, so that at the end of completion of WG > last call (approximately 4/15/02), we will be ready to > forward documents > to the IESG. > > In the spirit of various states that are assigning the same book to > everyone to read, I would like to suggest that members of the > AAA WG add > the Diameter Base, Transport and MIP drafts to their reading > lists, and > complete a read through prior to AAA WG meeting at IETF 53, > posting your > issues to the mailing list. I will keep the issues list updated as the > issues come in, and we will cover all the open issues at IETF 53. > > Since this is effectively your last opportunity to comment on Base, > Transport and MIP documents, please spend that extra bit of > effort in your > read through. It should be expected that many of the comments will be > editorial -- don't be hesitant about pointing out spelling mistakes, > etc. Also, as usual we are open to technical comments as well, though > given the advanced status of the specification, the bar is > very high for > major changes at this point. > > Given that the Diameter Base, Transport and MIP specs are > eagerly awaited > by our partners in 3GPP and 3GPP2, time is running out to complete the > specifications in a timely way. Let's make this next pass through the > Base, Transport and MIP documents our last. > > From owner-aaa-wg@merit.edu Fri Mar 15 11:36:54 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03634 for <aaa-archive@lists.ietf.org>; Fri, 15 Mar 2002 11:36:53 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 48456912F8; Fri, 15 Mar 2002 11:36:43 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 119AC912F9; Fri, 15 Mar 2002 11:36:42 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CD50D912F8 for <aaa-wg@trapdoor.merit.edu>; Fri, 15 Mar 2002 11:36:41 -0500 (EST) Received: by segue.merit.edu (Postfix) id AFD425DDAB; Fri, 15 Mar 2002 11:36:41 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from dzick.interlinknetworks.com (nat.interlinknetworks.com [198.108.5.3]) by segue.merit.edu (Postfix) with ESMTP id 821125DD99 for <aaa-wg@merit.edu>; Fri, 15 Mar 2002 11:36:41 -0500 (EST) Received: from interlinknetworks.com (localhost.localdomain [127.0.0.1]) by dzick.interlinknetworks.com (8.11.0/8.11.0) with ESMTP id g2FGU1O09349; Fri, 15 Mar 2002 11:30:01 -0500 Message-ID: <3C922188.CAA5D041@interlinknetworks.com> Date: Fri, 15 Mar 2002 11:30:00 -0500 From: Don Zick <dzick@interlinknetworks.com> Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: stephen.farrell@baltimore.ie Cc: Bernard Aboba <aboba@internaut.com>, aaa-wg@merit.edu Subject: Re: [AAA-WG]: CMS Security questions References: <3C8E46CF.4A527B10@interlinknetworks.com> <3C908361.DE44FDEE@baltimore.ie> Content-Type: text/plain; charset=iso-8859-1 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id LAA03634 Hi Stephen, comments inline... Stephen Farrell wrote: > Don, > > Thanks for these. Let's create an omnibus issue for 'em all. > Responses embedded below. > > Bernard - will you make this a new CMS issue? (Also #307 can, > I believe, be closed/rejected, given Don's mail [1]). > > Stephen. > > [1] http://www.merit.edu/mail.archives/aaa-wg/msg03431.html > > Submitter name: Stephen Farrell > Submitter email address: stephen.farrell@baltimore.ie > Date first submitted: March 14, 2002 > Reference: > Document: CMS > Comment type: T/E > Priority: 1 > Section: various > Rationale/Explanation of issue: > > Don Zick wrote: > > > > Hi Stephen, > > > > Before I go hog-wild submitting any more issues could you please address > > the following questions concerning the Diameter CMS Security draft? > > > > 1. In section 3.1, it states: > > > > We use Diameter Security Association Request (DSAR) and Diameter > > Security Association Answer (DSAA) messages to establish a DSA, > > which > > specifies which AVPs should be encrypted, signed or both, as well > > as > > which public key(s) to use. > > > > Now that the expected-signed and expected-encrypted AVPs have been > > removed, shouldn't the text "which specifies which AVPs should be > > encrypted, signed or both" be removed? > > Yes. Will do. > > > > > 2. The AVP occurrence rules table in section 8 shows that at most 1 > > AAA-Node-Cert AVP may appear in a DSAR or a DSAA. However, the > > ABNF definition for the DSAR and DSAA indicate that any number > > of AAA-Node-Cert AVPs may appear. Is the AVP occurrene rules > > table correct? If so, shouldn't "public key(s)" mentioned in > > item 1 really be "public key"? > > We do want to allow >1 certificate to be included (we're just > insisting they all be verifiable from a single CA-Chain). > > So, I'd go for changing the avp occurrence rule and leaving the > text and abnf alone. Okay > > > > 3. In section 3.1, it states: > > > > - Its local policy allows the given TTL, realm, AVP protection > > expectations, certification status, and other parameters. > > > > Now that the expected-signed and expected-encrypted AVPs have been > > removed, shouldn't the text "AVP protection expectations" be removed? > > Yes. > > > 4. In section 3.1 it states: > > > > ...the destination node returns the DSAA message which contains: > > ... > > - public key certificates for the Diameter servers in the > > realm... > > > > This goes back to question #2. Must a Diameter server know all of > > the certificates for all servers in its realm? Why is that useful > > when the Diameter node is only establishing a DSA with a single > > server? > > Fixed with #2. > > > > > 5. In section 3.1 it states: > > > > The DSAA MUST include the CMS-Signed-Data, signed by a Diameter > > agent > > or server within the user's realm, to prevent an intermediate node > > from modifying the protection expectations for AVPs. > > > > Shouldn't this requirement be removed now that expected-signed and > > expected-encrypted AVPs have been removed? > > Hmm...That's a reasonable point, but I'd (somewhat less than entirely > convincingly) argue to stick with the DSAA MUST be signed position for > the following reasons: > > - A node producing a DSAA really has to have a private key for anything > useful to subsequently happen, therefore requiring the signature > doesn't require any additional code or administration, just the few > additional CPU cycles required for signing this message. > - The signed AVPs from the DSAA (in particular the DSA-TTL) can't be > modified by intermediaies, though that's not much of a threat > compared to modifying expected-* AVPs, I agree. > - It provides some assurance that the originator of the message is > the entity that (the CA said) has the relevant private key. However, > for this to be better, a random challenge should be added to > the DSAR and (that or a digest of the DSAR) reflected back in > the DSAA as a signed AVP (I was thinking of proposing this as > an addition to -04 but didn't). I don't have an issue with requiring the signing, but can the text "to prevent an intermediate node from modifying the protection expectations for AVPs" be removed? > > > > > > 6. In section 3.2 it states: > > > > For multiple Diameter servers within a realm that share a public > > key, > > each server's identity is encoded in the subjectAltName extension. > > This allows any server within a realm to decrypt AVPs intended for > > that realm. > > > > Why would a server that is not part of the DSA ever decrypt AVPs? > > Various forms of load-balancing I guess. > > > Wouldn't there be potential problems with content encryption key > > reuse? > > Yes. As with reboots, so nothing new there. > > > 7. In section 4.4, the PDSR is defined. When an access device sends > > a PDSR to a local proxy, the local proxy will establish a DSA with > > a server in the DSAR-Target-Realm. If the access device sends an > > authentication request to the local proxy and the authentication > > request contains Destination-Realm but does not contain > > Destination-Host, must the local proxy add the Destination-Host > > AVP to the message to ensure that it is routed to the server in > > the Destination-Realm that has the DSA? If this is a requirement > > I think it should be stated explicitly. > > I guess we do need more text here and will add that. I guess I > should change "authentication request" to "any Diameter message" in > the above though? Okay. One other concern is that the Destination-Host AVP has the 'P' bit set. If this AVP is added by a local proxy won't the proxy have to break the rules and not set the 'P' bit? Otherwise the Destination-Host will not be able to validate the CMS-Signed-Data AVP from the Origin-Host. This brings up a bigger issue. Suppose you have 3 Diameter nodes, A, B, and C. Suppose there is a DSA between A and C and that all messages between A and C are routed through B. Can server B ever add AVPs with the 'P' bit set to a message? It seems not because then the CMS-Signed-Data AVP created by A and C could no longer be validated. Is the CMS Security application supposed to allow intermediate nodes to add AVPs and sign them? > > > > 8. Section 6.3 provides some example encodings for encrypted and > > signed AVPs. The examples indicate that different Diameter > > nodes can have different encryption and signing requirements. > > Aren't these examples misleading now that the expected-signed > > and expected-encrypted AVPs have been removed? (All Diameter > > nodes share the same encryption and signing requirements.) > > The examples are based on requirements on AVPs which can be determined > from the RFC or by an astrologer. So I disagree that this is related > to the expected-* removal. Okay, I see. > > > > 9. The AVP occurrence rules table and ABNF message definitions > > have some inconsistencies: > > > > DSAR ABNF DSAR Occurrence rules table > > AAA-Node-Cert * 0-1 > > Was the above meant to be in your mail? Yes, this was the one inconsistency I noticed in the DSAR message. > > > > DSAA ABNF DSAA Occurrence rules table > > AAA-Node-Cert * 0-1 > should be 0+ > > > OCSP-Responses * 1+ > should be 0+ > > Origin-Realm 0*1 1 > > Redirect-Host not listed 0+ > > Redirect-Host-Usage not listed 0-1 > > Redirect-Max- > > Cache-Time not listed 0-1 > I don't know what's right for these. Want to suggest > something? Origin-Realm is a 1 for all the other DSA message and I think it should be 1 for the DSAA. I *think* the redirect host AVPs should be allowed in the DSAA as specified by the occurrence rules table, and should be added to the DSAA ABNF. I hope someone with more knowledge of redirect servers could chime in here. > > > > 10. DSAA ABNF has Local-CA-info surrounded by curly brackets. I > > think square brackets are correct. > > Disagree. Doesn't *{foo} mean "one or more", whereas *[foo] means > "zero or more". One or more is what's wanted. Okay, then there is another inconsistency between the DSAA ABNF and the DSAA occurrence rule table settings. Please change the occurrence rules table for the DSAA to indicate Local-CA-info can occur 1+ times instead of 0+ times. > > > > > > 11.Origin-State-Id listed as Original-State-Id in AVP occurrence table. > > I'm guessing that Origin-State-Id is the right name? Yes > > > > 12.Section 3.1 states: > > > > Once the DSA is in place, any Diameter messages created by a DSA > > peer > > that has a private key MUST contain a signature over all AVPs whose > > > > definition states that their 'P' bit MAY be set. > > > > I think the CMS-Encrypted-Data AVP is an exception to this rule. It > > only requires a signature if any of the encrypted AVPs contained in > > the CMS-Encrypted-Data AVP require signing. > > Good point. I'll add text indicating this. > > > 13.Some typos: > > > > Section 1: "two different set of messages" > > "two different sets of messages" > > > > Section 1.2 "DSA would the NAS" > > "DSA would be the NAS" > > > > "initiate an DSAR" > > "initiate a DSAR" > > > > Section 1.3 "such an an aggregating relay" > > "such as an aggregating relay" > > > > "recelived" > > "received" > > > > Section 3.1 "MUST re-validated" > > "MUST be re-validated" > > > > "implemetors" > > "implementors" > > > > Section 5 "CAA" (in diagram) > > "CEA" > > > > "issues an DSAR message" > > "issues a DSAR message" > > > > Section 6.11 "lenght" > > "length" > > > Thanks, > Stephen. > > -- > ____________________________________________________________ > Stephen Farrell > Baltimore Technologies, tel: (direct line) +353 1 881 6716 > 39 Parkgate Street, fax: +353 1 881 7000 > Dublin 8. mailto:stephen.farrell@baltimore.ie > Ireland http://www.baltimore.com Thanks, Don From owner-aaa-wg@merit.edu Fri Mar 15 11:44:04 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03967 for <aaa-archive@lists.ietf.org>; Fri, 15 Mar 2002 11:44:03 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id CF99D912F9; Fri, 15 Mar 2002 11:43:51 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 96F78912FA; Fri, 15 Mar 2002 11:43:51 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4A2E8912F9 for <aaa-wg@trapdoor.merit.edu>; Fri, 15 Mar 2002 11:43:50 -0500 (EST) Received: by segue.merit.edu (Postfix) id 31F905DDC0; Fri, 15 Mar 2002 11:43:50 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from ocasey.baltimore.com (ocasey.baltimore.com [193.41.17.101]) by segue.merit.edu (Postfix) with ESMTP id 709FD5DDB4 for <aaa-wg@merit.edu>; Fri, 15 Mar 2002 11:43:49 -0500 (EST) Received: from Baltimore-FW1 ([172.19.1.1]) by ocasey.baltimore.com (8.11.6/8.9.3) with SMTP id g2FGhmb29682 for <aaa-wg@merit.edu>; Fri, 15 Mar 2002 16:43:48 GMT Received: from Baltimore-FW1 (wilde-i-1.ie.baltimore.com) by emeairlsw1.baltimore.com (Content Technologies SMTPRS 4.2.5) with SMTP id <T59a743bc5a0a9919350f8@emeairlsw1.baltimore.com> for <aaa-wg@merit.edu>; Fri, 15 Mar 2002 16:38:43 +0000 Received: from baltimore.ie (wks140-4.ie.baltimore.com [10.153.4.140]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id QAA04134; Fri, 15 Mar 2002 16:43:45 GMT Message-ID: <3C9224CE.725013B4@baltimore.ie> Date: Fri, 15 Mar 2002 16:43:58 +0000 From: Stephen Farrell <stephen.farrell@baltimore.ie> Reply-To: stephen.farrell@baltimore.ie Organization: Baltimore Technologies Ltd. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Don Zick <dzick@interlinknetworks.com> Cc: Bernard Aboba <aboba@internaut.com>, aaa-wg@merit.edu Subject: Re: [AAA-WG]: CMS Security questions References: <3C8E46CF.4A527B10@interlinknetworks.com> <3C908361.DE44FDEE@baltimore.ie> <3C922188.CAA5D041@interlinknetworks.com> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Don, I think this mail might close down this batch issue. Couple of things in-line below. Stephen. Don Zick wrote: > > Hi Stephen, > > comments inline... > > Stephen Farrell wrote: > > > Don, > > > > Thanks for these. Let's create an omnibus issue for 'em all. > > Responses embedded below. > > > > Bernard - will you make this a new CMS issue? (Also #307 can, > > I believe, be closed/rejected, given Don's mail [1]). > > > > Stephen. > > > > [1] http://www.merit.edu/mail.archives/aaa-wg/msg03431.html > > > > Submitter name: Stephen Farrell > > Submitter email address: stephen.farrell@baltimore.ie > > Date first submitted: March 14, 2002 > > Reference: > > Document: CMS > > Comment type: T/E > > Priority: 1 > > Section: various > > Rationale/Explanation of issue: > > > > Don Zick wrote: > > > > > > Hi Stephen, > > > > > > Before I go hog-wild submitting any more issues could you please address > > > the following questions concerning the Diameter CMS Security draft? > > > > > > 1. In section 3.1, it states: > > > > > > We use Diameter Security Association Request (DSAR) and Diameter > > > Security Association Answer (DSAA) messages to establish a DSA, > > > which > > > specifies which AVPs should be encrypted, signed or both, as well > > > as > > > which public key(s) to use. > > > > > > Now that the expected-signed and expected-encrypted AVPs have been > > > removed, shouldn't the text "which specifies which AVPs should be > > > encrypted, signed or both" be removed? > > > > Yes. Will do. > > > > > > > > 2. The AVP occurrence rules table in section 8 shows that at most 1 > > > AAA-Node-Cert AVP may appear in a DSAR or a DSAA. However, the > > > ABNF definition for the DSAR and DSAA indicate that any number > > > of AAA-Node-Cert AVPs may appear. Is the AVP occurrene rules > > > table correct? If so, shouldn't "public key(s)" mentioned in > > > item 1 really be "public key"? > > > > We do want to allow >1 certificate to be included (we're just > > insisting they all be verifiable from a single CA-Chain). > > > > So, I'd go for changing the avp occurrence rule and leaving the > > text and abnf alone. > > Okay > > > > > > > > 3. In section 3.1, it states: > > > > > > - Its local policy allows the given TTL, realm, AVP protection > > > expectations, certification status, and other parameters. > > > > > > Now that the expected-signed and expected-encrypted AVPs have been > > > removed, shouldn't the text "AVP protection expectations" be removed? > > > > Yes. > > > > > 4. In section 3.1 it states: > > > > > > ...the destination node returns the DSAA message which contains: > > > ... > > > - public key certificates for the Diameter servers in the > > > realm... > > > > > > This goes back to question #2. Must a Diameter server know all of > > > the certificates for all servers in its realm? Why is that useful > > > when the Diameter node is only establishing a DSA with a single > > > server? > > > > Fixed with #2. > > > > > > > > 5. In section 3.1 it states: > > > > > > The DSAA MUST include the CMS-Signed-Data, signed by a Diameter > > > agent > > > or server within the user's realm, to prevent an intermediate node > > > from modifying the protection expectations for AVPs. > > > > > > Shouldn't this requirement be removed now that expected-signed and > > > expected-encrypted AVPs have been removed? > > > > Hmm...That's a reasonable point, but I'd (somewhat less than entirely > > convincingly) argue to stick with the DSAA MUST be signed position for > > the following reasons: > > > > - A node producing a DSAA really has to have a private key for anything > > useful to subsequently happen, therefore requiring the signature > > doesn't require any additional code or administration, just the few > > additional CPU cycles required for signing this message. > > - The signed AVPs from the DSAA (in particular the DSA-TTL) can't be > > modified by intermediaies, though that's not much of a threat > > compared to modifying expected-* AVPs, I agree. > > - It provides some assurance that the originator of the message is > > the entity that (the CA said) has the relevant private key. However, > > for this to be better, a random challenge should be added to > > the DSAR and (that or a digest of the DSAR) reflected back in > > the DSAA as a signed AVP (I was thinking of proposing this as > > an addition to -04 but didn't). > > I don't have an issue with requiring the signing, but can the text "to > prevent an intermediate node from modifying the protection expectations for > AVPs" be removed? Sure. > > > > > > > > > > > 6. In section 3.2 it states: > > > > > > For multiple Diameter servers within a realm that share a public > > > key, > > > each server's identity is encoded in the subjectAltName extension. > > > This allows any server within a realm to decrypt AVPs intended for > > > that realm. > > > > > > Why would a server that is not part of the DSA ever decrypt AVPs? > > > > Various forms of load-balancing I guess. > > > > > Wouldn't there be potential problems with content encryption key > > > reuse? > > > > Yes. As with reboots, so nothing new there. > > > > > 7. In section 4.4, the PDSR is defined. When an access device sends > > > a PDSR to a local proxy, the local proxy will establish a DSA with > > > a server in the DSAR-Target-Realm. If the access device sends an > > > authentication request to the local proxy and the authentication > > > request contains Destination-Realm but does not contain > > > Destination-Host, must the local proxy add the Destination-Host > > > AVP to the message to ensure that it is routed to the server in > > > the Destination-Realm that has the DSA? If this is a requirement > > > I think it should be stated explicitly. > > > > I guess we do need more text here and will add that. I guess I > > should change "authentication request" to "any Diameter message" in > > the above though? > > Okay. One other concern is that the Destination-Host AVP has the 'P' bit set. > If this AVP is added by a local proxy won't the proxy have to break the rules > and not set the 'P' bit? Otherwise the Destination-Host will not be able to > validate the CMS-Signed-Data AVP from the Origin-Host. > > This brings up a bigger issue. Suppose you have 3 Diameter nodes, A, B, and > C. Suppose there is a DSA between A and C and that all messages between A > and C are routed through B. Can server B ever add AVPs with the 'P' bit set > to a message? It seems not because then the CMS-Signed-Data AVP created by > A and C could no longer be validated. Is the CMS Security application > supposed to allow intermediate nodes to add AVPs and sign them? No. We only support signing one set of AVPs and once a signature is attached that's it. That was a deliberate decision of the WG since the alternative is just too complex to be worthwhile (and no-one really wanted it either). Note that using countersignatures you can of course have as many signatures as you like, they just have to be applied sequentially and over the same set of AVPs. A proxy behaving as you've desribed is broken. Adding an AVP with the P bit set when a signature is present is not allowed. > > > > > > > > 8. Section 6.3 provides some example encodings for encrypted and > > > signed AVPs. The examples indicate that different Diameter > > > nodes can have different encryption and signing requirements. > > > Aren't these examples misleading now that the expected-signed > > > and expected-encrypted AVPs have been removed? (All Diameter > > > nodes share the same encryption and signing requirements.) > > > > The examples are based on requirements on AVPs which can be determined > > from the RFC or by an astrologer. So I disagree that this is related > > to the expected-* removal. > > Okay, I see. > > > > > > > > 9. The AVP occurrence rules table and ABNF message definitions > > > have some inconsistencies: > > > > > > DSAR ABNF DSAR Occurrence rules table > > > AAA-Node-Cert * 0-1 > > > > Was the above meant to be in your mail? > > Yes, this was the one inconsistency I noticed in the DSAR message. My fault - didn't notice the "R" :-) > > > > > > > > DSAA ABNF DSAA Occurrence rules table > > > AAA-Node-Cert * 0-1 > > should be 0+ > > > > > OCSP-Responses * 1+ > > should be 0+ > > > Origin-Realm 0*1 1 > > > Redirect-Host not listed 0+ > > > Redirect-Host-Usage not listed 0-1 > > > Redirect-Max- > > > Cache-Time not listed 0-1 > > I don't know what's right for these. Want to suggest > > something? > > Origin-Realm is a 1 for all the other DSA message and I think it should be 1 > for the DSAA. I *think* the redirect host AVPs should be allowed in the DSAA > as specified by the occurrence rules table, and should be added to the > DSAA ABNF. I hope someone with more knowledge of redirect servers could > chime in here. > > > > > > > > 10. DSAA ABNF has Local-CA-info surrounded by curly brackets. I > > > think square brackets are correct. > > > > Disagree. Doesn't *{foo} mean "one or more", whereas *[foo] means > > "zero or more". One or more is what's wanted. > > Okay, then there is another inconsistency between the DSAA ABNF and the DSAA > occurrence rule table settings. Please change the occurrence rules table for > the DSAA to indicate Local-CA-info can occur 1+ times instead of 0+ times. Ok. > > > > > > > > > > > 11.Origin-State-Id listed as Original-State-Id in AVP occurrence table. > > > > I'm guessing that Origin-State-Id is the right name? > > Yes > > > > > > > > 12.Section 3.1 states: > > > > > > Once the DSA is in place, any Diameter messages created by a DSA > > > peer > > > that has a private key MUST contain a signature over all AVPs whose > > > > > > definition states that their 'P' bit MAY be set. > > > > > > I think the CMS-Encrypted-Data AVP is an exception to this rule. It > > > only requires a signature if any of the encrypted AVPs contained in > > > the CMS-Encrypted-Data AVP require signing. > > > > Good point. I'll add text indicating this. > > > > > 13.Some typos: > > > > > > Section 1: "two different set of messages" > > > "two different sets of messages" > > > > > > Section 1.2 "DSA would the NAS" > > > "DSA would be the NAS" > > > > > > "initiate an DSAR" > > > "initiate a DSAR" > > > > > > Section 1.3 "such an an aggregating relay" > > > "such as an aggregating relay" > > > > > > "recelived" > > > "received" > > > > > > Section 3.1 "MUST re-validated" > > > "MUST be re-validated" > > > > > > "implemetors" > > > "implementors" > > > > > > Section 5 "CAA" (in diagram) > > > "CEA" > > > > > > "issues an DSAR message" > > > "issues a DSAR message" > > > > > > Section 6.11 "lenght" > > > "length" > > > > > Thanks, > > Stephen. > > > > -- > > ____________________________________________________________ > > Stephen Farrell > > Baltimore Technologies, tel: (direct line) +353 1 881 6716 > > 39 Parkgate Street, fax: +353 1 881 7000 > > Dublin 8. mailto:stephen.farrell@baltimore.ie > > Ireland http://www.baltimore.com > > Thanks, > Don -- ____________________________________________________________ Stephen Farrell Baltimore Technologies, tel: (direct line) +353 1 881 6716 39 Parkgate Street, fax: +353 1 881 7000 Dublin 8. mailto:stephen.farrell@baltimore.ie Ireland http://www.baltimore.com From owner-aaa-wg@merit.edu Fri Mar 15 13:58:36 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07165 for <aaa-archive@lists.ietf.org>; Fri, 15 Mar 2002 13:58:36 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A9A5591230; Fri, 15 Mar 2002 13:58:24 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7584191231; Fri, 15 Mar 2002 13:58:24 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3470691230 for <aaa-wg@trapdoor.merit.edu>; Fri, 15 Mar 2002 13:58:23 -0500 (EST) Received: by segue.merit.edu (Postfix) id F09AF5DE02; Fri, 15 Mar 2002 13:57:57 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id DA6A45DDF5 for <aaa-wg@merit.edu>; Fri, 15 Mar 2002 13:57:57 -0500 (EST) Received: from phoenix (nat.interlinknetworks.com [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with SMTP id 6A7C998; Fri, 15 Mar 2002 13:57:42 -0500 (EST) From: "Bob Kopacz" <BKopacz@InterlinkNetworks.com> To: "Tony Johansson" <tony.johansson@ericsson.com>, "Johan Johansson" <johanj@ipunplugged.com>, "David Spence" <DSpence@InterlinkNetworks.com> Cc: "aaa-wg" <aaa-wg@merit.edu> Subject: RE: [AAA-WG]: [issue] Need more explanation about handling MN handoffs Date: Fri, 15 Mar 2002 13:56:41 -0500 Message-ID: <NEBBKEONMLEDJCMHGHPICEHCDOAA.BKopacz@InterlinkNetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6600 In-Reply-To: <3C90F6A9.263557@ericsson.com> Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Tony, Here's an idea which may help solve many of the problems with a foreign HA, i.e. the MN handoff problems (issue#299), and the problems with securing AAAH-generated keys (issue#301). I'll note the new requirements in square brackets along the way. Initial MN connection: ---------------------- 1. Suppose the MN initially connects to FA1 in ForeignNetwork1, and requests that an HA be allocated in either the home or foreign network. 2. The FA1 sends an AMR to his local AAAF1 in ForeignNetwork1. 3. AAAF1 decides that HA1 (in ForeignNetwork1) is a good candidate HA and forwards an AMR with a Candidate-HA(value=HA1) AVP to the home network. AAAF1 includes his realm & identity in the Originating-AAAF AVP, per issue#266. 4. AAAH1 in the home network decides that a foreign HA is just fine. [AAAH1 must be a session-stateful AAA server]. 5. If AAAH1 is generating any session keys destined for the HA and wants to secure them, the AAAH1 sets up a DSA with AAAF1, and sends CMS-encrypted keys in the HAR. 6. AAAH1 sends the HAR to AAAF1, not to HA1. That is, the HAR carries a Destination-Realm(value=AAAF1's realm), Destination-Host(value=AAAF1's identity), and a new grouped AVP called the HA-Identity AVP which has two members, HA-Realm(value=HA1's realm) and the HA-Identity(value=HA1's identity, from the AMR's Candidate-HA AVP). [The HAR is destined to AAAF1, not HA1]. [An HAR sent to a foreign network, because of a foreign HA, is always sent to an AAAF, not an HA, and always includes an AVP which carries the HA's identity]. 7. If there are any CMS-secured keys in the HAR, then AAAF1 decrypts them. 8a. Case 1: AAAF1 hosts both FA1 and HA1... AAAF1 may be the AAA server hosting HA1, in which case AAAF1 can send the HAR to HA1 (after replacing the Destination-Host and Destination-Realm to target HA1, and removing the HA-Identity AVP, and generating the HA/FA key if necessary). 8b. Case 2: AAAF1 hosts FA1 but not HA1... There may an AAAF2 (also in ForeignNetwork1) which is hosting HA1, in which case AAAF1 sends the HAR to AAAF2. Then AAAF2 sends the HAR to HA1 (after doing the same sort of HAR-massaging that AAAF1 did above). 9. In either case, if the destination-AAAF generates an FA-HA key and wants to return it secured to the origin-AAAF (AAAF1), then the destination-AAAF sets up a DSA with AAAF1 a la issue#266, and passes a CMS-encrypted FA-HA key in the HAA. 10. When AAAH1 receives the HAA, it updates its session-state information for this session. The AAAH's session-state info contains, among other things: - AAAF1's realm and identity - HA1's realm and identity - HA1's IP address MN handoff to FA2 in ForeignNetwork2 ------------------------------------ (The handoff could also be to another FA in ForeignNetwork1, but I thought I'd describe the potentially most-troublesome circumstance). 1. Suppose the MN migrates to FA2 in ForeignNetwork2. 2. FA2 creates an AMR and sends this to his local AAAF, AAAF3, in ForeignNetwork2. 3. AAAF3 adds an Originating-AAAF(value=AAAF3's realm+identity) to the AMR, and forwards the AMR to the home network. 4. The AMR must (somehow) be received by AAAH1, who is the AAAH holding the session-state info for this MN packet session. There are a couple ways to ensure that this AMR makes its way to AAAH1: 4a. Require that each realm is authorized/authenticated by exactly one AAAH. So while a home network may have multiple AAAH's, the realms are partitioned over the set of home network AAAH's. or 4b. If the home realm has multiple AAA servers AAAH1, AAAH2, ..., AAAHn, then [this needs further thought, but one idea (a bad idea that works) is that, when the AMR is received by an AAAH in the home network, the AMR hot-potatoes around the AAAHs until it ends up at some AAAH who recognizes this session, i.e. AAAH1] 5. When AAAH1 receives the AMR, it looks for a session that matches the AMR's User-Name, MN IP address, and HA IP address. AAAH1 finds this session, and retrieves HA1's identity and AAAF1's identity. Now the AAAH knows all the good stuff, and things can proceed along the lines of steps 5-10 in the preceding "Initial MN Connection" section. Variation: ---------- A minor variation on this scheme is for AAAF2's identity to be stashed as part of AAAH's session-state info, so that AAAH could send the HAR directly to AAAF2 rather than dog-legging it through AAAF1. This could happen if either AAAF1 included both HA1's identity and AAAF2's identity in the initial AMR, or if AAAF2 returned his identity in the HAA. What do you think? I've got an even worse idea which I will also write up and send along. Bob K. From owner-aaa-wg@merit.edu Fri Mar 15 15:12:29 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09066 for <aaa-archive@lists.ietf.org>; Fri, 15 Mar 2002 15:12:28 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id ACEAD91231; Fri, 15 Mar 2002 15:12:15 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7CDA491232; Fri, 15 Mar 2002 15:12:15 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 194F491231 for <aaa-wg@trapdoor.merit.edu>; Fri, 15 Mar 2002 15:12:14 -0500 (EST) Received: by segue.merit.edu (Postfix) id EB30A5DDF5; Fri, 15 Mar 2002 15:12:13 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by segue.merit.edu (Postfix) with ESMTP id 877C85DDB1 for <aaa-wg@merit.edu>; Fri, 15 Mar 2002 15:12:13 -0500 (EST) Received: from mr7.exu.ericsson.se (mr7att.ericy.com [138.85.224.158]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g2FKCCS08189; Fri, 15 Mar 2002 14:12:12 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g2FKCCG25719; Fri, 15 Mar 2002 14:12:12 -0600 (CST) Received: from qpop.exu.ericsson.se (qpop [138.85.75.72]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id OAA18403; Fri, 15 Mar 2002 14:12:11 -0600 (CST) Received: from ericsson.com ([138.85.159.114]) by qpop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id OAA29613; Fri, 15 Mar 2002 14:12:10 -0600 (CST) Message-ID: <3C9254FB.5BA3B53@ericsson.com> Date: Fri, 15 Mar 2002 12:09:31 -0800 From: Tony Johansson <tony.johansson@ericsson.com> X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Fredrik Johansson <fredrik.johansson@ipunplugged.com> Cc: Sivasundar Ramamurthy <sramam@cup.hp.com>, AAA Working Group <aaa-wg@merit.edu> Subject: Re: [AAA-WG]: [issue] MN starting at Home References: <MJEMJBGGCLLDLFFAHLJKAEDMEBAA.fredrik.johansson@ipunplugged.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Comments inline...... Fredrik Johansson wrote: > Tony, > > see comments inline. > > /fredrik > > >-----Original Message----- > >From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of > >Tony Johansson > >Sent: den 15 mars 2002 04:46 > >To: Sivasundar Ramamurthy > >Cc: AAA Working Group > >Subject: Re: [AAA-WG]: [issue] MN starting at Home > > > > > > > > > >Sivasundar Ramamurthy wrote: > > > >> Hi Tony, > >> > >> > please find comments embedded... > >> > > >> > /Tony > >> > > >> > Sivasundar Ramamurthy wrote: > >> > > >> > > Hello, > >> > > > >> > > I am not sure if this scenario has been considered by the Mobile IP > >> > > application draft. > >> > > > >> > > Some MN might employ the policy to turn off security in data > >> > > communication when at home. But the HA advertisement alone may not > >> > > enough for the MN to "decide" it is at home, since it could be > >> > > spoofed. So when the MN is starting at home, it would still rely on a > >> > > de-registration request and a successful reply in order to > >verify that > >> > > it IS at home. > >> > > >> > > > >> > > Assuming that this approach is reasonable, an MN starting at home > >> > > would recieve HA advertisments and would still send a de-registration > >> > > request to the HA. But since it does not have any keys to the HA, the > >> > > MN will make a AAA request, which can be processed by the HA only via > >> > > AAA (just like a request from a co-located MN). > >> > > >> > Well, you can not have a HA without a valid SA (i.e. MN-HA > >session keys). > >> > Thus, if your SA has expired you must re-register in order to > >keep the HA. > >> > >> But a MN can be configured with a static HA and to use AAA to get > >> a MN-HA SA, right? > > > >No, if you have a static HA configured you would also have a > >static MN-HA SA. > >Thus, Mobile IPv4. > > Why, it must be possible to have a "fallback HA" configured. Just consider > the co-located case, how would the MN register if it doesn't have a > "default" HA? It doesn't speak Diameter and it has no FA to send the request > to. i.e. it has to send the request directly to a HA. > I'm sorry for the confusion, you are of course right you . Of course you can have a "fallback HA" configured like for the co-located case. However, here we are talking about the a case where you may have a default HA configured, which the MN is not registered to, but the HA receives a de-registertion request from the MN anyway. So, what does the RFC3220 (MIPv4) say the HA should do in this case, since the user would already be non-existent in the HA's routing tables / internal state information ?! /Tony From owner-aaa-wg@merit.edu Fri Mar 15 17:21:41 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12171 for <aaa-archive@lists.ietf.org>; Fri, 15 Mar 2002 17:21:41 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 72F91912FA; Fri, 15 Mar 2002 17:21:28 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3A47B912FC; Fri, 15 Mar 2002 17:21:28 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id EBC95912FA for <aaa-wg@trapdoor.merit.edu>; Fri, 15 Mar 2002 17:21:26 -0500 (EST) Received: by segue.merit.edu (Postfix) id D29735DDB1; Fri, 15 Mar 2002 17:21:26 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by segue.merit.edu (Postfix) with ESMTP id 6E4E85DD8F for <aaa-wg@merit.edu>; Fri, 15 Mar 2002 17:21:26 -0500 (EST) Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.224.157]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g2FMLQS26072; Fri, 15 Mar 2002 16:21:26 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g2FMLPE01265; Fri, 15 Mar 2002 16:21:25 -0600 (CST) Received: from qpop.exu.ericsson.se (qpop [138.85.75.72]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id QAA06941; Fri, 15 Mar 2002 16:21:24 -0600 (CST) Received: from ericsson.com ([138.85.159.114]) by qpop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id QAA01944; Fri, 15 Mar 2002 16:21:23 -0600 (CST) Message-ID: <3C927344.AAEC357E@ericsson.com> Date: Fri, 15 Mar 2002 14:18:44 -0800 From: Tony Johansson <tony.johansson@ericsson.com> X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Bob Kopacz <BKopacz@InterlinkNetworks.com> Cc: Johan Johansson <johanj@ipunplugged.com>, David Spence <DSpence@InterlinkNetworks.com>, aaa-wg <aaa-wg@merit.edu> Subject: Re: [AAA-WG]: [issue] Need more explanation about handling MN handoffs References: <NEBBKEONMLEDJCMHGHPICEHCDOAA.BKopacz@InterlinkNetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Bob, I agree in principle with all of your statements below and I've been thinking about this within the same lines. All, any strong objection / comments against these imposed restrictions / requirements. If not, I will continue to work on some new text for this. Please, find some more comments embedded... Thanks a lot, /Tony Bob Kopacz wrote: > Hi Tony, > > Here's an idea which may help solve many of the problems with a foreign > HA, i.e. the MN handoff problems (issue#299), and the problems with > securing AAAH-generated keys (issue#301). > > I'll note the new requirements in square brackets along the way. > > Initial MN connection: > ---------------------- > > 1. Suppose the MN initially connects to FA1 in ForeignNetwork1, and > requests that an HA be allocated in either the home or foreign network. > > 2. The FA1 sends an AMR to his local AAAF1 in ForeignNetwork1. > > 3. AAAF1 decides that HA1 (in ForeignNetwork1) is a good candidate HA > and forwards an AMR with a Candidate-HA(value=HA1) AVP to the home > network. AAAF1 includes his realm & identity in the Originating-AAAF > AVP, per issue#266. > > 4. AAAH1 in the home network decides that a foreign HA is just fine. > > [AAAH1 must be a session-stateful AAA server]. > > 5. If AAAH1 is generating any session keys destined for the HA and wants > to secure them, the AAAH1 sets up a DSA with AAAF1, and sends > CMS-encrypted keys in the HAR. > > 6. AAAH1 sends the HAR to AAAF1, not to HA1. That is, the HAR carries a > Destination-Realm(value=AAAF1's realm), Destination-Host(value=AAAF1's > identity), and a new grouped AVP called the HA-Identity AVP which has > two members, HA-Realm(value=HA1's realm) and the HA-Identity(value=HA1's > identity, from the AMR's Candidate-HA AVP). We could also re-use the Candidate-HA AVP. > > > [The HAR is destined to AAAF1, not HA1]. > > [An HAR sent to a foreign network, because of a foreign HA, is always > sent to an AAAF, not an HA, and always includes an AVP which carries the > HA's identity]. > > 7. If there are any CMS-secured keys in the HAR, then AAAF1 decrypts > them. > > 8a. Case 1: AAAF1 hosts both FA1 and HA1... AAAF1 may be the AAA server > hosting HA1, in which case AAAF1 can send the HAR to HA1 (after > replacing the Destination-Host and Destination-Realm to target HA1, and > removing the HA-Identity AVP, and generating the HA/FA key if > necessary). > > 8b. Case 2: AAAF1 hosts FA1 but not HA1... There may an AAAF2 (also in > ForeignNetwork1) which is hosting HA1, in which case AAAF1 sends the HAR > to AAAF2. Then AAAF2 sends the HAR to HA1 (after doing the same sort of > HAR-massaging that AAAF1 did above). > > 9. In either case, if the destination-AAAF generates an FA-HA key and > wants to return it secured to the origin-AAAF (AAAF1), then the > destination-AAAF sets up a DSA with AAAF1 a la issue#266, and passes > a CMS-encrypted FA-HA key in the HAA. > > 10. When AAAH1 receives the HAA, it updates its session-state > information for this session. The AAAH's session-state info contains, > among other things: > > - AAAF1's realm and identity > - HA1's realm and identity > - HA1's IP address > > MN handoff to FA2 in ForeignNetwork2 > ------------------------------------ > > (The handoff could also be to another FA in ForeignNetwork1, but I > thought I'd describe the potentially most-troublesome circumstance). > > 1. Suppose the MN migrates to FA2 in ForeignNetwork2. > > 2. FA2 creates an AMR and sends this to his local AAAF, AAAF3, in > ForeignNetwork2. > > 3. AAAF3 adds an Originating-AAAF(value=AAAF3's realm+identity) to the > AMR, and forwards the AMR to the home network. > > 4. The AMR must (somehow) be received by AAAH1, who is the AAAH holding > the session-state info for this MN packet session. > > There are a couple ways to ensure that this AMR makes its way to AAAH1: > > 4a. Require that each realm is authorized/authenticated by exactly one > AAAH. So while a home network may have multiple AAAH's, the realms are > partitioned over the set of home network AAAH's. > > or > > 4b. If the home realm has multiple AAA servers AAAH1, AAAH2, ..., AAAHn, > then [this needs further thought, but one idea (a bad idea that works) > is that, when the AMR is received by an AAAH in the home network, the > AMR hot-potatoes around the AAAHs until it ends up at some AAAH who > recognizes this session, i.e. AAAH1] Issue#282 (Base-11) would make it possible to ask a re-direct server to which AAAH the user belongs to... > > > 5. When AAAH1 receives the AMR, it looks for a session that matches the > AMR's User-Name, MN IP address, and HA IP address. AAAH1 finds this > session, and retrieves HA1's identity and AAAF1's identity. Now the > AAAH knows all the good stuff, and things can proceed along the lines of > steps 5-10 in the preceding "Initial MN Connection" section. > > Variation: > ---------- > A minor variation on this scheme is for AAAF2's identity to be stashed > as part of AAAH's session-state info, so that AAAH could send the HAR > directly to AAAF2 rather than dog-legging it through AAAF1. This could > happen if either AAAF1 included both HA1's identity and AAAF2's identity > in the initial AMR, or if AAAF2 returned his identity in the HAA. This sounds like a better solution to me. > > > What do you think? I've got an even worse idea which I will also write > up and send along. Okay, I'm may looking forward to it ;-) > > > Bob K. From owner-aaa-wg@merit.edu Sat Mar 16 07:41:20 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02376 for <aaa-archive@odin.ietf.org>; Sat, 16 Mar 2002 07:41:20 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D2C059120A; Sat, 16 Mar 2002 07:40:57 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9C9939120E; Sat, 16 Mar 2002 07:40:57 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6DC059120A for <aaa-wg@trapdoor.merit.edu>; Sat, 16 Mar 2002 07:40:56 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4838C5DE17; Sat, 16 Mar 2002 07:40:56 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id A23695DD9D for <aaa-wg@merit.edu>; Sat, 16 Mar 2002 07:40:55 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g2GBxL429222; Sat, 16 Mar 2002 03:59:21 -0800 Date: Sat, 16 Mar 2002 03:59:21 -0800 (PST) From: Bernard Aboba <aboba@internaut.com> To: Tony Johansson <tony.johansson@ericsson.com> Cc: "'aaa-wg@merit.edu'" <aaa-wg@merit.edu>, Lollo =?iso-8859-1?Q?T=F6nnesson?= <Lollo.Tonnesson@epk.ericsson.se> Subject: Re: [AAA-WG]: Issue 311: Acct-Application-Id and Vendor-Specific-Applications In-Reply-To: <3C9017FE.874BE993@ericsson.com> Message-ID: <Pine.LNX.4.21.0203160341510.25701-100000@internaut.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk I think that this issue is in part engendered by a lack of clarity in the spec about when a new Acct-Application-Id is needed. Accounting is somewhat different from Authentication in that in many cases the accounting server only writes the AVPs to disk, and therefore doesn't need to understand them. As a result, one can send vendor-specific AVPs to an accounting server without the server needing to "support" them. Thus, section 1.2.4 was written to try to discourage gratuitous use of new Acct-Application-Ids: 1.2.4 Creating New Accounting Applications There are services that only require the use of Diameter accounting. Since such services need to define the service specific AVPs that must be carried in the Accounting-Request/Answer messages, but do not need to define command codes, the rules on allocation of Accounting Application Identifiers is different from the ones defined in section 2.3.3. When possible, a new Diameter accounting application SHOULD attempt to re-use any existing Diameter AVP, in order to reduce the possibility of having multiple AVPs that carry similar information. Every Diameter accounting application specification MUST have an IANA assigned Application Identifier (see section 2.4). Note that section 1.2.4 says that rules on allocation of Accounting Applications Identifiers [sic] is different, but doesn't say *how* it is different. My understanding is that it is different because there is even less reason to create a new Acct-Application-Id than a new Auth Application. Thus, it would seem that adding Vendor-Specific AVPs may not be a good enough reason to create a new Acct-Application-Id. To resolve this issue, I think we need to specify when new Accounting Applications are created in more detail. Here is what section 2.3.3. says about Authentication Applications: 2.3.3 Creating New Auth Applications Should a new application require Diameter support, but it cannot fit within an existing application without requiring major changes to the specification, it may be desirable to create a new Diameter application. Major changes to an application include: - Requiring a whole different set of mandatory AVPs to a command - Requiring a command that has a different number of round trips to satisfy a request (e.g. application foo has a command that requires one round trip, but new application bar has a command that requires two round trips to complete). - The method used to authenticate the user is drastically different from any existing application, and the authentication information cannot be carried within the AVPs defined in the application. Note that the creation of a new application should be viewed as a last resort. New Diameter applications MUST define at least one Command Code, the expected AVPs in an ABNF [ABNF] grammar (see section 3.2), and MAY also define new AVPs. If the Diameter application has any accounting requirements, it MUST also specify the AVPs that are to be present in the Diameter Accounting messages (see section 9.3). When possible, a new Diameter application SHOULD attempt to re-use any existing Diameter AVP, in order to reduce the possibility of having multiple AVPs that carry similar information. Every Diameter application specification MUST have an IANA assigned Application Identifier (see section 2.4). From owner-aaa-wg@merit.edu Sat Mar 16 12:08:23 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06156 for <aaa-archive@odin.ietf.org>; Sat, 16 Mar 2002 12:08:23 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 00DD791213; Sat, 16 Mar 2002 12:08:07 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BEE2791214; Sat, 16 Mar 2002 12:08:06 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 73A2691213 for <aaa-wg@trapdoor.merit.edu>; Sat, 16 Mar 2002 12:08:05 -0500 (EST) Received: by segue.merit.edu (Postfix) id 523765DE00; Sat, 16 Mar 2002 12:08:05 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 3DD545DD97 for <aaa-wg@merit.edu>; Sat, 16 Mar 2002 12:08:05 -0500 (EST) Received: from phoenix (nat.interlinknetworks.com [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with SMTP id B733191; Sat, 16 Mar 2002 12:08:04 -0500 (EST) From: "Bob Kopacz" <BKopacz@InterlinkNetworks.com> To: "Tony Johansson" <tony.johansson@ericsson.com> Cc: "Johan Johansson" <johanj@ipunplugged.com>, "David Spence" <DSpence@InterlinkNetworks.com>, "aaa-wg" <aaa-wg@merit.edu> Subject: RE: [AAA-WG]: [issue] Need more explanation about handling MN handoffs Date: Sat, 16 Mar 2002 12:07:03 -0500 Message-ID: <NEBBKEONMLEDJCMHGHPIKEHPDOAA.BKopacz@InterlinkNetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <3C927344.AAEC357E@ericsson.com> Importance: Normal X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Tony, > -----Original Message----- > From: Tony Johansson [mailto:tony.johansson@ericsson.com] > Sent: Friday, March 15, 2002 5:19 PM > To: Bob Kopacz > Cc: Johan Johansson; David Spence; aaa-wg > Subject: Re: [AAA-WG]: [issue] Need more explanation about handling MN > handoffs > > Hi Bob, > > I agree in principle with all of your statements below and I've been > thinking about this within the same lines. > > All, any strong objection / comments against these imposed restrictions / > requirements. If not, I will continue to work on some new text for this. I was just floating an idea for you guys to chew on. I didn't submit any text because I didn't want to promote this partly-baked thought as an issue quite yet; not until I got at least one positive feedback. > Please, find some more comments embedded... > > Thanks a lot, > > /Tony > > Bob Kopacz wrote: > > > Hi Tony, > > > > Here's an idea which may help solve many of the problems with a foreign > > HA, i.e. the MN handoff problems (issue#299), and the problems with > > securing AAAH-generated keys (issue#301). > > > > I'll note the new requirements in square brackets along the way. > > > > Initial MN connection: > > ---------------------- > > > > 1. Suppose the MN initially connects to FA1 in ForeignNetwork1, and > > requests that an HA be allocated in either the home or foreign network. > > > > 2. The FA1 sends an AMR to his local AAAF1 in ForeignNetwork1. > > > > 3. AAAF1 decides that HA1 (in ForeignNetwork1) is a good candidate HA > > and forwards an AMR with a Candidate-HA(value=HA1) AVP to the home > > network. AAAF1 includes his realm & identity in the Originating-AAAF > > AVP, per issue#266. > > > > 4. AAAH1 in the home network decides that a foreign HA is just fine. > > > > [AAAH1 must be a session-stateful AAA server]. > > > > 5. If AAAH1 is generating any session keys destined for the HA and wants > > to secure them, the AAAH1 sets up a DSA with AAAF1, and sends > > CMS-encrypted keys in the HAR. > > > > 6. AAAH1 sends the HAR to AAAF1, not to HA1. That is, the HAR carries a > > Destination-Realm(value=AAAF1's realm), Destination-Host(value=AAAF1's > > identity), and a new grouped AVP called the HA-Identity AVP which has > > two members, HA-Realm(value=HA1's realm) and the HA-Identity(value=HA1's > > identity, from the AMR's Candidate-HA AVP). > > We could also re-use the Candidate-HA AVP. I thought about that, but after a handoff, the HA is not longer a candidate, he's an elected official. So at that point the Candidate-HA AVP can be used, but it's a bit of a misnomer. Is there any virtue in creating two or three generic AVPs, called "Host-Identity" and "Host-Realm" and maybe "Host-IP-Address"? These AVPs would be members of a grouped AVP which carries the identity information for one of the participants in the mobile session. e.g. MIP-Originating-Foreign-AAA ::= < AVP Header:... > { Host-Realm } { Host-Identity } MIP-Candidate-Home-Agent ::= < AVP Header:... > { Host-Realm } { Host-Identity } MIP-Foreign-Agent ::= < AVP Header:... > { Host-Realm } { Host-Identity } MIP-Home-Agent ::= < AVP Header:... > { Host-Realm } { Host-Identity } [ Host-IP-Address ] And then eliminating the non-grouped AVPs which purport to carry the all you need to know about a node, but actually carry only the identity but not the realm. > > > > > > [The HAR is destined to AAAF1, not HA1]. > > > > [An HAR sent to a foreign network, because of a foreign HA, is always > > sent to an AAAF, not an HA, and always includes an AVP which carries the > > HA's identity]. > > > > 7. If there are any CMS-secured keys in the HAR, then AAAF1 decrypts > > them. > > > > 8a. Case 1: AAAF1 hosts both FA1 and HA1... AAAF1 may be the AAA server > > hosting HA1, in which case AAAF1 can send the HAR to HA1 (after > > replacing the Destination-Host and Destination-Realm to target HA1, and > > removing the HA-Identity AVP, and generating the HA/FA key if > > necessary). > > > > 8b. Case 2: AAAF1 hosts FA1 but not HA1... There may an AAAF2 (also in > > ForeignNetwork1) which is hosting HA1, in which case AAAF1 sends the HAR > > to AAAF2. Then AAAF2 sends the HAR to HA1 (after doing the same sort of > > HAR-massaging that AAAF1 did above). > > > > 9. In either case, if the destination-AAAF generates an FA-HA key and > > wants to return it secured to the origin-AAAF (AAAF1), then the > > destination-AAAF sets up a DSA with AAAF1 a la issue#266, and passes > > a CMS-encrypted FA-HA key in the HAA. > > > > 10. When AAAH1 receives the HAA, it updates its session-state > > information for this session. The AAAH's session-state info contains, > > among other things: > > > > - AAAF1's realm and identity > > - HA1's realm and identity > > - HA1's IP address > > > > MN handoff to FA2 in ForeignNetwork2 > > ------------------------------------ > > > > (The handoff could also be to another FA in ForeignNetwork1, but I > > thought I'd describe the potentially most-troublesome circumstance). > > > > 1. Suppose the MN migrates to FA2 in ForeignNetwork2. > > > > 2. FA2 creates an AMR and sends this to his local AAAF, AAAF3, in > > ForeignNetwork2. > > > > 3. AAAF3 adds an Originating-AAAF(value=AAAF3's realm+identity) to the > > AMR, and forwards the AMR to the home network. > > > > 4. The AMR must (somehow) be received by AAAH1, who is the AAAH holding > > the session-state info for this MN packet session. > > > > There are a couple ways to ensure that this AMR makes its way to AAAH1: > > > > 4a. Require that each realm is authorized/authenticated by exactly one > > AAAH. So while a home network may have multiple AAAH's, the realms are > > partitioned over the set of home network AAAH's. > > > > or > > > > 4b. If the home realm has multiple AAA servers AAAH1, AAAH2, ..., AAAHn, > > then [this needs further thought, but one idea (a bad idea that works) > > is that, when the AMR is received by an AAAH in the home network, the > > AMR hot-potatoes around the AAAHs until it ends up at some AAAH who > > recognizes this session, i.e. AAAH1] > > Issue#282 (Base-11) would make it possible to ask a re-direct server to > which AAAH the user belongs to... > > > > > > > 5. When AAAH1 receives the AMR, it looks for a session that matches the > > AMR's User-Name, MN IP address, and HA IP address. AAAH1 finds this > > session, and retrieves HA1's identity and AAAF1's identity. Now the > > AAAH knows all the good stuff, and things can proceed along the lines of > > steps 5-10 in the preceding "Initial MN Connection" section. This solves the problem that the AAAH has in trying to map the HA's IP address into a DiameterIdentity & realm. It still doesn't solve the problem for the originating AAAF (after a handoff), who wants to do the same mapping. I'll float another idea here (groping for solutions): The AAAF, when receiving the AMR from the FA after a handoff, doesn't try to do the reverse DNS (to map the HA IP's address into HA Identity and HA Realm). The AAAF just sends the AMR on to the stateful AAAH. The AAAH returns the HA Identity & Realm in the AMA. The originating AAAF now has the desired info, and can make his policy decisions, albeit late in the game. > > Variation: > > ---------- > > A minor variation on this scheme is for AAAF2's identity to be stashed > > as part of AAAH's session-state info, so that AAAH could send the HAR > > directly to AAAF2 rather than dog-legging it through AAAF1. This could > > happen if either AAAF1 included both HA1's identity and AAAF2's identity > > in the initial AMR, or if AAAF2 returned his identity in the HAA. > > This sounds like a better solution to me. > > > > > > > What do you think? I've got an even worse idea which I will also write > > up and send along. > > Okay, I'm may looking forward to it ;-) > > > > > > > Bob K. > > From owner-aaa-wg@merit.edu Sat Mar 16 12:31:35 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06530 for <aaa-archive@odin.ietf.org>; Sat, 16 Mar 2002 12:31:35 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 4F7D391214; Sat, 16 Mar 2002 12:31:10 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1574391223; Sat, 16 Mar 2002 12:31:10 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E6D1791214 for <aaa-wg@trapdoor.merit.edu>; Sat, 16 Mar 2002 12:31:08 -0500 (EST) Received: by segue.merit.edu (Postfix) id BBA615DE00; Sat, 16 Mar 2002 12:31:08 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 9AA465DD97 for <aaa-wg@merit.edu>; Sat, 16 Mar 2002 12:31:08 -0500 (EST) Received: from phoenix (nat.interlinknetworks.com [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with SMTP id 6D5A279; Sat, 16 Mar 2002 12:31:08 -0500 (EST) From: "Bob Kopacz" <BKopacz@InterlinkNetworks.com> To: "Tony Johansson" <tony.johansson@ericsson.com> Cc: "aaa-wg" <aaa-wg@merit.edu> Subject: RE: [AAA-WG]: Re: [issue] Securing the AAAH-generated session keys Date: Sat, 16 Mar 2002 12:30:06 -0500 Message-ID: <NEBBKEONMLEDJCMHGHPICEIADOAA.BKopacz@InterlinkNetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <3C8ECF74.CFDDDF1A@ericsson.com> Importance: Normal X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Tony, > -----Original Message----- > From: Tony Johansson [mailto:tony.johansson@ericsson.com] > Sent: Friday, March 15, 2002 5:19 PM > To: Bob Kopacz > Cc: Johan Johansson; David Spence; aaa-wg > Subject: Re: [AAA-WG]: [issue] Need more explanation about handling MN > handoffs > > > > What do you think? I've got an even worse idea which I will also write > > up and send along. > > Okay, I'm may looking forward to it ;-) Or you may not. Here it is. Suppose we made another requirement: that mobility agents, like servers, MUST support the CMS application. This, in conjunction with a session-stateful AAAH, simplifies the problem of securing session keys, i.e.: 1. While the AAAFs come and go during a mobile session, the HA is constant. 2. The session-stateful AAAH always knows the identity of the FA and the HA, so the AAAH can set up DSAs with these MAs and send CMS-encrypted session keys. 3. For securing the FA-HA key that the destination AAAF may generate, this can be done by a the AAAF passing the HA-FA and FA-HA keys to the foreign HA. The foreign HA can set up a DSA with the FA (rather than having the destination-AAAF set up a DSA with the originating-AAAF), and then the foreign HA can return the FA-HA key via the HAA, as either a FA-HA-Key AVP or a CMS-Encrypted-Data AVP. I don't know if this is a practical burden to place on the mobility agents. It's just a thought. Bob K. From owner-aaa-wg@merit.edu Mon Mar 18 06:27:25 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03193 for <aaa-archive@odin.ietf.org>; Mon, 18 Mar 2002 06:27:24 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 79B3091205; Mon, 18 Mar 2002 06:27:13 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4394091211; Mon, 18 Mar 2002 06:27:13 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 291B391205 for <aaa-wg@trapdoor.merit.edu>; Mon, 18 Mar 2002 06:27:12 -0500 (EST) Received: by segue.merit.edu (Postfix) id 024BD5DD9B; Mon, 18 Mar 2002 06:27:12 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by segue.merit.edu (Postfix) with ESMTP id 48C135DD94 for <aaa-wg@merit.edu>; Mon, 18 Mar 2002 06:27:11 -0500 (EST) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g2IBRui05724 for <aaa-wg@merit.edu>; Mon, 18 Mar 2002 13:27:56 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id <T59b6076fd6ac158f21082@esvir01nok.ntc.nokia.com>; Mon, 18 Mar 2002 13:27:10 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Mon, 18 Mar 2002 13:27:10 +0200 Received: from trebe002.NOE.Nokia.com ([172.22.232.173]) by esebe004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 18 Mar 2002 13:27:09 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [AAA-WG]: Questions about draft-hakala-diameter-credit-control-01.txt Date: Mon, 18 Mar 2002 13:27:09 +0200 Message-ID: <0AA9E01B31168E42A308714A6EF2718401682580@trebe002.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Diameter CCA protocol: uncovered scenarios Thread-Index: AcHAUjPDtcjxvYTaQvi6jT+AMA18hgOGzetQ From: <juha-pekka.koskinen@nokia.com> To: <aaa-wg@merit.edu>, <Harri.Hakala@lmf.ericsson.se> X-OriginalArrivalTime: 18 Mar 2002 11:27:09.0654 (UTC) FILETIME=[D7936F60:01C1CE6F] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA03193 Hi, I have few questions about this diameter-credit-control -draft... About this spontaneous updating which was already discussed here earlier. I still think that there will be cases where the spontaneous Interim_record trigger is needed from client to server. This could be caused by tariff change time or QoS changes. Because this was not accepted to the diameter base, should it be mentioned in this credit-control -draft? In the several interrogation scenario it is stated that only one Unit-type must be used. It would also be useful to give the possibilities to send at least two Unit-type during a credit control session for example time and volume so as the first condition met is reported. This would enable charging model where is expected to send only a certain amount of data volume in a given time, if the volume is exceeded the user would pay more. In 3GPP network we might have a number of accounting sessions and events related to the same SIP session or used service coming from different network elements/servers. How can we correlate this sessions/events? Maybe a new AVP is needed to transport a correlation identifier, if we refer to e.g. IMS this could be the "charging correlation vector". In chapter 5.15 Time stamp indicate the time when the service is requested. What happen with the time stamp in several interrogation scenario? Is this always the time stamp of the first ACR or..? This should be clarified in the document, just in case. Br, JPK From owner-aaa-wg@merit.edu Mon Mar 18 20:53:30 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28865 for <aaa-archive@lists.ietf.org>; Mon, 18 Mar 2002 20:53:29 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B71359123B; Mon, 18 Mar 2002 20:53:08 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 892259123C; Mon, 18 Mar 2002 20:53:08 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 88EBD9123B for <aaa-wg@trapdoor.merit.edu>; Mon, 18 Mar 2002 20:53:07 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6A33E5DDEB; Mon, 18 Mar 2002 20:53:07 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from imsm016dat.netvigator.com (imsm016.netvigator.com [208.167.231.26]) by segue.merit.edu (Postfix) with ESMTP id B2B765DD8C for <aaa-wg@merit.edu>; Mon, 18 Mar 2002 20:53:06 -0500 (EST) Received: from imsm040.wtt.netvigator.com ([192.168.14.50]) by imsm016dat.netvigator.com (InterMail vM.4.01.03.18 201-229-121-118) with ESMTP id <20020319015305.DKFP20042.imsm016dat.netvigator.com@imsm040.wtt.netvigator.com> for <aaa-wg@merit.edu>; Tue, 19 Mar 2002 09:53:05 +0800 To: <aaa-wg@merit.edu> From: phllee@netvigator.com Reply-To: phllee@netvigator.com Subject: [AAA-WG]: Unknown termination cause MIME-Version: 1.0 Content-Type: text/plain Message-Id: <20020319015305.DKFP20042.imsm016dat.netvigator.com@imsm040.wtt.netvigator.com> Date: Tue, 19 Mar 2002 09:53:05 +0800 Sender: owner-aaa-wg@merit.edu Precedence: bulk Does anyone know where to have new definition of the termination cause like 185 &210? Thanks Philip From owner-aaa-wg@merit.edu Mon Mar 18 23:35:41 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04558 for <aaa-archive@lists.ietf.org>; Mon, 18 Mar 2002 23:35:41 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5B4489123E; Mon, 18 Mar 2002 23:35:32 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2D5429123F; Mon, 18 Mar 2002 23:35:32 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1ADB59123E for <aaa-wg@trapdoor.merit.edu>; Mon, 18 Mar 2002 23:35:31 -0500 (EST) Received: by segue.merit.edu (Postfix) id E95925DDDB; Mon, 18 Mar 2002 23:35:30 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mail.funk.com (mail.funk.com [198.186.160.22]) by segue.merit.edu (Postfix) with ESMTP id BB7E75DDD7 for <aaa-wg@merit.edu>; Mon, 18 Mar 2002 23:35:30 -0500 (EST) Received: from pii400 (pii400.funk.com [198.186.160.46]) by mail.funk.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id GP9J5YHX; Mon, 18 Mar 2002 23:44:27 -0500 Message-Id: <4.1.20020318215129.0276c7a0@mail.funk.com> X-Sender: paul@mail.funk.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Mon, 18 Mar 2002 23:29:43 -0500 To: aaa-wg@merit.edu From: Paul Funk <paul@funk.com> Subject: [AAA-WG]: NAS-Session-Key AVP Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-aaa-wg@merit.edu Precedence: bulk I promised at the last IETF to present my thoughts on the key distribution AVPs in NASREQ. I am woefully late in doing so, and have not fully reviewed comments on the list, so if this is way off base or too late, please disregard with my apologies. It seems to me that the NAS-Session-Key AVP with its multiple grouped components (direction, type, key, data, binding, etc.) is a doomed attempt to predict the ways people will want to use session keys in the future. A simpler mechanism would be for keying information to be composed of exactly two items: key material and cipher suite. This approach takes its cue from TLS, and is both powerful and economical. The key material is a byte sequence that may represent a single key or multiple keys in concatenated segments. The cipher suite is a single value that encapsulates all information about the segmentation, interpretation and usage of the key material. Cipher suites are defined as needed, and may be as simple or complex as required. Cipher suite numbers would be given out by IANA, or vendors or industry groups could use their IDs to create their own. For example, cipher suite number 1 might mean 802.1X/WEP encryption, with key material consisting of a 32-byte of encryption key followed by a 32-byte signature key. When, say, WEP-AES is developed, the 802.1X group applies for a new number, gets assigned cipher suite number 2, writes up a spec on what that means, and doesn't have to figure out how to describe their encryption scheme via AVPs like direction, type, binding, etc. Plus, all the NAS wants to know is whether to use WEP or WEP-AES, and would appreciate getting a single cipher suite number in the AAA response. Cipher suites can also be negotiated between NAS and AAA server in a simple way. The NAS sends a list of supported cipher suites in preference order, the AAA server responds with its selection. Another advantage of this approach is that it is possible to make the AAA server completely ignorant of cipher suites. All the AAA server really needs to know is how to generate key material. The set of cipher suites sent by the NAS could include required length of key material. So if the server wants to be ignorant, all it has to do is select the first cipher suite suggested by the NAS and generate key material of the requested size. The only AVP in the NASREQ draft that cannot be subsumed within keying material and cipher suite is Key-Lifetime. That would have to be a separate AVP determined by policy. Paul Paul Funk Funk Software, Inc. 617 497-6339 paul@funk.com From owner-aaa-wg@merit.edu Tue Mar 19 03:09:04 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16933 for <aaa-archive@lists.ietf.org>; Tue, 19 Mar 2002 03:09:04 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 14CAF91240; Tue, 19 Mar 2002 03:08:32 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8F16691241; Tue, 19 Mar 2002 03:08:31 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7C85B91240 for <aaa-wg@trapdoor.merit.edu>; Tue, 19 Mar 2002 03:08:19 -0500 (EST) Received: by segue.merit.edu (Postfix) id 596085DDFE; Tue, 19 Mar 2002 03:08:19 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by segue.merit.edu (Postfix) with ESMTP id D7E7D5DD90 for <aaa-wg@merit.edu>; Tue, 19 Mar 2002 03:08:18 -0500 (EST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g2J88HUw015712 for <aaa-wg@merit.edu>; Tue, 19 Mar 2002 09:08:17 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Tue Mar 19 09:08:05 2002 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id <F4G26SSV>; Tue, 19 Mar 2002 08:58:05 +0100 Message-ID: <0154633DAF7BD4119C360002A513AA0301F94792@efijont102> From: "Harri Hakala (LMF)" <Harri.Hakala@lmf.ericsson.se> To: "'aaa-wg@merit.edu'" <aaa-wg@merit.edu> Subject: Re: [AAA-WG]: Diameter CCA protocol: uncovered scenarios Date: Tue, 19 Mar 2002 09:07:31 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi, answers inline. /Harri About this spontaneous updating which was already discussed here earlier. I still think that there will be cases where the spontaneous Interim_record trigger is needed from client to server. This could be caused by tariff change time or QoS changes. Because this was not accepted to the diameter base, should it be mentioned in this credit-control -draft? >>>> Yes. I think that spontaneous updating is needed. I will add statement that in case of spontaneous updating (mid-session events) a new Accounting-Request should be sent even if all the granted service units have not spent or the accounting interim interval has not expired. In the several interrogation scenario it is stated that only one Unit-type must be used. It would also be useful to give the possibilities to send at least two Unit-type during a credit control session for example time and volume so as the first condition met is reported. This would enable charging model where is expected to send only a certain amount of data volume in a given time, if the volume is exceeded the user would pay more. >>>>we put this restriction to avoid service to be too complex. If we allow several unit types during a credit control session (simultaneously) we should also report several unit-types (used-service units) when the first condition is met and let server to decide how to charge the service. I can update this. In 3GPP network we might have a number of accounting sessions and events related to the same SIP session or used service coming from different network elements/servers. How can we correlate this sessions/events? Maybe a new AVP is needed to transport a correlation identifier, if we refer to e.g. IMS this could be the "charging correlation vector". >>>> I see your point. I can add a new AVP. In chapter 5.15 Time stamp indicate the time when the service is requested. What happen with the time stamp in several interrogation scenario? Is this always the time stamp of the first ACR or..? This should be clarified in the document, just in case. >>>> I will clarify. In the first request (START) it indicates the time when service is requested and other requests it indicates the time of the event that triggered the sending of the ACR. From owner-aaa-wg@merit.edu Thu Mar 21 02:36:45 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06247 for <aaa-archive@odin.ietf.org>; Thu, 21 Mar 2002 02:36:45 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id EF08591207; Thu, 21 Mar 2002 02:36:23 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B2D1B9122F; Thu, 21 Mar 2002 02:36:22 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9443991207 for <aaa-wg@trapdoor.merit.edu>; Thu, 21 Mar 2002 02:36:21 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6E8665DDCA; Thu, 21 Mar 2002 02:36:21 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by segue.merit.edu (Postfix) with ESMTP id 79C515DD8E for <aaa-wg@merit.edu>; Thu, 21 Mar 2002 02:36:20 -0500 (EST) Received: from fredrikj (hotel-33.local.ipunplugged.com [192.168.8.33]) by mailgw.ipunplugged.com (8.9.3/8.9.3) with SMTP id IAA14093; Thu, 21 Mar 2002 08:33:26 +0100 From: "Fredrik Johansson" <fredrik.johansson@ipunplugged.com> To: "Tony Johansson" <tony.johansson@ericsson.com>, "Bob Kopacz" <BKopacz@InterlinkNetworks.com> Cc: "Johan Johansson" <johanj@ipunplugged.com>, "David Spence" <DSpence@InterlinkNetworks.com>, "aaa-wg" <aaa-wg@merit.edu> Subject: RE: [AAA-WG]: [issue] Need more explanation about handling MN handoffs Date: Thu, 21 Mar 2002 08:36:34 +0100 Message-ID: <MJEMJBGGCLLDLFFAHLJKEEKDEBAA.fredrik.johansson@ipunplugged.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <3C927344.AAEC357E@ericsson.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit I don't realy like the idea of starting to add restrictions to the protocol now when we have been working so hard the past year to have a flexible solution that can handle multiple AAA-h. I believe that we at least should give it a try in the Mobile IP wg and try to use the gnaie-draft. I've talked to Phil Roberts (mip wg chair) and he seems to be positive to such a solution. If we start to impose the restrictions, then we might as well go back and clean up the rest of the protocol. /Fredrik >-----Original Message----- >From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of >Tony Johansson >Sent: den 15 mars 2002 23:19 >To: Bob Kopacz >Cc: Johan Johansson; David Spence; aaa-wg >Subject: Re: [AAA-WG]: [issue] Need more explanation about handling MN >handoffs > > >Hi Bob, > >I agree in principle with all of your statements below and I've been >thinking about this within the same lines. > >All, any strong objection / comments against these imposed restrictions / >requirements. If not, I will continue to work on some new text for this. > >Please, find some more comments embedded... > > >Thanks a lot, > >/Tony > >Bob Kopacz wrote: > >> Hi Tony, >> >> Here's an idea which may help solve many of the problems with a foreign >> HA, i.e. the MN handoff problems (issue#299), and the problems with >> securing AAAH-generated keys (issue#301). >> >> I'll note the new requirements in square brackets along the way. >> >> Initial MN connection: >> ---------------------- >> >> 1. Suppose the MN initially connects to FA1 in ForeignNetwork1, and >> requests that an HA be allocated in either the home or foreign network. >> >> 2. The FA1 sends an AMR to his local AAAF1 in ForeignNetwork1. >> >> 3. AAAF1 decides that HA1 (in ForeignNetwork1) is a good candidate HA >> and forwards an AMR with a Candidate-HA(value=HA1) AVP to the home >> network. AAAF1 includes his realm & identity in the Originating-AAAF >> AVP, per issue#266. >> >> 4. AAAH1 in the home network decides that a foreign HA is just fine. >> >> [AAAH1 must be a session-stateful AAA server]. >> >> 5. If AAAH1 is generating any session keys destined for the HA and wants >> to secure them, the AAAH1 sets up a DSA with AAAF1, and sends >> CMS-encrypted keys in the HAR. >> >> 6. AAAH1 sends the HAR to AAAF1, not to HA1. That is, the HAR carries a >> Destination-Realm(value=AAAF1's realm), Destination-Host(value=AAAF1's >> identity), and a new grouped AVP called the HA-Identity AVP which has >> two members, HA-Realm(value=HA1's realm) and the HA-Identity(value=HA1's >> identity, from the AMR's Candidate-HA AVP). > >We could also re-use the Candidate-HA AVP. > >> >> >> [The HAR is destined to AAAF1, not HA1]. >> >> [An HAR sent to a foreign network, because of a foreign HA, is always >> sent to an AAAF, not an HA, and always includes an AVP which carries the >> HA's identity]. >> >> 7. If there are any CMS-secured keys in the HAR, then AAAF1 decrypts >> them. >> >> 8a. Case 1: AAAF1 hosts both FA1 and HA1... AAAF1 may be the AAA server >> hosting HA1, in which case AAAF1 can send the HAR to HA1 (after >> replacing the Destination-Host and Destination-Realm to target HA1, and >> removing the HA-Identity AVP, and generating the HA/FA key if >> necessary). >> >> 8b. Case 2: AAAF1 hosts FA1 but not HA1... There may an AAAF2 (also in >> ForeignNetwork1) which is hosting HA1, in which case AAAF1 sends the HAR >> to AAAF2. Then AAAF2 sends the HAR to HA1 (after doing the same sort of >> HAR-massaging that AAAF1 did above). >> >> 9. In either case, if the destination-AAAF generates an FA-HA key and >> wants to return it secured to the origin-AAAF (AAAF1), then the >> destination-AAAF sets up a DSA with AAAF1 a la issue#266, and passes >> a CMS-encrypted FA-HA key in the HAA. >> >> 10. When AAAH1 receives the HAA, it updates its session-state >> information for this session. The AAAH's session-state info contains, >> among other things: >> >> - AAAF1's realm and identity >> - HA1's realm and identity >> - HA1's IP address >> >> MN handoff to FA2 in ForeignNetwork2 >> ------------------------------------ >> >> (The handoff could also be to another FA in ForeignNetwork1, but I >> thought I'd describe the potentially most-troublesome circumstance). >> >> 1. Suppose the MN migrates to FA2 in ForeignNetwork2. >> >> 2. FA2 creates an AMR and sends this to his local AAAF, AAAF3, in >> ForeignNetwork2. >> >> 3. AAAF3 adds an Originating-AAAF(value=AAAF3's realm+identity) to the >> AMR, and forwards the AMR to the home network. >> >> 4. The AMR must (somehow) be received by AAAH1, who is the AAAH holding >> the session-state info for this MN packet session. >> >> There are a couple ways to ensure that this AMR makes its way to AAAH1: >> >> 4a. Require that each realm is authorized/authenticated by exactly one >> AAAH. So while a home network may have multiple AAAH's, the realms are >> partitioned over the set of home network AAAH's. >> >> or >> >> 4b. If the home realm has multiple AAA servers AAAH1, AAAH2, ..., AAAHn, >> then [this needs further thought, but one idea (a bad idea that works) >> is that, when the AMR is received by an AAAH in the home network, the >> AMR hot-potatoes around the AAAHs until it ends up at some AAAH who >> recognizes this session, i.e. AAAH1] > >Issue#282 (Base-11) would make it possible to ask a re-direct server to >which AAAH the user belongs to... > >> >> >> 5. When AAAH1 receives the AMR, it looks for a session that matches the >> AMR's User-Name, MN IP address, and HA IP address. AAAH1 finds this >> session, and retrieves HA1's identity and AAAF1's identity. Now the >> AAAH knows all the good stuff, and things can proceed along the lines of >> steps 5-10 in the preceding "Initial MN Connection" section. >> >> Variation: >> ---------- >> A minor variation on this scheme is for AAAF2's identity to be stashed >> as part of AAAH's session-state info, so that AAAH could send the HAR >> directly to AAAF2 rather than dog-legging it through AAAF1. This could >> happen if either AAAF1 included both HA1's identity and AAAF2's identity >> in the initial AMR, or if AAAF2 returned his identity in the HAA. > >This sounds like a better solution to me. > >> >> >> What do you think? I've got an even worse idea which I will also write >> up and send along. > >Okay, I'm may looking forward to it ;-) > >> >> >> Bob K. From owner-aaa-wg@merit.edu Thu Mar 21 11:51:30 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17041 for <aaa-archive@odin.ietf.org>; Thu, 21 Mar 2002 11:51:30 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 31E919128B; Thu, 21 Mar 2002 11:51:12 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EFA639128C; Thu, 21 Mar 2002 11:51:11 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DD8919128B for <aaa-wg@trapdoor.merit.edu>; Thu, 21 Mar 2002 11:51:10 -0500 (EST) Received: by segue.merit.edu (Postfix) id B93395DE13; Thu, 21 Mar 2002 11:51:10 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id A13DC5DDD1 for <aaa-wg@merit.edu>; Thu, 21 Mar 2002 11:51:10 -0500 (EST) Received: from phoenix (nat.interlinknetworks.com [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with SMTP id 571706C; Thu, 21 Mar 2002 11:51:10 -0500 (EST) From: "Bob Kopacz" <BKopacz@InterlinkNetworks.com> To: "Fredrik Johansson" <fredrik.johansson@ipunplugged.com>, "Tony Johansson" <tony.johansson@ericsson.com> Cc: "Johan Johansson" <johanj@ipunplugged.com>, "David Spence" <DSpence@InterlinkNetworks.com>, "aaa-wg" <aaa-wg@merit.edu> Subject: RE: [AAA-WG]: [issue] Need more explanation about handling MN handoffs Date: Thu, 21 Mar 2002 11:50:07 -0500 Message-ID: <NEBBKEONMLEDJCMHGHPIGEPADOAA.BKopacz@InterlinkNetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 In-Reply-To: <MJEMJBGGCLLDLFFAHLJKEEKDEBAA.fredrik.johansson@ipunplugged.com> Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Fredrik, > -----Original Message----- > From: Fredrik Johansson [mailto:fredrik.johansson@ipunplugged.com] > Sent: Thursday, March 21, 2002 2:37 AM > To: Tony Johansson; Bob Kopacz > Cc: Johan Johansson; David Spence; aaa-wg > Subject: RE: [AAA-WG]: [issue] Need more explanation about handling MN > handoffs > > I don't realy like the idea of starting to add restrictions to the protocol > now when we have been working so hard the past year to have a flexible > solution that can handle multiple AAA-h. I believe that we at least should > give it a try in the Mobile IP wg and try to use the gnaie-draft. I've > talked to Phil Roberts (mip wg chair) and he seems to be positive to such a > solution. I agree with you that this problem is best solved with some help from the Mobile IP protocol. I was just tossing out ideas. > If we start to impose the restrictions, then we might as well go back and > clean up the rest of the protocol. > > /Fredrik Bob K. From owner-aaa-wg@merit.edu Thu Mar 21 12:48:13 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19530 for <aaa-archive@odin.ietf.org>; Thu, 21 Mar 2002 12:48:12 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 578C091212; Thu, 21 Mar 2002 12:47:20 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1EF9B91213; Thu, 21 Mar 2002 12:47:20 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4DD0491212 for <aaa-wg@trapdoor.merit.edu>; Thu, 21 Mar 2002 12:47:18 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2A0F15DE37; Thu, 21 Mar 2002 12:47:18 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from palrel13.hp.com (palrel13.hp.com [156.153.255.238]) by segue.merit.edu (Postfix) with ESMTP id 0BAA35DE13 for <aaa-wg@merit.edu>; Thu, 21 Mar 2002 12:47:18 -0500 (EST) Received: from hpindsra.cup.hp.com (hpindsra.cup.hp.com [15.13.104.190]) by palrel13.hp.com (Postfix) with ESMTP id 642A84003DD for <aaa-wg@merit.edu>; Thu, 21 Mar 2002 09:47:17 -0800 (PST) Received: from hpindsra (hpindsra [15.13.104.190]) by hpindsra.cup.hp.com with ESMTP (8.8.6 (PHNE_17190)/8.8.6 SMKit7.02) id JAA21200 for <aaa-wg@merit.edu>; Thu, 21 Mar 2002 09:47:39 -0800 (PST) Date: Thu, 21 Mar 2002 09:47:38 -0800 (PST) From: Sivasundar Ramamurthy <sramam@cup.hp.com> X-Sender: sramam@hpindsra To: AAA Working Group <aaa-wg@merit.edu> Subject: [AAA-WG]: Home-Agent-Address AVP Message-ID: <Pine.HPX.4.10.10203210912090.21091-100000@hpindsra> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Hello, It seems as if the sole purpose of the Home-Agent-Address AVP in a HAR is to provide means for the AAAH during HA allocation to specify the address on which a (multihomed) HA "should" service the MN. Letting the HA chose the address of service might be a more flexible option. If this is acceptable, then the Home-Agent-Address AVP serves no use in a HAR. Even during Home Agent Allocation, the HA can use the HA address in the reg-request AVP to deduce that is has been allocated by the AAAH. Can we thus remove the Home-Agent-Address AVP from the HAR? thanks, Siva From owner-aaa-wg@merit.edu Fri Mar 22 12:19:39 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26395 for <aaa-archive@lists.ietf.org>; Fri, 22 Mar 2002 12:19:38 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id AC75091217; Fri, 22 Mar 2002 12:19:28 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 80839912A2; Fri, 22 Mar 2002 12:19:28 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 92A0091217 for <aaa-wg@trapdoor.merit.edu>; Fri, 22 Mar 2002 12:19:27 -0500 (EST) Received: by segue.merit.edu (Postfix) id 75E235DDA5; Fri, 22 Mar 2002 12:19:27 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from frascone.com (adsl-66-137-237-97.dsl.rcsntx.swbell.net [66.137.237.97]) by segue.merit.edu (Postfix) with SMTP id B148B5DD93 for <aaa-wg@merit.edu>; Fri, 22 Mar 2002 12:19:26 -0500 (EST) Received: (qmail 9298 invoked by uid 500); 22 Mar 2002 17:19:26 -0000 Date: Fri, 22 Mar 2002 11:19:26 -0600 From: David Frascone <dave@frascone.com> To: aaa-wg@merit.edu Subject: [AAA-WG]: Interop Results / Request Message-ID: <20020322171925.GE8113@newman.frascone.com> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.25i X-encrypt-payload: no Sender: owner-aaa-wg@merit.edu Precedence: bulk Since we ran out of time in the meeting, I thought I'd give a brief synopsis of the testing that occured at Connectathon: No one showed up. Well, to be fair, there were several Mobile-Ip vendors present that had AAA servers, but none of them supported the applications / extensions that we wanted to test. On a good note, I was able to get a successful interoperation of Nasreq, over the 'net. So, here is a synopsis of what has been interoperated: o Base Protocol o TLS (only once) o Mobile-IPv4 o Accounting o Nasreq (only once, and AAR/AAA only, no DER/DEA) And, here is what really needs to be hammered on: o TLS - Since it has only interoperated once, it needs more testing. o Nasreq - Needs more testing, and DER/DEA needs to be tried. o CMS Security o Diameter over IPSec All of the Nasreq interoperation has been done across the net. Since all of the tests that need to be done are basically point to point exchanges, internet tests should be more than sufficient. (Mobile-IP is very difficult to test when you're not in the same room, but the other tests are not as complex to set up) So, my request: If you have implemented, or are implementing any of the untested extensions *please* send an e-mail to this list (or to me) so we can test. -Dave -- David Frascone Press Ctrl-Alt-Del to continue... From owner-aaa-wg@merit.edu Sun Mar 24 03:03:06 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11430 for <aaa-archive@odin.ietf.org>; Sun, 24 Mar 2002 03:03:06 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 04F1B91222; Sun, 24 Mar 2002 03:02:36 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C924291233; Sun, 24 Mar 2002 03:02:35 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0A85991222 for <aaa-wg@trapdoor.merit.edu>; Sun, 24 Mar 2002 03:02:32 -0500 (EST) Received: by segue.merit.edu (Postfix) id D1D9B5DE00; Sun, 24 Mar 2002 03:02:32 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 48F7F5DD98 for <aaa-wg@merit.edu>; Sun, 24 Mar 2002 03:02:32 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g2O7KLx02190 for <aaa-wg@merit.edu>; Sat, 23 Mar 2002 23:20:21 -0800 Date: Sat, 23 Mar 2002 23:20:21 -0800 (PST) From: Bernard Aboba <aboba@internaut.com> To: aaa-wg@merit.edu Subject: [AAA-WG]: REMINDER: Call for issues on MIP, Base and Transport Message-ID: <Pine.LNX.4.21.0203232309510.1608-100000@internaut.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk As noted at IETF 53, we will be bringing the MIP, Base and Transport documents to WG last call starting on April 2, 2002; the Last Call will run until April 16, 2002. Since the intent is for this to be the final WG last call for these documents, this is effectively your last opportunity to read and comment on them. Since we are getting to the part of the IETF ceremony where the Chair says "speak now, or forever hold your piece", it seemed like a good time to send one last reminder. This means that if you have not read the documents through in their entirety lately, you owe it to yourself (and the AAA WG) to do so NOW. My suggestion is that you set aside some time this week for this -- an uinterrupted period of a few hours, where you can read one or more drafts completely through and comment on it. Since there won't be a "next time", if you don't do this, you'll have no basis on which to complain later. As usual, we will be following the format for issue submissions laid out in http://www.drizzle.com/~aboba/AAA/issues.html, so that the editors can process the required changes most efficiently. This means that in recommending a change, you need to suggest the new text, not just ask the editor to "fix it". This takes more time for the commentor but greatly improves the editor's productivity. For Editorial issues, you do not need to file a separate issue for each spelling mistake. Just package the items together in one big "bag o'nits" and send it off to the mailing list with [issue] in the subject. For Technical issues, it is desirable to keep orthogonal issues separate, so they can be resolved separately, but closely related concerns can be filed together. From owner-aaa-wg@merit.edu Sun Mar 24 15:18:01 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17282 for <aaa-archive@odin.ietf.org>; Sun, 24 Mar 2002 15:18:00 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 709DA91201; Sun, 24 Mar 2002 15:17:26 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CF3B89120F; Sun, 24 Mar 2002 15:17:21 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BDF6891201 for <aaa-wg@trapdoor.merit.edu>; Sun, 24 Mar 2002 15:17:20 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9F2F65DDF9; Sun, 24 Mar 2002 15:17:20 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 3E8535DD8C for <aaa-wg@merit.edu>; Sun, 24 Mar 2002 15:17:20 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g2OJZ6j10757 for <aaa-wg@merit.edu>; Sun, 24 Mar 2002 11:35:06 -0800 Date: Sun, 24 Mar 2002 11:35:06 -0800 (PST) From: Bernard Aboba <aboba@internaut.com> To: aaa-wg@merit.edu Subject: [AAA-WG]: Slides, please Message-ID: <Pine.LNX.4.21.0203241134370.10428-100000@internaut.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk If you presented Slides at the IETF 53 AAA WG meeting, or took minutes, please send them to me. Thanks! From owner-aaa-wg@merit.edu Sun Mar 24 21:11:13 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21059 for <aaa-archive@odin.ietf.org>; Sun, 24 Mar 2002 21:11:13 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 41E0D91203; Sun, 24 Mar 2002 21:11:02 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 15EF591206; Sun, 24 Mar 2002 21:11:02 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 15C6D91203 for <aaa-wg@trapdoor.merit.edu>; Sun, 24 Mar 2002 21:11:01 -0500 (EST) Received: by segue.merit.edu (Postfix) id EA3185DE2F; Sun, 24 Mar 2002 21:11:00 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from cisco.com (titans.cisco.com [161.44.72.74]) by segue.merit.edu (Postfix) with ESMTP id 5F1A85DE26 for <aaa-wg@merit.edu>; Sun, 24 Mar 2002 21:11:00 -0500 (EST) Received: (from gdweber@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) id VAA04686; Sun, 24 Mar 2002 21:10:52 -0500 (EST) From: Greg Weber <gdweber@cisco.com> Message-Id: <200203250210.VAA04686@cisco.com> Subject: Re: [AAA-WG]: REMINDER: Call for issues on MIP, Base and Transport To: aboba@internaut.com (Bernard Aboba) Date: Sun, 24 Mar 2002 21:10:52 -0500 (EST) Cc: aaa-wg@merit.edu In-Reply-To: <Pine.LNX.4.21.0203232309510.1608-100000@internaut.com> from "Bernard Aboba" at Mar 23, 2002 11:20:21 PM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > > As noted at IETF 53, we will be bringing the MIP, Base and Transport > documents to WG last call starting on April 2, 2002; the Last Call will > run until April 16, 2002. A small process observation. The MIPv4 draft has at least a couple of SHOULD references to the CMS draft. One wonders how the IESG will be able to evaluate the former if the latter is not yet submitted... Greg > > Since the intent is for this to be the final WG last call for these > documents, this is effectively your last opportunity to read and comment > on them. > > Since we are getting to the part of the IETF ceremony where the Chair says > "speak now, or forever hold your piece", it seemed like a good time to > send one last reminder. > > This means that if you have not read the documents through in their > entirety lately, you owe it to yourself (and the AAA WG) to do so NOW. My > suggestion is that you set aside some time this week for this -- an > uinterrupted period of a few hours, where you can read one or more drafts > completely through and comment on it. Since there won't be a "next time", > if you don't do this, you'll have no basis on which to complain later. > > As usual, we will be following the format for issue submissions laid out > in http://www.drizzle.com/~aboba/AAA/issues.html, so that the editors can > process the required changes most efficiently. This means that in > recommending a change, you need to suggest the new text, not just ask the > editor to "fix it". This takes more time for the commentor but greatly > improves the editor's productivity. > > For Editorial issues, you do not need to file a separate issue for each > spelling mistake. Just package the items together in one big "bag > o'nits" and send it off to the mailing list with [issue] in the subject. > > For Technical issues, it is desirable to keep orthogonal issues separate, > so they can be resolved separately, but closely related concerns can be > filed together. > > From owner-aaa-wg@merit.edu Mon Mar 25 02:34:53 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04965 for <aaa-archive@odin.ietf.org>; Mon, 25 Mar 2002 02:34:48 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 8CC3091238; Mon, 25 Mar 2002 02:33:08 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 58A1991239; Mon, 25 Mar 2002 02:33:08 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9A8C191238 for <aaa-wg@trapdoor.merit.edu>; Mon, 25 Mar 2002 02:33:01 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8095D5DDEA; Mon, 25 Mar 2002 02:33:01 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by segue.merit.edu (Postfix) with ESMTP id 4AF905DD8D for <aaa-wg@merit.edu>; Mon, 25 Mar 2002 02:33:01 -0500 (EST) Received: from mr5.exu.ericsson.se (mr5att.ericy.com [138.85.224.141]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g2P7Wpi01021; Mon, 25 Mar 2002 01:32:51 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g2P7Wpm19398; Mon, 25 Mar 2002 01:32:51 -0600 (CST) Received: from qpop.exu.ericsson.se (qpop [138.85.75.72]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id BAA09957; Mon, 25 Mar 2002 01:32:50 -0600 (CST) Received: from ericsson.com (racomin-103.exu.ericsson.se [138.85.130.103]) by qpop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id BAA00779; Mon, 25 Mar 2002 01:32:49 -0600 (CST) Message-ID: <3C9ED1FB.C4767485@ericsson.com> Date: Sun, 24 Mar 2002 23:30:03 -0800 From: Tony Johansson <tony.johansson@ericsson.com> X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: aaa-wg <aaa-wg@merit.edu> Cc: Bob Kopacz <BKopacz@InterlinkNetworks.com>, Fredrik Johansson <fredrik.johansson@ipunplugged.com>, Johan Johansson <johanj@ipunplugged.com>, David Spence <DSpence@InterlinkNetworks.com>, "Pat R. Calhoun" <pcalhoun@bstormnetworks.com> Subject: [AAA-WG]: Issue #299 and #301 References: <NEBBKEONMLEDJCMHGHPIGEPADOAA.BKopacz@InterlinkNetworks.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit All, During, the AAA working group meeting at IETF53 I presented the issues #299 and #301 and two alternative ways in which we could workout a solution to the open issues - see below: Alt1: Clarifications / new requirements without any new dependencies to MIP. ------------------------------------------------------------------------------ AAAH - Require that each subdomain of a realm is authorized/authenticated by exactly one AAAH. So while a home network may have multiple AAAH's, each subdomain will have exactly one AAAH. - Or, require that, if the home realm has multiple AAA servers to which the same user can be routed to, then there MUST be a synchronization mechanism between the AAAH servers. However, the specific synchronization mechanism is beyond the scope of this spec. AAAF - How to map HA IP address to HA FQDN is still open. Reverse DNS look up is not at all a straightforward solution for this… Alt 2: New dependencies to MIP, by requiring the usage of the GNAIE draft. ----------------------------------------------------------------------------- AAAH - Require that the MN support the GNAIE draft, updated to include the definition of a AAAH NAI. When sending a MIP RegReq, this AAAH NAI would be included to guarantee that a registered user always ends up in the same initial AAAH. AAAF - The mapping of the HA IP address and HA FQDN, Host and realm would be automatically solved, since this would be included in the MIP RegReq as well. There was a very clear and strong consensus that alternative 2 would be by far the best solution. However, this means more work and dependencies to the MIP working group and the goal is set to have the Diameter MIPv4 appl. draft in working group last call by the April 2nd. Looking at the GNAIE draft, I done see that much work needs to be done to make it fulfill our needs, so to me it could easily be done in time, but the big question is how quickly could it be pushed through the MIP working group and go to last call? I have sent the question MIP wg and I hope to soon get answer back. Regards, Tony From owner-aaa-wg@merit.edu Tue Mar 26 14:18:45 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19767 for <aaa-archive@odin.ietf.org>; Tue, 26 Mar 2002 14:18:45 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id BFFBF91280; Tue, 26 Mar 2002 14:16:44 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 139CC912FC; Tue, 26 Mar 2002 14:16:43 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2E90F91280 for <aaa-wg@trapdoor.merit.edu>; Tue, 26 Mar 2002 14:16:39 -0500 (EST) Received: by segue.merit.edu (Postfix) id 142605DE87; Tue, 26 Mar 2002 14:16:39 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id F2AEE5DE86 for <aaa-wg@merit.edu>; Tue, 26 Mar 2002 14:16:38 -0500 (EST) Received: from phoenix (nat.interlinknetworks.com [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with SMTP id C415379; Tue, 26 Mar 2002 14:16:38 -0500 (EST) From: "Bob Kopacz" <BKopacz@InterlinkNetworks.com> To: "John Loughney" <john.loughney@nokia.com> Cc: "aaa-wg" <aaa-wg@merit.edu> Subject: [AAA-WG]: [issue] Minor corrections/clarifications to base-10 Date: Tue, 26 Mar 2002 14:15:35 -0500 Message-ID: <NEBBKEONLKEDJCMHGHPICEPKCEAA.BKopacz@InterlinkNetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi John, Issue : Minor corrections/clarifications to base-10 Submitter name: Bob Kopacz Submitter email address:bkopacz@interlinknetworks.com Date first submitted: 03-26-2002 Reference: Document: draft-base-10 Comment type: Technical Priority: 1 Section: Rationale/Explanation of issue: Minor corrections/clarifications to base-10. Requested change: In section 1.1.1 Differences from Radius Change "Radius" to all caps in the section title. - - - In section 6.1.8 Relaying and Proxying Requests Change the first two lines of the following paragraph: Relay and Proxy agents MAY include the Proxy-Info AVP in requests if it requires access any local state information when the corresponding response is received. Alternatively, it MAY simply use local storage to store state information. To (four changes "A"... "or"... "agent"... "to"): A Relay or Proxy agent MAY include the Proxy-Info AVP in requests if it requires access to any local state information when the corresponding response is received. Alternatively, it MAY simply use local storage to store state information. - - - In section 7.1 Result-Code AVP The Result-Code AVP (AVP Code 268) is of type Unsigned32 and indicates whether a particular request was completed successfully or whether an error occurred. All Diameter answer messages MUST include one Result-Code AVP. A non-successful Result-Code AVP (one containing a non 2xxx value) MUST include the Error-Reporting-Host AVP if the host setting the Result-Code AVP is different from the identity encoded in the Origin-Host AVP. Change the parenthesized phrase in the preceding paragraph: (one containing a non 2xxx value) To: (one containing a non 2xxx value other than DIAMETER_REDIRECT_INDICATION) - - - In section 8 DIAMETER USER SESSIONS Services provided past the expiration of the Authorization- Lifetime and Auth-Grace-Period AVPs is the responsibility of the access device. Change "is the responsibility" to "are the responsibility". - - - In section 8.4 Session Termination It is also possible that a session that was authorized is never actually started due to action of a proxy. For example, a proxy may modify an authorization answer, converting the result from success to failure, prior to forwarding the message to the access device. A proxy that causes an authorized session not to be started MUST issue an STR to the Diameter server that authorized the session, since the access device has no way of knowing that the session had been authorized. Change the last sentence of the preceding paragraph to: If the answer did not contain an Auth-Session-State AVP with the value NO_STATE_MAINTAINED, a proxy that causes an authorized session not to be started MUST issue an STR to the Diameter server that authorized the session, since the access device has no way of knowing that the session had been authorized. - - - In section 8.12 Re-Auth-Request-Type AVP Following this sentence: The Re-Auth-Request-Type AVP (AVP Code 285) is of type Enumerated and is included in application-specific auth answers to inform the client of the action expected upon expiration of the Authorization-Lifetime. Add the following sentence: If the answer message contains an Authorization-Lifetime AVP with a positive value, the Re-Auth-Request-Type AVP MUST be present in an answer message. - - - In section 8.13 Session-Timeout AVP Change the following sentence: A Session-Timeout AVP MAY be present in a re-authorization message, and contains the number of seconds from the beginning of the re-auth. To: A Session-Timeout AVP MAY be present in a re-authorization answer message, and contains the remaining number of seconds from the beginning of the re-auth. - - - In section 8.17 Session-Binding AVP Change: ACCOUNTING 4 When set, all accounting messages for this session MUST NOT include the Destination-Host AVP. When cleared, the default value, the Destination-Host AVP MUST be present in all accounting messages for this session. To: ACCOUNTING 4 When set, all accounting messages for this session MUST NOT include the Destination-Host AVP. When cleared, the default value, the Destination-Host AVP, if known, MUST be present in all accounting messages for this session. The reason for adding the "if known" phrase is this: The accounting server may be different from the authentication server, and if so, probably isn't known when the first accounting message is sent. For subsequent accounting messages, the accounting server is known by the client and the Destination-Host can be included from then on. - - - Throughout the document: Change "Accounting-Multi-Session-Id" to "Acct-Multi-Session-Id". Since this is an AVP inherited from RADIUS, it should retain the RADIUS name. - - - In section 10.1 Base Protocol Command AVP Table Change: Attribute Name |CER|CEA|... --------------------|---+---+... Supported-Vendor-Id |0+ |0 |... To: Attribute Name |CER|CEA|... --------------------|---+---+... Supported-Vendor-Id |0+ |0+ |... - - - In section 10.2 Accounting AVP Table Change the sentence: The table in this section is used to represent which AVPs defined in this document are to be present in the Accounting messages. To: The table in this section is used to represent which AVPs defined in this document are to be present in the Accounting messages. These AVP occurrence requirements are guidelines which may be expanded and/or overriden by application-specific requirements in the Diameter applications documents. - - - In section 10.2 Accounting AVP Table Add these entries: Attribute Name | ACR | ACA | ------------------------------|-----+-----+ Auth-Application-Id | 0 | 0 | Termination-Cause | 0-1 | 0-1 | Event-Timestamp | 0-1 | 0-1 | - - - In section 10.2 Accounting AVP Table Change: Attribute Name | ACR | ACA | ------------------------------|-----+-----+ User-Name | 0+ | 0+ | To: Attribute Name | ACR | ACA | ------------------------------|-----+-----+ User-Name | 1 | 0-1 | The thinking is, that since the Session-Id AVP requirement is "1", this means the accounting message is for a specific session and hence for a specific user, so the User-Name requirement is also "1". And the User-Name is optionally echoed back in the ACA (per issue#264), hence the "0-1". - - - From owner-aaa-wg@merit.edu Tue Mar 26 14:35:19 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20314 for <aaa-archive@odin.ietf.org>; Tue, 26 Mar 2002 14:35:18 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5B84391282; Tue, 26 Mar 2002 14:35:02 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 90C2191285; Tue, 26 Mar 2002 14:34:09 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CFED491282 for <aaa-wg@trapdoor.merit.edu>; Tue, 26 Mar 2002 14:33:51 -0500 (EST) Received: by segue.merit.edu (Postfix) id ADD875DE86; Tue, 26 Mar 2002 14:33:51 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by segue.merit.edu (Postfix) with ESMTP id F0B0E5DE80 for <aaa-wg@merit.edu>; Tue, 26 Mar 2002 14:33:50 -0500 (EST) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g2QJYeA29349 for <aaa-wg@merit.edu>; Tue, 26 Mar 2002 21:34:40 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id <T59e0f7dcfbac158f21081@esvir01nok.ntc.nokia.com> for <aaa-wg@merit.edu>; Tue, 26 Mar 2002 21:33:49 +0200 Received: from esebe014.NOE.Nokia.com ([172.21.138.53]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 26 Mar 2002 21:33:49 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [AAA-WG]: Proxy-host AVP data type - Minor correction Date: Tue, 26 Mar 2002 21:33:49 +0200 Message-ID: <9E3407CE45911B4097632389B77B202306D074@esebe014.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Updated AAA WG issues list Thread-Index: AcHH5T71PsrXcRJ0SgCpek3zeNNiMgNF/wyQ From: <Ext-Venkata.Ghadiyaram@nokia.com> To: <aaa-wg@merit.edu> X-OriginalArrivalTime: 26 Mar 2002 19:33:49.0697 (UTC) FILETIME=[27766710:01C1D4FD] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA20314 Hi, The data type Proxy-host AVP is specified as IPAddress in the AVP table in section 4.6 of base protocol draft-10 and in section 6.7.3 it is specified as DiameterIdentity. Regards, Kishore From owner-aaa-wg@merit.edu Wed Mar 27 08:03:25 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25755 for <aaa-archive@odin.ietf.org>; Wed, 27 Mar 2002 08:03:25 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 68C379129A; Wed, 27 Mar 2002 08:00:30 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7B15E912D1; Wed, 27 Mar 2002 08:00:24 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E4FCE9129A for <aaa-wg@trapdoor.merit.edu>; Wed, 27 Mar 2002 08:00:21 -0500 (EST) Received: by segue.merit.edu (Postfix) id B06AE5DE16; Wed, 27 Mar 2002 08:00:21 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 73BBD5DD8E for <aaa-wg@merit.edu>; Wed, 27 Mar 2002 08:00:16 -0500 (EST) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g2RD0Ts20190 for <aaa-wg@merit.edu>; Wed, 27 Mar 2002 15:00:29 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id <T59e4b5e4eeac158f24078@esvir04nok.ntc.nokia.com> for <aaa-wg@merit.edu>; Wed, 27 Mar 2002 15:00:15 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 27 Mar 2002 15:00:14 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Proxy-host AVP data type - Minor correction Date: Wed, 27 Mar 2002 15:00:14 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64D21@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Updated AAA WG issues list Thread-Index: AcHH5T71PsrXcRJ0SgCpek3zeNNiMgNF/wyQACSCqiA= From: <john.loughney@nokia.com> To: <Ext-Venkata.Ghadiyaram@nokia.com>, <aaa-wg@merit.edu> X-OriginalArrivalTime: 27 Mar 2002 13:00:14.0962 (UTC) FILETIME=[56658D20:01C1D58F] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA25755 Hi Kishore, > The data type Proxy-host AVP is specified as IPAddress in the > AVP table in section 4.6 of base protocol draft-10 and in > section 6.7.3 it is specified as DiameterIdentity. It should be DiamterIdentity. I will update the document. John From owner-aaa-wg@merit.edu Wed Mar 27 08:14:51 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26420 for <aaa-archive@odin.ietf.org>; Wed, 27 Mar 2002 08:14:51 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 39CC2912D1; Wed, 27 Mar 2002 08:14:37 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F35D9912D2; Wed, 27 Mar 2002 08:14:36 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CD122912D1 for <aaa-wg@trapdoor.merit.edu>; Wed, 27 Mar 2002 08:14:35 -0500 (EST) Received: by segue.merit.edu (Postfix) id A79745DE5B; Wed, 27 Mar 2002 08:14:35 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id EC6975DD8E for <aaa-wg@merit.edu>; Wed, 27 Mar 2002 08:14:34 -0500 (EST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g2RDEls03858 for <aaa-wg@merit.edu>; Wed, 27 Mar 2002 15:14:47 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id <T59e4c2fe59ac158f23078@esvir03nok.nokia.com>; Wed, 27 Mar 2002 15:14:33 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 27 Mar 2002 15:14:33 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [AAA-WG]: RE: [issue] Minor corrections/clarifications to base-10 Date: Wed, 27 Mar 2002 15:14:33 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64D22@esebe004.NOE.Nokia.com> Thread-Topic: [issue] Minor corrections/clarifications to base-10 Thread-Index: AcHU+sK/9DU1EUYmRSuPmTGgtRUg1AAlop0Q From: <john.loughney@nokia.com> To: <BKopacz@InterlinkNetworks.com> Cc: <aaa-wg@merit.edu> X-OriginalArrivalTime: 27 Mar 2002 13:14:33.0714 (UTC) FILETIME=[5640B520:01C1D591] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA26420 Hi Bob, Thasnks for all of the catches. I've updated the document. John > -----Original Message----- > From: ext Bob Kopacz [mailto:BKopacz@InterlinkNetworks.com] > Sent: 26 March, 2002 21:16 > To: Loughney John (NRC/Helsinki) > Cc: aaa-wg > Subject: [issue] Minor corrections/clarifications to base-10 > > > Hi John, > > Issue : Minor corrections/clarifications to base-10 > Submitter name: Bob Kopacz > Submitter email address:bkopacz@interlinknetworks.com > Date first submitted: 03-26-2002 > Reference: > Document: draft-base-10 > Comment type: Technical > Priority: 1 > Section: > > Rationale/Explanation of issue: > > Minor corrections/clarifications to base-10. > > Requested change: > > > In section 1.1.1 Differences from Radius > > Change "Radius" to all caps in the section title. > > - - - > > In section 6.1.8 Relaying and Proxying Requests > > Change the first two lines of the following paragraph: > > Relay and Proxy agents MAY include the Proxy-Info AVP in requests if > it requires access any local state information when the > corresponding > response is received. Alternatively, it MAY simply use local storage > to store state information. > > To (four changes "A"... "or"... "agent"... "to"): > > A Relay or Proxy agent MAY include the Proxy-Info AVP in requests if > it requires access to any local state information when the > corresponding > response is received. Alternatively, it MAY simply use local storage > to store state information. > > - - - > > In section 7.1 Result-Code AVP > > The Result-Code AVP (AVP Code 268) is of type Unsigned32 and > indicates whether a particular request was completed successfully or > whether an error occurred. All Diameter answer messages MUST include > one Result-Code AVP. A non-successful Result-Code AVP (one > containing > a non 2xxx value) MUST include the Error-Reporting-Host AVP if the > host setting the Result-Code AVP is different from the identity > encoded in the Origin-Host AVP. > > Change the parenthesized phrase in the preceding paragraph: > > (one containing a non 2xxx value) > > To: > > (one containing a non 2xxx value other than > DIAMETER_REDIRECT_INDICATION) > > - - - > > In section 8 DIAMETER USER SESSIONS > > Services provided past the expiration of the Authorization- > Lifetime and Auth-Grace-Period AVPs is the responsibility of the > access device. > > Change "is the responsibility" to "are the responsibility". > > - - - > > In section 8.4 Session Termination > > It is also possible that a session that was authorized is never > actually started due to action of a proxy. For example, a proxy may > modify an authorization answer, converting the result from > success to > failure, prior to forwarding the message to the access device. A > proxy that causes an authorized session not to be started MUST issue > an STR to the Diameter server that authorized the session, since the > access device has no way of knowing that the session had been > authorized. > > Change the last sentence of the preceding paragraph to: > > If the answer did not contain an Auth-Session-State AVP > with the value > NO_STATE_MAINTAINED, a proxy that causes an authorized > session not to be > started MUST issue an STR to the Diameter server that authorized the > session, since the access device has no way of knowing that > the session > had been authorized. > > - - - > > In section 8.12 Re-Auth-Request-Type AVP > > Following this sentence: > > The Re-Auth-Request-Type AVP (AVP Code 285) is of type > Enumerated and > is included in application-specific auth answers to inform > the client > of the action expected upon expiration of the > Authorization-Lifetime. > > Add the following sentence: > > If the answer message contains an Authorization-Lifetime AVP with a > positive value, the Re-Auth-Request-Type AVP MUST be > present in an answer > message. > > - - - > > In section 8.13 Session-Timeout AVP > > Change the following sentence: > > A Session-Timeout AVP MAY be present in a re-authorization message, > and contains the number of seconds from the beginning of > the re-auth. > > To: > > A Session-Timeout AVP MAY be present in a re-authorization > answer message, > and contains the remaining number of seconds from the > beginning of the > re-auth. > > - - - > > In section 8.17 Session-Binding AVP > > Change: > > ACCOUNTING 4 > When set, all accounting messages for this session MUST NOT > include the Destination-Host AVP. When cleared, the default > value, the Destination-Host AVP MUST be present in all > accounting messages for this session. > > To: > > ACCOUNTING 4 > When set, all accounting messages for this session MUST NOT > include the Destination-Host AVP. When cleared, the default > value, the Destination-Host AVP, if known, MUST be present in all > accounting messages for this session. > > The reason for adding the "if known" phrase is this: The > accounting server > may be different from the authentication server, and if so, > probably isn't > known when the first accounting message is sent. For subsequent > accounting messages, the accounting server is known by the > client and the > Destination-Host can be included from then on. > > - - - > > Throughout the document: > > Change "Accounting-Multi-Session-Id" to > "Acct-Multi-Session-Id". Since > this is an AVP inherited from RADIUS, it should retain the > RADIUS name. > > - - - > > In section 10.1 Base Protocol Command AVP Table > > Change: > > Attribute Name |CER|CEA|... > --------------------|---+---+... > Supported-Vendor-Id |0+ |0 |... > > To: > > Attribute Name |CER|CEA|... > --------------------|---+---+... > Supported-Vendor-Id |0+ |0+ |... > > - - - > > In section 10.2 Accounting AVP Table > > Change the sentence: > > The table in this section is used to represent which AVPs defined in > this document are to be present in the Accounting messages. > > To: > > The table in this section is used to represent which AVPs > defined in this > document are to be present in the Accounting messages. These AVP > occurrence requirements are guidelines which may be expanded and/or > overriden by application-specific requirements in the Diameter > applications documents. > > - - - > > In section 10.2 Accounting AVP Table > > Add these entries: > > Attribute Name | ACR | ACA | > ------------------------------|-----+-----+ > Auth-Application-Id | 0 | 0 | > Termination-Cause | 0-1 | 0-1 | > Event-Timestamp | 0-1 | 0-1 | > > - - - > > In section 10.2 Accounting AVP Table > > Change: > > Attribute Name | ACR | ACA | > ------------------------------|-----+-----+ > User-Name | 0+ | 0+ | > > To: > > Attribute Name | ACR | ACA | > ------------------------------|-----+-----+ > User-Name | 1 | 0-1 | > > The thinking is, that since the Session-Id AVP requirement is > "1", this > means the accounting message is for a specific session and hence for a > specific user, so the User-Name requirement is also "1". And the > User-Name is optionally echoed back in the ACA (per > issue#264), hence the > "0-1". > > - - - > > From owner-aaa-wg@merit.edu Wed Mar 27 08:19:42 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26653 for <aaa-archive@odin.ietf.org>; Wed, 27 Mar 2002 08:19:41 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 74557912D2; Wed, 27 Mar 2002 08:19:21 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3DD3A912D3; Wed, 27 Mar 2002 08:19:21 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4A42E912D2 for <aaa-wg@trapdoor.merit.edu>; Wed, 27 Mar 2002 08:19:20 -0500 (EST) Received: by segue.merit.edu (Postfix) id 300D25DDBC; Wed, 27 Mar 2002 08:19:20 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by segue.merit.edu (Postfix) with ESMTP id 4661F5DD8E for <aaa-wg@merit.edu>; Wed, 27 Mar 2002 08:19:19 -0500 (EST) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g2RDK8A29559 for <aaa-wg@merit.edu>; Wed, 27 Mar 2002 15:20:09 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id <T59e4c7507fac158f21081@esvir01nok.ntc.nokia.com> for <aaa-wg@merit.edu>; Wed, 27 Mar 2002 15:19:16 +0200 Received: from esebe014.NOE.Nokia.com ([172.21.138.53]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 27 Mar 2002 15:19:17 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [AAA-WG]: Host-IP-Address AVP in CER and CEA Date: Wed, 27 Mar 2002 15:19:17 +0200 Message-ID: <9E3407CE45911B4097632389B77B2023AC74A4@esebe014.NOE.Nokia.com> Thread-Topic: Host-IP-Address AVP in CER and CEA Thread-Index: AcHF6WCAlRROnyXVEdatcAAADnz2vQ== From: <Ext-Venkata.Ghadiyaram@nokia.com> To: <aaa-wg@merit.edu> X-OriginalArrivalTime: 27 Mar 2002 13:19:17.0905 (UTC) FILETIME=[FFA4D010:01C1D591] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA26653 Hi, Maybe this is too simple a question to be put to the WG. I am posting this again as I could not find an answer. I have one query regarding the 1*{Host-IP-Address} AVP in CER and CEA commands. The IPAddress corresponding to the sender, is a part of the TCP connection or an SCTP association(all the potential addresses in case of a multihomed host). When this information can be obtained from the transport layer, is it not redundant to send it as part of CER/CEA. Regards, Kishore From owner-aaa-wg@merit.edu Wed Mar 27 09:47:02 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00514 for <aaa-archive@odin.ietf.org>; Wed, 27 Mar 2002 09:47:02 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 06A2491208; Wed, 27 Mar 2002 09:45:18 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9D78C91237; Wed, 27 Mar 2002 09:45:16 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 04AEF91208 for <aaa-wg@trapdoor.merit.edu>; Wed, 27 Mar 2002 09:45:14 -0500 (EST) Received: by segue.merit.edu (Postfix) id BBCC75DE63; Wed, 27 Mar 2002 09:45:14 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by segue.merit.edu (Postfix) with ESMTP id 130E25DD8E for <aaa-wg@merit.edu>; Wed, 27 Mar 2002 09:45:14 -0500 (EST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g2REjDkY017854 for <aaa-wg@merit.edu>; Wed, 27 Mar 2002 15:45:13 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Wed Mar 27 15:44:30 2002 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id <F4GJGCCB>; Wed, 27 Mar 2002 15:34:23 +0100 Message-ID: <0154633DAF7BD4119C360002A513AA0301F947A3@efijont102> From: "Harri Hakala (LMF)" <Harri.Hakala@lmf.ericsson.se> To: aaa-wg@merit.edu Subject: [AAA-WG]: FW: I-D ACTION:draft-hakala-diameter-credit-control-02.txt Date: Wed, 27 Mar 2002 15:44:29 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C1D59D.E64C33E0" Sender: owner-aaa-wg@merit.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C1D59D.E64C33E0 Content-Type: text/plain; charset="iso-8859-1" Hi, I am forwarding the IETF announcement. All Comments are highly appreciated. Regards......Harri -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: 27. maaliskuuta 2002 14:14 Subject: I-D ACTION:draft-hakala-diameter-credit-control-02.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Diameter Credit Control Application Author(s) : H. Hakala et al. Filename : draft-hakala-diameter-credit-control-02.txt Pages : 23 Date : 26-Mar-02 This document specifies a Diameter application that is used for real- time cost and credit control between a service element and a Credit Control Server in service environment. Diameter accounting messages with additional AVPs are used to transfer service and credit control information between the service element and the Credit Control Server. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-hakala-diameter-credit-control-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-hakala-diameter-credit-control-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-hakala-diameter-credit-control-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------_=_NextPart_000_01C1D59D.E64C33E0 Content-Type: message/rfc822 To: Subject: Date: Wed, 27 Mar 2002 14:56:25 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_002_01C1D59D.E64C33E0" ------_=_NextPart_002_01C1D59D.E64C33E0 Content-Type: text/plain ------_=_NextPart_002_01C1D59D.E64C33E0 Content-Type: application/octet-stream; name="ATT20238" Content-Disposition: attachment; filename="ATT20238" Content-type: message/external-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020326114106.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-hakala-diameter-credit-control-02.txt ------_=_NextPart_002_01C1D59D.E64C33E0 Content-Type: message/external-body; site="internet-drafts"; dir="draft-hakala-diameter-credit-control-02.txt"; mode="ftp.ietf.org"; access-type="anon-ftp" ------_=_NextPart_002_01C1D59D.E64C33E0-- ------_=_NextPart_000_01C1D59D.E64C33E0-- From owner-aaa-wg@merit.edu Wed Mar 27 11:34:45 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06033 for <aaa-archive@odin.ietf.org>; Wed, 27 Mar 2002 11:34:45 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id BED2E91237; Wed, 27 Mar 2002 11:34:33 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8EE169129C; Wed, 27 Mar 2002 11:34:33 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 848DB91237 for <aaa-wg@trapdoor.merit.edu>; Wed, 27 Mar 2002 11:34:32 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0AE045DE57; Wed, 27 Mar 2002 11:34:32 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from ns2.bln1.siemens.de (ns2.bln1.siemens.de [194.138.127.35]) by segue.merit.edu (Postfix) with ESMTP id E1A3E5DE18 for <aaa-wg@merit.edu>; Wed, 27 Mar 2002 11:34:30 -0500 (EST) Received: from mail.bln1.siemens.de (stbf6582 [194.138.127.68]) by ns2.bln1.siemens.de (8.9.3/8.9.3) with ESMTP id RAA06524 for <aaa-wg@merit.edu>; Wed, 27 Mar 2002 17:34:23 +0100 (MET) Received: from bln1.siemens.de (localhost [127.0.0.1]) by mail.bln1.siemens.de (8.11.6+Sun/8.11.6) with ESMTP id g2RGYN411792 for <aaa-wg@merit.edu>; Wed, 27 Mar 2002 17:34:23 +0100 (MET) Message-ID: <3CA1F490.C6B40651@bln1.siemens.de> Date: Wed, 27 Mar 2002 17:34:24 +0100 From: Marko Klaus <mklaus@bln1.siemens.de> Reply-To: mklaus@bln1.siemens.de X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: de,en,zh-CN MIME-Version: 1.0 To: aaa-wg <aaa-wg@merit.edu> Subject: [AAA-WG]: "signoff" Content-Type: multipart/mixed; boundary="------------2EC574033C08F093A5F72AE3" Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. --------------2EC574033C08F093A5F72AE3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit "signoff" --------------2EC574033C08F093A5F72AE3 Content-Type: text/x-vcard; charset=us-ascii; name="mklaus.vcf" Content-Description: Card for Marko Klaus Content-Disposition: attachment; filename="mklaus.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Klaus;Marko x-mozilla-html:FALSE adr:;;;;;; version:2.1 email;internet:<mklaus@bln1.siemens.de> fn:Marko Klaus Werksstudent ICM N PG ES SE B end:vcard --------------2EC574033C08F093A5F72AE3-- From owner-aaa-wg@merit.edu Wed Mar 27 12:59:22 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11876 for <aaa-archive@odin.ietf.org>; Wed, 27 Mar 2002 12:59:22 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DA09491217; Wed, 27 Mar 2002 12:59:08 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A3FA091235; Wed, 27 Mar 2002 12:59:08 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5330091217 for <aaa-wg@trapdoor.merit.edu>; Wed, 27 Mar 2002 12:59:06 -0500 (EST) Received: by segue.merit.edu (Postfix) id 38B895DEA1; Wed, 27 Mar 2002 12:59:06 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com [192.11.226.163]) by segue.merit.edu (Postfix) with ESMTP id E19365DE7E for <aaa-wg@merit.edu>; Wed, 27 Mar 2002 12:59:05 -0500 (EST) Received: from marconi.ih.lucent.com (h135-1-120-108.lucent.com [135.1.120.108]) by hoemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g2RHx4N22853 for <aaa-wg@merit.edu>; Wed, 27 Mar 2002 12:59:04 -0500 (EST) Received: from nwsgpb.ih.lucent.com by marconi.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id LAA16609; Wed, 27 Mar 2002 11:59:04 -0600 (CST) Received: by nwsgpb.ih.lucent.com (8.8.8+Sun/EMS-1.5 client sol2) id LAA06390; Wed, 27 Mar 2002 11:59:04 -0600 (CST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15522.2150.22595.765656@nwsgpb.ih.lucent.com> Date: Wed, 27 Mar 2002 11:59:02 -0600 (CST) From: Pete McCann <mccap@lucent.com> To: aaa-wg@merit.edu Subject: [AAA-WG]: [issue] Bug in Acct state machine + Split State Machines into Client vs. Server X-Mailer: VM 6.75 under 20.4 "Emerald" XEmacs Lucid Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Issue: Bug in Acct state machine + State machines should be split into client vs. server Submitter name: Pete McCann Submitter email address: mccap@lucent.com Date first submitted: 03-27-2002 Reference: Document: diameter-base-09 Comment type: Technical Priority: S Section: 8.1, 8.2 Rationale: Currently, there is no way to enter the PendingI state in the accounting state machine. This is a bug. The state machines given in the diameter base document are confusing to read, because they mix client and server states. Requested Change: Split each machine in two, and replace 8.1 and 8.2 with the following text. Note the addition of an event to the client accounting state machine to enter the PendingI state: 8.1 Authorization Session State Machine This section contains a set of finite state machines, representing the life cycle of Diameter sessions, and which MUST be observed by all Diameter implementations that make use of the authentication and/or authorization portion of a Diameter application. The term Service- Specific below refers to a message defined in a Diameter application (e.g. Mobile IP, NASREQ). There are four different authorization session state machines supported in the Diameter base protocol. The first two describe a session in which the server is maintaining session state, indicated by the value of the Auth-Session-State AVP (or its absence). One describes the session from a client perspective, the other from a server perspective. The second two state machines are used when the server does not maintain session state. Here again, one describes the session from a client perspective, the other from a server perspective. When a session is moved to the Idle state, any resources that were allocated for the particular session must be released. Any event not listed in the state machines MUST be considered as an error condition, and an answer, if applicable, MUST be returned to the originator of the message. The following state machine is observed by a client when state is maintained on the server: CLIENT, STATEFUL State Event Action New State ------------------------------------------------------------- Idle Client or Device Requests send Pending access service specific auth req Pending Successful Service-specific Grant Open authorization answer Access received with default Auth-Session-State value Pending Successful Service-specific Sent STR Discon authorization answer received but service not provided Pending Error processing successful Sent STR Discon Service-specific authorization answer Pending Failed Service-specific Cleanup Idle authorization answer received Open user or client device send Open requests access to service service specific auth req Open Successful Service-specific Extend Open authorization answer received Answer Open Accounting message sent process Open Open Failed Service-specific Discon. Idle authorization answer user/device received. Open Session-Timeout Expires on send STR Discon Access Device Open ASR Received send ASA, Discon STR Open Authorization-Lifetime + send STR Discon Auth-Grace-Period expires on access device Discon ASR Received None Discon Discon STA Received Discon. Idle user/device The following state machine is observed by a server when it is maintaining state for the session: SERVER, STATEFUL State Event Action New State ------------------------------------------------------------- Idle Service-specific authorization send Open request received, and successful user is authorized serv. specific answer Idle Service-specific authorization send Idle request received, and failed serv. user is not authorized specific answer Open Service-specific authorization send Open request received, and user successful is authorized serv. specific answer Open Service-specific authorization send Idle request received, and user Failed serv. is not authorized specific answer, Cleanup Open Accounting message received process Open Open Home server wants to send ASR Open terminate the service Open ASA Received Cleanup Idle with Result-Code = UNKNOWN-SESSION-ID Open ASA Received None Open with Result-Code (ignore) not = UNKNOWN-SESSION-ID Open Authorization-Lifetime (and Cleanup Discon Auth-Grace-Period) expires on home server. Open Session-Timeout expires on Cleanup Discon home server Open STR Received Send STA Idle Not ASA Received None No Change. Open Discon STR Received Send STA Idle The following state machine is observed by a client when state is not maintained on the server: CLIENT, STATELESS State Event Action New State ------------------------------------------------------------- Idle Client or Device Requests send Pending access service specific auth req Pending Successful Service-specific Grant Open authorization answer Access received with Auth-Session- State set to NO_STATE_MAINTAINED Pending Failed Service-specific Cleanup Idle authorization answer received Open Accounting message sent process Open Open Session-Timeout Expires on Discon. Idle Access Device user/device Open Service to user is terminated Discon. Idle user/device The following state machine is observed by a server when it is not maintaining state for the session: SERVER, STATELESS State Event Action New State ------------------------------------------------------------- Idle Service-specific authorization send serv. Open request received, and specific successfully processed answer Open Accounting message received process Open 8.2 Accounting Session State Machine For applications that only require accounting services, the following state machines MUST be supported. The first is to be observed by clients, the second by servers. When a session is moved to the Idle state, any resources that were allocated for the particular session must be released. Any event not listed in the state machines MUST be considered as an error condition, and an answer, if applicable, MUST be returned to the originator of the message. CLIENT, ACCOUNTING State Event Action New State ------------------------------------------------------------- Idle Client or device requests send PendingS access accounting start req. Open Interim interval elapses send PendingI accounting interim record Idle Client or device requests send PendingE a one-time service accounting event req Idle Records in storage Send PendingB record Open User service terminated send PendingL accounting stop req. PendingS Successful accounting Open start answer received PendingS Failure to send and buffer Store Open space available and realtime Start not equal to DELIVER_AND_GRANT Record PendingS Failure to send and no buffer Open space available and realtime equal to GRANT_AND_LOSE PendingS Failure to send and no buffer Disconnect Idle space available and realtime user/dev not equal to GRANT_AND_LOSE PendingI Failure to send and (buffer Store Open space available or old record Interim can be overwritten) and Record realtime not equal to DELIVER_AND_GRANT PendingI Failure to send and no buffer Open space available and realtime equal to GRANT_AND_LOSE PendingI Failure to send and no buffer Disconnect Idle space available and realtime user/dev not equal to GRANT_AND_LOSE PendingE Successful accounting Idle event answer received PendingE Failure to send and buffer Store Idle space available Event Record PendingE Failure to send and no buffer Idle space available PendingB Successful accounting answer Delete Idle received record PendingB Failure to send Idle PendingL Successful accounting Idle stop answer received PendingL Failure to send and buffer Store Idle space available Stop Record PendingL Failure to send and no buffer Idle space available SERVER, ACCOUNTING State Event Action New State ------------------------------------------------------------- Idle Accounting start request send Open received, and successfully accounting processed. start answer Idle Accounting event request send Idle received, and successfully accounting processed. event answer Open Receive Interim Record send Open accounting answer Open Accounting stop request send Idle received, and successfully accounting processed stop answer From owner-aaa-wg@merit.edu Wed Mar 27 14:59:24 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19232 for <aaa-archive@odin.ietf.org>; Wed, 27 Mar 2002 14:59:24 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id BEB919129F; Wed, 27 Mar 2002 14:59:11 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 92777912A0; Wed, 27 Mar 2002 14:59:11 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 98AD49129F for <aaa-wg@trapdoor.merit.edu>; Wed, 27 Mar 2002 14:59:10 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7803A5DE54; Wed, 27 Mar 2002 14:59:10 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 0B2F45DE02 for <aaa-wg@merit.edu>; Wed, 27 Mar 2002 14:59:10 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g2RJGZi08274; Wed, 27 Mar 2002 11:16:35 -0800 Date: Wed, 27 Mar 2002 11:16:35 -0800 (PST) From: Bernard Aboba <aboba@internaut.com> To: Bob Kopacz <BKopacz@InterlinkNetworks.com> Cc: John Loughney <john.loughney@nokia.com>, aaa-wg <aaa-wg@merit.edu> Subject: Re: [AAA-WG]: [issue] Minor corrections/clarifications to base-10 In-Reply-To: <NEBBKEONLKEDJCMHGHPICEPKCEAA.BKopacz@InterlinkNetworks.com> Message-ID: <Pine.LNX.4.21.0203271115590.5997-100000@internaut.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Assigned Issue #314. See http://www.drizzle.com/~aboba/AAA/issues.html for details. On Tue, 26 Mar 2002, Bob Kopacz wrote: > Hi John, > > Issue : Minor corrections/clarifications to base-10 > Submitter name: Bob Kopacz > Submitter email address:bkopacz@interlinknetworks.com > Date first submitted: 03-26-2002 > Reference: > Document: draft-base-10 > Comment type: Technical > Priority: 1 > Section: From owner-aaa-wg@merit.edu Wed Mar 27 18:43:24 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29721 for <aaa-archive@odin.ietf.org>; Wed, 27 Mar 2002 18:43:23 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 26A0B912A1; Wed, 27 Mar 2002 18:43:02 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E464E912A2; Wed, 27 Mar 2002 18:43:01 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DA5E7912A1 for <aaa-wg@trapdoor.merit.edu>; Wed, 27 Mar 2002 18:43:00 -0500 (EST) Received: by segue.merit.edu (Postfix) id BE8E15DDC2; Wed, 27 Mar 2002 18:43:00 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by segue.merit.edu (Postfix) with ESMTP id C98DD5DDBC for <aaa-wg@merit.edu>; Wed, 27 Mar 2002 18:42:59 -0500 (EST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 7BE516A904; Thu, 28 Mar 2002 01:42:53 +0200 (EET) Message-ID: <3CA2595C.2070301@kolumbus.fi> Date: Thu, 28 Mar 2002 01:44:28 +0200 From: Jari Arkko <jari.arkko@kolumbus.fi> User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: aaa-wg@merit.edu, Stephen Farrell <stephen.farrell@baltimore.ie>, john.loughney@nokia.com Subject: [AAA-WG]: [issue] CMS editorial stuff References: <15522.2150.22595.765656@nwsgpb.ih.lucent.com> Content-Type: multipart/mixed; boundary="------------010302000800050903030401" Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. --------------010302000800050903030401 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, On my way to the IETF I I decided to try and read the CMS document well once more. I have only now found the time to send this e-mail about some suggestions I have. Feel free to use these suggestions or discard them if you don't agree... note that there's also a related clarification to base. And I'm proposing some modifications to the AVP occurrence rules in CMS so some of this borders on a technical issue. Jari ---- Issue: CMS editorial issues Submitter name: Jari Arkko Submitter email address: jari@arkko.com Date first submitted: 03-27-2002 Reference: Document: cms-09, base-09 Comment type: Editorial Priority: S Section: CMS: Abs, ToC, 1, 2, 3, 4, 5, Base: 4.6 Rationale: 1) In the abstract "... perform message routing, and other than routing AVPs, do not modify Diameter messages." => "... perform message routing and do not modify Diameter messages beyond routing AVPs." 2) ToC and the document structure. I would suggest the following modifications: - Since terms generally need to introduced before they are used, 1.1 needs to move to its own chapter before chapter 1. - I would add a Terms section. See attached file for initial text. - I would name 2.0 "AVP Protection' and place current 2.0 under it as '2.1. Format' and 1.7 under it as 2.3. Then I would add some clarifying text on exactly what the CMS spec expects nodes to do with AVPs (I couldn't find such text before this point). See attached second file for initial text. - I would name 5.0 "Example Message Flow" 3) Chapter 1. Doesn't really describe what the functionality provided here is, just talks about how it is provided. Suggested text to add before the third paragraph: "This specification provides an additional security mechanism to protect transport of Diameter AVPs through rogue Diameter agents." 4) Chapter 1. "Redirector agent" => "redirect agent" (the term used in base). 5) Chapter 1.2 last paragraph only talks about signing. Why? I suggest that we should talk about both signing and encryption. Here's some proposed text to add at the end: "Similarly, participants MAY apply encryption to protect one or more AVPs within a message." 6) Chapter 4.6 in base. This is related to the above issue. We have now clarified very well what MAY ENCR means, but we haven't done the same for 'MAY Set P Bit'. Essentially, isn't this the same thing? Propose to add text after first paragraph of 4.6: "Similarly, for the originator of a DIameter message, a "P" in the "MAY" column means that if a message containing that AVP is to be sent via a proxy/agent then the message MUST NOT be sent unless there is a DSA between the originator and the recipient or the originator has locally trusted configuration that indicates that CMS need not be used." 7) Chapter 1.3 "reuse the values" -- what values? I think this is still referring to the old Encrypted-AVPs AVP, or something like that. Propose to delete the sentence. 8) 1.3, "does not request a DSAR to request a DSA" => "does not request a DSA through sending a DSAR message" 9) 1.3, "the access device can then determine whether it is willing to provide service, based on its local policy". I would simply say "The access device can then determine whether to trust this notification, based on local configuration i.e. the keys of trusted agents. If the access device can not trust this notification, it MUST refuse the service in question." 10) 3.1, "... which AVPs should be encrypted, signed or both..." -- remove this text, but keep the part about the public keys. 11) 3.1. DSA[RA] message contents, doesn't clearly show which AVPs are used for which purpose, which makes the spec harder to read. Also, misses some of the AVPs. Proposed text in the third attachment. 12) 4.2 Local-CA-Info appears to be unnecessary. Remove from this message. 13) 3.2 "capable of acting as recipients for confidentiality" => "that support DSAs". 14) 3.3. AES. Replace the current text with "It is strongly recommended that the AES algorithm is supported where it is available." 15) 4.1 delete the statement about the cert distribution protocol, I don't think we need to state that. 16) 5.0 delete the text about the bidir signatures and encryption. 17) 5.0 step h,add to the end "Those AVPs that need to be kept confidential are placed in CMS-Encrypted-AVP in encrypted form. Modify picture accordingly. 18) 5.0 step i. Add before the encryption part "The message includes the CMS-Signed-AVP, which authenticates the AVPs that need it". 19) 5.0 step h. "that were requested by the Home Server in the DSAA." => "that need it". 20) section 4.I think CA-Chain should be a "*" instead of "0*1". THere may be zero chains, if the roots and the certs don't mix or if the peer should already know the chain. But there can be multiple chains if several roots are used. --------------010302000800050903030401 Content-Type: text/plain; name="cms-terms.txt" Content-Disposition: inline; filename="cms-terms.txt" Content-Transfer-Encoding: 7bit CA Certificate Authority, a trusted third party that signs cryptographic certificates for other nodes. CMS Cryptographic Message Syntax [CMS]. DSA Diameter Security Association. OCSP Online Certificate Status Protocol [OCSP]. --------------010302000800050903030401 Content-Type: text/plain; name="cms-avp-intro.txt" Content-Disposition: inline; filename="cms-avp-intro.txt" Content-Transfer-Encoding: 7bit This specification allows both the encryption and signing of AVPs. Encryption takes place through taking the AVPs that need protection from the Diameter message and placing them, concatenated and encrypted, in CMS-Encrypted-Data AVP. The original AVPs are not retained in the message. Signing takes place through signing contents of the protected AVPs, and placing the signature in the CMS-Signed-Data AVP. The original AVPs are retained in the message, except in the case where both encryption and signatures are needed. In this case the CMS-Encrypted-Data AVP is created first and this is then signed. --------------010302000800050903030401 Content-Type: text/plain; name="cms-message-contents.txt" Content-Disposition: inline; filename="cms-message-contents.txt" Content-Transfer-Encoding: 7bit The originating node sends the DSAR message to a server in the destination realm. The DSAR message contains: - TTL for this DSA (seconds) in the DSA-TTL AVP. - The realm part of the user's NAI in the Destination-Realm AVP. - The list of direct trust CA's that the originating Diameter node has configured into it for certificate validation. A "direct trust" CA is one that the node is willing to use as the "top" of a certificate chain, sometimes confusingly known as a "root CA". The list is given in a sequence of Local-CA-Info AVPs. - Certificate chains from each direct trust CA, in a sequence of CA-Chain AVPs. One AVP value is needed for each direct trust CA. A value MAY be omitted when the peers know that the relevant chains already exist at the other side. - Public key certificates for the Diameter servers in the sending realm, all of which MUST validate up to one of the CAs above, via the chain of CA certificates above. - A flag indicating whether the originating Diameter node wishes to receive certificate status information using OCSP messages. If this flag requires a fresh OCSP response, a nonce to be used by the destination Diameter node in OCSP requests MUST also be supplied. See [OCSP] for more details on the certificate status protocol and messages. The flag is given in the OCSP-Request-Flags AVP. - Optional nonce for OCSP, in the OCSP-Nonce AVP. - The DSAR message MAY include the CMS-Signed-Data AVP. If the originating node has a private key, and it includes AVPs whose 'P' bit are set, the CMS-Signed-Data AVP MUST be present. The destination node MUST check that the provided elements of the DSAR are valid. It MUST check, at least, that: - Its local policy allows the given TTL, realm, certification status, and other parameters. - A common "top" of the certificate chain can be found between the home and foreign domains. - This certificate chain is cryptographically correct, passes the (relevant parts of the) path validation algorithm specified in [CERTPROF] and terminates at a CA mentioned in the DSAR message - The certificate chain between the "top" certificate and the certificate in the AAA-Node-Cert AVP can be cryptographically verified. - The signature, if any, can be verified. If these conditions can not be verified, the destination node MUST return a DSAA with the Result-Code AVP set to DIAMETER_NO_DSA_ESTABLISHED. In the event the DSAR requested OCSP validation, via the OCSP- Request-Flags AVP, and OCSP is not locally supported, the DSAA MUST be returned with the Result-Code AVP set to DIAMETER_OCSP_NOT_SUPPORTED. Otherwise, the destination node returns the DSAA message which contains: - TTL for this DSA (seconds), in the DSA-TTL AVP. - One or more chains of certificates from the "top" CAs in the DSAR message to the certificates of this node. Each chain appears as a CA-Chain AVP. - Public key certificates for the Diameter servers in the realm that sends the DSAA message. All the certificates MUST validate up to one of the CAs in the DSAR message, via the chain of CA certificates above. - Optionally, if OCSP an response was requested in the DSAR and OCSP is supported, a list of OCSP responses for the certificates in question. If a fresh response was required and a nonce value was included, each response will contain the nonce from the DSAR message - The DSAA MUST include the CMS-Signed-Data, signed by a Diameter agent or server within the user's realm, to prevent an intermediate node from falsely claiming that the DSA has been established. The originating Diameter node MUST check that the provided elements of the DSAR are valid. Any failure results in silently discarding the DSAA message, auditing the event and not sending the original Diameter message that requested protection from a DSA. It MUST check, at least, that: - the certificate chain provided in the DSAA is cryptographically correct, passes the (relevant parts of the) path validation algorithm specified in [CERTPROF] and terminates at a CA mentioned in the DSAR message - the name in the certificate is consistent with the rules detailed in section 3.2. - the DSAA message MUST include the CMS-Signed-Data AVP, the signature MUST be validated and the signer's certificate chain MUST terminate as a CA mentioned in the DSAR message - the expiration of the TTL MUST be less or equal to the earliest expiration of all certificates in the message, encoded in the notAfter field. If the initiator's policy is such that certificate status is required, it MAY indicate that it requires an OCSP response from the DSA peer in the DSAA message, via the OCSP-Request-Flags AVP. Further, the initiator MAY request that the OCSP response be fresh (non-cached) via the OCSP-Request-Flags and OCSP-Nonce AVPs. Upon receipt of a DSAR message requesting an OCSP response, the receiver issues an OCSP request and returns the response within the DSAA message's OCSP-Responses AVP. The sender of the DSAA MAY included a cached OCSP response, unless the requestor specifically requested a fresh response. The nonce value is to be (the beginning of) the nonce in the OCSP response. The reason for this is that the responder MAY add additional bits to the nonce, but the nonce provided in the OSCP- Nonce MUST be present at the beginning of the nonce of the OSCP response. If certificate revocation is enabled, anytime a certificate is used from the local certificate cache, a revocation check MUST be performed. --------------010302000800050903030401-- From owner-aaa-wg@merit.edu Wed Mar 27 19:06:55 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00269 for <aaa-archive@odin.ietf.org>; Wed, 27 Mar 2002 19:06:55 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E9F8F91290; Wed, 27 Mar 2002 19:06:41 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B799A912A2; Wed, 27 Mar 2002 19:06:41 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D01DD91290 for <aaa-wg@trapdoor.merit.edu>; Wed, 27 Mar 2002 19:06:40 -0500 (EST) Received: by segue.merit.edu (Postfix) id B000E5DDF8; Wed, 27 Mar 2002 19:06:40 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 2F07B5DDB5 for <aaa-wg@merit.edu>; Wed, 27 Mar 2002 19:06:40 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g2RNO5k21240; Wed, 27 Mar 2002 15:24:05 -0800 Date: Wed, 27 Mar 2002 15:24:05 -0800 (PST) From: Bernard Aboba <aboba@internaut.com> To: Jari Arkko <jari.arkko@kolumbus.fi> Cc: aaa-wg@merit.edu, Stephen Farrell <stephen.farrell@baltimore.ie>, john.loughney@nokia.com Subject: Re: [AAA-WG]: [issue] CMS editorial stuff In-Reply-To: <3CA2595C.2070301@kolumbus.fi> Message-ID: <Pine.LNX.4.21.0203271523510.20568-100000@internaut.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Assigned issue #316. On Thu, 28 Mar 2002, Jari Arkko wrote: > > Hi, > > On my way to the IETF I I decided to try and read the CMS document well > once more. I have only now found the time to send this e-mail about some > suggestions I have. Feel free to use these suggestions or discard them > if you don't agree... note that there's also a related clarification to > base. And I'm proposing some modifications to the AVP occurrence rules > in CMS so some of this borders on a technical issue. > > Jari > ---- > Issue: CMS editorial issues > Submitter name: Jari Arkko > Submitter email address: jari@arkko.com > Date first submitted: 03-27-2002 > Reference: > Document: cms-09, base-09 > Comment type: Editorial > Priority: S > Section: CMS: Abs, ToC, 1, 2, 3, 4, 5, Base: 4.6 > Rationale: From owner-aaa-wg@merit.edu Wed Mar 27 19:25:22 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00570 for <aaa-archive@odin.ietf.org>; Wed, 27 Mar 2002 19:25:21 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2882C912A2; Wed, 27 Mar 2002 19:24:59 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EA568912A3; Wed, 27 Mar 2002 19:24:58 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id F29B7912A2 for <aaa-wg@trapdoor.merit.edu>; Wed, 27 Mar 2002 19:24:57 -0500 (EST) Received: by segue.merit.edu (Postfix) id D38AE5DDF8; Wed, 27 Mar 2002 19:24:57 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 5F5D15DDB5 for <aaa-wg@merit.edu>; Wed, 27 Mar 2002 19:24:57 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g2RNgP922190 for <aaa-wg@merit.edu>; Wed, 27 Mar 2002 15:42:26 -0800 Date: Wed, 27 Mar 2002 15:42:25 -0800 (PST) From: Bernard Aboba <aboba@internaut.com> To: aaa-wg@merit.edu Subject: [AAA-WG]: Relax with a copy of the Diameter Specification.... Message-ID: <Pine.LNX.4.21.0203271538360.22002-100000@internaut.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Another reminder that if you haven't read the Diameter specifications lately, you owe it to yourself to do so before your opportunity to comment has expired. The Base, MIP and Transport docs will be going to WG last call soon (April 2). Many of us are spending this week with family and friends. As with any such gathering there are "down" moments. For example, Uncle Fred might decide to show his home videos... why not duck out for a few minutes and take a refreshing "Diameter break"? Sit down with the spec of your choice, jot some notes in the margin... and send email when you get back. Your relatives will not miss you, and the AAA WG will be enriched by your contribution. There will be many such "Diameter moments" during the next week, I'm sure. Take advantage of them. Nothing refreshes quite like an hour or two spent reading the Diameter specifications. Just a thought, Bernard From owner-aaa-wg@merit.edu Wed Mar 27 20:35:13 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01619 for <aaa-archive@lists.ietf.org>; Wed, 27 Mar 2002 20:35:13 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 51938912A4; Wed, 27 Mar 2002 20:34:52 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 29783912A6; Wed, 27 Mar 2002 20:34:52 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 194A8912A4 for <aaa-wg@trapdoor.merit.edu>; Wed, 27 Mar 2002 20:34:51 -0500 (EST) Received: by segue.merit.edu (Postfix) id EA3FB5DDB5; Wed, 27 Mar 2002 20:34:50 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from palrel10.hp.com (palrel10.hp.com [156.153.255.245]) by segue.merit.edu (Postfix) with ESMTP id CC5875DDAC for <aaa-wg@merit.edu>; Wed, 27 Mar 2002 20:34:50 -0500 (EST) Received: from hpindsra.cup.hp.com (hpindsra.cup.hp.com [15.13.104.190]) by palrel10.hp.com (Postfix) with ESMTP id 61321C00A69 for <aaa-wg@merit.edu>; Wed, 27 Mar 2002 17:34:50 -0800 (PST) Received: from hpindsra (sramam@hpindsra [15.13.104.190]) by hpindsra.cup.hp.com with ESMTP (8.8.6 (PHNE_17190)/8.8.6 SMKit7.02) id RAA28632 for <aaa-wg@merit.edu>; Wed, 27 Mar 2002 17:35:22 -0800 (PST) Date: Wed, 27 Mar 2002 17:35:22 -0800 (PST) From: Sivasundar Ramamurthy <sramam@cup.hp.com> X-Sender: sramam@hpindsra To: AAA Working Group <aaa-wg@merit.edu> Subject: [AAA-WG]: [issue] ha-fa key Message-ID: <Pine.HPX.4.10.10203271718340.27939-100000@hpindsra> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Submitter Name: Siva Ramamurthy Submitter email address: sivasundar_ramamurthy@hp.com Date first submitter: 3/27/2002 Document: Mobile IP Comment Type: T Priority: 1 Section: 4.5 Explanation of Issue: Section 4.5 has text that says: "If the FA's local policy allows it to receive AAA session Keys, and it does not have any existing keys with the HA, it MAY set the FA-HA-Key-Request flag". the co-existance of the phrases "any existing keys" and "AAA session keys" is confusing! Is the FA-HA key to be used only for the session from which it was obtained, or can it be used with any other sessions that require communciation between this FA and HA? In other words, is the FA-HA key session specific or not? Requested Change: Please clarify, since different implementations at the FA and HA can lead to needless FOR_HOME authentication failures. thanks. From owner-aaa-wg@merit.edu Wed Mar 27 20:42:03 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01676 for <aaa-archive@lists.ietf.org>; Wed, 27 Mar 2002 20:42:02 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 4E851912A6; Wed, 27 Mar 2002 20:41:50 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 22535912A9; Wed, 27 Mar 2002 20:41:50 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2E919912A6 for <aaa-wg@trapdoor.merit.edu>; Wed, 27 Mar 2002 20:41:49 -0500 (EST) Received: by segue.merit.edu (Postfix) id 104865DDB5; Wed, 27 Mar 2002 20:41:39 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 85EE75DDAC for <aaa-wg@merit.edu>; Wed, 27 Mar 2002 20:41:38 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g2S0wvv26124; Wed, 27 Mar 2002 16:58:57 -0800 Date: Wed, 27 Mar 2002 16:58:57 -0800 (PST) From: Bernard Aboba <aboba@internaut.com> To: Greg Weber <gdweber@cisco.com> Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: REMINDER: Call for issues on MIP, Base and Transport (fwd) In-Reply-To: <200203280037.TAA00350@cisco.com> Message-ID: <Pine.LNX.4.21.0203271657410.26030-100000@internaut.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk I would suggest that MIPv4 normative references to CMS be removed, if it is expected that MIPv4 be approved for publication prior to when CMS is ready. On Wed, 27 Mar 2002, Greg Weber wrote: > > Hi Bernard, > Do dependencies between MIPv4 & CMS present a problem for > submitting the drafts separately to IESG? My understanding > from the IETF-53 meeting was that after the coming last call, > MIPv4 would be submitted, but CMS would not yet be ready. > > Thanks, > Greg > > > Forwarded message: > > From: Greg Weber <gdweber@cisco.com> > > Subject: Re: [AAA-WG]: REMINDER: Call for issues on MIP, Base and Transport > > Date: Sun, 24 Mar 2002 21:10:52 -0500 (EST) > > Cc: aaa-wg@merit.edu > > > > > > > > As noted at IETF 53, we will be bringing the MIP, Base and Transport > > > documents to WG last call starting on April 2, 2002; the Last Call will > > > run until April 16, 2002. > > > > A small process observation. The MIPv4 draft has at least > > a couple of SHOULD references to the CMS draft. One wonders > > how the IESG will be able to evaluate the former if the > > latter is not yet submitted... > > > > Greg From owner-aaa-wg@merit.edu Thu Mar 28 03:04:57 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17885 for <aaa-archive@lists.ietf.org>; Thu, 28 Mar 2002 03:04:56 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 0AB13912AE; Thu, 28 Mar 2002 03:04:43 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B64C7912AF; Thu, 28 Mar 2002 03:04:42 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C8EFC912AE for <aaa-wg@trapdoor.merit.edu>; Thu, 28 Mar 2002 03:04:39 -0500 (EST) Received: by segue.merit.edu (Postfix) id 770245DDE0; Thu, 28 Mar 2002 03:04:39 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 4EDFD5DD9A for <aaa-wg@merit.edu>; Thu, 28 Mar 2002 03:04:38 -0500 (EST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g2S84os17838 for <aaa-wg@merit.edu>; Thu, 28 Mar 2002 10:04:50 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id <T59e8cd9572ac158f23078@esvir03nok.nokia.com> for <aaa-wg@merit.edu>; Thu, 28 Mar 2002 10:04:36 +0200 Received: from esebe014.NOE.Nokia.com ([172.21.138.53]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Thu, 28 Mar 2002 10:04:36 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [AAA-WG]: [issue] Host-IP-Address AVP in CER and CEA is redundant Date: Thu, 28 Mar 2002 10:04:35 +0200 Message-ID: <9E3407CE45911B4097632389B77B202306D07B@esebe014.NOE.Nokia.com> Thread-Topic: [issue] Host-IP-Address AVP in CER and CEA is redundant Thread-Index: AcHWMCnIq4jOPTmhEdatcAAADnz2vQ== From: <Ext-Venkata.Ghadiyaram@nokia.com> To: <aaa-wg@merit.edu> X-OriginalArrivalTime: 28 Mar 2002 08:04:36.0731 (UTC) FILETIME=[34000CB0:01C1D62F] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA17885 Subject: [issue] Host-IP-Address AVP in CER and CEA is redundant Submitter name: Ghadiyaram Venkata Kishore Submitter email address: Ext-Venkata.Ghadiyaram@nokia.com, Date first submitted: March 28, 2002 Reference: Document: Base Comment type: T Priority: 1 Section: Rationale/Explanation of issue When a peer receives a CER, the IPAddress(IPAddresses in case of SCTP) of the host sending the message can be obtained from the transport layer as this information is maintained by the transport layer as part of TCP connection or SCTP association. So sending this information as part of Diameter payload is redundant. If alternate peers have to be provided through CER/CEA then we need a list of DiameterURIs, just the IPAddress of the peers is of no use. Requested change: Remove Host-IP-Address AVP from the specification of CER and CEA (both in the text and te ABNF). From owner-aaa-wg@merit.edu Thu Mar 28 03:41:39 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18765 for <aaa-archive@lists.ietf.org>; Thu, 28 Mar 2002 03:41:38 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id AD0FE912AF; Thu, 28 Mar 2002 03:41:27 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 80C71912B0; Thu, 28 Mar 2002 03:41:27 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0932E912AF for <aaa-wg@trapdoor.merit.edu>; Thu, 28 Mar 2002 03:41:25 -0500 (EST) Received: by segue.merit.edu (Postfix) id D8A885DDAC; Thu, 28 Mar 2002 03:41:05 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by segue.merit.edu (Postfix) with ESMTP id ECD415DD9A for <aaa-wg@merit.edu>; Thu, 28 Mar 2002 03:41:04 -0500 (EST) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g2S8ffA08489 for <aaa-wg@merit.edu>; Thu, 28 Mar 2002 10:41:42 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id <T59e8eeb3e9ac158f21081@esvir01nok.ntc.nokia.com>; Thu, 28 Mar 2002 10:40:47 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Thu, 28 Mar 2002 10:40:48 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [AAA-WG]: RE: [issue] CMS editorial stuff Date: Thu, 28 Mar 2002 10:40:48 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64D32@esebe004.NOE.Nokia.com> Thread-Topic: [issue] CMS editorial stuff Thread-Index: AcHV6R5uV/pdip+ZQy+9NpjLl6MnOAASwXhw From: <john.loughney@nokia.com> To: <jari.arkko@kolumbus.fi>, <aaa-wg@merit.edu>, <stephen.farrell@baltimore.ie> X-OriginalArrivalTime: 28 Mar 2002 08:40:48.0715 (UTC) FILETIME=[429A81B0:01C1D634] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA18765 Hi Jari, I've added the text to 4.6 (as suggested) to the base. 316 can be now marked closed for the base. John > -----Original Message----- > From: ext Jari Arkko [mailto:jari.arkko@kolumbus.fi] > Sent: 28 March, 2002 01:44 > To: aaa-wg@merit.edu; Stephen Farrell; Loughney John (NRC/Helsinki) > Subject: [issue] CMS editorial stuff > > > > Hi, > > On my way to the IETF I I decided to try and read the CMS > document well > once more. I have only now found the time to send this e-mail > about some > suggestions I have. Feel free to use these suggestions or discard them > if you don't agree... note that there's also a related > clarification to > base. And I'm proposing some modifications to the AVP occurrence rules > in CMS so some of this borders on a technical issue. > > Jari > ---- > Issue: CMS editorial issues > Submitter name: Jari Arkko > Submitter email address: jari@arkko.com > Date first submitted: 03-27-2002 > Reference: > Document: cms-09, base-09 > Comment type: Editorial > Priority: S > Section: CMS: Abs, ToC, 1, 2, 3, 4, 5, Base: 4.6 > Rationale: > > 1) In the abstract "... perform message routing, and other > than routing AVPs, do not modify Diameter messages." => > "... perform message routing and do not modify Diameter > messages beyond routing AVPs." > > 2) ToC and the document structure. I would suggest > the following modifications: > - Since terms generally need to introduced before they are > used, 1.1 needs to move to its own chapter before chapter 1. > - I would add a Terms section. See attached file for initial > text. > - I would name 2.0 "AVP Protection' and place current 2.0 under > it as '2.1. Format' and 1.7 under it as 2.3. Then I would > add some clarifying text on exactly what the CMS spec expects > nodes to do with AVPs (I couldn't find such text before this > point). See attached second file for initial text. > - I would name 5.0 "Example Message Flow" > > 3) Chapter 1. Doesn't really describe what the functionality > provided here is, just talks about how it is provided. Suggested > text to add before the third paragraph: "This specification > provides an additional security mechanism to protect transport of > Diameter AVPs through rogue Diameter agents." > > 4) Chapter 1. "Redirector agent" => "redirect agent" (the term > used in base). > > 5) Chapter 1.2 last paragraph only talks about signing. Why? I > suggest that we should talk about both signing and encryption. > Here's some proposed text to add at the end: "Similarly, participants > MAY apply encryption to protect one or more AVPs within a message." > > 6) Chapter 4.6 in base. This is related to the above issue. We > have now clarified very well what MAY ENCR means, but we haven't > done the same for 'MAY Set P Bit'. Essentially, isn't this the same > thing? Propose to add text after first paragraph of 4.6: "Similarly, > for the originator of a DIameter message, a "P" in the "MAY" column > means that if a message containing that AVP is to be sent > via a proxy/agent then the message MUST NOT be sent unless there > is a DSA between the originator and the recipient or the originator > has locally trusted configuration that indicates that > CMS need not be used." > > 7) Chapter 1.3 "reuse the values" -- what values? I think this > is still referring to the old Encrypted-AVPs AVP, or something like > that. Propose to delete the sentence. > > 8) 1.3, "does not request a DSAR to request a DSA" => "does > not request > a DSA through sending a DSAR message" > > 9) 1.3, "the access device can then determine whether it is willing to > provide service, based on its local policy". I would simply > say "The access > device can then determine whether to trust this notification, based > on local configuration i.e. the keys of trusted agents. If > the access device > can not trust this notification, it MUST refuse the service > in question." > > 10) 3.1, "... which AVPs should be encrypted, signed or > both..." -- remove > this text, but keep the part about the public keys. > > 11) 3.1. DSA[RA] message contents, doesn't clearly show which AVPs are > used for which purpose, which makes the spec harder to read. Also, > misses some of the AVPs. Proposed text in the third attachment. > > 12) 4.2 Local-CA-Info appears to be unnecessary. Remove from this > message. > > 13) 3.2 "capable of acting as recipients for confidentiality" => > "that support DSAs". > > 14) 3.3. AES. Replace the current text with "It is strongly > recommended > that the AES algorithm is supported where it is available." > > 15) 4.1 delete the statement about the cert distribution > protocol, I don't > think we need to state that. > > 16) 5.0 delete the text about the bidir signatures and encryption. > > 17) 5.0 step h,add to the end "Those AVPs that need to be > kept confidential > are placed in CMS-Encrypted-AVP in encrypted form. Modify > picture accordingly. > > 18) 5.0 step i. Add before the encryption part "The message > includes the > CMS-Signed-AVP, which authenticates the AVPs that need it". > > 19) 5.0 step h. "that were requested by the Home Server in > the DSAA." => > "that need it". > > 20) section 4.I think CA-Chain should be a "*" instead of "0*1". THere > may be zero chains, if the roots and the certs don't mix or > if the peer > should already know the chain. But there can be multiple > chains if several > roots are used. > > > From owner-aaa-wg@merit.edu Thu Mar 28 03:43:06 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18791 for <aaa-archive@lists.ietf.org>; Thu, 28 Mar 2002 03:43:06 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 627E2912B0; Thu, 28 Mar 2002 03:42:50 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 25F15912B1; Thu, 28 Mar 2002 03:42:50 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id F1A9E912B0 for <aaa-wg@trapdoor.merit.edu>; Thu, 28 Mar 2002 03:42:48 -0500 (EST) Received: by segue.merit.edu (Postfix) id D3D005DDE0; Thu, 28 Mar 2002 03:42:48 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 2B3A25DE7A for <aaa-wg@merit.edu>; Thu, 28 Mar 2002 03:42:39 -0500 (EST) Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g2S8gas17166 for <aaa-wg@merit.edu>; Thu, 28 Mar 2002 10:42:36 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id <T59e8f02aabac158f22077@esvir02nok.ntc.nokia.com>; Thu, 28 Mar 2002 10:42:23 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Thu, 28 Mar 2002 10:42:22 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: [issue] Minor corrections/clarifications to base-10 Date: Thu, 28 Mar 2002 10:42:22 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64D34@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: [issue] Minor corrections/clarifications to base-10 Thread-Index: AcHVydwOYrGA2XRnTy6f/HDUX59+iQAapMHA From: <john.loughney@nokia.com> To: <aboba@internaut.com>, <BKopacz@InterlinkNetworks.com> Cc: <aaa-wg@merit.edu> X-OriginalArrivalTime: 28 Mar 2002 08:42:23.0055 (UTC) FILETIME=[7AD5A5F0:01C1D634] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA18791 Hi Bernard, > Assigned Issue #314. I've added the text, it can be marked as closed. John From owner-aaa-wg@merit.edu Thu Mar 28 07:05:17 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22038 for <aaa-archive@odin.ietf.org>; Thu, 28 Mar 2002 07:05:16 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 873F7912B1; Thu, 28 Mar 2002 07:04:55 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 52F6B912B2; Thu, 28 Mar 2002 07:04:55 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2E7E5912B1 for <aaa-wg@trapdoor.merit.edu>; Thu, 28 Mar 2002 07:04:54 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1365E5DDC9; Thu, 28 Mar 2002 07:04:54 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 35DDF5DD9A for <aaa-wg@merit.edu>; Thu, 28 Mar 2002 07:04:53 -0500 (EST) Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g2SC55s14988 for <aaa-wg@merit.edu>; Thu, 28 Mar 2002 14:05:05 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id <T59e9a98b1fac158f22077@esvir02nok.ntc.nokia.com> for <aaa-wg@merit.edu>; Thu, 28 Mar 2002 14:04:51 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Thu, 28 Mar 2002 14:04:51 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [AAA-WG]: Issue 304: Allowance for temporary peer connections - Closed Date: Thu, 28 Mar 2002 14:04:50 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64D39@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: [issue] Allowance for temporary peer connections Thread-Index: AcHFM8wFPoDjfzWCS0SIq41yQanRawRHM61A From: <john.loughney@nokia.com> To: <aaa-wg@merit.edu> X-OriginalArrivalTime: 28 Mar 2002 12:04:51.0161 (UTC) FILETIME=[C3AB8490:01C1D650] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id HAA22038 The text has been added to section 5.3 John > -----Original Message----- > From: ext David Spence [mailto:DSpence@Interlinknetworks.com] > Sent: 06 March, 2002 19:24 > To: AAA Working Group > Subject: [AAA-WG]: [issue] Allowance for temporary peer connections > > > Subject: [issue] Allowance for temporary peer connections > > Submitter name: Ghadiyaram Venkata, David Spence > Submitter email address: Ext-Venkata.Ghadiyaram@nokia.com, > DSpence@Interlinknetworks.com > Date first submitted: March 6, 2002 > Reference: > Document: Base > Comment type: T > Priority: 1 > Section: > Rationale/Explanation of issue > > A CER received from a previously unknown peer (such as would > happen as a > result of peer discovery or a redirect) does not contain complete > information as to how the recipient could recreate the peer > connection if it > is lost. > > Requested change: > > Add the following text: > > "If a CER from and unknown peer is answered with a successful CEA, the > lifetime of the peer entry is equal to the lifetime of the transport > connection. In case of a transport failure, all the pending > transactions > destined to the unknown peer can be discarded." > > -- > David Spence email: > DSpence@Interlinknetworks.com > Interlink Networks, Inc. phone: (734) 821-1203 > 775 Technology Drive, Suite 200 fax: (734) 821-1235 > Ann Arbor, MI 48108 > U.S.A. > From owner-aaa-wg@merit.edu Thu Mar 28 07:11:31 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22649 for <aaa-archive@odin.ietf.org>; Thu, 28 Mar 2002 07:11:30 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 19B39912B3; Thu, 28 Mar 2002 07:11:12 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BEEA1912B4; Thu, 28 Mar 2002 07:11:11 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 75EA2912B3 for <aaa-wg@trapdoor.merit.edu>; Thu, 28 Mar 2002 07:11:10 -0500 (EST) Received: by segue.merit.edu (Postfix) id 561755DDD5; Thu, 28 Mar 2002 07:11:10 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 77AFD5DD9A for <aaa-wg@merit.edu>; Thu, 28 Mar 2002 07:11:09 -0500 (EST) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g2SCBLs19473 for <aaa-wg@merit.edu>; Thu, 28 Mar 2002 14:11:21 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id <T59e9af49beac158f24078@esvir04nok.ntc.nokia.com>; Thu, 28 Mar 2002 14:11:08 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Thu, 28 Mar 2002 14:11:08 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Issue 244: ELECTION_LOST result code Date: Thu, 28 Mar 2002 14:11:07 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64D3A@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Issue 244: ELECTION_LOST result code Thread-Index: AcHFLyXBOy4kOC86Qoin28EjK+QVdQRIm3jg From: <john.loughney@nokia.com> To: <johanj@ipunplugged.com> Cc: <fredrik.johansson@ipunplugged.com>, <aaa-wg@merit.edu> X-OriginalArrivalTime: 28 Mar 2002 12:11:08.0429 (UTC) FILETIME=[A48A0BD0:01C1D651] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id HAA22649 Johan, It has been moved to 7.1.4 Transient Failures now. John > -----Original Message----- > From: ext Johan Johansson [mailto:johanj@ipunplugged.com] > Sent: 06 March, 2002 19:14 > To: Loughney John (NRC/Helsinki) > Cc: fredrik.johansson@ipunplugged.com; aaa-wg@merit.edu > Subject: Re: [AAA-WG]: Issue 244: ELECTION_LOST result code > > > Probably. I guess someone will pop up soon and claim that the > socket is > just torn down, which is what is in section 5.6 in the peer state > machine. I'm not sure if this is just because Pat never got around to > documenting the decision or if it was later overturned. > > The thinking around sending a CEA instead of just tearing down the > socket was that it seemed more civilized and can't be > misinterpreted as > a proper network failure, not even momentarily. > > If this is no longer the consensus then it should be removed. > Or rather > not unremoved I guess. > > j > > john.loughney@nokia.com wrote: > > >Johan, > > > >So 3) Put ELECTION_LOST into the Result_Code AVP, probably > > under Transient Failures > > > >is the corrent answer, correct? > > > >John > > > >>-----Original Message----- > >>From: ext Johan Johansson [mailto:johanj@ipunplugged.com] > >>Sent: 06 March, 2002 18:55 > >>To: Loughney John (NRC/Helsinki) > >>Cc: fredrik.johansson@ipunplugged.com; aaa-wg@merit.edu > >>Subject: Re: [AAA-WG]: Issue 244: ELECTION_LOST result code > >> > >> > >>It was decided at the diameter bakeoff that when a connection > >>lost the > >>election a CEA with ELECTION_LOST as result code should be > >>sent instead > >>of a DPR which would imply that all connections with the peer was > >>severed. Unless this has for some reason been changed afterwards > >>ELECTION_LOST is used and must therefore remain. > >> > >>j > >> > >>john.loughney@nokia.com wrote: > >> > >>>Hi Fredrik, > >>> > >>>>I agree that this issue should be rejected. And I guess it > >>>>has. The strange > >>>>thing is that I can't find the Result Code ELECTION_LOST > anywhere in > >>>>base-10? Has it been deleted anyway? > >>>> > >>>There was continued discussion on this, that it is not > used anymore. > >>>So, I have removed it. However, I just noticed one mail I did not > >>>see - I've included the relevant mails. > >>> > >>>So, we are left with 3 possibilities: > >>>1) ELECTION_LOST code removed from the spec > >>>2) Restore ELECTION_LOST code to where it was in Base > >>> > >>(Disconnect-Cause AVP) > >> > >>>3) Put ELECTION_LOST into the Result_Code AVP, probably > >>> > >>under Transient Failures > >> > >>>Your thoughts? > >>>John > >>> > >> > >> > >> > > > > > > From owner-aaa-wg@merit.edu Thu Mar 28 07:17:19 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22802 for <aaa-archive@odin.ietf.org>; Thu, 28 Mar 2002 07:17:18 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9BB7B912B4; Thu, 28 Mar 2002 07:16:59 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6366B912B6; Thu, 28 Mar 2002 07:16:59 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A0E2B912B4 for <aaa-wg@trapdoor.merit.edu>; Thu, 28 Mar 2002 07:16:26 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7727E5DDD5; Thu, 28 Mar 2002 07:16:26 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id C56B15DD9A for <aaa-wg@merit.edu>; Thu, 28 Mar 2002 07:16:25 -0500 (EST) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g2SCGcs22975 for <aaa-wg@merit.edu>; Thu, 28 Mar 2002 14:16:38 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id <T59e9b41de3ac158f24078@esvir04nok.ntc.nokia.com> for <aaa-wg@merit.edu>; Thu, 28 Mar 2002 14:16:24 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Thu, 28 Mar 2002 14:16:24 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Issue 302: Combine occurrence rules tables with message ABNF - Comments? Date: Thu, 28 Mar 2002 14:16:24 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64D3B@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Issue 302: Combine occurrence rules tables with message ABNF - Comments? Thread-Index: AcHJEsQdmq2wSPDjRvK9lrg/9RL8qQNP3w1A From: <john.loughney@nokia.com> To: <aaa-wg@merit.edu> X-OriginalArrivalTime: 28 Mar 2002 12:16:24.0964 (UTC) FILETIME=[61357440:01C1D652] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id HAA22802 Hi all, I think that this issue can be marked as a reject, unless anyone has a strong reaction to the rejection. John - -----Original Message----- From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] Sent: Sunday, March 10, 2002 11:02 PM To: aboba@internaut.com; aaa-wg@merit.edu Subject: [AAA-WG]: Issue 302: Combine occurrence rules tables with message ABNF - Comments? Hi all, Issue 302 proposes an editorial modification to the drafts, for ABNF usage. Does the workgroup feel that this will improve the documentation? John http://www.drizzle.com/~aboba/AAA/issues.html#Issue%20#302 From owner-aaa-wg@merit.edu Thu Mar 28 07:41:50 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23477 for <aaa-archive@odin.ietf.org>; Thu, 28 Mar 2002 07:41:50 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 0746E912B5; Thu, 28 Mar 2002 07:41:38 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C6F35912B6; Thu, 28 Mar 2002 07:41:37 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8E588912B5 for <aaa-wg@trapdoor.merit.edu>; Thu, 28 Mar 2002 07:41:36 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6A2415DDD7; Thu, 28 Mar 2002 07:41:26 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id AF3175DDD5 for <aaa-wg@merit.edu>; Thu, 28 Mar 2002 07:41:25 -0500 (EST) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g2SCfMs08119 for <aaa-wg@merit.edu>; Thu, 28 Mar 2002 14:41:22 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id <T59e9cac489ac158f24078@esvir04nok.ntc.nokia.com>; Thu, 28 Mar 2002 14:41:09 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Thu, 28 Mar 2002 14:41:09 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [AAA-WG]: Issue 303: Security model for peer discovery and redirect - Text - Please Review Date: Thu, 28 Mar 2002 14:41:08 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64D3D@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Issue 303: Security model for peer discovery and redirect Thread-Index: AcHJ4zyVORCoD+NuRqmm8r/FExDu2wMcey5A From: <john.loughney@nokia.com> To: <aaa-wg@merit.edu> Cc: <DSpence@Interlinknetworks.com>, <randy@psg.com> X-OriginalArrivalTime: 28 Mar 2002 12:41:09.0407 (UTC) FILETIME=[D6017AF0:01C1D655] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id HAA23477 Hi all, I've attempted to write some text for security concerns when using peer-to-peer connections. Unfortunately (or is it fortunately) I missed out on the security 'pixie-dust' that was being handed out in Minneapolis, so I'm not sure if the text does the trick. At this point, I don't think we can do much better than providing guidence, so please verify that my guidence is completely out-to-lunch. thanks, John 13.3 Peer-to-Peer Considerations There are many security issues related to peer-to-peer connections. Caution should be used when creating peer-to-peer connections. Diameter is not intended to allow the peer-to-peer interface to be a public interface. The following is intended to provide some guidance on the issue. A Diameter node SHOULD implement the same security mechanism (IPsec or TLS) across all its peer-to-peer connections. Inconsistent use of security mechanisms can open security holes at a node. For example if a node using both TLS and IPsec, there is not good way in which a connection that is not TLS-secured is, in fact, IPsec secured. Additionally, a per-peer policy would need to be installed, which, in practice is quite hard to maintain. If IPsec is used to secure the peer-to-peer connections to a Diameter node, then there SHOULD be a mechanism to prevent non-IPsec protected traffic from reaching the node. For example, a firewall or inbound filter policy. If IPsec is used and preconfigured SAs are not used, it is not recommended to rely on a PKI-based solution. It is recommended that only peer-to-peer connections are created within a domain, or the Diameter nodes of an organization you trust. If TLS is used to secure peer-to-peer connections, it is recommended that certificates are used in such a way that you only allow peer-to-peer connections within a domain, or with the Diameter nodes of an organization you trust. From owner-aaa-wg@merit.edu Thu Mar 28 08:18:37 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24413 for <aaa-archive@odin.ietf.org>; Thu, 28 Mar 2002 08:18:37 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5BDF7912BA; Thu, 28 Mar 2002 08:18:21 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 29874912D3; Thu, 28 Mar 2002 08:18:21 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0528C912BA for <aaa-wg@trapdoor.merit.edu>; Thu, 28 Mar 2002 08:18:19 -0500 (EST) Received: by segue.merit.edu (Postfix) id D265E5DDD5; Thu, 28 Mar 2002 08:18:19 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by segue.merit.edu (Postfix) with ESMTP id 22A105DD9A for <aaa-wg@merit.edu>; Thu, 28 Mar 2002 08:18:19 -0500 (EST) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g2SDHWG23219 for <aaa-wg@merit.edu>; Thu, 28 Mar 2002 15:17:32 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id <T59e9ecb1d8ac158f25468@esvir05nok.ntc.nokia.com> for <aaa-wg@merit.edu>; Thu, 28 Mar 2002 15:18:12 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Thu, 28 Mar 2002 15:17:14 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [AAA-WG]: Issue #218 ABNF/Table inconsistencies - ?? Date: Thu, 28 Mar 2002 15:17:11 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64D41@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Issue 303: Security model for peer discovery and redirect Thread-Index: AcHJ4zyVORCoD+NuRqmm8r/FExDu2wMcey5AAAFiYCA= From: <john.loughney@nokia.com> To: <aaa-wg@merit.edu> X-OriginalArrivalTime: 28 Mar 2002 13:17:14.0648 (UTC) FILETIME=[E0970980:01C1D65A] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA24413 Hi, I noticed that this issue is listed as open: Issue #218 Pending ABNF/Table inconsistencies Since there is no text supplied, I suggest that this issue be rejected. If there are still inconsistancies, they should be re-entered with more specific text. John From owner-aaa-wg@merit.edu Thu Mar 28 08:26:27 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24705 for <aaa-archive@odin.ietf.org>; Thu, 28 Mar 2002 08:26:27 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 98C47912D3; Thu, 28 Mar 2002 08:26:07 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 642B1912D4; Thu, 28 Mar 2002 08:26:07 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 39ED0912D3 for <aaa-wg@trapdoor.merit.edu>; Thu, 28 Mar 2002 08:26:06 -0500 (EST) Received: by segue.merit.edu (Postfix) id 16FD75DDD6; Thu, 28 Mar 2002 08:26:06 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by segue.merit.edu (Postfix) with ESMTP id 5B5245DD9A for <aaa-wg@merit.edu>; Thu, 28 Mar 2002 08:26:05 -0500 (EST) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g2SDQvA10911 for <aaa-wg@merit.edu>; Thu, 28 Mar 2002 15:26:57 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id <T59e9f3dc8aac158f21081@esvir01nok.ntc.nokia.com> for <aaa-wg@merit.edu>; Thu, 28 Mar 2002 15:26:02 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Thu, 28 Mar 2002 15:26:04 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [AAA-WG]: Issue 311:Acct-Application-Id and Vendor-Specific-Application-Id in ACR Date: Thu, 28 Mar 2002 15:26:03 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD38D79@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Issue 303: Security model for peer discovery and redirect Thread-Index: AcHJ4zyVORCoD+NuRqmm8r/FExDu2wMcey5AAAGILqA= From: <john.loughney@nokia.com> To: <aaa-wg@merit.edu> X-OriginalArrivalTime: 28 Mar 2002 13:26:04.0154 (UTC) FILETIME=[1C333DA0:01C1D65C] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA24705 Hi all, Sometimes, reading through these issues gives me a headache .... but let me see if I have got this one right. The changes are as follows: Change the ABNF in 9.7.1 Accounting-Request from: <ACR> ::= < Diameter Header: 271, REQ, PXY > < Session-Id > {...} { Acct-Application-Id } [...] To: <ACR> ::= < Diameter Header: 271, REQ, PXY > < Session-Id > { ... } [ Acct-Application-Id ] [ ... ] and replace the last 2 paragraphs in section 2.3.3 with: Accounting is somewhat different from Authentication in that in many cases the accounting server only writes the AVPs to disk, and therefore doesn't need to understand them. As a result, one can send vendor-specific AVPs to an accounting server without the server needing to "support" them. Should a new application require Diameter support, but it cannot fit within an existing application without requiring major changes to the specification, it may be desirable to create a new Diameter application. Major changes to an application include: - Requiring a whole different set of mandatory AVPs to a command - Requiring a command that has a different number of round trips to satisfy a request (e.g. application foo has a command that requires one round trip, but new application bar has a command that requires two round trips to complete). - The accounting method is drastically different from any existing application, and the accounting server needs to understand the information carried within the AVPs defined in the application. Note that the creation of a new application should be viewed as a last resort. New Diameter applications MUST define at least one Command Code, the expected AVPs in an ABNF [ABNF] grammar (see section 3.2), and MAY also define new AVPs. When possible, a new Diameter application SHOULD attempt to re-use any existing Diameter AVP, in order to reduce the possibility of having multiple AVPs that carry similar information. Every Diameter application specification MUST have an IANA assigned Application Identifier (see section 2.4). Does this work? John From owner-aaa-wg@merit.edu Thu Mar 28 08:28:00 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24751 for <aaa-archive@odin.ietf.org>; Thu, 28 Mar 2002 08:27:59 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3E9BB912D4; Thu, 28 Mar 2002 08:27:43 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0E11E912D5; Thu, 28 Mar 2002 08:27:42 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DE0DD912D4 for <aaa-wg@trapdoor.merit.edu>; Thu, 28 Mar 2002 08:27:41 -0500 (EST) Received: by segue.merit.edu (Postfix) id BB1EB5DDE0; Thu, 28 Mar 2002 08:27:41 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by segue.merit.edu (Postfix) with ESMTP id A3D765DD9A for <aaa-wg@merit.edu>; Thu, 28 Mar 2002 08:27:40 -0500 (EST) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g2SDSSA11444 for <aaa-wg@merit.edu>; Thu, 28 Mar 2002 15:28:28 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id <T59e9f5409eac158f21081@esvir01nok.ntc.nokia.com>; Thu, 28 Mar 2002 15:27:33 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Thu, 28 Mar 2002 15:27:35 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: [issue] Bug in Acct state machine + Split State Machines into Client vs. Server Date: Thu, 28 Mar 2002 15:27:35 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64D43@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: [issue] Bug in Acct state machine + Split State Machines into Client vs. Server Thread-Index: AcHVvyGmUB/p6rWWSb6U0I8D4CnregAnRdjQ From: <john.loughney@nokia.com> To: <mccap@lucent.com>, <aaa-wg@merit.edu> X-OriginalArrivalTime: 28 Mar 2002 13:27:35.0306 (UTC) FILETIME=[5287EEA0:01C1D65C] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA24751 Hi all, Pete's text seems OK - can the group review it an make sure it looks OK? John > -----Original Message----- > From: ext Pete McCann [mailto:mccap@lucent.com] > Sent: 27 March, 2002 19:59 > To: aaa-wg@merit.edu > Subject: [AAA-WG]: [issue] Bug in Acct state machine + Split State > Machines into Client vs. Server > > > > Issue: Bug in Acct state machine + State machines > should be split into client vs. server > Submitter name: Pete McCann > Submitter email address: mccap@lucent.com > Date first submitted: 03-27-2002 > Reference: > Document: diameter-base-09 > Comment type: Technical > Priority: S > Section: 8.1, 8.2 > > Rationale: > > Currently, there is no way to enter the PendingI state in the > accounting state > machine. This is a bug. > > The state machines given in the diameter base document are confusing > to read, because they mix client and server states. > > Requested Change: > > Split each machine in two, and replace 8.1 and 8.2 with the following > text. Note the addition of an event to the client accounting state > machine to enter the PendingI state: > > > > 8.1 Authorization Session State Machine > > This section contains a set of finite state machines, > representing the life > cycle of Diameter sessions, and which MUST be observed by > all Diameter > implementations that make use of the authentication and/or > authorization portion of a Diameter application. The term Service- > Specific below refers to a message defined in a Diameter > application > (e.g. Mobile IP, NASREQ). > > There are four different authorization session state machines > supported in the Diameter base protocol. The first two describe a > session in which the server is maintaining session state, indicated > by the value of the Auth-Session-State AVP (or its absence). One > describes the session from a client perspective, the other from a > server perspective. The second two state machines are used when > the server does not maintain session state. Here again, one > describes the session from a client perspective, the other from a > server perspective. > > When a session is moved to the Idle state, any resources that were > allocated for the particular session must be released. > Any event not > listed in the state machines MUST be considered as an error > condition, and an answer, if applicable, MUST be returned to the > originator of the message. > > The following state machine is observed by a client when state is > maintained on the server: > > CLIENT, STATEFUL > State Event Action New State > ------------------------------------------------------------- > Idle Client or Device Requests send Pending > access service > specific > auth req > > Pending Successful Service-specific Grant Open > authorization answer Access > received with default > Auth-Session-State value > > Pending Successful Service-specific Sent STR Discon > authorization answer received > but service not provided > > Pending Error processing successful Sent STR Discon > Service-specific authorization > answer > > Pending Failed Service-specific Cleanup Idle > authorization answer received > > Open user or client device send Open > requests access to service service > specific > auth req > > Open Successful Service-specific Extend Open > authorization answer received Answer > > Open Accounting message sent process Open > > Open Failed Service-specific Discon. Idle > authorization answer user/device > received. > > Open Session-Timeout Expires on send STR Discon > Access Device > > Open ASR Received send ASA, Discon > STR > > Open Authorization-Lifetime + send STR Discon > Auth-Grace-Period expires on > access device > > Discon ASR Received None Discon > > Discon STA Received Discon. Idle > user/device > > > The following state machine is observed by a server when it is > maintaining state for the session: > > SERVER, STATEFUL > State Event Action New State > ------------------------------------------------------------- > Idle Service-specific authorization send Open > request received, and successful > user is authorized serv. > specific answer > > Idle Service-specific authorization send Idle > request received, and failed serv. > user is not authorized specific answer > > Open Service-specific authorization send Open > request received, and user successful > is authorized serv. specific > answer > > Open Service-specific authorization send Idle > request received, and user Failed serv. > is not authorized specific > answer, > Cleanup > > Open Accounting message received process Open > > Open Home server wants to send ASR Open > terminate the service > > Open ASA Received Cleanup Idle > with Result-Code > = UNKNOWN-SESSION-ID > > Open ASA Received None Open > with Result-Code (ignore) > not = UNKNOWN-SESSION-ID > > Open Authorization-Lifetime (and Cleanup Discon > Auth-Grace-Period) expires > on home server. > > Open Session-Timeout expires on Cleanup Discon > home server > > Open STR Received Send STA Idle > > Not ASA Received None No Change. > Open > > Discon STR Received Send STA Idle > > > > The following state machine is observed by a client when state is > not maintained on the server: > > CLIENT, STATELESS > State Event Action New State > ------------------------------------------------------------- > Idle Client or Device Requests send Pending > access service > specific > auth req > > Pending Successful Service-specific Grant Open > authorization answer Access > received with Auth-Session- > State set to > NO_STATE_MAINTAINED > > Pending Failed Service-specific Cleanup Idle > authorization answer > received > > Open Accounting message sent process Open > > Open Session-Timeout Expires on Discon. Idle > Access Device user/device > > Open Service to user is terminated Discon. Idle > user/device > > > > The following state machine is observed by a server when it is not > maintaining state for the session: > > SERVER, STATELESS > State Event Action New State > ------------------------------------------------------------- > Idle Service-specific authorization send serv. Open > request received, and specific > successfully processed answer > > Open Accounting message received process Open > > > > > 8.2 Accounting Session State Machine > > For applications that only require accounting services, > the following > state machines MUST be supported. The first is to be observed by > clients, the second by servers. > > When a session is moved to the Idle state, any resources that were > allocated for the particular session must be released. > Any event not > listed in the state machines MUST be considered as an error > condition, and an answer, if applicable, MUST be returned to the > originator of the message. > > > CLIENT, ACCOUNTING > State Event Action New State > ------------------------------------------------------------- > Idle Client or device requests send PendingS > access accounting > start req. > > Open Interim interval elapses send PendingI > accounting > interim > record > > Idle Client or device requests send PendingE > a one-time service accounting > event req > > Idle Records in storage Send PendingB > record > > Open User service terminated send PendingL > accounting > stop req. > > PendingS Successful accounting Open > start answer received > > PendingS Failure to send and buffer Store Open > space available and realtime Start > not equal to DELIVER_AND_GRANT Record > > PendingS Failure to send and no buffer Open > space available and realtime > equal to GRANT_AND_LOSE > > PendingS Failure to send and no buffer Disconnect Idle > space available and realtime user/dev > not equal to > GRANT_AND_LOSE > > PendingI Failure to send and (buffer Store Open > space available or old record Interim > can be overwritten) and Record > realtime not equal to > DELIVER_AND_GRANT > > PendingI Failure to send and no buffer Open > space available and realtime > equal to GRANT_AND_LOSE > > PendingI Failure to send and no buffer Disconnect Idle > space available and realtime user/dev > not equal to GRANT_AND_LOSE > > PendingE Successful accounting Idle > event answer received > > PendingE Failure to send and buffer Store Idle > space available Event > Record > > PendingE Failure to send and no buffer Idle > space available > > PendingB Successful accounting answer Delete Idle > received record > > PendingB Failure to send Idle > > PendingL Successful accounting Idle > stop answer received > > PendingL Failure to send and buffer Store Idle > space available Stop > Record > > PendingL Failure to send and no buffer Idle > space available > > > > > SERVER, ACCOUNTING > State Event Action New State > ------------------------------------------------------------- > > Idle Accounting start request send Open > received, and successfully accounting > processed. start > answer > > Idle Accounting event request send Idle > received, and successfully accounting > processed. event > answer > > Open Receive Interim Record send Open > accounting > answer > > Open Accounting stop request send Idle > received, and successfully accounting > processed stop answer > > > > From owner-aaa-wg@merit.edu Thu Mar 28 09:08:05 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26424 for <aaa-archive@odin.ietf.org>; Thu, 28 Mar 2002 09:08:05 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B5DF3912D7; Thu, 28 Mar 2002 09:07:51 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 87655912D8; Thu, 28 Mar 2002 09:07:51 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6F63C912D7 for <aaa-wg@trapdoor.merit.edu>; Thu, 28 Mar 2002 09:07:50 -0500 (EST) Received: by segue.merit.edu (Postfix) id 40EB25DDD5; Thu, 28 Mar 2002 09:07:50 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from frascone.com (adsl-66-137-237-97.dsl.rcsntx.swbell.net [66.137.237.97]) by segue.merit.edu (Postfix) with SMTP id 8259D5DD9A for <aaa-wg@merit.edu>; Thu, 28 Mar 2002 09:07:49 -0500 (EST) Received: (qmail 17791 invoked by uid 500); 28 Mar 2002 14:07:46 -0000 Date: Thu, 28 Mar 2002 08:07:46 -0600 From: David Frascone <dave@frascone.com> To: Ext-Venkata.Ghadiyaram@nokia.com Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: [issue] Host-IP-Address AVP in CER and CEA is redundant Message-ID: <20020328140746.GS4284@newman.frascone.com> Mail-Followup-To: Ext-Venkata.Ghadiyaram@nokia.com, aaa-wg@merit.edu References: <9E3407CE45911B4097632389B77B202306D07B@esebe014.NOE.Nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9E3407CE45911B4097632389B77B202306D07B@esebe014.NOE.Nokia.com> User-Agent: Mutt/1.3.25i X-encrypt-payload: no Sender: owner-aaa-wg@merit.edu Precedence: bulk I don't think I agree with this. If a host has multiple IP addresses, or, if a firewall is involved, the IP address reported in the transport layer might not be the IP address that the host wants to advertise. So, I vote, "reject". -Dave On Thursday, 28 Mar 2002, Ext-Venkata.Ghadiyaram@nokia.com wrote: > Subject: [issue] Host-IP-Address AVP in CER and CEA is redundant > > Submitter name: Ghadiyaram Venkata Kishore > Submitter email address: Ext-Venkata.Ghadiyaram@nokia.com, > Date first submitted: March 28, 2002 > Reference: > Document: Base > Comment type: T > Priority: 1 > Section: > Rationale/Explanation of issue > > When a peer receives a CER, the IPAddress(IPAddresses in case of SCTP) of the host sending the message can be obtained from the transport layer as this information is maintained by the transport layer as part of TCP connection or SCTP association. So sending this information as part of Diameter payload is redundant. > > If alternate peers have to be provided through CER/CEA then we need a list of DiameterURIs, just the IPAddress of the peers is of no use. > > Requested change: > > Remove Host-IP-Address AVP from the specification of CER and CEA (both in the text and te ABNF). > -- David Frascone I'm moving to Mars next week, so if you have any boxes... From owner-aaa-wg@merit.edu Thu Mar 28 10:05:18 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29492 for <aaa-archive@odin.ietf.org>; Thu, 28 Mar 2002 10:05:18 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 79A3A912DC; Thu, 28 Mar 2002 10:03:22 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 47248912DE; Thu, 28 Mar 2002 10:03:22 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 104C5912DC for <aaa-wg@trapdoor.merit.edu>; Thu, 28 Mar 2002 10:03:18 -0500 (EST) Received: by segue.merit.edu (Postfix) id E80085DE05; Thu, 28 Mar 2002 10:03:17 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 37C595DDBD for <aaa-wg@merit.edu>; Thu, 28 Mar 2002 10:03:17 -0500 (EST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g2SF3Ts27819 for <aaa-wg@merit.edu>; Thu, 28 Mar 2002 17:03:29 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id <T59ea4cdff1ac158f23078@esvir03nok.nokia.com>; Thu, 28 Mar 2002 17:03:15 +0200 Received: from esebe014.NOE.Nokia.com ([172.21.138.53]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Thu, 28 Mar 2002 17:03:15 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: [issue] Host-IP-Address AVP in CER and CEA is redundant Date: Thu, 28 Mar 2002 17:03:08 +0200 Message-ID: <9E3407CE45911B4097632389B77B202306D07E@esebe014.NOE.Nokia.com> Thread-Topic: [AAA-WG]: [issue] Host-IP-Address AVP in CER and CEA is redundant Thread-Index: AcHWYfGw9Inm7MspQvaXVdiPL/vkpgAAOzIA From: <Ext-Venkata.Ghadiyaram@nokia.com> To: <dave@frascone.com> Cc: <aaa-wg@merit.edu> X-OriginalArrivalTime: 28 Mar 2002 15:03:15.0951 (UTC) FILETIME=[B038D7F0:01C1D669] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA29492 Hi David, By "firewall involvemet" do you mean the firewall translates the address. The address/addresses retrieved from the transport layer are the addresses where the host can be reached. If there are addresses using which a host cannot be reached, why does one want to advertise them and why will be the receiver interested in them. In case of a multihomed host running SCTP, still all the IPAddresses can be obtained from the SCTP association. In any case I do not see any reason for the IPAddress information to be carried in the Diameter payload. -Kishore -----Original Message----- From: ext David Frascone [mailto:dave@frascone.com] Sent: 28. March 2002 16:08 To: Ghadiyaram Venkata (EXT-TataConsultancy/Helsinki) Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: [issue] Host-IP-Address AVP in CER and CEA is redundant I don't think I agree with this. If a host has multiple IP addresses, or, if a firewall is involved, the IP address reported in the transport layer might not be the IP address that the host wants to advertise. So, I vote, "reject". -Dave On Thursday, 28 Mar 2002, Ext-Venkata.Ghadiyaram@nokia.com wrote: > Subject: [issue] Host-IP-Address AVP in CER and CEA is redundant > > Submitter name: Ghadiyaram Venkata Kishore > Submitter email address: Ext-Venkata.Ghadiyaram@nokia.com, > Date first submitted: March 28, 2002 > Reference: > Document: Base > Comment type: T > Priority: 1 > Section: > Rationale/Explanation of issue > > When a peer receives a CER, the IPAddress(IPAddresses in case of SCTP) of the host sending the message can be obtained from the transport layer as this information is maintained by the transport layer as part of TCP connection or SCTP association. So sending this information as part of Diameter payload is redundant. > > If alternate peers have to be provided through CER/CEA then we need a list of DiameterURIs, just the IPAddress of the peers is of no use. > > Requested change: > > Remove Host-IP-Address AVP from the specification of CER and CEA (both in the text and te ABNF). > -- David Frascone I'm moving to Mars next week, so if you have any boxes... From owner-aaa-wg@merit.edu Thu Mar 28 10:09:35 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29656 for <aaa-archive@odin.ietf.org>; Thu, 28 Mar 2002 10:09:31 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 39A9E912DD; Thu, 28 Mar 2002 10:09:17 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0730C912DE; Thu, 28 Mar 2002 10:09:16 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id ED598912DD for <aaa-wg@trapdoor.merit.edu>; Thu, 28 Mar 2002 10:09:15 -0500 (EST) Received: by segue.merit.edu (Postfix) id BEC565DE05; Thu, 28 Mar 2002 10:09:15 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from frascone.com (adsl-66-137-237-97.dsl.rcsntx.swbell.net [66.137.237.97]) by segue.merit.edu (Postfix) with SMTP id 1B04C5DDBD for <aaa-wg@merit.edu>; Thu, 28 Mar 2002 10:09:15 -0500 (EST) Received: (qmail 18532 invoked by uid 500); 28 Mar 2002 15:09:14 -0000 Date: Thu, 28 Mar 2002 09:09:14 -0600 From: David Frascone <dave@frascone.com> To: Ext-Venkata.Ghadiyaram@nokia.com Cc: dave@frascone.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: [issue] Host-IP-Address AVP in CER and CEA is redundant Message-ID: <20020328150914.GA18486@newman.frascone.com> Mail-Followup-To: Ext-Venkata.Ghadiyaram@nokia.com, dave@frascone.com, aaa-wg@merit.edu References: <9E3407CE45911B4097632389B77B202306D07E@esebe014.NOE.Nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9E3407CE45911B4097632389B77B202306D07E@esebe014.NOE.Nokia.com> User-Agent: Mutt/1.3.25i X-encrypt-payload: no Sender: owner-aaa-wg@merit.edu Precedence: bulk On Thursday, 28 Mar 2002, Ext-Venkata.Ghadiyaram@nokia.com wrote: > Hi David, > > By "firewall involvemet" do you mean the firewall translates the address. The address/addresses retrieved from the transport layer are the addresses where the host can be reached. If there are addresses using which a host cannot be reached, why does one want to advertise them and why will be the receiver interested in them. By firewall involvement, I mean that I have five load balancing Diameter servers behind a firewall. But, only one of the servers has an IP address that is reachable from the net for inbound connections. The firewall blocks the rest. Since SYN's will be discarded by the firewall, shouldn't all five servers advertise the only routable address as their Host-IP-Address? > > In case of a multihomed host running SCTP, still all the IPAddresses can be obtained from the SCTP association. Ok. What about TCP? Since TCP is a mandatory MUST, Host-IP-Address seems to have value. Since it has *some* value, why remove it. > In any case I do not see any reason for the IPAddress information to be carried in the Diameter payload. I see reasons (mentioned above), so I am *against* this change. -- David Frascone IBM: I Buy Macinstosh From owner-aaa-wg@merit.edu Thu Mar 28 10:32:44 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00769 for <aaa-archive@odin.ietf.org>; Thu, 28 Mar 2002 10:32:44 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 4A092912DF; Thu, 28 Mar 2002 10:32:30 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0D818912E0; Thu, 28 Mar 2002 10:32:29 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A58E6912DF for <aaa-wg@trapdoor.merit.edu>; Thu, 28 Mar 2002 10:32:26 -0500 (EST) Received: by segue.merit.edu (Postfix) id 84AD85DDD3; Thu, 28 Mar 2002 10:32:26 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id C61165DDBD for <aaa-wg@merit.edu>; Thu, 28 Mar 2002 10:32:25 -0500 (EST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g2SFWcs12084 for <aaa-wg@merit.edu>; Thu, 28 Mar 2002 17:32:38 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id <T59ea678e82ac158f23078@esvir03nok.nokia.com> for <aaa-wg@merit.edu>; Thu, 28 Mar 2002 17:32:24 +0200 Received: from esebe014.NOE.Nokia.com ([172.21.138.53]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Thu, 28 Mar 2002 17:32:24 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: [issue] Host-IP-Address AVP in CER and CEA is redundant Date: Thu, 28 Mar 2002 17:32:23 +0200 Message-ID: <9E3407CE45911B4097632389B77B202306D07F@esebe014.NOE.Nokia.com> Thread-Topic: [AAA-WG]: [issue] Host-IP-Address AVP in CER and CEA is redundant Thread-Index: AcHWaoec3abPYJCuRLSPOUK2nLNmcQAAXaeg From: <Ext-Venkata.Ghadiyaram@nokia.com> To: <dave@frascone.com> Cc: <aaa-wg@merit.edu> X-OriginalArrivalTime: 28 Mar 2002 15:32:24.0555 (UTC) FILETIME=[C278A3B0:01C1D66D] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA00769 -----Original Message----- From: ext David Frascone [mailto:dave@frascone.com] Sent: 28. March 2002 17:09 To: Ghadiyaram Venkata (EXT-TataConsultancy/Helsinki) Cc: dave@frascone.com; aaa-wg@merit.edu Subject: Re: [AAA-WG]: [issue] Host-IP-Address AVP in CER and CEA is redundant On Thursday, 28 Mar 2002, Ext-Venkata.Ghadiyaram@nokia.com wrote: > Hi David, > > By "firewall involvemet" do you mean the firewall translates the address. The address/addresses retrieved from the transport layer are the addresses where the host can be reached. If there are addresses using which a host cannot be reached, why does one want to advertise them and why will be the receiver interested in them. By firewall involvement, I mean that I have five load balancing Diameter servers behind a firewall. But, only one of the servers has an IP address that is reachable from the net for inbound connections. The firewall blocks the rest. Since SYN's will be discarded by the firewall, shouldn't all five servers advertise the only routable address as their Host-IP-Address? - But in this case is it not this advertised address which could be retreived from the transport connection. > > In case of a multihomed host running SCTP, still all the IPAddresses can be obtained from the SCTP association. Ok. What about TCP? Since TCP is a mandatory MUST, Host-IP-Address seems to have value. - In case of TCP the connection is with only one address. In case this connection fails, other addresses are tried. But it is not necessary that the host is listening on the same port on the other addresses. So in this case the host should advertise multiple DiameterURIs and not just addresses. So sending a list of DiameterURIs in CER/CEA will be useful rather than sending just the IPAddresses. Since it has *some* value, why remove it. In case of TCP > In any case I do not see any reason for the IPAddress information to be carried in the Diameter payload. I see reasons (mentioned above), so I am *against* this change. -- David Frascone IBM: I Buy Macinstosh From owner-aaa-wg@merit.edu Thu Mar 28 14:43:39 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12496 for <aaa-archive@odin.ietf.org>; Thu, 28 Mar 2002 14:43:38 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5A6029121B; Thu, 28 Mar 2002 14:43:25 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1C39E912F8; Thu, 28 Mar 2002 14:43:25 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 062E8912F7 for <aaa-wg@trapdoor.merit.edu>; Thu, 28 Mar 2002 14:43:24 -0500 (EST) Received: by segue.merit.edu (Postfix) id E40AF5DDC5; Thu, 28 Mar 2002 14:43:23 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by segue.merit.edu (Postfix) with ESMTP id 9D48F5DDB8 for <aaa-wg@merit.edu>; Thu, 28 Mar 2002 14:43:23 -0500 (EST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 1234C6A904; Thu, 28 Mar 2002 21:43:12 +0200 (EET) Message-ID: <3CA372B0.7040201@kolumbus.fi> Date: Thu, 28 Mar 2002 21:44:48 +0200 From: Jari Arkko <jari.arkko@kolumbus.fi> User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: john.loughney@nokia.com Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 311:Acct-Application-Id and Vendor-Specific-Application-Id in ACR References: <0C1353ABB1DEB74DB067ADFF749C4EEFD38D79@esebe004.NOE.Nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit I have a somewhat modified proposal. Removing the acct-application-id is a nice idea, but unfortunately it runs into trouble with the capability discovery process and in particular with the contents of section 6.1. So, I'm proposing we keep the acct application ids, but allow for vendor specific values as well. This allows also at the same time that the accounting servers will be able to know the application type immediately, without trying to infer it from the AVPs. My proposed solution contains the following changes: 1) Section 2.3.3 should be renumbered in base to 1.3.3. (!) 2) References to section 2.5 throughout the base are wrong, and should probably point to 2.4 3) 2.5 Connections vs. Sessions is missing from the contents table. (It seems like going through the whole contents table as well as all references would make sense.) 4) Relay app id (0xffffffff) can be used also by "dumb" file writing accounting servers. Add text to just before "while" in 2.4: ", accounting servers capable of storing any records MUST advertise the Relay Application Identifier for accounting". 5) Modify ANF for ACR as follows: <ACR> ::= < Diameter Header: 271, REQ, PXY > < Session-Id > { ... } [ Acct-Application-Id ] [ Vendor-Specific-Application-Id ] [ ... ] And add text: "One of Acct-Application-Id and Vendor-Specific-Application-Id AVPs MUST be present. If the Vendor-Specific-Application-Id grouped AVP is present, it must have an Acct-Application-Id inside." 6) Similar modifications for ACA. 7) Don't touch 2.3.3 (i.e. 1.2.3), it is for authentication only. 8) Add replace the text in 1.2.4 with Services that have an Application Identifier MUST use the same identifier also to identify the service when Diameter accounting is used. There are services that only require the use of Diameter accounting. Such services need to define the service specific AVPs that must be carried in the Accounting-Request/Answer messages, but do not need to define command codes. Application Identifiers are, however, still required for accounting due to the Diameter capability discovery process. Every accounting application MUST have either an IANA allocated Application Identifier, or a vendor specific Application Identifier. When possible, a new Diameter accounting application SHOULD attempt to re-use any existing Diameter AVP, in order to reduce the possibility of having multiple AVPs that carry similar information. 9) Modify AVP occurrence tables appropriately. 10) 6.1.1 add Vendor-Specific-Application-Id to the list in the last bullet. 11) Add a new paragraph after the first paragraph of 11.3: "Both Application-Id and Acct-Application-Id AVPs use the same Application Identifier space." 12) Also add to 11 that not just zero but also 0xffffffff are reserved values. From owner-aaa-wg@merit.edu Thu Mar 28 17:59:04 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18892 for <aaa-archive@odin.ietf.org>; Thu, 28 Mar 2002 17:59:04 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id ACB6D91302; Thu, 28 Mar 2002 17:58:53 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8230491303; Thu, 28 Mar 2002 17:58:53 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6840E91302 for <aaa-wg@trapdoor.merit.edu>; Thu, 28 Mar 2002 17:58:52 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4DB0C5DDC3; Thu, 28 Mar 2002 17:58:52 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from hoemail1.firewall.lucent.com (hoemail1.lucent.com [192.11.226.161]) by segue.merit.edu (Postfix) with ESMTP id AEB095DDAD for <aaa-wg@merit.edu>; Thu, 28 Mar 2002 17:58:51 -0500 (EST) Received: from marconi.ih.lucent.com (h135-1-120-108.lucent.com [135.1.120.108]) by hoemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g2SMwob25567 for <aaa-wg@merit.edu>; Thu, 28 Mar 2002 17:58:50 -0500 (EST) Received: from nwsgpb.ih.lucent.com by marconi.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id QAA20795; Thu, 28 Mar 2002 16:58:49 -0600 (CST) Received: by nwsgpb.ih.lucent.com (8.8.8+Sun/EMS-1.5 client sol2) id QAA06255; Thu, 28 Mar 2002 16:58:49 -0600 (CST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15523.41001.499715.698374@nwsgpb.ih.lucent.com> Date: Thu, 28 Mar 2002 16:58:49 -0600 (CST) From: Pete McCann <mccap@lucent.com> To: aaa-wg@merit.edu Subject: [AAA-WG]: [issue] Accounting-Realtime-Required X-Mailer: VM 6.75 under 20.4 "Emerald" XEmacs Lucid Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Issue: Accounting-Realtime-Required should appear in Section 9.7.2, and text in Section 9.8.7 should give its AVP Code Submitter name: Pete McCann Submitter email address: mccap@lucent.com Date first submitted: 03-28-2002 Reference: Document: diameter-base-09 Comment type: Editorial Priority: 1 Section: 9.7.2, 9.8.7 Rationale: The Accounting-Realtime-Required AVP is defined in Section 9.8.7, but is not mentioned in the ABNF for Accounting-Answer messages in Section 9.7.2. Also, the description in Section 9.8.7 lists the AVP Code as "TBD", but the table on page 50-51 lists the AVP with Code 483. Requested Change: Add the following line to 9.7.2, after "[Accounting-Interim-Interval]": [ Accounting-Realtime-Required ] Change the first line of Section 9.8.7 to read: The Accounting-Realtime-Required AVP (AVP Code 483) is of type -Pete From owner-aaa-wg@merit.edu Fri Mar 29 09:17:19 2002 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14912 for <aaa-archive@lists.ietf.org>; Fri, 29 Mar 2002 09:17:19 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 257829130B; Fri, 29 Mar 2002 09:16:33 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DEE099130D; Fri, 29 Mar 2002 09:16:32 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7A50C9130B for <aaa-wg@trapdoor.merit.edu>; Fri, 29 Mar 2002 09:16:20 -0500 (EST) Received: by segue.merit.edu (Postfix) id 47F0D5DE1E; Fri, 29 Mar 2002 09:16:20 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id C419C5DDC5 for <aaa-wg@merit.edu>; Fri, 29 Mar 2002 09:16:19 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g2TDXaE11062; Fri, 29 Mar 2002 05:33:36 -0800 Date: Fri, 29 Mar 2002 05:33:36 -0800 (PST) From: Bernard Aboba <aboba@internaut.com> To: Ext-Venkata.Ghadiyaram@nokia.com Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: [issue] Host-IP-Address AVP in CER and CEA is redundant In-Reply-To: <9E3407CE45911B4097632389B77B202306D07B@esebe014.NOE.Nokia.com> Message-ID: <Pine.LNX.4.21.0203290533290.8859-100000@internaut.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Assigned #318. On Thu, 28 Mar 2002 Ext-Venkata.Ghadiyaram@nokia.com wrote: > Subject: [issue] Host-IP-Address AVP in CER and CEA is redundant > > Submitter name: Ghadiyaram Venkata Kishore > Submitter email address: Ext-Venkata.Ghadiyaram@nokia.com, > Date first submitted: March 28, 2002 > Reference: > Document: Base > Comment type: T > Priority: 1 > Section: > Rationale/Explanation of issue > > When a peer receives a CER, the IPAddress(IPAddresses in case of SCTP) of the host sending the message can be obtained from the transport layer as this information is maintained by the transport layer as part of TCP connection or SCTP association. So sending this information as part of Diameter payload is redundant. > > If alternate peers have to be provided through CER/CEA then we need a list of DiameterURIs, just the IPAddress of the peers is of no use. > > Requested change: > > Remove Host-IP-Address AVP from the specification of CER and CEA (both in the text and te ABNF). > From owner-aaa-wg@merit.edu Fri Mar 29 09:39:46 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16018 for <aaa-archive@lists.ietf.org>; Fri, 29 Mar 2002 09:39:45 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 481EE9130D; Fri, 29 Mar 2002 09:39:35 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 156349130E; Fri, 29 Mar 2002 09:39:35 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 19FE39130D for <aaa-wg@trapdoor.merit.edu>; Fri, 29 Mar 2002 09:39:34 -0500 (EST) Received: by segue.merit.edu (Postfix) id EF8C65DE29; Fri, 29 Mar 2002 09:39:33 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 7C8A15DDC5 for <aaa-wg@merit.edu>; Fri, 29 Mar 2002 09:39:33 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g2TDU9R10914; Fri, 29 Mar 2002 05:30:10 -0800 Date: Fri, 29 Mar 2002 05:30:09 -0800 (PST) From: Bernard Aboba <aboba@internaut.com> To: Sivasundar Ramamurthy <sramam@cup.hp.com> Cc: AAA Working Group <aaa-wg@merit.edu> Subject: Re: [AAA-WG]: [issue] ha-fa key In-Reply-To: <Pine.HPX.4.10.10203271718340.27939-100000@hpindsra> Message-ID: <Pine.LNX.4.21.0203290530000.8859-100000@internaut.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Assigned Issue #317. On Wed, 27 Mar 2002, Sivasundar Ramamurthy wrote: > > Submitter Name: Siva Ramamurthy > Submitter email address: sivasundar_ramamurthy@hp.com > Date first submitter: 3/27/2002 > Document: Mobile IP > Comment Type: T > Priority: 1 > Section: 4.5 > > Explanation of Issue: > > Section 4.5 has text that says: > > "If the FA's local policy allows it to receive AAA session Keys, and > it does not have any existing keys with the HA, it MAY set the > FA-HA-Key-Request flag". > > the co-existance of the phrases "any existing keys" and "AAA session > keys" is confusing! Is the FA-HA key to be used only for the session > from which it was obtained, or can it be used with any other sessions > that require communciation between this FA and HA? In other words, is > the FA-HA key session specific or not? > > Requested Change: > Please clarify, since different implementations at the FA and HA can > lead to needless FOR_HOME authentication failures. > > > > thanks. > From owner-aaa-wg@merit.edu Fri Mar 29 10:00:11 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17009 for <aaa-archive@lists.ietf.org>; Fri, 29 Mar 2002 10:00:10 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A550E9130E; Fri, 29 Mar 2002 09:59:56 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 76ACF9130F; Fri, 29 Mar 2002 09:59:56 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 711969130E for <aaa-wg@trapdoor.merit.edu>; Fri, 29 Mar 2002 09:59:55 -0500 (EST) Received: by segue.merit.edu (Postfix) id 50F995DE2E; Fri, 29 Mar 2002 09:59:55 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 892A45DDC5 for <aaa-wg@merit.edu>; Fri, 29 Mar 2002 09:59:54 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g2TEHBh13347; Fri, 29 Mar 2002 06:17:11 -0800 Date: Fri, 29 Mar 2002 06:17:10 -0800 (PST) From: Bernard Aboba <aboba@internaut.com> To: john.loughney@nokia.com Cc: aaa-wg@merit.edu, DSpence@Interlinknetworks.com, randy@psg.com Subject: Re: [AAA-WG]: Issue 303: Security model for peer discovery and redirect - Text - Please Review In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEFC64D3D@esebe004.NOE.Nokia.com> Message-ID: <Pine.LNX.4.21.0203290537070.8859-100000@internaut.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > > 13.3 Peer-to-Peer Considerations > > There are many security issues related to peer-to-peer connections. Caution should be used when >creating peer-to-peer connections. Diameter is not intended to allow the >peer-to-peer interface to be a public interface. I'd change this to the following: "As with any peer-to-peer protocol, proper configuration of the trust model within a Diameter peer is essential to security. When certificates are used, it is necessary to configure the root certificate authorities trusted by the Diameter peer. These root CAs are likely to be unique to Diameter usage and distinct from the root CAs that might be trusted for other purposes such as Web browsing. In general, it is expected that those root CAs will be configured so as to reflect the business relationships between the organization hosting the Diameter peer and other organizations. As a result, a Diameter peer will typically not be configured to allow connectivity with any arbitrary peer. When certificate authentication Diameter peers may not be known beforehand, and therefore peer discovery may be required. Note that IPsec is considerably less flexible than TLS when it comes to configuring root CAs. Since use of Port identifiers is prohibited within IKE Phase 1, within IPsec it is not possible to uniquely configure trusted root CAs for each application individually; the same policy must be used for all applications. This implies, for example, that a root CA trusted for use with Diameter must also be trusted to protect SNMP. These restrictions can be awkward at best. Since TLS supports application-level granularity in certificate policy, TLS SHOULD be used to protect Diameter connections between administrative domains. IPsec is most appropriate for intra-domain usage when pre-shared keys are used as a security mechanism. When pre-shared key authentication is used with IPsec to protect Diameter, unique pre-shared keys are configured with Diameter peers, who are identified by their IP address (Main Mode), or possibly their FQDN (Aggressive Mode). As a result, it is necessary for the set of Diameter peers to be known beforehand. Therefore peer discovery is typically not necessary. The following is intended to provide some guidance on the issue. > > A Diameter node SHOULD implement the same security mechanism (IPsec or TLS) across > all its peer-to-peer connections. Inconsistent use of security > mechanisms can open security holes at a node. For example if a node > using both TLS and IPsec, there is not good way in which a connection >that is not TLS-secured is, in fact, IPsec secured. Additionally, a > per-peer policy would need to be installed, which, in practice is quite >hard to maintain. Suggested change: It is recommended that a Diameter peer implement the same security mechanism (IPsec or TLS) across all its peer-to-peer connections. Inconsistent use of security mechanisms can result in redundant security mechanisms being used (e.g. TLS over IPsec) or worse, potential security vulnerabilities. When IPsec is used with Diameter, a typical security policy for outbound traffic is "Initiate IPsec, From me to any, destination port Diameter"; for inbound traffic, the policy would be "Require IPsec, From any to me, destination port Diameter". This policy causes IPsec to be used whenever a Diameter peer initiates a connection to another Diameter peer, and to be required whenever an inbound Diameter connection occurs. This policy is attractive, since it does not require policy to be set for each peer or dynamically plumbed each time a new Diameter connection is created; an IPsec SA is automatically created based on a simple static policy. Since IPsec extensions are typically not available to the sockets API on most platforms, and IPsec policy functionality is implementation dependent, use of a simple static policy is the often the simplest route to IPsec-enabling a Diameter implementation. One implication of the recommended policy is that if a node is using both TLS and IPsec, there is not a convenient way in which to use either TLS or IPsec, but not both, without reserving an additional port for TLS usage. Since Diameter uses the same port for TLS and non-TLS usage, where the recommended IPsec policy is put in place, a TLS-protected connection will match the IPsec policy, and both IPsec and TLS will be used to protect the Diameter connection. To avoid this, it would be necessary to plumb peer-specific policies either statically or dynamically. > > If IPsec is used to secure the peer-to-peer connections to a Diameter node, >then there SHOULD be a mechanism to prevent non-IPsec protected traffic >from reaching the node. For example, a firewall or inbound filter >policy. Change to: If IPsec is used to secure Diameter peer-to-peer connections, IPsec policy SHOULD be set so as to require IPsec protection for inbound connections, and to initiate IPsec protection for outbound connections. This can be accomplished via use of inbound and outbound filter policy. > > If IPsec is used and preconfigured SAs are not used, it is not recommended to > rely on a PKI-based solution. It is recommended that only peer-to-peer > connections are created within a domain, or the Diameter nodes of an > organization you trust. By preconfigured SAs, do you mean manual SAs? Not sure what we are saying here; are we recommending against certificate-based authentication with IPsec? My recommendation is to delete the above paragraph. > > If TLS is used to secure peer-to-peer connections, it is recommended that <certificates are used in such a way that you only allow peer-to-peer >connections within a domain, or with the Diameter nodes of an >organization you trust. I think this is covered by the above text. From owner-aaa-wg@merit.edu Fri Mar 29 10:05:34 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17312 for <aaa-archive@lists.ietf.org>; Fri, 29 Mar 2002 10:05:34 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A90629130F; Fri, 29 Mar 2002 10:05:14 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7049191310; Fri, 29 Mar 2002 10:05:14 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7AE4E9130F for <aaa-wg@trapdoor.merit.edu>; Fri, 29 Mar 2002 10:05:13 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5B1B35DDFF; Fri, 29 Mar 2002 10:05:13 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id D49585DDC5 for <aaa-wg@merit.edu>; Fri, 29 Mar 2002 10:05:12 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g2TEMUc13601; Fri, 29 Mar 2002 06:22:30 -0800 Date: Fri, 29 Mar 2002 06:22:30 -0800 (PST) From: Bernard Aboba <aboba@internaut.com> To: Pete McCann <mccap@lucent.com> Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: [issue] Accounting-Realtime-Required In-Reply-To: <15523.41001.499715.698374@nwsgpb.ih.lucent.com> Message-ID: <Pine.LNX.4.21.0203290622240.8859-100000@internaut.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Assigned #319. On Thu, 28 Mar 2002, Pete McCann wrote: > > Issue: Accounting-Realtime-Required should appear > in Section 9.7.2, and text in Section 9.8.7 > should give its AVP Code > Submitter name: Pete McCann > Submitter email address: mccap@lucent.com > Date first submitted: 03-28-2002 > Reference: > Document: diameter-base-09 > Comment type: Editorial > Priority: 1 > Section: 9.7.2, 9.8.7 > > Rationale: > > The Accounting-Realtime-Required AVP is defined in Section 9.8.7, but > is not mentioned in the ABNF for Accounting-Answer messages in Section > 9.7.2. Also, the description in Section 9.8.7 lists the AVP Code as > "TBD", but the table on page 50-51 lists the AVP with Code 483. > > Requested Change: > > Add the following line to 9.7.2, > after "[Accounting-Interim-Interval]": > > [ Accounting-Realtime-Required ] > > Change the first line of Section 9.8.7 to read: > > The Accounting-Realtime-Required AVP (AVP Code 483) is of type > > > > -Pete > From owner-aaa-wg@merit.edu Fri Mar 29 12:17:35 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24107 for <aaa-archive@lists.ietf.org>; Fri, 29 Mar 2002 12:17:35 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 051A491319; Fri, 29 Mar 2002 12:17:20 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C8A109131B; Fri, 29 Mar 2002 12:17:19 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BEED891319 for <aaa-wg@trapdoor.merit.edu>; Fri, 29 Mar 2002 12:17:18 -0500 (EST) Received: by segue.merit.edu (Postfix) id 95D995DDC9; Fri, 29 Mar 2002 12:17:18 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 79CAD5DDA0 for <aaa-wg@merit.edu>; Fri, 29 Mar 2002 12:17:18 -0500 (EST) Received: from phoenix (nat.interlinknetworks.com [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with SMTP id D663E79; Fri, 29 Mar 2002 12:17:17 -0500 (EST) From: "Bob Kopacz" <BKopacz@InterlinkNetworks.com> To: "John Loughney" <john.loughney@nokia.com>, "Pete McCann" <mccap@lucent.com> Cc: "aaa-wg" <aaa-wg@merit.edu> Subject: RE: [AAA-WG]: [issue] Bug in Acct state machine + Split State Machines into Client vs. Server Date: Fri, 29 Mar 2002 12:16:13 -0500 Message-ID: <NEBBKEONMLEDJCMHGHPIOEEODPAA.BKopacz@InterlinkNetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 In-Reply-To: <15522.2150.22595.765656@nwsgpb.ih.lucent.com> Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Pete and John, Here's some feedback. I think Pete's cutting and pasting was perfect. When reviewing the state tables, I've suggested some new changes which I hope are improvements, but if you think it is too late for these changes, then just disregard them. Bob K. > Issue: Bug in Acct state machine + State machines > should be split into client vs. server > Submitter name: Pete McCann > Submitter email address: mccap@lucent.com > Date first submitted: 03-27-2002 > Reference: > Document: diameter-base-09 > Comment type: Technical > Priority: S > Section: 8.1, 8.2 > > Rationale: > > Currently, there is no way to enter the PendingI state in the accounting state > machine. This is a bug. > > The state machines given in the diameter base document are confusing > to read, because they mix client and server states. > > Requested Change: > > Split each machine in two, and replace 8.1 and 8.2 with the following > text. Note the addition of an event to the client accounting state > machine to enter the PendingI state: > > > 8.1 Authorization Session State Machine > > This section contains a set of finite state machines, representing the life > cycle of Diameter sessions, and which MUST be observed by all Diameter > implementations that make use of the authentication and/or > authorization portion of a Diameter application. The term Service- > Specific below refers to a message defined in a Diameter application > (e.g. Mobile IP, NASREQ). > > There are four different authorization session state machines > supported in the Diameter base protocol. The first two describe a > session in which the server is maintaining session state, indicated > by the value of the Auth-Session-State AVP (or its absence). One > describes the session from a client perspective, the other from a > server perspective. The second two state machines are used when > the server does not maintain session state. Here again, one > describes the session from a client perspective, the other from a > server perspective. > > When a session is moved to the Idle state, any resources that were > allocated for the particular session must be released. Any event not > listed in the state machines MUST be considered as an error > condition, and an answer, if applicable, MUST be returned to the > originator of the message. > > The following state machine is observed by a client when state is > maintained on the server: > > CLIENT, STATEFUL > State Event Action New State > ------------------------------------------------------------- > Idle Client or Device Requests send Pending > access service > specific > auth req > > Pending Successful Service-specific Grant Open > authorization answer Access > received with default > Auth-Session-State value > > Pending Successful Service-specific Sent STR Discon > authorization answer received > but service not provided > > Pending Error processing successful Sent STR Discon > Service-specific authorization > answer > > Pending Failed Service-specific Cleanup Idle > authorization answer received > > Open user or client device send Open > requests access to service service > specific > auth req > > Open Successful Service-specific Extend Open > authorization answer received Answer > > Open Accounting message sent process Open > > Open Failed Service-specific Discon. Idle > authorization answer user/device > received. > > Open Session-Timeout Expires on send STR Discon > Access Device > > Open ASR Received send ASA, Discon > STR I think you might want to split the above "ASR Received" event into three events, making the client's state machine more consistent with the Server's state machine and with the base protocol text; i.e. Idle ASR Received send ASA Idle for unknown session with Result-Code = UNKNOWN- SESSION-ID Open ASR Received, Send ASA Discon client will comply with with request to end the session Result-Code = SUCCESS. Send STR. Open ASR Received, Send ASA Open client will not comply with with request to end the session Result-Code != SUCCESS. > Open Authorization-Lifetime + send STR Discon > Auth-Grace-Period expires on > access device > > Discon ASR Received None Discon Shouldn't the above be: Discon ASR Received Send STA. Discon > Discon STA Received Discon. Idle > user/device > > > The following state machine is observed by a server when it is > maintaining state for the session: > > SERVER, STATEFUL > State Event Action New State > ------------------------------------------------------------- > Idle Service-specific authorization send Open > request received, and successful > user is authorized serv. > specific answer > > Idle Service-specific authorization send Idle > request received, and failed serv. > user is not authorized specific answer > > Open Service-specific authorization send Open > request received, and user successful > is authorized serv. specific > answer > > Open Service-specific authorization send Idle > request received, and user Failed serv. > is not authorized specific > answer, > Cleanup > > Open Accounting message received process Open > > Open Home server wants to send ASR Open > terminate the service > > Open ASA Received Cleanup Idle > with Result-Code > = UNKNOWN-SESSION-ID > > Open ASA Received None Open > with Result-Code (ignore) > not = UNKNOWN-SESSION-ID > > Open Authorization-Lifetime (and Cleanup Discon > Auth-Grace-Period) expires > on home server. I think going to Idle is more appropriate above, because the server may not be receiving an STR from the client, i.e. Open Authorization-Lifetime (and Cleanup Idle Auth-Grace-Period) expires on home server. > Open Session-Timeout expires on Cleanup Discon > home server I think going to Idle is more appropriate above, because the server may not be receiving an STR from the client, i.e. Open Session-Timeout expires on Cleanup Idle home server > Open STR Received Send STA Idle I'd add a "cleanup" to the above, i.e. Open STR Received Send STA, Idle Cleanup > Not ASA Received None No Change. > Open > > Discon STR Received Send STA Idle I'd replace the above by: Not Open STR Received Send STA, Idle Cleanup > > > The following state machine is observed by a client when state is > not maintained on the server: > > CLIENT, STATELESS > State Event Action New State > ------------------------------------------------------------- > Idle Client or Device Requests send Pending > access service > specific > auth req > > Pending Successful Service-specific Grant Open > authorization answer Access > received with Auth-Session- > State set to > NO_STATE_MAINTAINED > > Pending Failed Service-specific Cleanup Idle > authorization answer > received > > Open Accounting message sent process Open > > Open Session-Timeout Expires on Discon. Idle > Access Device user/device > > Open Service to user is terminated Discon. Idle > user/device > > > > The following state machine is observed by a server when it is not > maintaining state for the session: > > SERVER, STATELESS > State Event Action New State > ------------------------------------------------------------- > Idle Service-specific authorization send serv. Open > request received, and specific > successfully processed answer > > Open Accounting message received process Open Since the server isn't maintaining session state, I'd delete the above "SERVER, STATELESS" table altogether. And then change the 2nd paragraph of the proposed text to say "three" rather than "four" machines. > > > > 8.2 Accounting Session State Machine > > For applications that only require accounting services, the following > state machines MUST be supported. The first is to be observed by > clients, the second by servers. > > When a session is moved to the Idle state, any resources that were > allocated for the particular session must be released. Any event not > listed in the state machines MUST be considered as an error > condition, and an answer, if applicable, MUST be returned to the > originator of the message. > > > CLIENT, ACCOUNTING > State Event Action New State > ------------------------------------------------------------- > Idle Client or device requests send PendingS > access accounting > start req. > > Open Interim interval elapses send PendingI > accounting > interim > record > > Idle Client or device requests send PendingE > a one-time service accounting > event req > > Idle Records in storage Send PendingB > record > > Open User service terminated send PendingL > accounting > stop req. > > PendingS Successful accounting Open > start answer received > > PendingS Failure to send and buffer Store Open > space available and realtime Start > not equal to DELIVER_AND_GRANT Record > > PendingS Failure to send and no buffer Open > space available and realtime > equal to GRANT_AND_LOSE > > PendingS Failure to send and no buffer Disconnect Idle > space available and realtime user/dev > not equal to > GRANT_AND_LOSE > > PendingI Failure to send and (buffer Store Open > space available or old record Interim > can be overwritten) and Record > realtime not equal to > DELIVER_AND_GRANT > > PendingI Failure to send and no buffer Open > space available and realtime > equal to GRANT_AND_LOSE > > PendingI Failure to send and no buffer Disconnect Idle > space available and realtime user/dev > not equal to GRANT_AND_LOSE > > PendingE Successful accounting Idle > event answer received > > PendingE Failure to send and buffer Store Idle > space available Event > Record > > PendingE Failure to send and no buffer Idle > space available > > PendingB Successful accounting answer Delete Idle > received record > > PendingB Failure to send Idle > > PendingL Successful accounting Idle > stop answer received > > PendingL Failure to send and buffer Store Idle > space available Stop > Record > > PendingL Failure to send and no buffer Idle > space available > I have less to offer in terms of the Accounting state machine, but here's a couple of observations: 1. When in the PendingX states, do you want to add entries for an "Unsuccessful accounting answer received" event? 2. Do you want to add entries to deal with having to send a Stop when a Start or Interim is still pending, e.g. something like: PendingS User Service terminated Send Stop PendingL PendingI User Service terminated Send Stop PendingL > > SERVER, ACCOUNTING > State Event Action New State > ------------------------------------------------------------- > > Idle Accounting start request send Open > received, and successfully accounting > processed. start > answer > > Idle Accounting event request send Idle > received, and successfully accounting > processed. event > answer > > Open Receive Interim Record send Open > accounting > answer > > Open Accounting stop request send Idle > received, and successfully accounting > processed stop answer > From owner-aaa-wg@merit.edu Fri Mar 29 12:36:29 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24834 for <aaa-archive@lists.ietf.org>; Fri, 29 Mar 2002 12:36:29 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D24659120C; Fri, 29 Mar 2002 12:36:16 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 837E29131B; Fri, 29 Mar 2002 12:36:16 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 42ABD9120C for <aaa-wg@trapdoor.merit.edu>; Fri, 29 Mar 2002 12:36:15 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1F7175DE0E; Fri, 29 Mar 2002 12:36:15 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from palrel10.hp.com (palrel10.hp.com [156.153.255.245]) by segue.merit.edu (Postfix) with ESMTP id F224B5DDA0 for <aaa-wg@merit.edu>; Fri, 29 Mar 2002 12:36:14 -0500 (EST) Received: from hpindsra.cup.hp.com (hpindsra.cup.hp.com [15.13.104.190]) by palrel10.hp.com (Postfix) with ESMTP id 5CA7EC0061F for <aaa-wg@merit.edu>; Fri, 29 Mar 2002 09:36:12 -0800 (PST) Received: from hpindsra (hpindsra [15.13.104.190]) by hpindsra.cup.hp.com with ESMTP (8.8.6 (PHNE_17190)/8.8.6 SMKit7.02) id JAA00967 for <aaa-wg@merit.edu>; Fri, 29 Mar 2002 09:36:45 -0800 (PST) Date: Fri, 29 Mar 2002 09:36:44 -0800 (PST) From: Sivasundar Ramamurthy <sramam@cup.hp.com> X-Sender: sramam@hpindsra To: AAA Working Group <aaa-wg@merit.edu> Subject: Re: [AAA-WG]: Issue 305: Purpose of MIP-Foreign-Agent-Host Message-ID: <Pine.HPX.4.10.10203290911001.790-100000@hpindsra> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Hello, I might have a couple of uses for this avp. 1. The assumption here is that the FA-HA key is not session specific (see Issue: 317). When the HAR containing the HA-FA key is received by the HA, the HA needs to know which FA the FA-HA key is for. The COA in the reg-request must be one of the FA's addresses but need not be the address from which the FA forwards UDP reg requests to the HA. The FQDN in FA-Host AVP might be a more reliable way to identify the FA and store the key against. When a UDP MIP request containing a FA-HA auth ext is received, the HA can get the host name of the FA from the source address (DNS) and determine if it has a SA to that FA. Hopefully the address the FA uses to forward the request matches against the hostname retrived from the FA-Host AVP in the HAR. NOTE: If this usage, and thus the necessity of this AVP, makes sense, maybe we can extend it as an argument for requiring support for the GNAIE drafts; the presence of a FA-host NAI in normal (UDP) reg requests will let the HA find a key for the FA (without using DNS) and authenticate it. 2. Section 1.3 in the MIP draft has text that says: "...it is necessary for the resulting HAR received by the HA to be identified as a continuation of an existing session". Maybe the FQDN in the FA-Host-AVP is a reliable way to determine session continuation?? thanks! Siva From owner-aaa-wg@merit.edu Sat Mar 30 15:39:42 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04477 for <aaa-archive@odin.ietf.org>; Sat, 30 Mar 2002 15:39:41 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 6B96F9121C; Sat, 30 Mar 2002 15:39:22 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3DA449121D; Sat, 30 Mar 2002 15:39:22 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 459589121C for <aaa-wg@trapdoor.merit.edu>; Sat, 30 Mar 2002 15:39:21 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2C4105DDAE; Sat, 30 Mar 2002 15:39:21 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from cisco.com (titans.cisco.com [161.44.72.74]) by segue.merit.edu (Postfix) with ESMTP id 995925DD92 for <aaa-wg@merit.edu>; Sat, 30 Mar 2002 15:39:20 -0500 (EST) Received: (from gdweber@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) id PAA19415; Sat, 30 Mar 2002 15:39:18 -0500 (EST) From: Greg Weber <gdweber@cisco.com> Message-Id: <200203302039.PAA19415@cisco.com> Subject: [AAA-WG]: [issue] Remove MIPv4 references to CMS To: aaa-wg@merit.edu Date: Sat, 30 Mar 2002 15:39:18 -0500 (EST) X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Description of issue: MIPv4 draft has dependencies on CMS Submitter name: Greg Weber Submitter email address: gdweber@cisco.com Date first submitted: March 30, 2002 Reference: URL to e-mail describing problem, if available http://www.merit.edu/mail.archives/aaa-wg/msg03519.html Document: MIPv4 Comment type: E Priority: S Section: 5.0, 5.2, 5.5.2, 6.0, 10.0, 11.1 Rationale/Explanation of issue: The MIPv4 draft has several normative references to the CMS application draft. If the MIPv4 draft is to be submitted to the IESG before the CMS draft is ready, then these references should be removed. Requested change: From Bernard: "I would suggest that MIPv4 normative references to CMS be removed, if it is expected that MIPv4 be approved for publication prior to when CMS is ready." From owner-aaa-wg@merit.edu Sat Mar 30 17:12:48 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05736 for <aaa-archive@odin.ietf.org>; Sat, 30 Mar 2002 17:12:48 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 095E89121D; Sat, 30 Mar 2002 17:12:38 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C35A29121E; Sat, 30 Mar 2002 17:12:37 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C53E79121D for <aaa-wg@trapdoor.merit.edu>; Sat, 30 Mar 2002 17:12:36 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9E88B5DD92; Sat, 30 Mar 2002 17:12:36 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 2536A5DD8D for <aaa-wg@merit.edu>; Sat, 30 Mar 2002 17:12:36 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g2ULTk713160; Sat, 30 Mar 2002 13:29:46 -0800 Date: Sat, 30 Mar 2002 13:29:46 -0800 (PST) From: Bernard Aboba <aboba@internaut.com> To: Greg Weber <gdweber@cisco.com> Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: [issue] Remove MIPv4 references to CMS In-Reply-To: <200203302039.PAA19415@cisco.com> Message-ID: <Pine.LNX.4.21.0203301329380.12502-100000@internaut.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Assigned issue #321. On Sat, 30 Mar 2002, Greg Weber wrote: > > Description of issue: MIPv4 draft has dependencies on CMS > Submitter name: Greg Weber > Submitter email address: gdweber@cisco.com > Date first submitted: March 30, 2002 > Reference: URL to e-mail describing problem, if available > http://www.merit.edu/mail.archives/aaa-wg/msg03519.html > Document: MIPv4 > Comment type: E > Priority: S > Section: 5.0, 5.2, 5.5.2, 6.0, 10.0, 11.1 > Rationale/Explanation of issue: > The MIPv4 draft has several normative references to the CMS > application draft. If the MIPv4 draft is to be submitted to > the IESG before the CMS draft is ready, then these references > should be removed. > Requested change: > From Bernard: > "I would suggest that MIPv4 normative references to CMS be removed, if it > is expected that MIPv4 be approved for publication prior to when CMS is > ready." > From owner-aaa-wg@merit.edu Sat Mar 30 18:40:37 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06990 for <aaa-archive@odin.ietf.org>; Sat, 30 Mar 2002 18:40:36 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A70279121F; Sat, 30 Mar 2002 18:40:26 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 66C3291224; Sat, 30 Mar 2002 18:40:26 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 72CCB9121F for <aaa-wg@trapdoor.merit.edu>; Sat, 30 Mar 2002 18:40:25 -0500 (EST) Received: by segue.merit.edu (Postfix) id 52D595DD98; Sat, 30 Mar 2002 18:40:25 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id E529E5DD8D for <aaa-wg@merit.edu>; Sat, 30 Mar 2002 18:40:24 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g2UMvaC17750 for <aaa-wg@merit.edu>; Sat, 30 Mar 2002 14:57:36 -0800 Date: Sat, 30 Mar 2002 14:57:36 -0800 (PST) From: Bernard Aboba <aboba@internaut.com> To: aaa-wg@merit.edu Subject: [AAA-WG]: IETF 53 AAA WG minutes Message-ID: <Pine.LNX.4.21.0203301455560.16225-100000@internaut.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Here are the minutes from IETF 53 AAA WG: http://www.drizzle.com/~aboba/AAA/IETF53/minutes53.txt Here are the presentations from IETF 53 AAA WG: http://www.drizzle.com/~aboba/AAA/IET53/presentations.zip