From owner-aaa-wg@merit.edu Fri Aug 2 15:04: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 PAA01853 for ; Fri, 2 Aug 2002 15:04:51 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0ADA59120F; Fri, 2 Aug 2002 15:05:48 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C8CC19121A; Fri, 2 Aug 2002 15:05:47 -0400 (EDT) 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 87C339120F for ; Fri, 2 Aug 2002 15:05:46 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6B8A75DF3F; Fri, 2 Aug 2002 15:05:46 -0400 (EDT) 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 25E8E5DE8B for ; Fri, 2 Aug 2002 15:05:46 -0400 (EDT) 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 g72J5jl16590 for ; Fri, 2 Aug 2002 14:05:45 -0500 (CDT) Received: from eamrcnt750.exu.ericsson.se (eamrcnt750.exu.ericsson.se [138.85.133.51]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g72J5jN24674 for ; Fri, 2 Aug 2002 14:05:45 -0500 (CDT) Received: from ericsson.com (T21ICEMAN [138.85.159.136]) by eamrcnt750.exu.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id PV0T6V2Q; Fri, 2 Aug 2002 14:05:45 -0500 Message-ID: <3D4AD6EA.CCFB8EBE@ericsson.com> Date: Fri, 02 Aug 2002 12:00:58 -0700 X-Sybari-Trust: 24eabfcc 14dfe396 93c353d9 00000138 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 Subject: [AAA-WG]: new - draft-ietf-aaa-diameter-mobileip-12alpha1.txt 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 have updated the draft to cover all of Luis comments below to hopefully a satisfying level. Please, review this -12alpha1 and let me know if you have any objection/comments or any additional text proposals. http://www.erilab.com/users/temp/draft-ietf-aaa-diameter-mobileip-12alpha1.txt Thanks, /Tony Bernard Aboba wrote: > ---------- Forwarded message ---------- > Date: Wed, 10 Jul 2002 09:07:58 -0400 > From: Luis A. Sanchez > To: Bernard Aboba , Randy Bush , > "Wijnen, Bert (Bert)" > Subject: Re: FW: request for review from AAA WG > > Bernard, > > Enclosed you will find a review of the > Diameter Mobile IPv4 > application. There is more to review here including the CMS > interactions > . I have to finish a MIPv6 review first and then get back to CMS. This > > won't happen until after the IETF meeting. My apologies for the delay. > > Regards, > > Luis > > ================================= > > General Comments > ---------------- > > - The document uses terminology used in other standards documents. For > > example, in the IPsec context, security associations are simplex and > uniquely identified by the triple (IP address, SPI, protocol). It is > not > clear if there is a 1 to 1 mapping between IPsec security associations > > and the "security associations" between mobile nodes and AAA servers. > > - There is no explanation on the KDC functionality with message > exchanges in the introduction section. This would help understand the > feature. > > - The KDC part of the protocol is not symmetric. It sends keying > material to the MN and sessions keys to the FA. It is not clear why > this > is the case. > > - The security considerations sections does not provide any > considerations about the KDC feature of the protocol. > > Specific Comments > ----------------- > > Section 1.0 > > 1) Combined with the Inter-Realm capability of the base protocol, this > > application allows mobile nodes to receive service from foreign > service providers. > > Problem: Confusing sentence, what protocol? > Suggestion: "... capability of the Diameter base protocol... > > 2) Strong authentication and confidentiality of session keys is > required, and it is recommended to be provided using the CMS > security > application [CMS], but may be provided via other security > mechanisms, > e.g. using mutually authenticated TLS or IPsec when deployed in an > > environment without Diameter agents, then hop-by-hop security is > sufficient for protecting session keys. > > Problem: Missing a comma or period after "IPsec". Otherwise it reads > as > a recommendation to use IPsec only when Diameter agents are *NOT* > present. > Suggestion: "... but may be provided via other security mechanisms, > e.g. using mutually authenticated TLS or IPsec, when deployed in > an > environment without Diameter agents, then hop-by-hop security is > sufficient for protecting session keys." > > Section 1.2 > > 1) "This means that > without support of the AAA NAI extension, the FA may not be able > to > guarantee, that the AMR well be destined to the same AAAH, which > previously authenticated and authorized the mobile node, since the > FA > may not know the identity of the AAAH." > > Problem: extra word (well) found in sentence fragment. > Suggestion: Please delete "well" in front of "be destined" > > 2) "Upon receipt of the HAA, the AAAH creates the > AA-Mobile-Node-Answer > (AMA) message, includes the Acct-Multi-Session-Id that was present > in > the HAA, and the MIP-Home-Agent-Address, MIP-Mobile-Node-Address > AVPs > in the AMA message, enabling appropriate firewall controls for the > > penetration of tunneled traffic between the home agent and the > mobile > node." > > Problem: The authors mention firewall controls and there is no clear > understanding on what exactly does it mean in this context. For > example, > does it means that one of the AVPs will include packet filtering rules > > that MUST be implemented in some firewall? If so, what are the > selectors > fields for these rules, what entity will push these rules to the > firewall and how one validate the authenticity of the rules. One may > also want to provide confidentiality to such rules. The latter can > piggyback on the existing secured exchanged but it needs some > clarification. As you can see this opens a can of worms. > > Suggestion: Please clarify what is meant by "firewall controls" and > establish the exact operation and security model (if needed). If meant > > something different please clarify too. > > Section 1.4 > > 1) If no security association > exists between the AAAH and the originating AAAF, the AAAH will > make > use of the CMS application [CMS] to establish this association. > > Problem: This statement seems to imply that the only mechanism that > can > be used to establish a security association is CMS which contradicts > previously made statements. > > Suggestion: Modify statement to include other mechanisms such as > IPsec. > > 2) Figure 6: Mobile IP/Diameter Message Exchange > > Problem: Same figure caption as in figure 2. > Suggestion: Change caption to indicated that it is "Figure 6: Mobile > IP/Diameter Message Exchange when HA is in Visited Realm" or something > > similar. > > 3) If the mobile node is allowed to keep the home agent the AAAH then > > sends a HAR, which contains the Mobile IP Registration Request > message data encapsulated in the MIP-Reg-Request AVP and the MIP- > Home-Agent-Address AVP with home agent address, as well as any > optional KDC session keys, to the AAAF in foreign network 1. > > Problem: First time KDC is mentioned and no further explanation is > given. > > Suggestion: Introduce the entire KDC feature first. Architecture view > should suffice. Need to explain the security for each message > exchange. > > Section 1.6 > > 1) Diameter Session Termination > > Problem: When an STR is sent what happens to the session keys? > Suggestions: All resources (including session keys) must be > deallocated > (destroy) at the AAAH. > > Section 5.1 > > 1) A value of zero indicates infinity (no time-out). > > Problem: This setting is of high security risk. However useful for > debugging purposes. > > Suggestion: Please make a note in the document indicating that this > setting is not recommended since keeping session keys for a long time > (no refresh) increases the vulnerability of the system. > > Section 5.2 > > 1) The key sent to the mobile node is always in the form of key > material, which the AAAH does by generating a random [RANDOM] > value > of at least 64 bits. > > Problem: The KDC system is asymmetric. It sends keying material in one > > case (to the MN) and session keys in other cases (FA). > > Suggestion. Make the system symmetric. THe home AAAH server MUST > generate all session keys and send them to the MN, FA and HA > respectively. > > 2) The following is an example of a > session creation procedure, using MD5 as the hashing algorithm. > Additional algorithms are supported, and listed in [MIPKEYS]. > > MD5(AAA-Key | key material | node-address | AAA-Key) > > Problem: For key derivation, this document recommends using > MD5/prefix+suffix mode. Back in 1996 Bellare, Canetti and Krawczyk > published a paper on crypto discussing how a keyed hash function used > in > append/pre-append mode is more susceptible to the "divide and conquer" > > attack, although impractical, than a keyed-hashed function using a > keyed-IV instead. They also proved that cryptographic ally HMAC is as > strong as the hash function used with it. One can no make such a > statement with a key-hashed function used in prefix+suffix > mode. As such, IPsec dropped RFC1828 and adopted HMAC-MD5 and > HMAC-SHA1 > the latter truncated to 90bits. Another potential problem with > MD5/prefix+suffix could come in if the nonsecret component of the key > is > variable length. In that case, if you were using MD5(secret, > nonsecret) > = newkey, then someone might be able to see newkey and later observe > an > exchange where nonsecret' = nonsecret|1. Then the key would be > MD5(newkey, 1) = newkey'. You have to analyze the protocol very > carefully to assure that this doesn't happen, but if you use HMAC, you > > don't have to worry about it. > > **Recommendation: Advise reader to derive keys using: key = > HMAC-MD5(AAA-key, > > {Key Material | node-addres}) or HMAC-SHA1. Do not recommend using > MD5/prefix+suffix. > > 3) "- AAA-Key is the long term secret shared between the mobile > node and the AAAH." > > Problem: The AAA key need to be chosen at random (or using a > cryptographically strong pseudo-random generator seeded with a random > seed), and periodically refreshed. It is not clear that we can > recommended a specific frequency for key changes as the attacks refer > to > above may seem practically unfeasible. However, periodic key > refreshment is a fundamental security practice that helps against > potential weaknesses of the function and keys, and limits the damage > of > an exposed key. > > **Recommendation: Add a statement to ensure that both the Mobile Node > and the AAA server refresh their shared AAA-key. THis could be done > via > the AAA protocol or some other out-of-band mechanism. For in-band > refreshing the new key MUST be encrypted, authenticated and its > integrity MUST be protected while on transit. > > 4) "The Foreign-Home session key is shared between two mobility > agents: > the FA and HA. Since this key is not destined for the mobile node, > > there is no need to follow the session key generation procedures > detailed above. Instead, the AAAH generates a random [RANDOM] > value > of at least 64 bits for use as the Foreign-Home session key." > > Problem: This text seems to suggest that the security level required > between the FA and HA is lower hence no need to create/use a > cryptographically generated session key. What is the argument for > this? > > Suggestion: Please explain. A symmetric protocol is easier to analyze > and understand its security. > > Section 5.5.2 > > 1) If the session key needs to be encrypted, the AAAF will check if a > security association can be established, using the CMS security > application [CMS] with the originating host found in the MIP- > Originating-Foreign-AAA AVP. > > Problem: Sessions keys MUST always be encrypted. This function seems > to > be attached to CMS and this should not be the case. > > SUggestion: Always encrypt the session key using permanent keys > (AAA-keys) > > Section 6.0 > > 1) In other words, AAA > servers MUST be able to create three session keys: the > Mobile-Home, > Mobile-Foreign, and Foreign-Home keys. > > Problem: Inconsistent with previous statements. The message sent to > the > MN does not contain a session key but rather the keying material. > > Suggestion: Eliminate this problem by having the AAAH calculate all > keys > except in the case where the HA is in the foreign realm in which case > the AAAF will calculate the session key for the HA. > > Section 6.8 MIP-Algorithm-Type AVP > > 1) The MIP-Algorithm-Type AVP (AVP Code 345) is of type Enumerated, > and > contains the Algorithm identifier used to generate the associated > Mobile IP authentication extension. The following values are > currently defined: > > 1 Prefix+Suffix MD5 [MOBILEIP] > 2 HMAC-MD5 [HMAC] > 3 HMAC-SHA-1 [HMAC] > > Problem: as explained before. > Suggestion: deprecate option 1 From owner-aaa-wg@merit.edu Tue Aug 6 05:26: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 FAA00424 for ; Tue, 6 Aug 2002 05:26:14 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E3CDC91290; Tue, 6 Aug 2002 05:27:14 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A8F9E91291; Tue, 6 Aug 2002 05:27:14 -0400 (EDT) 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 7063D91290 for ; Tue, 6 Aug 2002 05:27:13 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 158A7609A7; Tue, 6 Aug 2002 04:59:16 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mail.alcatel.be (alc250.alcatel.be [195.207.101.250]) by segue.merit.edu (Postfix) with ESMTP id CCAE55F713 for ; Tue, 6 Aug 2002 04:41:08 -0400 (EDT) Received: from bemail04.net.alcatel.be (relay3 [127.0.0.1]) by mail.alcatel.be (8.11.0/8.11.4) with ESMTP id g768aNe18951 for ; Tue, 6 Aug 2002 10:36:23 +0200 Received: from alcatel.be ([138.203.65.127]) by bemail04.net.alcatel.be (Lotus Domino Release 5.0.8) with ESMTP id 2002080610410253:1972 ; Tue, 6 Aug 2002 10:41:02 +0200 Message-ID: <3D4F8B9E.2E12C40@alcatel.be> Date: Tue, 06 Aug 2002 10:41:02 +0200 From: suresh.leroy@alcatel.be Organization: Alcatel X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: aaa-wg@merit.edu Subject: [AAA-WG]: question about section 4.6 in base draft X-MIMETrack: Itemize by SMTP Server on BEMAIL04/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 08/06/2002 10:41:02, Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 08/06/2002 10:41:04, Serialize complete at 08/06/2002 10:41:04 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hello,

I'm new to this list so my apologies if this question was already asked.
When reading the diameter base spec (version 12) I was wondering what the difference is between the 'MAY encr' and the  P flag column in the table in section 4.6. When reading the text the explanation for the both columns is identical.

For instance for the 'Auth-Request type' the P may be set but the 'MAY encr' indicates it may not be encrypted. Does this mean I can set the P bit but not encrypt the message?

Small typo in the command code ABNF spec?
should (double quote  missing?):
header = "<" diameter-Header:" command-id [r-bit] [p-bit] [e-bit] ">"
read:
header = "<" "diameter-Header:" command-id [r-bit] [p-bit] [e-bit] ">"

also in the example
Example-Request ::= < "Diameter-Header: 9999999, REQ, PXY >
should read?
Example-Request ::= < Diameter-Header: 9999999, REQ, PXY >
 

Regards,
    Suresh From owner-aaa-wg@merit.edu Tue Aug 6 09:42: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 JAA11444 for ; Tue, 6 Aug 2002 09:42:01 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id ED00391295; Tue, 6 Aug 2002 09:41:32 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A340191296; Tue, 6 Aug 2002 09:41:32 -0400 (EDT) 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 E1FF791295 for ; Tue, 6 Aug 2002 09:41:27 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B874F62B44; Tue, 6 Aug 2002 08:20:09 -0400 (EDT) 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 2CCDF68259 for ; Tue, 6 Aug 2002 07:22:44 -0400 (EDT) Received: by p2.piuha.net (Postfix, from userid 962) id 83A326A907; Tue, 6 Aug 2002 14:22:37 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id CE03A6A906; Tue, 6 Aug 2002 14:22:30 +0300 (EEST) Message-ID: <3D4FB1F9.9050100@kolumbus.fi> Date: Tue, 06 Aug 2002 14:24:41 +0300 From: Jari Arkko 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: suresh.leroy@alcatel.be Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: question about section 4.6 in base draft References: <3D4F8B9E.2E12C40@alcatel.be> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit suresh.leroy@alcatel.be wrote: > Hello, > > I'm new to this list so my apologies if this question was already asked. > When reading the diameter base spec (version 12) I was wondering what > the difference is between the 'MAY encr' and the P flag column in the > table in section 4.6. When reading the text the explanation for the both > columns is identical. > > For instance for the 'Auth-Request type' the P may be set but the 'MAY > encr' indicates it may not be encrypted. Does this mean I can set the P > bit but not encrypt the message? This must be some problem that remains from the time we made CMS independent of the base. The following should fix it: "there is end-to-end security between the originator and the recipient" => "there is end-to-end security between the originator and the recipient and integrity / confidentiality protection is offered for this AVP" Jari From owner-aaa-wg@merit.edu Wed Aug 7 06:55: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 GAA12336 for ; Wed, 7 Aug 2002 06:55:13 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 27A1291207; Wed, 7 Aug 2002 06:56:13 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DF6D3912D1; Wed, 7 Aug 2002 06:56:12 -0400 (EDT) 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 BEF0C91207 for ; Wed, 7 Aug 2002 06:56:11 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 984CF5DE08; Wed, 7 Aug 2002 06:56:11 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14]) by segue.merit.edu (Postfix) with ESMTP id 1289B5DD94 for ; Wed, 7 Aug 2002 06:56:11 -0400 (EDT) Received: from fokus.gmd.de (dhcp229 [195.37.78.229]) by mailhub.fokus.gmd.de (8.11.6/8.11.6) with ESMTP id g77Au9W15454 for ; Wed, 7 Aug 2002 12:56:09 +0200 (MEST) Message-ID: <3D50FC74.1050900@fokus.gmd.de> Date: Wed, 07 Aug 2002 12:54:44 +0200 From: Sebastian Zander Organization: Fraunhofer FOKUS User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; de-DE; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: de-DE MIME-Version: 1.0 To: aaa-wg@merit.edu Subject: [AAA-WG]: DIAMETER protocol as candidate for IPFIX group 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 Hi, the IPFIX working group is about to standardize a protocol for IP flow information export http://www.ietf.org/html.charters/ipfix-charter.html. The IPFIX WG will select an existing protocol as basis for the IPFIX protocol. Currently the call for protocol submissions is open until 2nd of September: http://ipfix.doit.wisc.edu/eval/call_for_protocols.html I will advocate the DIAMETER protocol because I think it is a suitable candidate. If there is someone from this group who wants to contribute to this effort please contact me. I would also be happy about comments. Sorry for being not straight on topic. Cheers, Sebastian -- Sebastian Zander E-mail: zander@fokus.fhg.de FhI FOKUS / Global Networking (GloNe) Tel: +49-30-3463-7287 Kaiserin-Augusta-Allee 31 Fax: +49-30-3463-8287 D-10589 Berlin, Germany www.fokus.fhg.de/usr/sebastian.zander From owner-aaa-wg@merit.edu Wed Aug 7 10:10: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 KAA18851 for ; Wed, 7 Aug 2002 10:10:41 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0FC5A9120A; Wed, 7 Aug 2002 10:11:41 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CFAF8912D4; Wed, 7 Aug 2002 10:11:40 -0400 (EDT) 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 AF3769120A for ; Wed, 7 Aug 2002 10:11:39 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9922C5DE13; Wed, 7 Aug 2002 10:11:39 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mail.alcatel.be (alc250.alcatel.be [195.207.101.250]) by segue.merit.edu (Postfix) with ESMTP id D66C45DE11 for ; Wed, 7 Aug 2002 10:11:38 -0400 (EDT) Received: from bemail04.net.alcatel.be (relay3 [127.0.0.1]) by mail.alcatel.be (8.11.0/8.11.4) with ESMTP id g77E6lc10378; Wed, 7 Aug 2002 16:06:47 +0200 Received: from alcatel.be ([138.203.65.127]) by bemail04.net.alcatel.be (Lotus Domino Release 5.0.8) with ESMTP id 2002080716112894:4651 ; Wed, 7 Aug 2002 16:11:28 +0200 Message-ID: <3D512A8D.A41DE166@alcatel.be> Date: Wed, 07 Aug 2002 16:11:25 +0200 From: suresh.leroy@alcatel.be Organization: Alcatel X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Jari Arkko Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: question about section 4.6 in base draft References: <3D4F8B9E.2E12C40@alcatel.be> <3D4FB1F9.9050100@kolumbus.fi> X-MIMETrack: Itemize by SMTP Server on BEMAIL04/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 08/07/2002 16:11:29, Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 08/07/2002 16:11:30, Serialize complete at 08/07/2002 16:11:30 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Jari, Thank you for the answer. Here are however some questions I'm struggling with: 1) Are Integrity & confidentiality not part of the basic end-to-end security? 2) What do I have to do with an AVP where the 'may encr' states no and the P bit is set? integrity/confidentiality but not end-to-end security? 3) end-to-end is this true e2e or up to the proxy? Can I use proxy agents when end-to-end security is used (according to section 2.8.2 not) ? two other small things: In section 5.4 the Disconnect-Reason AVP should be changed to Disconnect-Cause AVP. I didn't find the E2E-Sequence AVP (section 6.15) back in the table in section 4.6 (is this part of the base spec or a specific application?). Is there an identifier in the Inband-security-Id for IPsec? Regards, Suresh Jari Arkko wrote: > suresh.leroy@alcatel.be wrote: > > > Hello, > > > > I'm new to this list so my apologies if this question was already asked. > > When reading the diameter base spec (version 12) I was wondering what > > the difference is between the 'MAY encr' and the P flag column in the > > table in section 4.6. When reading the text the explanation for the both > > columns is identical. > > > > For instance for the 'Auth-Request type' the P may be set but the 'MAY > > encr' indicates it may not be encrypted. Does this mean I can set the P > > bit but not encrypt the message? > > This must be some problem that remains from the time we made CMS > independent of the base. > > The following should fix it: > > "there is end-to-end security between the originator and the recipient" > > => > > "there is end-to-end security between the originator and the recipient > and integrity / confidentiality protection is offered for this AVP" > > Jari From owner-aaa-wg@merit.edu Wed Aug 7 10:26: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 KAA19710 for ; Wed, 7 Aug 2002 10:26:37 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0487D912D4; Wed, 7 Aug 2002 10:27:37 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C350E912D5; Wed, 7 Aug 2002 10:27:36 -0400 (EDT) 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 D2422912D4 for ; Wed, 7 Aug 2002 10:27:35 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BB5BE5DE13; Wed, 7 Aug 2002 10:27:35 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mailgw.local.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by segue.merit.edu (Postfix) with ESMTP id EC4025DE11 for ; Wed, 7 Aug 2002 10:27:34 -0400 (EDT) Received: from ipunplugged.com (aniara.local.ipunplugged.com [192.168.4.103]) by mailgw.local.ipunplugged.com (8.12.3/8.12.3) with ESMTP id g77EQfEa020342 for ; Wed, 7 Aug 2002 16:26:41 +0200 Message-ID: <3D512E56.1030806@ipunplugged.com> Date: Wed, 07 Aug 2002 16:27:34 +0200 From: Boris Prochazka Reply-To: boris@ipunplugged.com Organization: InteractivePeopleUnplugged User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011126 Netscape6/6.2.1 X-Accept-Language: sv, en-us MIME-Version: 1.0 To: aaa-wg@merit.edu Subject: [AAA-WG]: Some typografick flaws in diameter-mobileip-11 section 2.1 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-RAVMilter-Version: 8.3.3(snapshot 20020312) (mailgw) Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit In draft-ietf-aaa-diameter-mobileip-11.txt section 2.1 I am lacking some information: uses information found in the Registration Request to construct the following AVPs that are to be included as part of the AMR: home address (MIP-Mobile-Node-Address AVP) home agent address (MIP-Home-Agent-Address AVP) mobile node NAI (User-Name AVP [DIAMBASE]) MN-HA Key Request (MIP-Feature-Vector AVP) MN-FA Key Request (MIP-Feature-Vector AVP) MN-AAA Authentication Extension (MIP-MN-AAA-Auth AVP) foreign agent Challenge Extension (MIP-FA-Challenge AVP) home agent NAI (MIP-Home-Agent-Host, MIP-Home-Agent-Realm AVP) <<< home AAA server NAI (Destination-Host AVP, Destination-Realm [DIAMBASE]) <<< The MIP-Home-Agent-Realm is missing in the message. Without the realm part I dont see a way for the AAAH to be able to reach the HA. (I think it would be a mistake to send the HA-NAI in a AVP called -Host). You could of course remove the -Host part and treat it as a grouped AVP like in MIP-Origination-Foreign-AAA I guess that the Destination-Realm can be set from the AAA-NAI like the Destination-Host (AAA-NAI ::= host@realm). If that all is true then both MIP-Home-Agent-Host and MIP-Home-Agent-Realm is missing in the Message Format for AA-Mobile-Node-Request and there is also lacking a AVP description of the MIP-Home-Agent-Realm Boris. From owner-aaa-wg@merit.edu Wed Aug 7 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 RAA09279 for ; Wed, 7 Aug 2002 17:10:29 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A0969912E1; Wed, 7 Aug 2002 17:08:46 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F2748912E3; Wed, 7 Aug 2002 17:08:45 -0400 (EDT) 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 45126912E5 for ; Wed, 7 Aug 2002 17:08:15 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 12AB45DE1B; Wed, 7 Aug 2002 17:08:15 -0400 (EDT) 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 D36CD5DDCE for ; Wed, 7 Aug 2002 17:08:14 -0400 (EDT) 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 g77L8Ei04784; Wed, 7 Aug 2002 16:08:14 -0500 (CDT) Received: from eamrcnt750.exu.ericsson.se (eamrcnt750.exu.ericsson.se [138.85.133.51]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g77L8EF13095; Wed, 7 Aug 2002 16:08:14 -0500 (CDT) Received: from ericsson.com (T21ICEMAN [138.85.159.136]) by eamrcnt750.exu.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id QMW2ZS4K; Wed, 7 Aug 2002 16:08:13 -0500 Message-ID: <3D518B1A.A1250CEC@ericsson.com> Date: Wed, 07 Aug 2002 14:03:22 -0700 X-Sybari-Trust: d647cf26 14dfe396 16511001 00000138 From: Tony Johansson X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: boris@ipunplugged.com Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Some typografick flaws in diameter-mobileip-11 section 2.1 References: <3D512E56.1030806@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 Hi Boris, Thanks for your comments, but I am a bit confused though. The MIP-Home-Agent-Host AVP IS of type grouped, thus MIP-Home-Agent-Host ::= < AVP Header: 348 > { Destination-Realm } { Destination-Host } * [ AVP ] So, is it just the name " MIP-Home-Agent-Host" you find confusing or is it something more that I am blindly missing. Regards, /Tony Ps. Please review the -12alpha1 instead, http://www.erilab.com/users/temp/draft-ietf-aaa-diameter-mobileip-12alpha1.txt Boris Prochazka wrote: > In draft-ietf-aaa-diameter-mobileip-11.txt section 2.1 I am lacking some > information: > > uses information found in the Registration Request to construct the > following AVPs that are to be included as part of the AMR: > > home address (MIP-Mobile-Node-Address AVP) > home agent address (MIP-Home-Agent-Address AVP) > mobile node NAI (User-Name AVP [DIAMBASE]) > MN-HA Key Request (MIP-Feature-Vector AVP) > MN-FA Key Request (MIP-Feature-Vector AVP) > MN-AAA Authentication Extension (MIP-MN-AAA-Auth AVP) > foreign agent Challenge Extension (MIP-FA-Challenge AVP) > home agent NAI (MIP-Home-Agent-Host, > MIP-Home-Agent-Realm AVP) <<< > home AAA server NAI (Destination-Host AVP, > Destination-Realm [DIAMBASE]) <<< > > The MIP-Home-Agent-Realm is missing in the message. Without the > realm part I dont see a way for the AAAH to be able to reach the HA. > (I think it would be a mistake to send the HA-NAI in a AVP called -Host). > You could of course remove the -Host part and treat it as a grouped > AVP like in MIP-Origination-Foreign-AAA > > I guess that the Destination-Realm can be set from the AAA-NAI like the > Destination-Host (AAA-NAI ::= host@realm). > > If that all is true then both MIP-Home-Agent-Host and > MIP-Home-Agent-Realm is missing in the Message Format for > AA-Mobile-Node-Request and there is also lacking a AVP description of > the MIP-Home-Agent-Realm > > Boris. From owner-aaa-wg@merit.edu Thu Aug 8 01:55: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 BAA22328 for ; Thu, 8 Aug 2002 01:55:56 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 391F4912E9; Thu, 8 Aug 2002 01:56:56 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0A997912EA; Thu, 8 Aug 2002 01:56:55 -0400 (EDT) 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 1F4C5912E9 for ; Thu, 8 Aug 2002 01:56:55 -0400 (EDT) Received: by segue.merit.edu (Postfix) id ED5E65DE3D; Thu, 8 Aug 2002 01:56:54 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 9029F5DDDD for ; Thu, 8 Aug 2002 01:56:54 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g7851o801135 for ; Wed, 7 Aug 2002 22:01:50 -0700 Date: Wed, 7 Aug 2002 22:01:49 -0700 (PDT) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: AAA WG last call on draft-ietf-aaa-diameter-12.txt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk This is an announcement of AAA WG last call on: http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-12.txt Please send your comments to the AAA WG mailing list, as well as to the authors, on or before August 23, 2002, using the issue submission format described below: http://www.drizzle.com/~aboba/AAA/issues.html From owner-aaa-wg@merit.edu Fri Aug 9 05:26: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 FAA20708 for ; Fri, 9 Aug 2002 05:26:15 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id CC0D391225; Fri, 9 Aug 2002 05:27:15 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9C01D91230; Fri, 9 Aug 2002 05:27:15 -0400 (EDT) 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 8795C91225 for ; Fri, 9 Aug 2002 05:27:14 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7015F5DEDE; Fri, 9 Aug 2002 05:27:14 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mailgw.local.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by segue.merit.edu (Postfix) with ESMTP id CF2985DDF8 for ; Fri, 9 Aug 2002 05:27:13 -0400 (EDT) Received: from ipunplugged.com (aniara.local.ipunplugged.com [192.168.4.103]) by mailgw.local.ipunplugged.com (8.12.3/8.12.3) with ESMTP id g799QCEa030738; Fri, 9 Aug 2002 11:26:13 +0200 Message-ID: <3D538AEA.9060406@ipunplugged.com> Date: Fri, 09 Aug 2002 11:27:06 +0200 From: Boris Prochazka Reply-To: boris@ipunplugged.com Organization: InteractivePeopleUnplugged User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011126 Netscape6/6.2.1 X-Accept-Language: sv, en-us MIME-Version: 1.0 To: Tony Johansson Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Some typografick flaws in diameter-mobileip-11 section 2.1 References: <3D512E56.1030806@ipunplugged.com> <3D518B1A.A1250CEC@ericsson.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-RAVMilter-Version: 8.3.3(snapshot 20020312) (mailgw) Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit True Tony, I somehow overlooked it. Still having the tailing -Host on the is MIP-Home-Agent-Host AVP is confusing. I believe the readability would improve without it, therefore I vote for removing the tailing -Host on MIP-Home-Agent-Host AVP. Am I right about the Destination-Realm in AMR. I think that if you set the Destination-Host from the Regigstration Request you should also set the Destination-Realm otherwise you have problem to reach the AAAH. Both the realm and host of the AAAH are part of the AAANAI extension according to draft-ietf-mobileip-aaa-nai-02. Boris Tony Johansson wrote: > Hi Boris, > > Thanks for your comments, but I am a bit confused though. > > The MIP-Home-Agent-Host AVP IS of type grouped, thus > > MIP-Home-Agent-Host ::= < AVP Header: 348 > > { Destination-Realm } > { Destination-Host } > * [ AVP ] > > > So, is it just the name " MIP-Home-Agent-Host" you find confusing or is it > something more that I am blindly missing. > > Regards, > > /Tony > > Ps. Please review the -12alpha1 instead, > http://www.erilab.com/users/temp/draft-ietf-aaa-diameter-mobileip-12alpha1.txt > > Boris Prochazka wrote: > > >>In draft-ietf-aaa-diameter-mobileip-11.txt section 2.1 I am lacking some >>information: >> >> uses information found in the Registration Request to construct the >> following AVPs that are to be included as part of the AMR: >> >> home address (MIP-Mobile-Node-Address AVP) >> home agent address (MIP-Home-Agent-Address AVP) >> mobile node NAI (User-Name AVP [DIAMBASE]) >> MN-HA Key Request (MIP-Feature-Vector AVP) >> MN-FA Key Request (MIP-Feature-Vector AVP) >> MN-AAA Authentication Extension (MIP-MN-AAA-Auth AVP) >> foreign agent Challenge Extension (MIP-FA-Challenge AVP) >> home agent NAI (MIP-Home-Agent-Host, >> MIP-Home-Agent-Realm AVP) <<< >> home AAA server NAI (Destination-Host AVP, >> Destination-Realm [DIAMBASE]) <<< >> >>The MIP-Home-Agent-Realm is missing in the message. Without the >>realm part I dont see a way for the AAAH to be able to reach the HA. >>(I think it would be a mistake to send the HA-NAI in a AVP called -Host). >>You could of course remove the -Host part and treat it as a grouped >>AVP like in MIP-Origination-Foreign-AAA >> >>I guess that the Destination-Realm can be set from the AAA-NAI like the >>Destination-Host (AAA-NAI ::= host@realm). >> >>If that all is true then both MIP-Home-Agent-Host and >>MIP-Home-Agent-Realm is missing in the Message Format for >>AA-Mobile-Node-Request and there is also lacking a AVP description of >>the MIP-Home-Agent-Realm >> >>Boris. >> From owner-aaa-wg@merit.edu Mon Aug 19 11:24: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 LAA05542 for ; Mon, 19 Aug 2002 11:24:28 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id CF2739125A; Mon, 19 Aug 2002 11:25:35 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 96BE89125B; Mon, 19 Aug 2002 11:25:35 -0400 (EDT) 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 808C69125A for ; Mon, 19 Aug 2002 11:25:34 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 57AC85DEE1; Mon, 19 Aug 2002 11:25:34 -0400 (EDT) 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 E736A5DE6D for ; Mon, 19 Aug 2002 11:25:33 -0400 (EDT) Received: from nwsgpa.ih.lucent.com (h135-1-121-22.lucent.com [135.1.121.22]) by hoemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g7JFPWU13707 for ; Mon, 19 Aug 2002 11:25:32 -0400 (EDT) Received: from mccap-1.lucent.com by nwsgpa.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id KAA11702; Mon, 19 Aug 2002 10:25:32 -0500 (CDT) Received: from [127.0.0.1] (helo=MCCAP-1.lucent.com) by mccap-1.lucent.com with esmtp (Exim 4.04) id H13K6J-0001JC-00 for aaa-wg@merit.edu; Mon, 19 Aug 2002 11:25:31 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15713.3562.138763.578834@gargle.gargle.HOWL> Date: Mon, 19 Aug 2002 10:25:30 -0500 From: Pete McCann To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue #352 X-Mailer: VM 7.03 under 21.4 (patch 7) "Economic Science (Windows [1])" XEmacs Lucid Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi, I wanted to make sure everyone is reading the IANA Considerations section of draft-12. I think the current text is not quite correct with respect to the new experimental Application ID space. Because these IDs can appear by themselves in a Diameter header, they really need to be centrally administered, rather than for Private Use as stated in Section 11.3. While I would personally favor First Come First Served for this space, I don't think we could realistically expect the IESG to go along. How about Designated Expert Review as the assignment policy? This would work as follows. First, the existing text from 11.3: > 11.3 Application Identifiers > > As defined in section 2.4, the Application Identifier is used to > identify a specific Diameter Application. There are standards-track > application ids and vendor specific application ids. > > IANA [IANA] will assign the range 0x00000001 to 0x00ffffff for > standards-track applications; and 0xff00000000 - 0xfffffffe for > vendor specific applications. > > Both Application-Id and Acct-Application-Id AVPs use the same > Application Identifier space. > > Vendor-Specific Application Identifiers, encoded in the Vendor- > Specific-Application-Id Grouped AVP, with the Vendor-Id AVP set to > the vendor's enterprise number, is for Private Use. > > Note that the Diameter protocol is not intended to be extended for > any purpose. Any applications defined MUST ensure that they fit > within the existing framework, and that no changes to the base > protocol are required. I propose to strike the last two paragraphs above, and add instead: > Vendor-Specific Application Identifiers, encoded in the Vendor- > Specific-Application-Id Grouped AVP with the Vendor-Id AVP set to > the vendor's enterprise number, and appearing in the Diameter > header, will be assigned by IANA after review by a Designated > Expert. The Expert will ensure that the requested application fits > within the existing Diameter framework, does not require changes to > the base protocol, and does not cause interoperability problems > with any existing Diameter application before approving the > assignment. I hope this sort of wording would satisfy all the interested parties; it does not allow for completely uncontrolled creation of Diameter applications, but I think the Designated Expert Review process is the least onerous to follow. The language should address all of the IESG concerns regarding interoperability. -Pete From owner-aaa-wg@merit.edu Fri Aug 23 17:49: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 RAA18469 for ; Fri, 23 Aug 2002 17:49:35 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8CCFA913B1; Fri, 23 Aug 2002 17:50:38 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CC643913B3; Fri, 23 Aug 2002 17:50:36 -0400 (EDT) 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 9F16D913B1 for ; Fri, 23 Aug 2002 17:50:33 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6CAE15DE43; Fri, 23 Aug 2002 17:50:33 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by segue.merit.edu (Postfix) with ESMTP id 0C3EC5DDD0 for ; Fri, 23 Aug 2002 17:50:33 -0400 (EDT) Received: from tari.research.telcordia.com (tari [207.3.232.66]) by thumper.research.telcordia.com (8.12.1/8.12.1) with ESMTP id g7NLoIA1023145 for ; Fri, 23 Aug 2002 17:50:18 -0400 (EDT) Received: from localhost (ohba@tari-dhcp-104.research.telcordia.com [207.3.232.104]) by tari.research.telcordia.com (8.8.8/8.8.8) with ESMTP id RAA16238 for ; Fri, 23 Aug 2002 17:50:40 -0400 (EDT) Date: Fri, 23 Aug 2002 17:50:11 -0400 To: aaa-wg@merit.edu Subject: [AAA-WG]: Need more specifics on list of AVPs Message-ID: <20020823215011.GC1685@catfish> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline User-Agent: Mutt/1.4i From: Yoshihiro Ohba X-Dispatcher: imput version 20000414(IM141) Lines: 29 X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Sender: owner-aaa-wg@merit.edu Precedence: bulk Need more specifics on list of AVPs Submitter name: Yoshihiro Ohba Submitter email address: yohba@tari.toshiba.com Date first submitted: August 23, 2002 Document: base Comment type: T Priority: S Section: 4 Rationale/Explanation of issue: In section 4 it is descibred that: Some AVPs MAY be listed more than once. The effect of such an AVP is specific, and is specified in each case by the AVP description. But the specification is not clear on whether each AVP in the list of AVPs of the same type can be dispersely located in the message payload (e.g, a Host-IP-Address AVP, then an Origin-Realm AVP, and then a Host-IP-Address AVP again) or must be located back to back (e.g, two Host-IP-Address AVPs, and then an Origin-Realm AVP). From the debugging point of view, the latter would be prefered since it makes easier to find out where AVPs of a specific type are in the payload. Requested change: Each AVP in a list of AVPs of the same type must be located back to back in the message payload. From owner-aaa-wg@merit.edu Sun Aug 25 23: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 XAA19688 for ; Sun, 25 Aug 2002 23:03:25 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E0EB791220; Sun, 25 Aug 2002 23:04:31 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B0D6D9122F; Sun, 25 Aug 2002 23:04:31 -0400 (EDT) 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 8007A91220 for ; Sun, 25 Aug 2002 23:04:30 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6DAE65DE1B; Sun, 25 Aug 2002 23:04:30 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from cms1.etri.re.kr (cms1.etri.re.kr [129.254.16.11]) by segue.merit.edu (Postfix) with ESMTP id 99C5E5DDBB for ; Sun, 25 Aug 2002 23:04:29 -0400 (EDT) Received: from JUNNY (junny.etri.re.kr [129.254.241.18]) by cms1.etri.re.kr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id PXQGQPY2; Mon, 26 Aug 2002 11:59:05 +0900 Message-ID: <001d01c24cad$4bb1ec80$12f1fe81@JUNNY> From: =?ks_c_5601-1987?B?wMy8rsHY?= To: Subject: [AAA-WG]: Some Questions Date: Mon, 26 Aug 2002 12:04:30 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001A_01C24CF8.BB8B3CA0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_001A_01C24CF8.BB8B3CA0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 SGVsbG8sDQoNCkkgaGF2ZSBzb21lIHF1ZXN0aW9ucyBhYm91dCAoYXV0aG9yaXphdGlvbikgc2Vz c2lvbiBzdGF0ZSBtYWNoaW5lLg0KDQoxLiAiSSB0aGluayBpdCBpcyBub3QgZGVzY3JpYmVkIHdo ZW4gdGhlIFJBUiB3aWxsIGJlIHNlbnQgYnkgdGhlIHNlcnZlciB0byB0aGUgDQpjbGllbnQgaW4g dGhlIGF1dGhvcml6YXRpb24gc2Vzc2lvbiBzdGF0ZSBtYWNoaW5lLiINCih0aGlzIHF1ZXN0aW9u IHdhcyBhc2tlZCBieSBMaXUgUWlvbmcgQm8sIE1heSAyMDAyKQ0KSSB3YW50IHRvIGtub3cgaWYg dGhpcyBjYXNlIHdvdWxkIGFmZmVjdCBzb21lIGtpbmRzIG9mIHRpbWVycyhlLmcuIHNlc3Npb24t dGltZW91dCkNCg0KMi4gQ2FuIFJBUiBiZSBpbml0aWF0ZWQgYnkgY2xpZW50PyANCg0KMy4gSWYg YSByZXF1ZXN0IG1lc3NhZ2Ugd2l0aCBhdXRoZW50aWNhdGlvbiBvbmx5IHJlY2VpdmVkIGJ5IHNl cnZlciANCihzZW50IGJ5IGNsaWVudCksIGRvZXMgbm90IHNlcnZlciBuZWVkIHRvIG1haW50YWlu IHNlc3Npb24gc3RhdGUgaW5mb3JtYXRpb24/DQp0aGVuLCBhcHBsaWNhdGlvbihlLmcuIG5hc3Jl cSwgbWlwKSBzaG91bGQgbWFpbnRhaW4gc29tZSBpbmZvcm1hdGlvbiANCmFib3V0IGF1dGhlbnRp Y2F0aW9uIGlmIG11bHRpLXJvdW5kIGF1dGhlbnRpY2F0aW9uIGlzIG5lY2Vzc2FyeSwgYW0gSSBy aWdodD8gDQpXaGF0IGNhbiBjbGllbnQoTkFTKSBkbyB0byB1c2VyIGluIHRoZSBjYXNlIHRoYXQg YXV0aG9yaXppbmcgaXMgbm90IHBlcmZvcm1lZD8NCg0KNC4gSG93IHdpbGwgY2xpZW50IG9yIHNl cnZlciBwcm9jZXNzIGluIHNlc3Npb24gc3RhdGUgbWFjaGluZSBpZiANCmF1dGhvcml6YXRpb24g YW5zd2VyIG1lc3NhZ2Ugd2l0aCBSZXN1bHQtQ29kZSA9IERJQU1FVEVSX01VTFRJX1JPVU5EX0FV VEgNCmlzIGdlbmVyYXRlZCBhbmQgc2VudC9yZWNlaXZlZD8gKGVzcGVjaWFsbHksIGhvdyBhYm91 dCBwZW5kaW5nIHN0YXRlIGluIGNsaWVudCBtYWNoaW5lKQ0KDQpyZWdhcmRzLA0KU29ram9vbg0K ------=_NextPart_000_001A_01C24CF8.BB8B3CA0 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWtzX2NfNTYwMS0xOTg3Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1T SFRNTCA2LjAwLjI3MTkuMjIwMCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwv SEVBRD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgc2l6ZT0yPkhlbGxvLDwv Rk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+ PEZPTlQgc2l6ZT0yPkkgaGF2ZSBzb21lIHF1ZXN0aW9ucyBhYm91dCAoYXV0aG9yaXphdGlvbikg c2Vzc2lvbiBzdGF0ZSANCm1hY2hpbmUuPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+ PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+MS4gIkkgdGhpbmsgaXQgaXMg bm90IGRlc2NyaWJlZCB3aGVuIHRoZSBSQVIgd2lsbCBiZSBzZW50IGJ5IA0KdGhlIHNlcnZlciB0 byB0aGUgPEJSPmNsaWVudCBpbiB0aGUgYXV0aG9yaXphdGlvbiBzZXNzaW9uIHN0YXRlIA0KbWFj aGluZS4iPEJSPih0aGlzIHF1ZXN0aW9uIHdhcyBhc2tlZCBieSBMaXUgUWlvbmcgQm8sIE1heSAy MDAyKTxCUj5JIHdhbnQgdG8gDQprbm93IGlmIHRoaXMgY2FzZSB3b3VsZCBhZmZlY3Qgc29tZSBr aW5kcyBvZiB0aW1lcnMoZS5nLiANCnNlc3Npb24tdGltZW91dCk8L0ZPTlQ+PC9ESVY+DQo8RElW PjxGT05UIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj4yLiBD YW4gUkFSIGJlIGluaXRpYXRlZCBieSBjbGllbnQ/IDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQg c2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPjMuIElmIGEgcmVx dWVzdCBtZXNzYWdlIHdpdGggYXV0aGVudGljYXRpb24gb25seSByZWNlaXZlZCBieSANCnNlcnZl ciA8QlI+KHNlbnQgYnkgY2xpZW50KSwgZG9lcyBub3Qgc2VydmVyIG5lZWQgdG8gbWFpbnRhaW4g c2Vzc2lvbiBzdGF0ZSANCmluZm9ybWF0aW9uPzxCUj50aGVuLCBhcHBsaWNhdGlvbihlLmcuIG5h c3JlcSwgbWlwKSBzaG91bGQgbWFpbnRhaW4gc29tZSANCmluZm9ybWF0aW9uIDxCUj5hYm91dCBh dXRoZW50aWNhdGlvbiBpZiBtdWx0aS1yb3VuZCBhdXRoZW50aWNhdGlvbiBpcyBuZWNlc3Nhcnks IA0KYW0gSSByaWdodD8gPEJSPldoYXQgY2FuIGNsaWVudChOQVMpIGRvIHRvIHVzZXIgaW4gdGhl IGNhc2UgdGhhdCBhdXRob3JpemluZyBpcyANCm5vdCBwZXJmb3JtZWQ/PC9GT05UPjwvRElWPg0K PERJVj48Rk9OVCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+ NC4gSG93IHdpbGwgY2xpZW50IG9yIHNlcnZlciBwcm9jZXNzIGluIHNlc3Npb24gc3RhdGUgbWFj aGluZSANCmlmIDxCUj5hdXRob3JpemF0aW9uIGFuc3dlciBtZXNzYWdlIHdpdGggUmVzdWx0LUNv ZGUgPSANCkRJQU1FVEVSX01VTFRJX1JPVU5EX0FVVEg8QlI+aXMgZ2VuZXJhdGVkIGFuZCBzZW50 L3JlY2VpdmVkPyAoZXNwZWNpYWxseSwgDQpob3cmbmJzcDthYm91dCBwZW5kaW5nIHN0YXRlIGlu IGNsaWVudCBtYWNoaW5lKTwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPjwvRk9OVD4m bmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPnJlZ2FyZHMsPC9GT05UPjwvRElWPg0KPERJ Vj48Rk9OVCBzaXplPTI+U29ram9vbjwvRk9OVD48L0RJVj48L0JPRFk+PC9IVE1MPg0K ------=_NextPart_000_001A_01C24CF8.BB8B3CA0-- From owner-aaa-wg@merit.edu Tue Aug 27 14:46: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 OAA06638 for ; Tue, 27 Aug 2002 14:46:14 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id AB5D091298; Tue, 27 Aug 2002 14:46:38 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6C78E9129E; Tue, 27 Aug 2002 14:46:38 -0400 (EDT) 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 E09C091298 for ; Tue, 27 Aug 2002 14:46:33 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 798B65DDF3; Tue, 27 Aug 2002 14:46:33 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from ietf.org (odin.ietf.org [132.151.1.176]) by segue.merit.edu (Postfix) with ESMTP id 38A665DDBE; Tue, 27 Aug 2002 14:46:32 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06546 for <1timer>; Tue, 27 Aug 2002 14:44:44 -0400 (EDT) Message-Id: <200208271844.OAA06546@ietf.org> From: Phil Roberts To: IETF WG Participants: ; Subject: [AAA-WG]: Nomcom call for volunteers Date: Tue, 27 Aug 2002 14:44:44 -0400 Sender: owner-aaa-wg@merit.edu Precedence: bulk The members of the IESG and IAB and the IETF chair are selected by a nominations committee made up of volunteers from the IETF community. The nominations committee is now in the process of being formed and volunteers are being accepted until Sep 6. Please see (http://www.ietf.org/nomcom/msg19765.html) for information if you are interested in volunteering to be on the nominations committee. From owner-aaa-wg@merit.edu Thu Aug 29 09:39: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 JAA21668 for ; Thu, 29 Aug 2002 09:39:18 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B4486912BF; Thu, 29 Aug 2002 09:40:36 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 87EC5912E9; Thu, 29 Aug 2002 09:40:36 -0400 (EDT) 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 949B3912BF for ; Thu, 29 Aug 2002 09:40:35 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 74B2A5DE81; Thu, 29 Aug 2002 09:40:35 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id E81665DDD1 for ; Thu, 29 Aug 2002 09:40:34 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g7TChQR21247; Thu, 29 Aug 2002 05:43:26 -0700 Date: Thu, 29 Aug 2002 05:43:26 -0700 (PDT) From: Bernard Aboba To: aaa-wg@merit.edu Cc: iesg@ietf.org Subject: [AAA-WG]: Conclusion of AAA WG last call on draft-ietf-aaa-diameter-12.txt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk AAA WG last call has concluded on draft-ietf-aaa-diameter-12.txt. We therefore request that the IESG review this document for consideration as a Proposed Standard. From owner-aaa-wg@merit.edu Fri Aug 30 00:17: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 AAA22803 for ; Fri, 30 Aug 2002 00:17:41 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E51489121F; Fri, 30 Aug 2002 00:18:55 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 39C9791312; Fri, 30 Aug 2002 00:18:53 -0400 (EDT) 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 AFBC29121F for ; Fri, 30 Aug 2002 00:16:55 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 91BF95DD8F; Fri, 30 Aug 2002 00:16:55 -0400 (EDT) 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 1352E5DD8D for ; Fri, 30 Aug 2002 00:16:55 -0400 (EDT) Received: from gwzw2k (tokyo-vpn-user295.cisco.com [10.70.83.39]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id VAA01697; Thu, 29 Aug 2002 21:16:44 -0700 (PDT) Reply-To: From: "Glen Zorn" To: "'Bernard Aboba'" , Cc: Subject: RE: [AAA-WG]: Conclusion of AAA WG last call on draft-ietf-aaa-diameter-12.txt Date: Thu, 29 Aug 2002 21:13:25 -0700 Message-ID: <00b601c24fdb$f7308720$f000050a@amer.cisco.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 CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal In-Reply-To: Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Bernard Aboba [mailto://aboba@internaut.com] writes: > AAA WG last call has concluded on draft-ietf-aaa-diameter-12.txt. It is certainly a landmark that the WG rubberstamp phase is complete, and with only one comment (apparently ignored, perhaps because it didn't come from the IESG). The dirth of comment is especially good, since if there were to be an appeal of this fiasco (doubtful to say the least, given the historic suucess rate of such actions and the consequences to those who have the temerity to initiate them) the AD can point to this fact as justification, conveniently ignoring both the previous passage of WG Last Call by -11 and the storm of protest over -12. > We therefore request that the IESG review this document for > consideration as > a Proposed Standard. Leaving aside the fact that the very existance of -12 is a clear violation of WG consensus, perhaps the AD's hand-wrought protocol will now actually be presented to the full IESG; we can only await with baited breath the wise and wonderful objections to come. > > > From owner-aaa-wg@merit.edu Fri Aug 30 01:03: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 BAA23827 for ; Fri, 30 Aug 2002 01:03:12 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5814F91313; Fri, 30 Aug 2002 01:04:25 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2AA3191314; Fri, 30 Aug 2002 01:04:25 -0400 (EDT) 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 25E2C91313 for ; Fri, 30 Aug 2002 01:04:24 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0A78B5DD99; Fri, 30 Aug 2002 01:04:24 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 7FC735DD8D for ; Fri, 30 Aug 2002 01:04:23 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g7U47CE06854 for ; Thu, 29 Aug 2002 21:07:12 -0700 Date: Thu, 29 Aug 2002 21:07:12 -0700 (PDT) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: AAA WG last call on draft-ietf-aaa-diameter-mobileip-12.txt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk This is AAA WG last call on the document "Diameter Mobile IPv4 Application", prior to forwarding on to the IESG for consideration as an IETF Proposed Standard. The document can be found at: http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-mobileip-12.txt Please email your issues to the authors, with a cc: to the AAA WG mailing list, prior to the conclusion of AAA WG last call on September 15, 2002. The format required for issue submissions (and a list of previously resolved issues) can be found at: http://www.drizzle.com/~aboba/AAA/issues.html