From owner-aaa-wg@merit.edu Wed Jan 2 03: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 DAA00912 for ; Wed, 2 Jan 2002 03:36:29 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 0E20691213; Wed, 2 Jan 2002 03:36:15 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CA2C49124D; Wed, 2 Jan 2002 03:36: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 C3EDD91213 for ; Wed, 2 Jan 2002 03:36:13 -0500 (EST) Received: by segue.merit.edu (Postfix) id A45235DE13; Wed, 2 Jan 2002 03:36:13 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by segue.merit.edu (Postfix) with ESMTP id 112C05DE12 for ; Wed, 2 Jan 2002 03:36:13 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id g028aBJ05692; Wed, 2 Jan 2002 09:36:11 +0100 (MET) Received: from lmf.ericsson.se (lmf4ws450.lmf.ericsson.se [131.160.38.50]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g028aBhO004523; Wed, 2 Jan 2002 10:36:11 +0200 (EET) Message-ID: <3C32C67B.7B6FCFE2@lmf.ericsson.se> Date: Wed, 02 Jan 2002 10:36:11 +0200 From: Jari Arkko Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Bernard Aboba Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: [Issue] Error messages: decimal or hex? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit >Is an Informational error message 1000 - 1999 in DECIMAL? >Or is it 10000000 - 1FFFFFFF in HEX? Perhaps the hex variant is better, at least it saves a few ifs when testing for the error, and looks more logical. I propose however, that we do not consume the whole error code space today, and hence I would like to have hex-thousand ranges instead. I suggest the following new table for 7.1: - 0x1000..0x1FFFF (Informational) - 0x2000..0x2FFFF (Success) - 0x3000..0x3FFFF (Protocol Errors) - 0x4000..0x4FFFF (Transient Failures) - 0x5000..0x5FFFF (Permanent Failure) From owner-aaa-wg@merit.edu Wed Jan 2 03:39:09 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 DAA00933 for ; Wed, 2 Jan 2002 03:39:09 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7BDEE9124D; Wed, 2 Jan 2002 03:38:49 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3F7719124E; Wed, 2 Jan 2002 03:38: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 4395E9124D for ; Wed, 2 Jan 2002 03:38:48 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2A42F5DE13; Wed, 2 Jan 2002 03:38:48 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by segue.merit.edu (Postfix) with ESMTP id 644425DE12 for ; Wed, 2 Jan 2002 03:38:47 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id g028ckJ07334; Wed, 2 Jan 2002 09:38:46 +0100 (MET) Received: from lmf.ericsson.se (lmf4ws450.lmf.ericsson.se [131.160.38.50]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g028ckhO004744; Wed, 2 Jan 2002 10:38:46 +0200 (EET) Message-ID: <3C32C715.5CE572E9@lmf.ericsson.se> Date: Wed, 02 Jan 2002 10:38:45 +0200 From: Jari Arkko Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Bernard Aboba Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: [Issue] References to ADIF in NASREQ-08 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit >Suggestion: strike "the ADIF Record of" Yes. Jari From owner-aaa-wg@merit.edu Wed Jan 2 04:02: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 EAA01136 for ; Wed, 2 Jan 2002 04:02:02 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B891C9124E; Wed, 2 Jan 2002 04:01:41 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 865769124F; Wed, 2 Jan 2002 04:01: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 415D89124E for ; Wed, 2 Jan 2002 04:01:40 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1DD925DE12; Wed, 2 Jan 2002 04:01:40 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by segue.merit.edu (Postfix) with ESMTP id 462775DDCC for ; Wed, 2 Jan 2002 04:01:39 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id g0291cK17514; Wed, 2 Jan 2002 10:01:38 +0100 (MET) Received: from lmf.ericsson.se (lmf4ws450.lmf.ericsson.se [131.160.38.50]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g0291bhO005990; Wed, 2 Jan 2002 11:01:37 +0200 (EET) Message-ID: <3C32CC71.4A4B6C75@lmf.ericsson.se> Date: Wed, 02 Jan 2002 11:01:37 +0200 From: Jari Arkko Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Bernard Aboba Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: [Issue] Normative versus Informative references References: Content-Type: multipart/mixed; boundary="------------85D53D84A32D7FC6FCB2AE19" Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. --------------85D53D84A32D7FC6FCB2AE19 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > RFC Editor has indicated that future RFCs will need to separate Normative > versus Informative references. Well, here's my first cut at separating these in two classes. (Where the base spec mandates some specific thing, and has a reference, then I have considered it as a Normative reference. If the reference is just used as a background for Diameter requirements I've considered it as Informative.) There's a few borderline cases. For instance, is the NASREQ application Normative from the point of view of the Base spec? Interestingly, there's a few references I can't find any use for... Jari --------------85D53D84A32D7FC6FCB2AE19 Content-Type: text/plain; charset=us-ascii; name="refs.txt" Content-Disposition: inline; filename="refs.txt" Content-Transfer-Encoding: 7bit BASE DRAFT REFERENCE CLASSIFICATION Informative: ============ [1] C. Rigney, A. Rubens, W. Simpson, S. Willens, "Remote Authentica- tion Dial In User Service (RADIUS)", RFC 2865, June 2000. [20] B. Aboba, G. Zorn, "Criteria for Evaluating Roaming Protocols", RFC 2477, January 1999. [21] M. Beadles, D. Mitton, "Criteria for Evaluating Network Access Server Protocols", RFC 3169, September 2001. [22] T. Hiller and al, "CDMA2000 Wireless Data Requirements for AAA", RFC 3141, June 2001. [23] S. Glass, S. Jacobs, C. Perkins, "Mobile IP Authentication, Autho- rization, and Accounting Requirements". RFC 2977. October 2000. [25] L. J. Blunk, J. R. Vollbrecht, "PPP Extensible Authentication Pro- tocol (EAP)." RFC 2284, March 1998. [40] B. Aboba, J. Arkko, D. Harrington. "Introduction to Accounting Man- agement", RFC 2975, October 2000. [42] W. Simpson, "The Point-to-Point Protocol (PPP)", RFC 1661, STD 51, July 1994. [43] B. Aboba, J. Lu, J. Alsop, J. Ding, W. Wang, "Review of Roaming Implementations", RFC 2194, September 1997. [44] B. Aboba, J. Vollbrecht, "Proxy Chaining and Policy Implementation in Roaming", RFC 2607, June 1999. [45] C. Perkins, Editor. IP Mobility Support. RFC 2002, October 1996. Probable informative, not sure: =============================== [7] P. Calhoun, W. Bulley, A. Rubens, J. Haag, "Diameter NASREQ Appli- cation", draft-ietf-aaa-diameter-nasreq-08.txt, IETF work in progress, November 2001. [10] P. Calhoun, C. Perkins, "Diameter Mobile IP Application", draft- ietf-aaa-diameter-mobileip-08.txt, IETF work in progress, November 2001. [31] D. Crocker, P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. Normative: ========== [2] Reynolds, Postel, "Assigned Numbers", RFC 1700, October 1994. [3] Postel, "User Datagram Protocol", RFC 768, August 1980. [11] P. Calhoun, W. Bulley, S. Farrell, "Diameter CMS Security applica- tion", draft-ietf-aaa-diameter-cms-sec-03.txt, IETF work in progress, November 2001. [8] Aboba, Beadles "The Network Access Identifier." RFC 2486. January 1999. [12] Narten, Alvestrand,"Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998 [13] S. Bradner, "Key words for use in RFCs to Indicate Requirement Lev- els", BCP 14, RFC 2119, March 1997. [15] D. Harkins, D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998. [41] A. Shacham, R. Monsour, R. Pereira, M. Thomas, "IP Payload Compres- sion Protocol (IPComp)", RFC 2393, December 1998. [16] Hinden, Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998. [17] ISI, "Internet Protocol", RFC 791, September 1981. [18] Mills, "Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI, RFC 2030, October 1996. [24] F. Yergeau, "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998. [26] R. Stewart et al., "Stream Control Transmission Protocol". RFC 2960. October 2000. [27] Postel, J. "Transmission Control Protocol", RFC 793, January 1981. [28] E. Guttman, C. Perkins, J. Veizades, M. Day. "Service Location Pro- tocol, Version 2", RFC 2165, June 1999. [29] T. Berners-Lee, R. Fielding, U.C. Irvine, L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax". RFC 2396, August 1998. [30] Institute of Electrical and Electronics Engineers, "IEEE Standard for Binary Floating-Point Arithmetic", ANSI/IEEE Standard 754-1985, August 1985. [32] E. Guttman, C. Perkins, J. Kempf, "Service Templates and Service: Schemes", RFC 2609, June 1999. [33] A. Gulbrandsen, P. Vixie, L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000. [34] D. Eastlake, "Domain Name System Security Extensions", RFC 2535, March 1999. [35] D. Eastlake, "DNS Security Operational Considerations", RFC 2541, March 1999. [36] D. Eastlake, "DNS Request and Transaction Signatures ( SIG(0)s )", RFC 2931, September 2000. [37] S. Kent, R. Atkinson, "Security Architecture for the Internet Pro- tocol", RFC 2401, November 1998. [38] T. Dierks, C. Allen, "The TLS Protocol Version 1.0", RFC 2246, Jan- uary 1999. [46] IANA, "RADIUS Types", http://www.isi.edu/in-notes/iana/assign- ments/radius-types [47] IANA, "Number assignment", http://www.iana.org [49] K. Nichols, S. Blake, F. Baker, D. Black, "Definition of the Dif- ferentiated Services Field (DS Field) in the IPv4 and IPv6 Head- ers," RFC 2474, December 1998. [50] J. Heinanen, F. Baker, W. Weiss, J. Wroclawski, "Assured Forwarding PHB Group," RFC 2597, June 1999. [51] V. Jacobson, K. Nichols, K. Poduri, "An Expedited Forwarding PHB", RFC 2598, June 1999. [52] B. Aboba, J. Wood, "Authentication, Authorization and Accounting (AAA) Transport Profile", draft-ietf-aaa-transport-04.txt, IETF Work in Progress, June 2001. Seem unnecessary (quick search didn't reveal references): ========================================================= [4] Rivest, "The MD5 Message-Digest Algorithm", RFC 1321, April 1992. [5] Kaufman, Perlman, Speciner, "Network Security: Private Communica- tions in a Public World", Prentice Hall, March 1995, ISBN 0-13-061466-1. [6] Krawczyk, Bellare, Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, January 1997. [14] Myers, Ankney, Malpani, Galperin, Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol (OCSP)", RFC 2560, June 1999. [19] Housley, Ford, Polk, Solo, "Internet X.509 Public Key Infrastruc- ture Certificate and CRL Profile", RFC 2459, January 1999. [39] "The Communications of the ACM" Vol.33, No.6 (June 1990), pp. 677-680. [48] P. V. Mockapetris, "Domain names - implementation and specifica- tion," RFC 1035, November 1987. --------------85D53D84A32D7FC6FCB2AE19-- From owner-aaa-wg@merit.edu Wed Jan 2 04:50: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 EAA01572 for ; Wed, 2 Jan 2002 04:50:04 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2A6509124F; Wed, 2 Jan 2002 04:49:43 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E63FE91250; Wed, 2 Jan 2002 04:49: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 EC5B99124F for ; Wed, 2 Jan 2002 04:49:41 -0500 (EST) Received: by segue.merit.edu (Postfix) id BDEB15DE1C; Wed, 2 Jan 2002 04:49:41 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by segue.merit.edu (Postfix) with ESMTP id 021475DE12 for ; Wed, 2 Jan 2002 04:49:40 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id g029neJ09171; Wed, 2 Jan 2002 10:49:40 +0100 (MET) Received: from lmf.ericsson.se (lmf4ws450.lmf.ericsson.se [131.160.38.50]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g029ndhO009063; Wed, 2 Jan 2002 11:49:39 +0200 (EET) Message-ID: <3C32D7B3.C89348C6@lmf.ericsson.se> Date: Wed, 02 Jan 2002 11:49:39 +0200 From: Jari Arkko Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Bernard Aboba , aaa-wg@merit.edu Subject: Re: [AAA-WG]: [Issue] Error messages: decimal or hex? References: <3C32C67B.7B6FCFE2@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Uh... a small correction: - 0x1000..0x1FFF (Informational) - 0x2000..0x2FFF (Success) - 0x3000..0x3FFF (Protocol Errors) - 0x4000..0x4FFF (Transient Failures) - 0x5000..0x5FFF (Permanent Failure) From owner-aaa-wg@merit.edu Wed Jan 2 07:57: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 HAA03189 for ; Wed, 2 Jan 2002 07:57:57 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 4CFF091254; Wed, 2 Jan 2002 07:57:36 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 109E591255; Wed, 2 Jan 2002 07:57: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 0678991254 for ; Wed, 2 Jan 2002 07:57:35 -0500 (EST) Received: by segue.merit.edu (Postfix) id DAB655DE1F; Wed, 2 Jan 2002 07:57:34 -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 2FE6F5DE1E for ; Wed, 2 Jan 2002 07:57:34 -0500 (EST) Received: from fredrikj (hotel-14.local.ipunplugged.com [192.168.8.14]) by mailgw.ipunplugged.com (8.9.3/8.9.3) with SMTP id NAA14894; Wed, 2 Jan 2002 13:56:11 +0100 From: "Fredrik Johansson" To: "Bernard Aboba" , Subject: RE: [AAA-WG]: [Issue] TLS usage issues Date: Wed, 2 Jan 2002 13:58:06 +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 Importance: Normal In-Reply-To: Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit what about using TLS between two diameter servers, one of them has to act as a tls client and the other as a tls server. Or should we only use IPsec between diameter servers? /fredrik >-----Original Message----- >From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of >Bernard Aboba >Sent: den 29 december 2001 22:00 >To: aaa-wg@merit.edu >Subject: [AAA-WG]: [Issue] TLS usage issues > > >Submitter: Bernard Aboba >Date: December 28, 2001 >Reference: >Document: BASE-08 >Comment type: T >Priority: S >Section: 2.2 >Rationale/Explanation of issue: >There is no discussion of how TLS authentication is used with >Diameter. For example: > > a. Are both peers required to support certificates? > b. If not, how is it decided which peer authenticates to who? > >Proposed change: > >Add: > >"Diameter clients act as TLS clients according to [RFC2246], and Diameter >servers act as TLS servers. Diameter clients and servers implementing >TLS for security MUST mutually authenticate as part of TLS session >establishment. In order to ensure mutual authentication, Diameter servers >MUST request certificates from Diameter clients, and the client MUST be >prepared to supply a certificate on request." > From owner-aaa-wg@merit.edu Wed Jan 2 08:47: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 IAA03982 for ; Wed, 2 Jan 2002 08:47:36 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3C80391258; Wed, 2 Jan 2002 08:47:20 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0A53891259; Wed, 2 Jan 2002 08:47: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 25C8391258 for ; Wed, 2 Jan 2002 08:47:16 -0500 (EST) Received: by segue.merit.edu (Postfix) id F087B5DDBD; Wed, 2 Jan 2002 08:47:15 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by segue.merit.edu (Postfix) with ESMTP id 124AD5DD94 for ; Wed, 2 Jan 2002 08:47:15 -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.11.0/8.11.0/WIREfire-1.3) with SMTP id g02DlEJ04475 for ; Wed, 2 Jan 2002 14:47:14 +0100 (MET) Received: FROM esealnt743.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Wed Jan 02 14:46:58 2002 +0100 Received: by ESEALNT743.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 2 Jan 2002 14:47:12 +0100 Message-ID: <577066326047D41180AC00508B955DDA05ED1C14@eestqnt104.es.eu.ericsson.se> From: "Miguel-Angel Pallares-Lopez (ECE)" To: aaa-wg@merit.edu Subject: [AAA-WG]: [Issue] Qualifier of Vendor-Specific-Application-Id in CEA Date: Wed, 2 Jan 2002 14:47:01 +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 Submitter: Miguel-Angel Pallares E-mail address: miguel-angel.pallares-lopez@ece.ericsson.se Date: January 2, 2002 Type: E Priority: 1 Document: Base -08 Section: 5.3.2 Rationale: The qualifier for Vendor-Specific-Application-Id AVP in CEA should be "*", as in CER. Change in definition of CEA in 5.3.2, from: [ Vendor-Specific-Application-Id ] to: * [ Vendor-Specific-Application-Id ] From owner-aaa-wg@merit.edu Wed Jan 2 08:56: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 IAA04122 for ; Wed, 2 Jan 2002 08:56:02 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E8C0B9125C; Wed, 2 Jan 2002 08:55:45 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id ADE619125E; Wed, 2 Jan 2002 08:55: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 451569125C for ; Wed, 2 Jan 2002 08:55:40 -0500 (EST) Received: by segue.merit.edu (Postfix) id 222A45DE20; Wed, 2 Jan 2002 08:55:30 -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 EC5165DE14 for ; Wed, 2 Jan 2002 08:55:29 -0500 (EST) Received: from interlinknetworks.com (nat.interlinknetworks.com [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with ESMTP id 912456C for ; Wed, 2 Jan 2002 08:55:14 -0500 (EST) Message-ID: <3C331130.8D80FB7D@interlinknetworks.com> Date: Wed, 02 Jan 2002 08:54:56 -0500 From: Don Zick X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: aaa-wg@merit.edu Subject: Re: [AAA-WG]: [Issue] TLS usage issues References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit I agree with the proposed changes. I'd also like to see some comments concerning TLS cipher suites. I don't think that Diameter implementations should be required to support all TLS cipher suites listed in RFC 2246. Not all cipher suites are supported by available TLS tool kits and one cipher suite contains the proprietary IDEA encryption algorithm that you have to get permission to use. Therefore, to ensure inter operability, I think it is necessary to specify which cipher suites must be supported. Proposed change: Add: Diameter nodes must be able to negotiate the following TLS cipher suites: TLS_RSA_WITH_RC4_128_MD5 TLS_RSA_WITH_RC4_128_SHA TLS_RSA_WITH_3DES_EDE_CBC_SHA Bernard Aboba wrote: > Submitter: Bernard Aboba > Date: December 28, 2001 > Reference: > Document: BASE-08 > Comment type: T > Priority: S > Section: 2.2 > Rationale/Explanation of issue: > There is no discussion of how TLS authentication is used with > Diameter. For example: > > a. Are both peers required to support certificates? > b. If not, how is it decided which peer authenticates to who? > > Proposed change: > > Add: > > "Diameter clients act as TLS clients according to [RFC2246], and Diameter > servers act as TLS servers. Diameter clients and servers implementing > TLS for security MUST mutually authenticate as part of TLS session > establishment. In order to ensure mutual authentication, Diameter servers > MUST request certificates from Diameter clients, and the client MUST be > prepared to supply a certificate on request." From owner-aaa-wg@merit.edu Wed Jan 2 09:32: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 JAA04653 for ; Wed, 2 Jan 2002 09:32:08 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 6755D9125B; Wed, 2 Jan 2002 09:31:48 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2AF3A9125A; Wed, 2 Jan 2002 09:31: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 310BF91248 for ; Wed, 2 Jan 2002 09:31:47 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0B9955DE14; Wed, 2 Jan 2002 09:31: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 47D895DDBD for ; Wed, 2 Jan 2002 09:31:46 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id GAA67680; Wed, 2 Jan 2002 06:17:30 -0800 (PST) (envelope-from aboba@internaut.com) Date: Wed, 2 Jan 2002 06:17:30 -0800 (PST) From: Bernard Aboba To: Jari Arkko Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: [Issue] Normative versus Informative references In-Reply-To: <3C32CC71.4A4B6C75@lmf.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Question: Why is the reference to SNTP [18] normative? Does Diameter require time synchronization? If so, does it need *secure* time? Similarly, why the normative reference to DNS TSIG [36] and other DNS Security RFCs? In general, normative references relate to MAY, SHOULD, MUST, MUST NOT, etc. clauses in the spec. On Wed, 2 Jan 2002, Jari Arkko wrote: > > > RFC Editor has indicated that future RFCs will need to separate Normative > > versus Informative references. > > Well, here's my first cut at separating these in two classes. > (Where the base spec mandates some specific thing, and has > a reference, then I have considered it as a Normative reference. > If the reference is just used as a background for Diameter > requirements I've considered it as Informative.) > > There's a few borderline cases. For instance, is the > NASREQ application Normative from the point of view of > the Base spec? > > Interestingly, there's a few references I can't find any > use for... > > Jari From owner-aaa-wg@merit.edu Wed Jan 2 09:40: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 JAA04743 for ; Wed, 2 Jan 2002 09:40:30 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 66EC59125A; Wed, 2 Jan 2002 09:40:10 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 38C159125D; Wed, 2 Jan 2002 09:40: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 4F2209125A for ; Wed, 2 Jan 2002 09:40:09 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2FE475DE14; Wed, 2 Jan 2002 09:40:09 -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 64BB35DDBD for ; Wed, 2 Jan 2002 09:40:08 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id GAA67694; Wed, 2 Jan 2002 06:25:49 -0800 (PST) (envelope-from aboba@internaut.com) Date: Wed, 2 Jan 2002 06:25:49 -0800 (PST) From: Bernard Aboba To: Fredrik Johansson Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: [Issue] TLS usage issues In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > what about using TLS between two diameter servers, one of them has to act as > a tls client and the other as a tls server. Or should we only use IPsec > between diameter servers? > > /fredrik Since the spec says that TLS MUST be implemented by Diameter Servers, it's a reasonable question to ask how two servers would use it to secure their communication. Perhaps the Diameter peer originating the connection always acts as the TLS client? That way, you can leverage the existing election procedure. I'm also interested in what authentication modes are used, both for TLS and IPsec. Are we assuming that both sides in the TLS conversation use certificates to authenticate? This isn't stated in the spec. If not, then how is the TLS client authenticated? For IPsec, pre-shared keys are probably a viable (though not particularly scalable) authentication mode, but we need to clarify the identities used to determine the appropriate pre-shared key. Is this just the IP address? If so, then Main Mode is ok, no need for aggressive mode. If other identity payloads can be used (e.g. NAS-Identifier), then we should probably articulate what those are. From owner-aaa-wg@merit.edu Wed Jan 2 09:57: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 JAA05048 for ; Wed, 2 Jan 2002 09:57:13 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A819C9125D; Wed, 2 Jan 2002 09:57:02 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 75E6F9125E; Wed, 2 Jan 2002 09:57: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 8422E9125D for ; Wed, 2 Jan 2002 09:57:01 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5E3F25DE14; Wed, 2 Jan 2002 09:57:01 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by segue.merit.edu (Postfix) with ESMTP id 97D365DDBD for ; Wed, 2 Jan 2002 09:57:00 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id g02EuxK22181; Wed, 2 Jan 2002 15:56:59 +0100 (MET) Received: from lmf.ericsson.se (lmf4ws450.lmf.ericsson.se [131.160.38.50]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g02EuxhO027422; Wed, 2 Jan 2002 16:56:59 +0200 (EET) Message-ID: <3C331FBB.29B2E661@lmf.ericsson.se> Date: Wed, 02 Jan 2002 16:56:59 +0200 From: Jari Arkko Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Bernard Aboba Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: [Issue] Normative versus Informative references 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 Aboba wrote: > Why is the reference to SNTP [18] normative? Does Diameter require time > synchronization? If so, does it need *secure* time? [S stands for Simple, not Secure.] But the reason why I thought this should be normative was that section 4.4, under "Time", describes that our Time Format AVP values have some relationship to the format used in SNTP. The text also indicates that there's an extension mechanism described in the SNTP RFC that allows you to go beyond year 2036. Strangely, the text doesn't really say whether DIAMETER nodes MUST/MAY/SHOULD support this mechanism. I'm also not quite sure about the "some relationship" part, we simply state "containing the four most significant octets returned from NTP [18], in network byte order". This also seems a bit strange definition. Perhaps we should say "MUST contain a time value in the format defined in Section 3 of [18]"? > Similarly, why the normative reference to DNS TSIG [36] and other DNS > Security RFCs? Section 5.2 states that "it is prudent to employ DNS Security as a precaution". I'm pretty sure "it is prudent" is not a term in RFC 2119... I'm less sure whether we should change it to a MAY or or move the references to informative... Jari From owner-aaa-wg@merit.edu Wed Jan 2 09: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 JAA05081 for ; Wed, 2 Jan 2002 09:59:22 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2BA2B9125E; Wed, 2 Jan 2002 09:59:11 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E98BC9125F; Wed, 2 Jan 2002 09:59: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 0BB509125E for ; Wed, 2 Jan 2002 09:59:10 -0500 (EST) Received: by segue.merit.edu (Postfix) id E20C35DE14; Wed, 2 Jan 2002 09:59:09 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by segue.merit.edu (Postfix) with ESMTP id 25EE35DDBD for ; Wed, 2 Jan 2002 09:59:09 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id g02Ex8K22833; Wed, 2 Jan 2002 15:59:08 +0100 (MET) Received: from lmf.ericsson.se (lmf4ws450.lmf.ericsson.se [131.160.38.50]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g02Ex7hO027453; Wed, 2 Jan 2002 16:59:07 +0200 (EET) Message-ID: <3C33203C.EB40FE94@lmf.ericsson.se> Date: Wed, 02 Jan 2002 16:59:08 +0200 From: Jari Arkko Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Bernard Aboba Cc: Fredrik Johansson , aaa-wg@merit.edu Subject: Re: [AAA-WG]: [Issue] TLS usage issues 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 Aboba wrote: > I'm also interested in what authentication modes are used, both for TLS > and IPsec. Are we assuming that both sides in the TLS conversation use > certificates to authenticate? This isn't stated in the spec. If not, then > how is the TLS client authenticated? Web-like one-sided auth followed by client auth is not really appropriate here. We must require that both sides use certs. Jari From owner-aaa-wg@merit.edu Wed Jan 2 10:26: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 KAA05580 for ; Wed, 2 Jan 2002 10:26:13 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DE97091262; Wed, 2 Jan 2002 10:26:02 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AC21891264; Wed, 2 Jan 2002 10:26: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 E783991262 for ; Wed, 2 Jan 2002 10:26:00 -0500 (EST) Received: by segue.merit.edu (Postfix) id BC49A5DE14; Wed, 2 Jan 2002 10:26:00 -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 F24C35DDBD for ; Wed, 2 Jan 2002 10:25:59 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id HAA67760; Wed, 2 Jan 2002 07:11:44 -0800 (PST) (envelope-from aboba@internaut.com) Date: Wed, 2 Jan 2002 07:11:43 -0800 (PST) From: Bernard Aboba To: Jari Arkko Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: [Issue] Normative versus Informative references In-Reply-To: <3C331FBB.29B2E661@lmf.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > But the reason why I thought this should be normative was > that section 4.4, under "Time", describes that our Time Format > AVP values have some relationship to the format used in SNTP. OK. > The text also indicates that there's an extension mechanism > described in the SNTP RFC that allows you to go beyond year > 2036. Strangely, the text doesn't really say whether DIAMETER > nodes MUST/MAY/SHOULD support this mechanism. We should probably clarify this (can you open an issue?). We expect Diameter to be around a while ;) > I'm also not quite sure about the "some relationship" part, > we simply state "containing the four most significant octets > returned from NTP [18], in network byte order". This also > seems a bit strange definition. Perhaps we should say "MUST > contain a time value in the format defined in Section 3 of > [18]"? Is the reference to NTP or SNTP? > > > Similarly, why the normative reference to DNS TSIG [36] and other DNS > > Security RFCs? > > Section 5.2 states that "it is prudent to employ DNS Security > as a precaution". I'm pretty sure "it is prudent" is not a term > in RFC 2119... In general, RFC 2119 terms should be upper case, to avoid confusion. So "prudent" is not a normative term (e.g. not equivalent to SHOULD), and such references would therefore not be normative. From owner-aaa-wg@merit.edu Wed Jan 2 10:54: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 KAA05873 for ; Wed, 2 Jan 2002 10:54:36 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 4398391263; Wed, 2 Jan 2002 10:54:25 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0B4F091264; Wed, 2 Jan 2002 10:54: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 0539791263 for ; Wed, 2 Jan 2002 10:54:23 -0500 (EST) Received: by segue.merit.edu (Postfix) id D1E515DDE4; Wed, 2 Jan 2002 10:54:23 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by segue.merit.edu (Postfix) with ESMTP id 178665DDBD for ; Wed, 2 Jan 2002 10:54:23 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id g02FsMK05795; Wed, 2 Jan 2002 16:54:22 +0100 (MET) Received: from lmf.ericsson.se (lmf4ws450.lmf.ericsson.se [131.160.38.50]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g02FsLhO029731; Wed, 2 Jan 2002 17:54:21 +0200 (EET) Message-ID: <3C332D2D.6DB38645@lmf.ericsson.se> Date: Wed, 02 Jan 2002 17:54:21 +0200 From: Jari Arkko Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Bernard Aboba Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: [Issue] Normative versus Informative references References: Content-Type: multipart/mixed; boundary="------------BB1C207FC3A92E5BE09D4A5B" Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. --------------BB1C207FC3A92E5BE09D4A5B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Aboba wrote: > > The text also indicates that there's an extension mechanism > > described in the SNTP RFC that allows you to go beyond year > > 2036. Strangely, the text doesn't really say whether DIAMETER > > nodes MUST/MAY/SHOULD support this mechanism. > > We should probably clarify this (can you open an issue?). We expect > Diameter to be around a while ;) I'll do that. > > I'm also not quite sure about the "some relationship" part, > > we simply state "containing the four most significant octets > > returned from NTP [18], in network byte order". This also > > seems a bit strange definition. Perhaps we should say "MUST > > contain a time value in the format defined in Section 3 of > > [18]"? > > Is the reference to NTP or SNTP? Funny, the text says NTP and the reference is to SNTP... time for an issue... > > > Similarly, why the normative reference to DNS TSIG [36] and other DNS > > > Security RFCs? > > > > Section 5.2 states that "it is prudent to employ DNS Security > > as a precaution". I'm pretty sure "it is prudent" is not a term > > in RFC 2119... > > In general, RFC 2119 terms should be upper case, to avoid confusion. So > "prudent" is not a normative term (e.g. not equivalent to SHOULD), and > such references would therefore not be normative. OK, in that case we should simply put these things under the informative section. Here's a revised reference classification. However, we still need to work on the list: see for instance section 5.2 where various things such as SRV records and SLPv2 are referenced. I'm not sure what the specs actually say about these things. There's no MUST/MAY/SHOULDs anywhere, but a series of "recommendations". Personally, I'd prefer making it very explicit what is a mandatory requirement for DIAMETER and what is not. For instance, the first item in the list in 5.2 is propably a MUST item, while the others are MAY items? Jari --------------BB1C207FC3A92E5BE09D4A5B Content-Type: text/plain; charset=us-ascii; name="refs.txt" Content-Disposition: inline; filename="refs.txt" Content-Transfer-Encoding: 7bit BASE DRAFT REFERENCE CLASSIFICATION Informative: ============ [1] C. Rigney, A. Rubens, W. Simpson, S. Willens, "Remote Authentica- tion Dial In User Service (RADIUS)", RFC 2865, June 2000. [20] B. Aboba, G. Zorn, "Criteria for Evaluating Roaming Protocols", RFC 2477, January 1999. [21] M. Beadles, D. Mitton, "Criteria for Evaluating Network Access Server Protocols", RFC 3169, September 2001. [22] T. Hiller and al, "CDMA2000 Wireless Data Requirements for AAA", RFC 3141, June 2001. [23] S. Glass, S. Jacobs, C. Perkins, "Mobile IP Authentication, Autho- rization, and Accounting Requirements". RFC 2977. October 2000. [25] L. J. Blunk, J. R. Vollbrecht, "PPP Extensible Authentication Pro- tocol (EAP)." RFC 2284, March 1998. [34] D. Eastlake, "Domain Name System Security Extensions", RFC 2535, March 1999. [35] D. Eastlake, "DNS Security Operational Considerations", RFC 2541, March 1999. [36] D. Eastlake, "DNS Request and Transaction Signatures ( SIG(0)s )", RFC 2931, September 2000. [40] B. Aboba, J. Arkko, D. Harrington. "Introduction to Accounting Man- agement", RFC 2975, October 2000. [42] W. Simpson, "The Point-to-Point Protocol (PPP)", RFC 1661, STD 51, July 1994. [43] B. Aboba, J. Lu, J. Alsop, J. Ding, W. Wang, "Review of Roaming Implementations", RFC 2194, September 1997. [44] B. Aboba, J. Vollbrecht, "Proxy Chaining and Policy Implementation in Roaming", RFC 2607, June 1999. [45] C. Perkins, Editor. IP Mobility Support. RFC 2002, October 1996. Probable informative, not sure: =============================== [7] P. Calhoun, W. Bulley, A. Rubens, J. Haag, "Diameter NASREQ Appli- cation", draft-ietf-aaa-diameter-nasreq-08.txt, IETF work in progress, November 2001. [10] P. Calhoun, C. Perkins, "Diameter Mobile IP Application", draft- ietf-aaa-diameter-mobileip-08.txt, IETF work in progress, November 2001. [31] D. Crocker, P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. Normative: ========== [2] Reynolds, Postel, "Assigned Numbers", RFC 1700, October 1994. [3] Postel, "User Datagram Protocol", RFC 768, August 1980. [11] P. Calhoun, W. Bulley, S. Farrell, "Diameter CMS Security applica- tion", draft-ietf-aaa-diameter-cms-sec-03.txt, IETF work in progress, November 2001. [8] Aboba, Beadles "The Network Access Identifier." RFC 2486. January 1999. [12] Narten, Alvestrand,"Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998 [13] S. Bradner, "Key words for use in RFCs to Indicate Requirement Lev- els", BCP 14, RFC 2119, March 1997. [15] D. Harkins, D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998. [41] A. Shacham, R. Monsour, R. Pereira, M. Thomas, "IP Payload Compres- sion Protocol (IPComp)", RFC 2393, December 1998. [16] Hinden, Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998. [17] ISI, "Internet Protocol", RFC 791, September 1981. [18] Mills, "Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI, RFC 2030, October 1996. [24] F. Yergeau, "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998. [26] R. Stewart et al., "Stream Control Transmission Protocol". RFC 2960. October 2000. [27] Postel, J. "Transmission Control Protocol", RFC 793, January 1981. [28] E. Guttman, C. Perkins, J. Veizades, M. Day. "Service Location Pro- tocol, Version 2", RFC 2165, June 1999. [29] T. Berners-Lee, R. Fielding, U.C. Irvine, L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax". RFC 2396, August 1998. [30] Institute of Electrical and Electronics Engineers, "IEEE Standard for Binary Floating-Point Arithmetic", ANSI/IEEE Standard 754-1985, August 1985. [32] E. Guttman, C. Perkins, J. Kempf, "Service Templates and Service: Schemes", RFC 2609, June 1999. [33] A. Gulbrandsen, P. Vixie, L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000. [37] S. Kent, R. Atkinson, "Security Architecture for the Internet Pro- tocol", RFC 2401, November 1998. [38] T. Dierks, C. Allen, "The TLS Protocol Version 1.0", RFC 2246, Jan- uary 1999. [46] IANA, "RADIUS Types", http://www.isi.edu/in-notes/iana/assign- ments/radius-types [47] IANA, "Number assignment", http://www.iana.org [49] K. Nichols, S. Blake, F. Baker, D. Black, "Definition of the Dif- ferentiated Services Field (DS Field) in the IPv4 and IPv6 Head- ers," RFC 2474, December 1998. [50] J. Heinanen, F. Baker, W. Weiss, J. Wroclawski, "Assured Forwarding PHB Group," RFC 2597, June 1999. [51] V. Jacobson, K. Nichols, K. Poduri, "An Expedited Forwarding PHB", RFC 2598, June 1999. [52] B. Aboba, J. Wood, "Authentication, Authorization and Accounting (AAA) Transport Profile", draft-ietf-aaa-transport-04.txt, IETF Work in Progress, June 2001. Seem unnecessary (quick search didn't reveal references): ========================================================= [4] Rivest, "The MD5 Message-Digest Algorithm", RFC 1321, April 1992. [5] Kaufman, Perlman, Speciner, "Network Security: Private Communica- tions in a Public World", Prentice Hall, March 1995, ISBN 0-13-061466-1. [6] Krawczyk, Bellare, Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, January 1997. [14] Myers, Ankney, Malpani, Galperin, Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol (OCSP)", RFC 2560, June 1999. [19] Housley, Ford, Polk, Solo, "Internet X.509 Public Key Infrastruc- ture Certificate and CRL Profile", RFC 2459, January 1999. [39] "The Communications of the ACM" Vol.33, No.6 (June 1990), pp. 677-680. [48] P. V. Mockapetris, "Domain names - implementation and specifica- tion," RFC 1035, November 1987. --------------BB1C207FC3A92E5BE09D4A5B-- From owner-aaa-wg@merit.edu Wed Jan 2 11:18: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 LAA06250 for ; Wed, 2 Jan 2002 11:18:59 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B5F5691264; Wed, 2 Jan 2002 11:18:44 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8BE1D91265; Wed, 2 Jan 2002 11:18: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 A03AC91264 for ; Wed, 2 Jan 2002 11:18:43 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7F6BB5DE21; Wed, 2 Jan 2002 11:18:43 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by segue.merit.edu (Postfix) with ESMTP id BB79C5DE1A for ; Wed, 2 Jan 2002 11:18:42 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id g02GIfJ26436 for ; Wed, 2 Jan 2002 17:18:41 +0100 (MET) Received: from lmf.ericsson.se (lmf4ws450.lmf.ericsson.se [131.160.38.50]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g02GIbhO000708 for ; Wed, 2 Jan 2002 18:18:37 +0200 (EET) Message-ID: <3C3332DE.5C5D0234@lmf.ericsson.se> Date: Wed, 02 Jan 2002 18:18:38 +0200 From: Jari Arkko Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: aaa-wg@merit.edu Subject: [AAA-WG]: [Issue] SNTP referencing References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Submitter: Jari Arkko Date: January 2, 2002 Reference: Document: BASE-08 Comment type: T Priority: S Section: Rationale/Explanation of issue: Unclear reference to SNTP Current text reads as follows: The Time format is derived from the Unsigned32 AVP Base Format. This is 32 bit unsigned value containing the four most significant octets returned from NTP [18], in network byte order. This represent the number of seconds since 0h on 1 January 1900 with respect to the Coordinated Universal Time (UTC). On 6h 28m 16s UTC, 7 February 2036 the time value will overflow. NTP [18] describes a procedure to extend the time to 2104. This has two problems. First, it is unclear whether NTP or SNTP is meant and what format is really used. Second, we don't mandate the extension to year 2104. Also, I find it easier to explain the format issue if Time is derived from OctetString, not Unsigned32. Bits on the wire are not changed. Proposed change: The Time format is derived from the OctetString AVP Base Format. The string MUST contain four octets, in the same format as the four first bytes are in the NTP Timestamp Format. The NTP Timestamp format is defined in Chapter 3 of reference [18]. This represents the number of seconds since 0h on 1 January 1900 with respect to the Coordinated Universal Time (UTC). On 6h 28m 16s UTC, 7 February 2036 the time value will overflow. SNTP [18] describes a procedure to extend the time to 2104. This procedure MUST be used by all DIAMETER nodes. From owner-aaa-wg@merit.edu Wed Jan 2 11:28: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 LAA06380 for ; Wed, 2 Jan 2002 11:28:01 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id F131891266; Wed, 2 Jan 2002 11:27:49 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C10EA91267; Wed, 2 Jan 2002 11:27: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 CF35E91266 for ; Wed, 2 Jan 2002 11:27:47 -0500 (EST) Received: by segue.merit.edu (Postfix) id A45E95DE22; Wed, 2 Jan 2002 11:27:47 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by segue.merit.edu (Postfix) with ESMTP id 194785DE21 for ; Wed, 2 Jan 2002 11:27:47 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id g02GRkK11938 for ; Wed, 2 Jan 2002 17:27:46 +0100 (MET) Received: from lmf.ericsson.se (lmf4ws450.lmf.ericsson.se [131.160.38.50]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g02GRghO001086 for ; Wed, 2 Jan 2002 18:27:42 +0200 (EET) Message-ID: <3C3334FE.69BC4328@lmf.ericsson.se> Date: Wed, 02 Jan 2002 18:27:42 +0200 From: Jari Arkko Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: aaa-wg@merit.edu Subject: [AAA-WG]: [Issue] Peer discovery mechanism requirements Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Submitter: Jari Arkko Date: January 2, 2002 Reference: Document: BASE-08 Comment type: T Priority: S Section: 5.2 Rationale/Explanation of issue: Current text does not clearly enough specify which peer discovery mechanisms are mandatory and which are not. There's two approaches to handling this issue. One, (apparently the current approach) we stay clear of using MUST/SHOULD/MAY in section 5.2 and therefore all of the text falls to Informative, and nothing is really mandated. The second approach is that we explicitly state what DIAMETER nodes MUST/SHOULD/MAY be capable of in this area. I favor the latter approach. Proposed change: Indicate in the list under 5.2 that the first option (manual configuration) MUST be supported by all DIAMETER nodes, while the latter two options (SRVLOC and DNS SRV records) MAY be supported. From owner-aaa-wg@merit.edu Wed Jan 2 11:46: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 LAA06887 for ; Wed, 2 Jan 2002 11:46:24 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 49BA091265; Wed, 2 Jan 2002 11:45:30 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1FA6191267; Wed, 2 Jan 2002 11:45: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 3806991265 for ; Wed, 2 Jan 2002 11:45:29 -0500 (EST) Received: by segue.merit.edu (Postfix) id 18BB35DE1F; Wed, 2 Jan 2002 11:45:29 -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 5B7AD5DDA1 for ; Wed, 2 Jan 2002 11:45:28 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id IAA67862; Wed, 2 Jan 2002 08:31:12 -0800 (PST) (envelope-from aboba@internaut.com) Date: Wed, 2 Jan 2002 08:31:12 -0800 (PST) From: Bernard Aboba To: Jari Arkko Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: [Issue] Normative versus Informative references In-Reply-To: <3C332D2D.6DB38645@lmf.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > There's no MUST/MAY/SHOULDs anywhere, but a series > of "recommendations". Personally, I'd prefer making it very > explicit what is a mandatory requirement for DIAMETER and what > is not. For instance, the first item in the list in 5.2 is > propably a MUST item, while the others are MAY items? Yes, I think that is a good idea. Otherwise, you could have some people implementing one thing (SRV), others another thing (SLPv2) and problems in interoperability. So this sounds like another issue. From owner-aaa-wg@merit.edu Wed Jan 2 11:57: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 LAA07069 for ; Wed, 2 Jan 2002 11:57:05 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D59AF91267; Wed, 2 Jan 2002 11:56:54 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A778991268; Wed, 2 Jan 2002 11:56: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 B3A7091267 for ; Wed, 2 Jan 2002 11:56:53 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9B6FF5DE20; Wed, 2 Jan 2002 11:56:53 -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 3A8D25DDA1 for ; Wed, 2 Jan 2002 11:56:53 -0500 (EST) Received: from ehdb03-home.Germany.Sun.COM ([129.157.142.202]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA02835; Wed, 2 Jan 2002 09:56:33 -0700 (MST) Received: from field (field [129.157.142.146]) by ehdb03-home.Germany.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v2.1p1) with SMTP id RAA10954; Wed, 2 Jan 2002 17:56:50 +0100 (MET) Date: Wed, 2 Jan 2002 17:56:22 +0100 (MET) From: Erik Guttman X-Sender: erikg@field To: Bernard Aboba Cc: Jari Arkko , aaa-wg@merit.edu Subject: Re: [AAA-WG]: [Issue] Normative versus Informative references In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk On Wed, 2 Jan 2002, Bernard Aboba wrote: > > There's no MUST/MAY/SHOULDs anywhere, but a series > > of "recommendations". Personally, I'd prefer making it very > > explicit what is a mandatory requirement for DIAMETER and what > > is not. For instance, the first item in the list in 5.2 is > > propably a MUST item, while the others are MAY items? > > Yes, I think that is a good idea. Otherwise, you could have some people > implementing one thing (SRV), others another thing (SLPv2) and problems in > interoperability. So this sounds like another issue. It is more important for the information to be available than for it to be used, from a requirements perspective. Thus, if we RECOMMEND that SRV records are set up and Diameter servers advertise themselves with SLPv2, there is a good chance that Diameter clients can find servers dynamically. Whether they do so is a policy and technical decision for the diameter client implementors. So I advocate: The location of Diamter servers SHOULD be made available through configuration of DNS SRV RRs and through Diameter servers advertising via SLPv2. A Diameter client MUST support manual configuration, and MAY additionally support configuration of Diameter server location via either DNS SRV RR lookup or SLPv2. Erik From owner-aaa-wg@merit.edu Wed Jan 2 13: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 NAA08278 for ; Wed, 2 Jan 2002 13:20:02 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D9A2491217; Wed, 2 Jan 2002 13:19:41 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A7B8B9121A; Wed, 2 Jan 2002 13:19: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 9D49F91217 for ; Wed, 2 Jan 2002 13:19:40 -0500 (EST) Received: by segue.merit.edu (Postfix) id 809E15DE1A; Wed, 2 Jan 2002 13:19:40 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from fep02-app.kolumbus.fi (fep02-0.kolumbus.fi [193.229.0.44]) by segue.merit.edu (Postfix) with ESMTP id A0CBA5DDA1 for ; Wed, 2 Jan 2002 13:19:39 -0500 (EST) Received: from jariws1 ([62.248.238.9]) by fep02-app.kolumbus.fi (InterMail vM.5.01.03.08 201-253-122-118-108-20010628) with SMTP id <20020102181938.AJT3377.fep02-app.kolumbus.fi@jariws1>; Wed, 2 Jan 2002 20:19:38 +0200 Message-ID: <009c01c193ba$0b7e20e0$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: "Erik Guttman" , "Bernard Aboba" Cc: "Jari Arkko" , References: Subject: Re: [AAA-WG]: [Issue] Normative versus Informative references Date: Wed, 2 Jan 2002 20:19:40 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Erik Guttman wrote: > The location of Diamter servers SHOULD be made available > through configuration of DNS SRV RRs and through Diameter > servers advertising via SLPv2. A Diameter client MUST > support manual configuration, and MAY additionally support > configuration of Diameter server location via either DNS SRV > RR lookup or SLPv2. Good point. Agreed. Jari From owner-aaa-wg@merit.edu Wed Jan 2 14:22: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 OAA08961 for ; Wed, 2 Jan 2002 14:22:23 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3BCA49121F; Wed, 2 Jan 2002 14:22:06 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0FD1891224; Wed, 2 Jan 2002 14:22: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 1FEC89121F for ; Wed, 2 Jan 2002 14:22:05 -0500 (EST) Received: by segue.merit.edu (Postfix) id 06D015DDCF; Wed, 2 Jan 2002 14:22: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 E30825DD9C for ; Wed, 2 Jan 2002 14:22:04 -0500 (EST) Received: from interlinknetworks.com (nat.interlinknetworks.com [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with ESMTP id 88A246C for ; Wed, 2 Jan 2002 14:22:04 -0500 (EST) Message-ID: <3C335DCA.130B06B9@interlinknetworks.com> Date: Wed, 02 Jan 2002 14:21:46 -0500 From: Don Zick X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: aaa-wg@merit.edu Subject: [AAA-WG]: CMS Security TTL questions Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit From Section 1.3 of the Diameter CMS Security Application draft 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 if it needs the DSA to remain active. > Okay, so the access device can re-issue a PDSR to re-establish a DSA prior to expiration. >... >An optimized approach also allows the PDSR to be sent by the access >device without the DSAR-Target-Realm AVP. This message is used to >inform the proxy that it MUST establish a Diameter security >association for all realms it will be communicating with on behalf of >the access device. DSAs are typically established once the first >request for a given realm has been recelived by the proxy agent, but >it MAY establish certain DSAs with known realm in advance. What should TTL be set to in the PDSA in this case? > >If a DSA for a given realm cannot be established, the proxy agent >MUST reject the access device's request, and set the Result-Code AVP >to DIAMETER_NO_DSA_ESTABLISHED. Although the proxy agent MAY receive >many PDSRs from access devices, only one DSA per realm MUST be >established. Furthermore, the proxy is responsible for re- >establishing the DSA prior to expiration without any involvement by >the access device. It is the proxy's responsibility to re-establish a DSA prior to expiration? Isn't this inconsistent with what was stated in the first paragraph above? Thanks, Don From owner-aaa-wg@merit.edu Wed Jan 2 15:29: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 PAA10204 for ; Wed, 2 Jan 2002 15:29:49 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A568D91225; Wed, 2 Jan 2002 15:29:37 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7558791226; Wed, 2 Jan 2002 15:29: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 7741391225 for ; Wed, 2 Jan 2002 15:29:36 -0500 (EST) Received: by segue.merit.edu (Postfix) id 453D65DDA8; Wed, 2 Jan 2002 15:29:36 -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 30C9F5DD9C for ; Wed, 2 Jan 2002 15:29:36 -0500 (EST) Received: from interlinknetworks.com (nat.interlinknetworks.com [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with ESMTP id 9CA3B6C for ; Wed, 2 Jan 2002 15:29:35 -0500 (EST) Message-ID: <3C336D9D.F2EADEEC@interlinknetworks.com> Date: Wed, 02 Jan 2002 15:29:17 -0500 From: Don Zick X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: aaa-wg@merit.edu Subject: [AAA-WG]: CMS Security certificate question Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit From Section 3.1 of the Diameter CMS Security Application draft 3: >Otherwise, the destination node returns the DSAA message which >contains: > > - TTL for this DSA (seconds) > - a chain of CA certificates (possibly empty) > - public key certificates for the Diameter servers in the realm, > all of which MUST validate up to one of the CA's contained in > the DSAR message, via the chain of CA certificates above; >.... Why should a DSAA ever contain more than one public key certificate? From Section 3.2: >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. Thanks, Don From owner-aaa-wg@merit.edu Wed Jan 2 15:35: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 PAA10317 for ; Wed, 2 Jan 2002 15:35:33 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 987B591226; Wed, 2 Jan 2002 15:35:22 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6E88991268; Wed, 2 Jan 2002 15:35: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 7688D91226 for ; Wed, 2 Jan 2002 15:35:21 -0500 (EST) Received: by segue.merit.edu (Postfix) id 464965DDA8; Wed, 2 Jan 2002 15:35:21 -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 33A675DD9C for ; Wed, 2 Jan 2002 15:35:21 -0500 (EST) Received: from interlinknetworks.com (nat.interlinknetworks.com [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with ESMTP id AB58D6C for ; Wed, 2 Jan 2002 15:35:20 -0500 (EST) Message-ID: <3C336EF6.271B345D@interlinknetworks.com> Date: Wed, 02 Jan 2002 15:35:02 -0500 From: Don Zick X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: aaa-wg@merit.edu Subject: [AAA-WG]: CMS Security DSA question Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit I know this issue has been raised before, but I don't know what the resolution is. If a DSA is set up between an access device and a realm, how do all of the servers in the realm share info about the DSA such as DSA-TTL, CA-Chain, AAA-Node-Cert, and OCSP-Nonce? Thanks, Don From owner-aaa-wg@merit.edu Wed Jan 2 16:18: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 QAA10945 for ; Wed, 2 Jan 2002 16:18:23 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2CAE691206; Wed, 2 Jan 2002 16:18:07 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E8A9291228; Wed, 2 Jan 2002 16:18: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 EA8F491206 for ; Wed, 2 Jan 2002 16:18:05 -0500 (EST) Received: by segue.merit.edu (Postfix) id CFEBA5DDFE; Wed, 2 Jan 2002 16:18: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 BCBB05DDA8 for ; Wed, 2 Jan 2002 16:18:05 -0500 (EST) Received: from interlinknetworks.com (nat.interlinknetworks.com [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with ESMTP id 6086B6C for ; Wed, 2 Jan 2002 16:18:05 -0500 (EST) Message-ID: <3C3378FA.BAD91BB@interlinknetworks.com> Date: Wed, 02 Jan 2002 16:17:47 -0500 From: Don Zick X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: aaa-wg@merit.edu Subject: [AAA-WG]: Diameter TLS certificates Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit The Diameter base draft does not address how to ensure that a Diameter node is using its own TLS certificate. It is important to ensure that a Diameter node is using its own TLS certificate so that if a single Diameter node becomes compromised, it won't break security for all of the other Diameter nodes. It is a common practice with TLS to put a node's identity into the certificate's subjectAltName dNSName field. The Diameter CMS Security Application takes this approach. Below is a section from the Diameter CMS Security Application draft 3: >3.2 Certificate Requirements > > Certificates used for the purposes of Diameter MUST conform to the > PKIX profile [4], and MUST also include a Diameter node's FQDN, which > is typically added in the Origin-Host AVP [1], as one of the values > of the subjectAltName extension of the Certificate. The FQDN is to > be encoded as a dNSName within the subjectAltName. > > For Diameter nodes (capable of acting as recipients for > confidentiality), the FQDN MUST be of the form > "Diameter-.". Other Diameter nodes MAY use this naming > scheme. Note that this naming constraint is for PKI purposes only, > and in no way restricts a Diameter's host name. Proposal: Make Diameter TLS have the same dNSName field requirements as the Diameter CMS Security Application. From owner-aaa-wg@merit.edu Wed Jan 2 16:49: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 QAA11624 for ; Wed, 2 Jan 2002 16:49:59 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 18C0D91228; Wed, 2 Jan 2002 16:49:50 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D4D2D91234; Wed, 2 Jan 2002 16:49: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 DCB0B91228 for ; Wed, 2 Jan 2002 16:49:48 -0500 (EST) Received: by segue.merit.edu (Postfix) id B62C65DDD0; Wed, 2 Jan 2002 16:49:48 -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 0710F5DDA1 for ; Wed, 2 Jan 2002 16:49:48 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id NAA68216; Wed, 2 Jan 2002 13:35:31 -0800 (PST) (envelope-from aboba@internaut.com) Date: Wed, 2 Jan 2002 13:35:31 -0800 (PST) From: Bernard Aboba To: Don Zick Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Diameter TLS certificates In-Reply-To: <3C3378FA.BAD91BB@interlinknetworks.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > The Diameter base draft does not address how to ensure that a Diameter > node is using its own TLS certificate. It is important to ensure that > a Diameter node is using its own TLS certificate so that if a single > Diameter node becomes compromised, it won't break security for all of > the other Diameter nodes. Yes, it would be a pity if we went through all this trouble just to give all NASen the same cert -- just like many RADIUS installations use the same shared secret for all RADIUS client-server pairs. I'd suggest at least a SHOULD for this. Can you write up an issue on this? From owner-aaa-wg@merit.edu Thu Jan 3 09:03: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 JAA01594 for ; Thu, 3 Jan 2002 09:03:37 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 346B191220; Thu, 3 Jan 2002 09:03:21 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 046A191227; Thu, 3 Jan 2002 09:03: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 EC30D91220 for ; Thu, 3 Jan 2002 09:03:19 -0500 (EST) Received: by segue.merit.edu (Postfix) id BDD6B5DDC0; Thu, 3 Jan 2002 09:03:19 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by segue.merit.edu (Postfix) with ESMTP id F3AE55DD8E for ; Thu, 3 Jan 2002 09:03:18 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id g03E3HJ21459; Thu, 3 Jan 2002 15:03:17 +0100 (MET) Received: from lmf.ericsson.se (lmf4ws450.lmf.ericsson.se [131.160.38.50]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g03E3GhO004581; Thu, 3 Jan 2002 16:03:16 +0200 (EET) Message-ID: <3C3464A4.A3ED7836@lmf.ericsson.se> Date: Thu, 03 Jan 2002 16:03:16 +0200 From: Jari Arkko Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Bernard Aboba Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: [Issue] Granting Access via Accounting 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. I have now merged some requested modifications to the accounting state table [1, 2, 3]. These requests included - Adding one-time service accounting entries. - Removing dependency on waiting for the ack from the server before granting service. I also did the same modification for the session disconnection. I also modified in addition the following: - An entry to deal with sending an interim record. - Renamed states in a more consistent manner. I have NOT dealt with the following [2] yet since I think more discussion is needed: - Sections 9.4 and 8.2 are in conflict. The former requires clients to store acct records during network outage, and the latter requires immediate sending. I'll file a separate issue on this. - Adding the capability for an accounting server to send an ASR to the Diameter client. [1] http://www.merit.edu/mail.archives/aaa-wg/msg02788.html [2] http://www.merit.edu/mail.archives/aaa-wg/msg02791.html [3] http://www.merit.edu/mail.archives/aaa-wg/msg02807.html State Event Action New State ------------------------------------------------------------- Idle Client or device requests send PendingE a one-time service accounting event req. and grant service Idle Client or device requests send PendingS a measurable length service accounting start req. and grant service Idle Accounting event request send Idle received, and successfully accounting processed. event answer Open Time to send an interim send PendingI record accounting interim req. Open Receive Interim Record send Open accounting answer Open The measurable length user send PendingD service terminated accounting stop req. and discon. user/device Open Accounting stop request send Idle received, and successfully accounting processed stop answer PendingE Successful accounting Idle event answer received PendingS Successful accounting Open start answer received PendingI Successful accounting Open interim answer received PendingD Successful accounting Idle stop answer received Jari From owner-aaa-wg@merit.edu Thu Jan 3 10:29: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 KAA03887 for ; Thu, 3 Jan 2002 10:29:55 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 87A759122A; Thu, 3 Jan 2002 10:29:39 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5BB6291270; Thu, 3 Jan 2002 10:29: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 6DD5A9122A for ; Thu, 3 Jan 2002 10:29:38 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4FDB55DDE0; Thu, 3 Jan 2002 10:29:38 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by segue.merit.edu (Postfix) with ESMTP id 8B1B75DD8E for ; Thu, 3 Jan 2002 10:29:37 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id g03FTaJ06187 for ; Thu, 3 Jan 2002 16:29:36 +0100 (MET) Received: from lmf.ericsson.se (lmf4ws450.lmf.ericsson.se [131.160.38.50]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g03FDHhO009090 for ; Thu, 3 Jan 2002 17:13:17 +0200 (EET) Message-ID: <3C34750D.8C2F5299@lmf.ericsson.se> Date: Thu, 03 Jan 2002 17:13:17 +0200 From: Jari Arkko Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: aaa-wg@merit.edu Subject: [AAA-WG]: [Issue] Network outages and acct state machine References: <3C3464A4.A3ED7836@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Submitter: Jari Arkko Date: January 3, 2002 Reference: Document: BASE-08 Comment type: T Priority: S Section: 8.2 Rationale/Explanation of issue: Sections 9.4 and 8.2 are in conflict. The former requires clients to store acct records during network outage, and the latter requires immediate sending. The specification is also silent on how the client devices know whether it should grant access during times of network outages towards the accounting server. I can imagine that in some cases we would like to stop services if we can't provide real-time accounting, while in some other cases we would like to continue. Furthermore, the state machine in 8.2 (as well as the one that I just posted) does not specify what to do when things happen to the session faster than what it takes for an ack to come back from the server. For instance, what should we do if the session is terminated while we are still waiting for the start ack? Proposed change: An AVP similar to the Accounting-Interim-Interval could be used to control whether access should be granted or discontinued upon problems in sending the accounting records. The state machine must be modified to consider what to do with session termination and interim record generation while we are still waiting to send previous data. 9.8.x. Accounting-Realtime-Required AVP The Accounting-Realtime-Required AVP (AVP Code TBD) is of type Enumerated and is sent from the Diameter home authorization server to the Diameter client. The client uses information in this AVP to decide what to do if the sending of accounting records to the accounting server has been temporarily prevented due to, for instance, a network problem. DELIVER_AND_GRANT 1 The AVP with Value field set to DELIVER_AND_GRANT means that the service MUST only be granted as long as there is a connection to an accounting server. Note that the set of alternative accounting servers are treated as one server in this sense. Having to move the accounting record stream to a backup server is not a reason to discontinue the service to the user. GRANT_AND_STORE 2 The AVP with Value field set to GRANT_AND_STORE means that service SHOULD be granted if there is a connection, or as long as records can still be stored as described in section 9.4. This is the default behaviour if the AVP isn't included in the reply from the authorization server. GRANT_AND_LOSE 3 The AVP with Value field set to GRANT_AND_LOSE means that service SHOULD be granted even if the records can not be delivered or stored. 8.2. Accounting State Machine Add the following new entries: PendingE Failure to send and buffer Store Idle space available Event Record PendingE Failure to send and no buffer Idle space available 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 PendingD Failure to send and buffer Store Idle space available Stop Record PendingD Failure to send and no buffer Idle space available Idle Records in storage Send PendingB record PendingB Successful accounting answer Delete Idle received record From owner-aaa-wg@merit.edu Thu Jan 3 12:50: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 MAA06878 for ; Thu, 3 Jan 2002 12:50:00 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 0D0DB9122D; Thu, 3 Jan 2002 12:49:49 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CF3089122E; Thu, 3 Jan 2002 12:49: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 DD3649122D for ; Thu, 3 Jan 2002 12:49:47 -0500 (EST) Received: by segue.merit.edu (Postfix) id B46945DE16; Thu, 3 Jan 2002 12:49: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 967335DE0A for ; Thu, 3 Jan 2002 12:49:46 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id JAA69518; Thu, 3 Jan 2002 09:35:24 -0800 (PST) (envelope-from aboba@internaut.com) Date: Thu, 3 Jan 2002 09:35:24 -0800 (PST) From: Bernard Aboba To: Jari Arkko Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: [Issue] Network outages and acct state machine In-Reply-To: <3C34750D.8C2F5299@lmf.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > The former requires clients to store acct > records during network outage, and the > latter requires immediate sending. Here "network outage" means that absence of any connection in a usable state, correct? Since the transport spec prohibits sending on closed or suspect connections, if there is no connection that can be used, then "immediate sending" is not an option. > The specification is also silent on > how the client devices know whether > it should grant access during times > of network outages towards the accounting > server. There's an even bigger issue. The spec doesn't do a good job of differentating between "accounting servers" and servers that support Diameter base (which now includes accounting). Accounting and authentication now operate on the same port, and if I read the spec correctly on page 17, it states that Accounting does not have an Application Identifier because it is part of Base and therefore support is mandatory. I think this may confuse "mandatory to implement" with "mandatory to use". This means there is no way for a Diameter Server *not* to advertise accounting capabilities! This appears to be contradicted by section 5.3.1 on page 51, where the CER can include Acct-Application-Id. On page 19, it does indicate that a route entry can have a different destination based on the Acct-Application-Id or Auth-Application-Id. So presumably if this can be exchanged in the CER, then it can be used in routing. Since I envisage that the NAS will in most cases be dealing with a relay which advertises *, in practice it seems like both accounting and auth will flow over the same connection from NAS to relay, and then will be separately routed by the relay. Thus, there will typically be "fate sharing" between the two services on the first hop. Thus the notion of "primary" in the transport spec really means "primary for a given Acct-Application-Id or Auth-Application-Id." This isn't spelled out very well. > I can imagine that in some > cases we would like to stop services if > we can't provide real-time accounting, > while in some other cases we would like > to continue. I think we need to be careful about the definition of "can't provide real-time accounting". Does this mean that the session will go down whenever a transport failover occurs in any hop between the NAS and the Accounting Server? How will the NAS even know if this occurs if the failure is not on the first hop? Remember, the Watchdog isn't end to end. It only tells the NAS that its first hop (often a relay) is alive. If a connection goes down between the relay and a server, this doesn't affect the NAS-Relay connection, which is still live. The Relay initiates transport failover, and only after it runs out of options will it send a DIAMETER_UNABLE_TO_DELIVER message back to the NAS. Should such a message (or other error messages, too)sent in response to an Accounting Request result in a stoppage of services? > Furthermore, the state machine in 8.2 > (as well as the one that I just posted) > does not specify what to do when things > happen to the session faster than what it > takes for an ack to come back from the server. > For instance, what should we do if the session > is terminated while we are still waiting for > the start ack? The state table should probably include more events. > Proposed change: > > An AVP similar to the Accounting-Interim-Interval > could be used to control whether access should be > granted or discontinued upon problems in sending > the accounting records. Specifically, I think you want to define "problems" as receipt of any of a set of error messages or lack of *any* accounting-capable connection on the NAS. In terms of error messages on pages 76-77 of the spec, it occurs to me that for these purposes they would some protocol errors (3xxx), some Transient Failures (4xxx) and some Permanent Failures (5xxx). For example: 3001 DIAMETER_COMMAND_UNSUPPORTED 3002 DIAMETER_UNABLE_TO_DELIVER (accounting server(s) unavailable) 3003 DIAMETER_REALM_NOT_SERVED (Can't find an accounting server) 3004 DIAMETER_TOO_BUSY (Accounting server overwhelmed) 3005 DIAMETER_LOOP_DETECTED 3007 DIAMETER_APPLICATION_UNSUPPORTED 3008 DIAMETER_INVALID_HDR_BITS 4002 DIAMETER_OUT_OF_SPACE (No room on accounting server) > The state machine must be modified to consider what > to do with session termination and interim record > generation while we are still waiting to send previous > data. Remember, that the failure can occur between Relay and Server too. > The AVP with Value field set to DELIVER_AND_GRANT means > that the service MUST only be granted as long as there is > a connection to an accounting server. Not sure this is an adequate definition, since the NAS can have a connection to a relay that advertises *, but the accounting server can be down, causing the relay to send DIAMETER_UNABLE_TO_DELIVER messages. > Having to move the accounting record stream to a > backup server is not a reason to discontinue the service > to the user. Good. Let's avoid interaction with transport failover if we can. From owner-aaa-wg@merit.edu Fri Jan 4 06:16: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 GAA00598 for ; Fri, 4 Jan 2002 06:16:34 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 737BD9122C; Fri, 4 Jan 2002 06:16:19 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3555191232; Fri, 4 Jan 2002 06:16: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 49F6F9122C for ; Fri, 4 Jan 2002 06:16:17 -0500 (EST) Received: by segue.merit.edu (Postfix) id 26D035DDF9; Fri, 4 Jan 2002 06:16:17 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mel.alcatel.fr (mel.alcatel.fr [212.208.74.132]) by segue.merit.edu (Postfix) with ESMTP id BA44D5DDAB for ; Fri, 4 Jan 2002 06:16:15 -0500 (EST) Received: from aifhs2.alcatel.fr (mailhub.alcatel.fr [155.132.180.80]) by mel.alcatel.fr (ALCANET) with ESMTP id g04BGBVc006907; Fri, 4 Jan 2002 12:16:11 +0100 Received: from medine.ms.alcatel.fr (medine.ms.alcatel.fr [193.105.117.1]) by aifhs2.alcatel.fr (ALCANET/SMTP2) with ESMTP id MAA13147; Fri, 4 Jan 2002 12:14:58 +0100 (MET) Received: from ms.ms.alcatel.fr (ms.ms.alcatel.fr [188.9.12.93]) by medine.ms.alcatel.fr (8.8.8/8.8.8/aar-1.2) with ESMTP id MAA12580; Fri, 4 Jan 2002 12:15:21 +0100 (MET) Received: from athos.dinsunnet (athos [188.9.12.98]) by ms.ms.alcatel.fr (8.8.7/8.8.7/aar-1.0) with ESMTP id MAA24539; Fri, 4 Jan 2002 12:15:20 +0100 (MET) Received: from p50669 by athos.dinsunnet (8.9.1b+Sun/SMI-SVR4) id MAA28400; Fri, 4 Jan 2002 12:16:14 +0100 (MET) Message-ID: <018501c19510$ee221170$caf609bc@p50669> Reply-To: "Yacine El Mghazli" From: "Yacine El Mghazli" To: "Bernard Aboba" Cc: References: Subject: [AAA-WG]: what about the SLC minutes ? Date: Fri, 4 Jan 2002 12:14:08 +0100 Organization: Alcatel R&I MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit 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 Content-Transfer-Encoding: 7bit thanks in advance. -- Yacine El Mghazli ---------------------------------------------------------------------- Alcatel R&I Marcoussis, France Tel +33 1 6963 4187 Fax +33 1 6963 1169 yacine.el_mghazli@alcatel.fr ---------------------------------------------------------------------- From owner-aaa-wg@merit.edu Fri Jan 4 07:50: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 HAA01230 for ; Fri, 4 Jan 2002 07:50:47 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9987B9122F; Fri, 4 Jan 2002 07:50:35 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6F9E591233; Fri, 4 Jan 2002 07:50: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 4AEE49122F for ; Fri, 4 Jan 2002 07:50:34 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1E2FE5DE42; Fri, 4 Jan 2002 07:50:34 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by segue.merit.edu (Postfix) with ESMTP id 88BD05DDAB for ; Fri, 4 Jan 2002 07:50:33 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id g04CoWJ01203 for ; Fri, 4 Jan 2002 13:50:32 +0100 (MET) Received: from lmf.ericsson.se (lmf4ws450.lmf.ericsson.se [131.160.38.50]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g04CoUhO011367 for ; Fri, 4 Jan 2002 14:50:30 +0200 (EET) Message-ID: <3C35A516.A600F224@lmf.ericsson.se> Date: Fri, 04 Jan 2002 14:50:30 +0200 From: Jari Arkko Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: aaa-wg@merit.edu Subject: [AAA-WG]: Question on nasreq References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Somehow, in the middle of a Friday afternoon, I have managed to forget how the following works. Perhaps you can help. PPP authentication can be run in two directions. Normally we authenticate the user by the server. But we could also run e.g. CHAP to authenticate the server to the user. AAA basically allows a remote node, the AAA server, to perform the user authentication instead of the NAS. But can AAA handle the server authentication in a remote manner? It can do this using mutually authenticating EAP methods. But can it do it using other authentication types such as CHAP? That is, does our NASREQ extension allow for us to send the server authentication CHAP challenge to the server, and have it return the correct answer? Jari From owner-aaa-wg@merit.edu Fri Jan 4 17:01: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 RAA14803 for ; Fri, 4 Jan 2002 17:01:25 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2269D9123D; Fri, 4 Jan 2002 17:00:16 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E69D591271; Fri, 4 Jan 2002 17:00: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 C5DD19123D for ; Fri, 4 Jan 2002 17:00:14 -0500 (EST) Received: by segue.merit.edu (Postfix) id DB74C5DE57; Fri, 4 Jan 2002 17:00:12 -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 A63E45DE4A for ; Fri, 4 Jan 2002 17:00:11 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id NAA71434; Fri, 4 Jan 2002 13:45:41 -0800 (PST) (envelope-from aboba@internaut.com) Date: Fri, 4 Jan 2002 13:45:41 -0800 (PST) From: Bernard Aboba To: Yacine El Mghazli Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: what about the SLC minutes ? In-Reply-To: <018501c19510$ee221170$caf609bc@p50669> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk I'm working on it. Current deadline for submission to the IETF archives is 1/14/01. It's the first thing on my list as soon as I get back from vacation ;) On Fri, 4 Jan 2002, Yacine El Mghazli wrote: > thanks in advance. > > > -- Yacine El Mghazli > ---------------------------------------------------------------------- > Alcatel R&I > Marcoussis, France > Tel +33 1 6963 4187 > Fax +33 1 6963 1169 > yacine.el_mghazli@alcatel.fr > ---------------------------------------------------------------------- > > > From owner-aaa-wg@merit.edu Mon Jan 7 17:20: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 RAA29512 for ; Mon, 7 Jan 2002 17:20:53 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 4194291206; Mon, 7 Jan 2002 17:20:39 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 118AA9121F; Mon, 7 Jan 2002 17:20: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 1998591206 for ; Mon, 7 Jan 2002 17:20:38 -0500 (EST) Received: by segue.merit.edu (Postfix) id D806E5DDEC; Mon, 7 Jan 2002 17:20:37 -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 0803F5DDA5 for ; Mon, 7 Jan 2002 17:20:36 -0500 (EST) Received: (qmail 6636 invoked by uid 507); 7 Jan 2002 22:20:30 -0000 Date: Mon, 7 Jan 2002 16:20:28 -0600 From: David Frascone To: diameter@frascone.com, aaa-wg@merit.edu Subject: [AAA-WG]: Open Source Diameter Project Started Message-ID: <20020107222028.GJ13693@newman.frascone.com> Mail-Followup-To: diameter@frascone.com, 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 X-Virus-Scanned: by AMaViS perl-11 Sender: owner-aaa-wg@merit.edu Precedence: bulk I have had *many* inquiries about an open sourced diameter package ever since Sun released the binary evaluation package. I, for one, would really like to see an open source diameter implementation. (Plus, having a reference implementation for the aaa-wg would be a good thing too) So, I've started a project at sourceforge to create it. I'd *like* to see both Java and C++ implementations, but I doubt people will donate enough resources for both. So, please visit the page, http://www.sourceforge.net/projects/diameter and let me know (via e-mail or the forums) if you are willing to contribute code, testing, etc. to the effort. Thanks in advance, Dave P.S. I haven't had time to put together anything but a skeleton home page. I could use some help there too. From owner-aaa-wg@merit.edu Tue Jan 8 09:28: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 JAA23047 for ; Tue, 8 Jan 2002 09:28:05 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3C6669121D; Tue, 8 Jan 2002 09:27:53 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0046C91220; Tue, 8 Jan 2002 09:27: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 C16329121D for ; Tue, 8 Jan 2002 09:27:51 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9913F5DEBB; Tue, 8 Jan 2002 09:27:51 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from cms3.etri.re.kr (cms3.etri.re.kr [129.254.16.13]) by segue.merit.edu (Postfix) with ESMTP id EAD4A5DEBA for ; Tue, 8 Jan 2002 09:27:50 -0500 (EST) Received: by cms3.etri.re.kr with Internet Mail Service (5.5.2653.19) id ; Tue, 8 Jan 2002 23:13:31 +0900 Message-ID: <8470181DABD5D511B3E700D0B7A8AC4A7A7B12@cms3.etri.re.kr> From: haenamu@etri.re.kr To: aaa-wg@merit.edu Subject: [AAA-WG]: pcalhoun@diameter.org Date: Tue, 8 Jan 2002 23:13:30 +0900 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1984E.A5E7FDC0" 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_01C1984E.A5E7FDC0 Content-Type: text/plain; charset="euc-kr" Hello. Pat Calhoun. I am not good at security. So I have a question about security. After reading 'Diameter MIPv4 application' draft, and 'AAA Keys for Mobile IP' draft I can know that AAA server uses Keyed-MD5, HMAC-MD5, SHA-1 for Key Distribution and Derivation. but I can not know "which algorithm is used for MN authentication", (that is, to validate MN-AAA Extention's Authenticator) Is it the same or different? Thanks in advance. Regards, Haedong Lee Electronics and Telecommunications Research Institute(ETRI) ------_=_NextPart_001_01C1984E.A5E7FDC0 Content-Type: text/html; charset="euc-kr" Content-Transfer-Encoding: quoted-printable pcalhoun@diameter.org

Hello. Pat Calhoun.

I am not good at security. So I have a question about = security.

After reading 'Diameter MIPv4 application' draft, and = 'AAA Keys for Mobile IP' draft
I can know that AAA server uses Keyed-MD5, HMAC-MD5, = SHA-1 for Key Distribution and Derivation.
but I can not know "which algorithm is used for = MN authentication", (that is, to validate MN-AAA Extention's = Authenticator)

 
Is it the same or different?

Thanks in advance.


Regards,
Haedong Lee
Electronics and Telecommunications Research = Institute(ETRI)

------_=_NextPart_001_01C1984E.A5E7FDC0-- From owner-aaa-wg@merit.edu Tue Jan 8 09:50: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 JAA24063 for ; Tue, 8 Jan 2002 09:50:39 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5377F91220; Tue, 8 Jan 2002 09:50:27 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1D3C791227; Tue, 8 Jan 2002 09:50: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 DE9E391220 for ; Tue, 8 Jan 2002 09:50:25 -0500 (EST) Received: by segue.merit.edu (Postfix) id B51C05DE7D; Tue, 8 Jan 2002 09:50:25 -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 901355DE61 for ; Tue, 8 Jan 2002 09:50:25 -0500 (EST) Received: from interlinknetworks.com (nat.interlinknetworks.com [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with ESMTP id 28C2679 for ; Tue, 8 Jan 2002 09:50:25 -0500 (EST) Message-ID: <3C3B0720.A073D076@interlinknetworks.com> Date: Tue, 08 Jan 2002 09:50:08 -0500 From: Don Zick X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: aaa-wg@merit.edu Subject: [AAA-WG]: [issue] A Diameter node must use its own TLS certificate Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Issue Number: To be assigned by Pat Calhoun Description of issue: A Diameter node must use its own TLS certificate Submitter name: Don Zick Date first submitted: 1/2/2 Document: base Comment type: T Priority: 1 Section: 2.2 Securing Diameter Messages Rationale/Explanation of issues: The Diameter base draft does not address how to ensure that a Diameter node is using its own TLS certificate. It is important to ensure that a Diameter node is using its own TLS certificate so that if a single Diameter node becomes compromised, it won't break security for all of the other Diameter nodes. It is a common practice with TLS to put a node's identity into the certificate's subjectAltName dNSName field. The Diameter CMS Security Application takes this approach. Below is a section from the Diameter CMS Security Application draft 3: >3.2 Certificate Requirements > > Certificates used for the purposes of Diameter MUST conform to the > PKIX profile [4], and MUST also include a Diameter node's FQDN, which > is typically added in the Origin-Host AVP [1], as one of the values > of the subjectAltName extension of the Certificate. The FQDN is to > be encoded as a dNSName within the subjectAltName. > > For Diameter nodes (capable of acting as recipients for > confidentiality), the FQDN MUST be of the form > "Diameter-.". Other Diameter nodes MAY use this naming > scheme. Note that this naming constraint is for PKI purposes only, > and in no way restricts a Diameter's host name. Requested change: Make Diameter TLS have the same dNSName field requirements as the Diameter CMS Security Application. From owner-aaa-wg@merit.edu Tue Jan 8 09:58: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 JAA24331 for ; Tue, 8 Jan 2002 09:58:48 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D77C491227; Tue, 8 Jan 2002 09:58:36 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A982991229; Tue, 8 Jan 2002 09:58: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 80C8891227 for ; Tue, 8 Jan 2002 09:58:35 -0500 (EST) Received: by segue.merit.edu (Postfix) id 629335DE7D; Tue, 8 Jan 2002 09:58:35 -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 478725DE7C for ; Tue, 8 Jan 2002 09:58:35 -0500 (EST) Received: from interlinknetworks.com (nat.interlinknetworks.com [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with ESMTP id D2ECE6C for ; Tue, 8 Jan 2002 09:58:34 -0500 (EST) Message-ID: <3C3B0909.3B969E02@interlinknetworks.com> Date: Tue, 08 Jan 2002 09:58:17 -0500 From: Don Zick X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: aaa-wg@merit.edu Subject: [AAA-WG]: [issue] Mandate required TLS cipher suites Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Issue Number: To be assigned by Pat Calhoun Description of issue: Mandate required TLS cipher suites Submitter name: Don Zick Date first submitted: 1/8/2 Document: base Comment type: T Priority: S Section: 2.2 Securing Diameter Messages Rationale/Explanation of issues: Diameter implementations should not be required to support all TLS cipher suites listed in RFC 2246. Not all cipher suites are supported by available TLS tool kits and one cipher suite contains the proprietary IDEA encryption algorithm that you have to get permission to use. Therefore, to ensure inter operability, it is necessary to specify which cipher suites must be supported. Requested change: Add: Diameter nodes MUST be able to negotiate the following TLS cipher suites: TLS_RSA_WITH_RC4_128_MD5 TLS_RSA_WITH_RC4_128_SHA TLS_RSA_WITH_3DES_EDE_CBC_SHA Diameter nodes MAY negotiate other TLS cipher suites. From owner-aaa-wg@merit.edu Thu Jan 10 10:53: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 KAA16949 for ; Thu, 10 Jan 2002 10:53:24 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id F155291201; Thu, 10 Jan 2002 10:53:12 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BD43E9120F; Thu, 10 Jan 2002 10:53: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 A8CBE91201 for ; Thu, 10 Jan 2002 10:53:10 -0500 (EST) Received: by segue.merit.edu (Postfix) id 79A195DEF1; Thu, 10 Jan 2002 10:53: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 372A65DEBD for ; Thu, 10 Jan 2002 10:53:10 -0500 (EST) Received: from phoenix (nat.interlinknetworks.com [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with SMTP id 0B3647B; Thu, 10 Jan 2002 10:53:08 -0500 (EST) From: "Bob Kopacz" To: "Pat Calhoun" , "Johan Johansson" Cc: "David Spence" , Subject: RE: [AAA-WG]: Issue 212: How does the AAAH know the Destination-Host of a previously assigned foreign HA? Date: Thu, 10 Jan 2002 10:52:43 -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 Importance: Normal In-Reply-To: <20011113093454.H6449@charizard.diameter.org> Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Pat, Just a note. Requiring server discovery conflicts with Jari's recently submitted issue: > -----Original Message----- > From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of > Jari Arkko > Sent: Wednesday, January 02, 2002 11:28 AM > To: aaa-wg@merit.edu > Subject: [AAA-WG]: [Issue] Peer discovery mechanism requirements > > Submitter: Jari Arkko > Date: January 2, 2002 > Reference: > Document: BASE-08 > Comment type: T > Priority: S > Section: 5.2 > Rationale/Explanation of issue: > > Current text does not clearly enough specify > which peer discovery mechanisms are mandatory > and which are not. > > There's two approaches to handling this issue. > One, (apparently the current approach) we stay > clear of using MUST/SHOULD/MAY in section 5.2 > and therefore all of the text falls to Informative, > and nothing is really mandated. > > The second approach is that we explicitly state > what DIAMETER nodes MUST/SHOULD/MAY be capable of > in this area. I favor the latter approach. > > Proposed change: > > Indicate in the list under 5.2 that the first > option (manual configuration) MUST be supported > by all DIAMETER nodes, while the latter two options > (SRVLOC and DNS SRV records) MAY be supported. > -----Original Message----- > From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of > Pat Calhoun > Sent: Tuesday, November 13, 2001 12:35 PM > To: Johan Johansson > Cc: Pat Calhoun; David Spence; aaa-wg@merit.edu > Subject: Re: [AAA-WG]: Issue 212: How does the AAAH know the > Destination-Host of a previously assigned foreign HA? > > yes, I am proposing to add some text stating when to use server discovery in > the areas where this issue is concerned. > > PatC > On Tue, Nov 13, 2001 at 01:29:30PM +0100, Johan Johansson wrote: > > The base draft - correct me if I'm wrong - doesn't actually specify when > > to use server discovery. Does alternative 1 mean "use server discovery > > in this particular case" or does it mean "add server discovery to > > section 6.1.6/6.1.2 as a last-ditch effort"? > > > > Which comments are you referring to btw? > > > > j > > > > Pat Calhoun wrote: > > > > >The use of DNS and/or SLP is already specified in the base protocol. > > > > > >I would also argue that deploying, debugging, etc will be faster than > > >trying to change the MIP protocol (which is what option 2 would mean, and > > >you read the MIP chair's comments). > > > > > >PatC > > >On Mon, Nov 12, 2001 at 02:54:41PM -0500, David Spence wrote: > > > > > >>O.k., so we agree that option 1 could be made to work. But option 1 > > >>requires an independent mechanism (DNS and server discovery) to retrieve > > >>information that used to be known by the Diameter nodes. If everything > > >>isn't consistently configured among the directories and config files of > > >>different protocols, the exchange will fail. Option 2, on the other hand, > > >>avoids such consistency assumptions and is therefore preferable. > > >> > > >>>While looking at solving this issue, we have two options: > > >>> > > >>>1. Require that the AAAH perform the Server Discovery procedures in > > >>> section 5.2 to determine the URL of the Home Agent. > > >>> > > >>>2. Create a new Mobile IP extension, and associated AVP, which the Mobile > > >>> Node must include in its registration requests. This means > that once the > > >>> mobile has been initially registered by the HA, the HA would > include its > > >>> identity in the registration reply. > > >>> > > >Content-Description: Card for David Spence > > > > > > > > > > From owner-aaa-wg@merit.edu Thu Jan 10 11:31: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 LAA18262 for ; Thu, 10 Jan 2002 11:31:51 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 16E729123F; Thu, 10 Jan 2002 11:31:22 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AD59691287; Thu, 10 Jan 2002 11:31: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 C8A0E9126D for ; Thu, 10 Jan 2002 11:31:16 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8F51D5DF1B; Thu, 10 Jan 2002 11:30:22 -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 539975DEBD for ; Thu, 10 Jan 2002 11:30:22 -0500 (EST) Received: from phoenix (nat.interlinknetworks.com [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with SMTP id ED6D57C for ; Thu, 10 Jan 2002 11:30:21 -0500 (EST) From: "Bob Kopacz" To: "aaa-wg" Subject: [AAA-WG]: [issue] User-Name in Answer messages Date: Thu, 10 Jan 2002 11:29:56 -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 Number: To be assigned Description of issue: Inconsistent rules about presence of User-Name in Answer messages. Submitter name: Bob Kopacz Date first submitted: 01-10-2002. Document: base, mobile-ip, nasreq Comment type: T Priority: 1 Section: Occurrence rules tables, and Message ABNFs. Rationale/Explanation of issues: The rules for the inclusion of the User-Name AVP in Answer messages are inconsistent. In draft-08: The User-Name AVP MUST be echoed back (1 occurrence required) in these Answer messages: Re-Auth-Answer (base protocol) Abort-Session-Answer (base protocol) Session-Terminate-Answer (base protocol) Accounting-Answer (base protocol) The User-Name AVP MAY be echoed back (0-1 occurrence) in these Answer messages: AA-Answer (nasreq) Diameter-EAP-Answer (nasreq) The User-Name AVP MUST NOT be echoed back (0 occurrences required) in these Answer messages (which caused conflicts at the recent bakeoff): AA-Mobile-Node-Answer (mobile ip) Home-Agent-MIP-Answer (mobile ip) Requested change: Since it is natural and harmless for an implementation to echo back the User-Name, allow but do not require the User-Name AVP to appear in Answer messages, if present in the Request. From owner-aaa-wg@merit.edu Thu Jan 10 11:32: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 LAA18307 for ; Thu, 10 Jan 2002 11:32:43 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 332B591241; Thu, 10 Jan 2002 11:31:26 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 13E6691270; Thu, 10 Jan 2002 11:31: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 6BBF791243 for ; Thu, 10 Jan 2002 11:31:16 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7005E5DEEE; Thu, 10 Jan 2002 10:46: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 5999C5DEBD for ; Thu, 10 Jan 2002 10:46:02 -0500 (EST) Received: from phoenix (nat.interlinknetworks.com [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with SMTP id E17EF79; Thu, 10 Jan 2002 10:46:01 -0500 (EST) From: "Bob Kopacz" To: "Jari Arkko" , Cc: "David Spence" , "Pat Calhoun" Subject: RE: [AAA-WG]: [Issue] Peer discovery mechanism requirements Date: Thu, 10 Jan 2002 10:45:36 -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 Importance: Normal In-Reply-To: <3C3334FE.69BC4328@lmf.ericsson.se> Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi, I agree with the idea of not mandating server discovery. However there is a conflict between this issue and Pat's proposed solution to issue#212, which would require server discovery. (Maybe I should've sent this email to the issue#212 thread instead). My understanding of the problem addressed by issue#212 is this: Suppose a MN has been assigned a home agent in a foreign network, and the MN migrates to a new FA. The AAAH has no way to map the IP address in the registration request to a Destination-Host AVP and Destination-Realm AVP of the Home Agent. The AAAH needs to know these Destination-xxx AVPs so that the HAR may be routed to the correct network (in case the MN has migrated to a new foreign network and is retaining the HA allocated in the originally-visited network) and to the specific HA. Looking over the issue#212 thread, it seems that there are three solutions to this problem (the following is lifted from various emails): 1. Require that the AAAH perform the Server Discovery procedures in section 5.2 to determine the URL of the Home Agent. (This conflicts with Jari's new issue) 2. Create a new Mobile IP extension, and associated AVP, which the Mobile Node must include in its registration requests. This means that once the mobile has been initially registered by the HA, the HA would include its identity in the registration reply. (There was some support for this as being a better solution, but I think some felt this would take too long). 3. Require that the AAAH maintain session state, so that the identity of the HA is remembered. I'm not sure if this even works, given that the later AMA may be delivered to a different AAAH. (But this conflicts with draft-mobileip-08, which indicates that the AAAH is not required to be session stateful). Bob K. > -----Original Message----- > From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of > Jari Arkko > Sent: Wednesday, January 02, 2002 11:28 AM > To: aaa-wg@merit.edu > Subject: [AAA-WG]: [Issue] Peer discovery mechanism requirements > > > > Submitter: Jari Arkko > Date: January 2, 2002 > Reference: > Document: BASE-08 > Comment type: T > Priority: S > Section: 5.2 > Rationale/Explanation of issue: > > Current text does not clearly enough specify > which peer discovery mechanisms are mandatory > and which are not. > > There's two approaches to handling this issue. > One, (apparently the current approach) we stay > clear of using MUST/SHOULD/MAY in section 5.2 > and therefore all of the text falls to Informative, > and nothing is really mandated. > > The second approach is that we explicitly state > what DIAMETER nodes MUST/SHOULD/MAY be capable of > in this area. I favor the latter approach. > > Proposed change: > > Indicate in the list under 5.2 that the first > option (manual configuration) MUST be supported > by all DIAMETER nodes, while the latter two options > (SRVLOC and DNS SRV records) MAY be supported. > From owner-aaa-wg@merit.edu Thu Jan 10 13:47: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 NAA21174 for ; Thu, 10 Jan 2002 13:47:36 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 04A109126C; Thu, 10 Jan 2002 13:47:26 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 81DB39126D; Thu, 10 Jan 2002 13:47: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 39C499126C for ; Thu, 10 Jan 2002 13:47:14 -0500 (EST) Received: by segue.merit.edu (Postfix) id 18DB05DD99; Thu, 10 Jan 2002 13:47:14 -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 F15145DDDC for ; Thu, 10 Jan 2002 13:47:13 -0500 (EST) Received: from phoenix (nat.interlinknetworks.com [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with SMTP id 9EE837C for ; Thu, 10 Jan 2002 13:47:13 -0500 (EST) From: "Bob Kopacz" To: "aaa-wg" Subject: [AAA-WG]: [issue] MIP-Reg-Reply AVP not required in AMA for Co-located MN Date: Thu, 10 Jan 2002 13:46:48 -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 Number: To be assigned Description of issue: MIP-Reg-Reply AVP not required in AMA for Co-located MN Submitter name: Bob Kopacz Date first submitted: 01-10-2002. Document: mobile-ip draft-08 Comment type: T Priority: 1 Section: 2.2 "AA-Mobile-Node-Answer" Rationale/Explanation of issues: Sesion 2.2 of the Mobile-IP draft-08 states that "An AMA message with the Result-Code AVP set to DIAMETER_SUCCESS MUST include the [...] MIP-Reg-Reply AVP." In the case of a co-located MN, however, the AAAH would be sending the AMA as a direct response to the AMR, with no HAR/HAA messages involved, so in this case the AMA would not contain a MIP-Reg-Reply AVP. This was first noted by Siva Ramamurthy on the AAA-WG mailing list on 11-28-2001. The occurrence rule table and message ABNF are ok. Requested change: Change the first sentence of the second paragraph From: An AMA message with the Result-Code AVP set to DIAMETER_SUCCESS MUST include the MIP-Home-Agent-Address, MIP-Home-Mobile-Node-Address and MIP-Reg-Reply AVPs. To: An AMA message with the Result-Code AVP set to DIAMETER_SUCCESS MUST include the MIP-Home-Agent-Address AVP, MUST include the MIP-Home-Mobile-Node-Address AVP, and includes the MIP-Reg-Reply AVP if and only if the Co-Located-Mobile-Node bit was not set in the MIP-Feature-Vector AVP. From owner-aaa-wg@merit.edu Fri Jan 11 05:13: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 FAA12604 for ; Fri, 11 Jan 2002 05:13:10 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 83C3D91211; Fri, 11 Jan 2002 05:12:58 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 49A3691244; Fri, 11 Jan 2002 05:12: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 3530D91211 for ; Fri, 11 Jan 2002 05:12:57 -0500 (EST) Received: by segue.merit.edu (Postfix) id 08EBE5DE03; Fri, 11 Jan 2002 05:12:57 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by segue.merit.edu (Postfix) with ESMTP id 6BF035DDF3 for ; Fri, 11 Jan 2002 05:12:56 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id g0BAA7K17137; Fri, 11 Jan 2002 11:10:07 +0100 (MET) Received: from lmf.ericsson.se (lmf4ws450.lmf.ericsson.se [131.160.38.50]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g0BA9shO014437; Fri, 11 Jan 2002 12:09:58 +0200 (EET) Message-ID: <3C3EB9F2.B156D8C9@lmf.ericsson.se> Date: Fri, 11 Jan 2002 12:09:54 +0200 From: Jari Arkko Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Bob Kopacz Cc: aaa-wg@merit.edu, David Spence , Pat Calhoun Subject: Re: [AAA-WG]: [Issue] Peer discovery mechanism requirements References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Bob, I can't say I'm that familiar with issue 212, but you stated that one possible solution is for the AAAH to perform the Server Discovery procedures. You also said that this has the problem that it is in conflict with my proposed keywords, which do not require all nodes to support the three discovery mechanisms. Actually, I don't think this has to be a problem. Base DIAMETER could require support for manual config discovery, while MIP DIAMETER extension could require more, such as both SRVLOC and DNS SRV. Jari From owner-aaa-wg@merit.edu Fri Jan 11 05:59: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 FAA12621 for ; Fri, 11 Jan 2002 05:13:48 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 89EE791281; Fri, 11 Jan 2002 05:13:32 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5B9C191244; Fri, 11 Jan 2002 05:13: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 C65B191282 for ; Fri, 11 Jan 2002 05:13:30 -0500 (EST) Received: by segue.merit.edu (Postfix) id 93E205DE03; Fri, 11 Jan 2002 05:13:30 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by segue.merit.edu (Postfix) with ESMTP id CEE9E5DDF3 for ; Fri, 11 Jan 2002 05:13:29 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id g0BADRK19692; Fri, 11 Jan 2002 11:13:27 +0100 (MET) Received: from lmf.ericsson.se (lmf4ws450.lmf.ericsson.se [131.160.38.50]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g0BADQhO014755; Fri, 11 Jan 2002 12:13:26 +0200 (EET) Message-ID: <3C3EBAC6.AB507644@lmf.ericsson.se> Date: Fri, 11 Jan 2002 12:13:26 +0200 From: Jari Arkko Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Bob Kopacz Cc: aaa-wg Subject: Re: [AAA-WG]: [issue] User-Name in Answer messages References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit >Since it is natural and harmless for an implementation to echo back >the User-Name, allow but do not require the User-Name AVP to appear in >Answer messages, if present in the Request. I agree with this issue. Maybe we could give less room for interpretation in the text though. I propose "MUST echo back User-Name AVP if present in the Request". Jari From owner-aaa-wg@merit.edu Fri Jan 11 08:21: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 IAA14180 for ; Fri, 11 Jan 2002 08:21:46 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B368091244; Fri, 11 Jan 2002 08:21:33 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 833D291282; Fri, 11 Jan 2002 08:21: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 8135491244 for ; Fri, 11 Jan 2002 08:21:32 -0500 (EST) Received: by segue.merit.edu (Postfix) id 56F1B5DE39; Fri, 11 Jan 2002 08:21: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 4201A5DDFD for ; Fri, 11 Jan 2002 08:21:32 -0500 (EST) Received: from phoenix (nat.interlinknetworks.com [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with SMTP id B6C217D; Fri, 11 Jan 2002 08:21:31 -0500 (EST) From: "Bob Kopacz" To: Cc: "aaa-wg" Subject: RE: [AAA-WG]: [issue] User-Name in Answer messages Date: Fri, 11 Jan 2002 08:21:03 -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 Importance: Normal In-Reply-To: <3C3EBAC6.AB507644@lmf.ericsson.se> Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi, > > >Since it is natural and harmless for an implementation to echo back > >the User-Name, allow but do not require the User-Name AVP to appear in > >Answer messages, if present in the Request. > > I agree with this issue. > > Maybe we could give less room for interpretation in the > text though. I propose "MUST echo back User-Name AVP if present > in the Request". Sure, this is fine. I'm mainly after consistency. > Jari > Bob K. From owner-aaa-wg@merit.edu Fri Jan 11 08:25: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 IAA14207 for ; Fri, 11 Jan 2002 08:25:44 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id AAEF291282; Fri, 11 Jan 2002 08:25:32 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7EB6391283; Fri, 11 Jan 2002 08:25: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 9322391282 for ; Fri, 11 Jan 2002 08:25:31 -0500 (EST) Received: by segue.merit.edu (Postfix) id 716A65DE3F; Fri, 11 Jan 2002 08:25:31 -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 5D1C05DE3E for ; Fri, 11 Jan 2002 08:25:31 -0500 (EST) Received: from phoenix (nat.interlinknetworks.com [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with SMTP id A1CC07F; Fri, 11 Jan 2002 08:25:30 -0500 (EST) From: "Bob Kopacz" To: Cc: , "David Spence" , "Pat Calhoun" Subject: RE: [AAA-WG]: [Issue] Peer discovery mechanism requirements Date: Fri, 11 Jan 2002 08:25:02 -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 Importance: Normal In-Reply-To: <3C3EB9F2.B156D8C9@lmf.ericsson.se> Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Jari, > > Bob, > > I can't say I'm that familiar with issue 212, but > you stated that one possible solution is for the AAAH to > perform the Server Discovery procedures. You also > said that this has the problem that it is in conflict > with my proposed keywords, which do not require all > nodes to support the three discovery mechanisms. > > Actually, I don't think this has to be a problem. > Base DIAMETER could require support for manual config > discovery, while MIP DIAMETER extension could require > more, such as both SRVLOC and DNS SRV. You're right. I hadn't thought of this when blurting out my comment when first looking over your new issue. > Jari > Bob K. From owner-aaa-wg@merit.edu Sun Jan 13 12:46: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 MAA12945 for ; Sun, 13 Jan 2002 12:46:45 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id BF50C91209; Sun, 13 Jan 2002 12:46:34 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8F4899120A; Sun, 13 Jan 2002 12:46: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 C4FBF91209 for ; Sun, 13 Jan 2002 12:46:31 -0500 (EST) Received: by segue.merit.edu (Postfix) id A82D35DEBC; Sun, 13 Jan 2002 12:46:31 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from ws2.piuha.net (unknown [195.165.196.2]) by segue.merit.edu (Postfix) with ESMTP id 77AF05DEB9 for ; Sun, 13 Jan 2002 12:46:31 -0500 (EST) Received: from piuha.net (ws4.piuha.net [195.165.196.4]) by ws2.piuha.net (Postfix) with ESMTP id 032C26A90A; Sun, 13 Jan 2002 19:46:26 +0200 (EET) Message-ID: <3C41B667.9090704@kolumbus.fi> Date: Sun, 13 Jan 2002 18:31:35 +0200 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: Don Zick Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: [issue] Mandate required TLS cipher suites References: <3C3B0909.3B969E02@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 Don Zick wrote: > Diameter nodes MUST be able to negotiate the following TLS cipher > suites: > TLS_RSA_WITH_RC4_128_MD5 > TLS_RSA_WITH_RC4_128_SHA > TLS_RSA_WITH_3DES_EDE_CBC_SHA > Diameter nodes MAY negotiate other TLS cipher suites. Agree. Jari From owner-aaa-wg@merit.edu Mon Jan 14 16:35: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 QAA20538 for ; Mon, 14 Jan 2002 16:35:00 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5AFD79122E; Mon, 14 Jan 2002 16:34:50 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2F30A9122F; Mon, 14 Jan 2002 16:34: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 064CF9122E for ; Mon, 14 Jan 2002 16:34:48 -0500 (EST) Received: by segue.merit.edu (Postfix) id DAF255DD94; Mon, 14 Jan 2002 16:34:48 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by segue.merit.edu (Postfix) with ESMTP id 4B0A85DD91 for ; Mon, 14 Jan 2002 16:34:48 -0500 (EST) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate4.mot.com (motgate4 2.1) with ESMTP id OAA25078 for ; Mon, 14 Jan 2002 14:34:47 -0700 (MST)] Received: [from m-il06-r4.mot.com (m-il06-r4.mot.com [129.188.137.196]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id OAA17850 for ; Mon, 14 Jan 2002 14:34:47 -0700 (MST)] Received: from pobox.cstl.labs.mot.com by m-il06-r4.mot.com with ESMTP for aaa-wg@merit.edu; Mon, 14 Jan 2002 14:34:46 -0700 Received: from labs.mot.com ([173.23.95.28]) by pobox.cstl.labs.mot.com (Netscape Messaging Server 4.15) with ESMTP id GPY6LY00.TY5 for ; Mon, 14 Jan 2002 15:34:46 -0600 Message-Id: <3C434EF5.DAB38A75@labs.mot.com> Date: Mon, 14 Jan 2002 15:34:45 -0600 From: "Judy Fu" X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: aaa-wg@merit.edu Subject: [AAA-WG]: Invoking AAA during every handoff? References: <3C430F3B.4AEB5E83@labs.mot.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 need some help to clarify a question. Will AAA infrastructure need to be invoked to reauthenticate a mobile node during every handoff when previous authorization is still valid, if so, then a mobile node needs to include MN-AAA extension in registration request message everytime during handoff ? In draft-ietf-aaa-diameter-mobileip-08.txt, page 9, section 1.3, it says "the first registration request from a mobile node will therefore cause an AMR to be sent to its AAAF." So I guess the answer is yes. Then why is it yes? I guess not for authentication reason because the MN can be authenticated by HA with the valid MN-HA key. If so, then the only reason may be that the new FA needs to establish new AAA path in order to collect accounting data. Am I correct on that? Another quick question, in section 1.2 on page 7 of the same draft, it says "In the event that the AMR generated by the FA is for a session that has was previously authorized by the AAAH, it MUST include Destination-Host AVP, with the identity of the AAAH." I am not clear how the Destination-Host AVP will be used since later it says AMR message might be received by a different AAAH during handoff. Will the different AAAH have to send the message back to the original AAAH specified in Destination-Host AVP, and if so, why? Many thanks. Judy From owner-aaa-wg@merit.edu Tue Jan 15 08:41: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 IAA22832 for ; Tue, 15 Jan 2002 08:41:40 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 854B79124B; Tue, 15 Jan 2002 08:41:24 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 532039124C; Tue, 15 Jan 2002 08:41: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 2E91F9124B for ; Tue, 15 Jan 2002 08:41:23 -0500 (EST) Received: by segue.merit.edu (Postfix) id ECA5A5DDAF; Tue, 15 Jan 2002 08:41:22 -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 992E25DDA0 for ; Tue, 15 Jan 2002 08:41:17 -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 OAA14471 for ; Tue, 15 Jan 2002 14:39:45 +0100 Message-ID: <3C443F64.8010000@ipunplugged.com> Date: Tue, 15 Jan 2002 15:40:36 +0100 From: Johan Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.6) Gecko/20011120 X-Accept-Language: en-us MIME-Version: 1.0 To: aaa-wg@merit.edu Subject: [AAA-WG]: Why no termination cause in ASRs? 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 Just out of curiousity: how come STRs get termination causes while ASRs don't? j From owner-aaa-wg@merit.edu Tue Jan 15 14:40: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 OAA10958 for ; Tue, 15 Jan 2002 14:40:49 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 8684D9125B; Tue, 15 Jan 2002 14:40:37 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5242C9125C; Tue, 15 Jan 2002 14:40: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 565D29125B for ; Tue, 15 Jan 2002 14:40:36 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2B1BB5DDC8; Tue, 15 Jan 2002 14:40:36 -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 1143B5DDAE for ; Tue, 15 Jan 2002 14:40:36 -0500 (EST) Received: from phoenix (nat.interlinknetworks.com [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with SMTP id AB4E66C for ; Tue, 15 Jan 2002 14:40:35 -0500 (EST) From: "Bob Kopacz" To: "aaa-wg" Subject: [AAA-WG]: [issue] Returning AAAF-Generated FA-HA Key to FA Date: Tue, 15 Jan 2002 14:40:04 -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 : Returning AAAF-Generated FA-HA Key to FA Submitter name: Bob Kopacz Submitter email address: BKopacz@InterlinkNetworks.com Date first submitted: 01-15-2002 Reference: Document: mobileip Comment type: Technical Priority: 1 Section: 2.2, 2.4, 5.4, 8.1, Issue#203 Rationale/Explanation of issue: [The following is based on some issue#203-related emails exchanged with Mark Eklund. The proposal I'm contributing here is also Mark's, as I understand it] When the HA is in the foreign network and a FA-HA key is requested, the AAAF, rather than the AAAH, generates the key. Here's the diagram of the issue: amr-> amr-> FA --------> AAAF1 -------------> AAAH <-ama <-ama | | ^ | | har | haa | | V | | <-har <-har | HA <-------- AAAF2 <---------------/ haa-> haa-> In the above diagram, FA & HA & AAAF1 & AAAF2 are all in the same visited network. AAAF1 and AAAF2 may be the same server, or may be different servers. In the above diagram, AAAF2 generates the FA-HA key. The problem is that this key must somehow be returned to the FA via AAAF1. The proposal here is to pass the key back to the FA via the the HAA and AMA messages. AAAF2 may be concerned about security, so may want the FA-HA key to be passed encrypted so that AAAH and intervening servers can't figure it out, but AAAF1 can somehow decrypt it. The details are: 1. A new HAA-to-AMA-Data AVP, of type octetstring, is created. The purpose of this AVP is convey information from the HA's AAAF (AAAF2) to the FA's AAAF (AAAF1). All AAAFs in that foreign realm MUST have an agreed upon format and security method for this AVP to be used. (It may be possible to use CMS security to somehow encrypt this AVP, but it is unclear just how, as it involves the AAAH copying a secure AVP from the HAA to the AMA, and the AMA may carry both AAAH-FA and AAAF1-AAAF2 secured AVPs) 2. When the FA-HA key is generated by AAAF2, this key must somehow be conveyed to AAAF1. There are two ways to do this: a. Use the MIP-HAA-to-AMA-Data AVP, or b Have a common database among AAAFs in the foreign network, wherein AAAF2 may deposit the FA-HA key, which is later retrieved by AAAF1, in a proprietary manner not described in the Diameter documents. 3. If the HAA-to-AMA-Data AVP is present in the HAA, the AAAH treats it as opaque data and passes it in the AMA. 4, If AAAF1 receives the HAA-to-AMA-Data AVP in the AMA, AAAF1 will use this AVP to recreate the FA-HA key, and replace this AVP by a MIP-FA-to-HA-Key AVP in the AMA sent to the FA. Requested change: This issues supercedes issue#203, which also addresses the problem of returning an AAAF-Generated FA-HA Key to the FA, but didn't quite work in the case where there was a 2nd AAAF involved. In section 2.2. Add [HAA-to-AMA-Data] to the AMA ABNF. In section 2.4. Add [HAA-to-AMA-Data] to the HAA ABNF. In section 6, define the following new AVP: 6.x HAA-to-AMA-Data AVP The HAA-to-AMA-Data AVP (AVP Code TBD) is of type OctetString and may be used, when the HA is allocated in the foreign network and the HA's AAAF generates the FA-HA key, to convey the FA-HA key information (in some proprietary format and security method which is agreed-upon by all AAAF servers in the foreign network) back to the FA's AAAF. In section 8.1. Add a row for the new HAA-to-AMA-Data AVP, with these occurrence rules: AMR 0, AMA 0-1, HAR 0, HAA 0-1. Replace section 5.4 by If the home agent is in the home realm, then AAAH has to generate the Foreign-Home session key. Otherwise, it is generated by the AAAF receiving the HAR. If the AAAH generates the Foreign-Home session key, then the AAAH includes the session key in the MIP-HA-to-FA-Key AVP, and includes the AVP as part of the HAR message sent to the home agent. The corresponding session key that is to be sent to the foreign agent is cached on the AAAH until the HAA is received, at which time the AAAH adds the MIP-FA-to-HA Key AVP to the AMA, using the SPI in the MIP-FA-to-HA-SPI. Upon receipt of the HAR, the home agent recovers the Foreign-Home session key, allocates an SPI to be used with the key. The allocated SPI is included in the HAA's MIP-FA-to-HA SPI AVP. If the AAAH doesn't generate the Foreign-Home session key, then upon receipt of the HAA, the AAAH extracts and passes the MIP-FA-to-HA-SPI AVP (if present in the HAR) in the AMA, and extracts and passes the HAA-to-AMA-Data AVP (if present in the HAR) in the AMA. If the AAAF receives an AMA which contains a HAA-to-AMA-Data AVP, the AAAF will recreate the FA-HA key, generate a MIP-FA-to-HA-Key AVP, and pass the MIP-FA-to-HA-Key AVP to the FA. Alternatively, if the AAAF generates the Foreign-Home session key, the AAAFs in the foreign network may have a common database among AAAFs, wherein the HA's AAAF may deposit the FA-HA key, which is later retrieved by the FA's AAAF, in a proprietary manner not described in the Diameter documents. From owner-aaa-wg@merit.edu Tue Jan 15 15:21:32 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 PAA12188 for ; Tue, 15 Jan 2002 15:21:31 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 83B689126B; Tue, 15 Jan 2002 15:19:44 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 46C3C91274; Tue, 15 Jan 2002 15:19: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 5D3749126B for ; Tue, 15 Jan 2002 15:19:40 -0500 (EST) Received: by segue.merit.edu (Postfix) id 40FE55DDC7; Tue, 15 Jan 2002 15:19:40 -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 5104E5DDA5 for ; Tue, 15 Jan 2002 15:19:39 -0500 (EST) Received: from knox6039.cisco.com (knox6039.cisco.com [161.44.216.39]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id PAA18737; Tue, 15 Jan 2002 15:19:07 -0500 (EST) Received: (from meklund@localhost) by knox6039.cisco.com (8.9.3+Sun/8.9.3) id PAA02304; Tue, 15 Jan 2002 15:16:48 -0500 (EST) From: Mark Eklund MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15428.36400.807676.51365@gargle.gargle.HOWL> Date: Tue, 15 Jan 2002 15:16:48 -0500 To: "Bob Kopacz" Cc: "aaa-wg" Subject: Re: [AAA-WG]: [issue] Returning AAAF-Generated FA-HA Key to FA In-Reply-To: References: X-Mailer: VM 6.93 under Emacs 21.1.1 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Bob, I concur with your description of this Issue and the solution. -mark From owner-aaa-wg@merit.edu Wed Jan 16 03:16: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 DAA02528 for ; Wed, 16 Jan 2002 03:16:41 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id BC7299127D; Wed, 16 Jan 2002 03:15:35 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 75FA29127F; Wed, 16 Jan 2002 03:15: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 4745C9127D for ; Wed, 16 Jan 2002 03:15:34 -0500 (EST) Received: by segue.merit.edu (Postfix) id 70B785DDAD; Wed, 16 Jan 2002 03:15:33 -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 0C64D5DDD3 for ; Wed, 16 Jan 2002 03:15:27 -0500 (EST) Received: from fredrikj (hotel-14.local.ipunplugged.com [192.168.8.14]) by mailgw.ipunplugged.com (8.9.3/8.9.3) with SMTP id JAA28367; Wed, 16 Jan 2002 09:13:27 +0100 From: "Fredrik Johansson" To: "Bob Kopacz" , "aaa-wg" Subject: RE: [AAA-WG]: [issue] Returning AAAF-Generated FA-HA Key to FA Date: Wed, 16 Jan 2002 09:15:34 +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 Importance: Normal In-Reply-To: Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit I don't like the idea of "All AAAFs in that foreign realm MUST have an agreed upon format". This seems like a major source for interoperablity problems. I belive the format and thus the AVP should be standardized, or you will limit yourself to use only one vendor for all AAAF's. To me, having a HAA-to-AMA-Data AVP which is just a blob with a format which has to be agreed upon from case to case depending on what data you would like to convey, it's just another format for a vendor specific AVP. If we should have a way to send data from AAAF1 to AAAF2 I suggest making the HAA-to-AMA-Data AVP a grouped AVP and force the AAAH to copy the AVPs included in the HAA-to-AMA-Data AVP into the AMA. We can then use this AVP to send the FA to HA key (which should be in a standardized format). my 2c /Fredrik >-----Original Message----- >From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of >Bob Kopacz >Sent: den 15 januari 2002 20:40 >To: aaa-wg >Subject: [AAA-WG]: [issue] Returning AAAF-Generated FA-HA Key to FA > > >Issue : Returning AAAF-Generated FA-HA Key to FA >Submitter name: Bob Kopacz >Submitter email address: BKopacz@InterlinkNetworks.com >Date first submitted: 01-15-2002 >Reference: >Document: mobileip >Comment type: Technical >Priority: 1 >Section: 2.2, 2.4, 5.4, 8.1, Issue#203 >Rationale/Explanation of issue: > > [The following is based on some issue#203-related emails > exchanged with Mark Eklund. The proposal I'm contributing here > is also Mark's, as I understand it] > > > When the HA is in the foreign network and a FA-HA key is > requested, the AAAF, rather than the AAAH, generates the key. > > Here's the diagram of the issue: > > amr-> amr-> > FA --------> AAAF1 -------------> AAAH > <-ama <-ama | > | ^ > | | > har | haa > | | > V | > | > <-har <-har | > HA <-------- AAAF2 <---------------/ > haa-> haa-> > > In the above diagram, FA & HA & AAAF1 & AAAF2 are all in the same > visited network. AAAF1 and AAAF2 may be the same server, or may > be different servers. > > In the above diagram, AAAF2 generates the FA-HA key. > > The problem is that this key must somehow be returned to the FA > via AAAF1. The proposal here is to pass the key back to the FA > via the the HAA and AMA messages. AAAF2 may be concerned about > security, so may want the FA-HA key to be passed encrypted so > that AAAH and intervening servers can't figure it out, but AAAF1 > can somehow decrypt it. > > The details are: > > 1. A new HAA-to-AMA-Data AVP, of type octetstring, is created. > The purpose of this AVP is convey information from the HA's AAAF > (AAAF2) to the FA's AAAF (AAAF1). All AAAFs in that foreign > realm MUST have an agreed upon format and security method for > this AVP to be used. (It may be possible to use CMS security > to somehow encrypt this AVP, but it is unclear just how, as it > involves the AAAH copying a secure AVP from the HAA to the AMA, > and the AMA may carry both AAAH-FA and AAAF1-AAAF2 secured > AVPs) > > 2. When the FA-HA key is generated by AAAF2, this key must > somehow be conveyed to AAAF1. There are two ways to do this: > a. Use the MIP-HAA-to-AMA-Data AVP, or > b Have a common database among AAAFs in the foreign network, > wherein AAAF2 may deposit the FA-HA key, which is later retrieved > by AAAF1, in a proprietary manner not described in the Diameter > documents. > > 3. If the HAA-to-AMA-Data AVP is present in the HAA, the AAAH > treats it as opaque data and passes it in the AMA. > > 4, If AAAF1 receives the HAA-to-AMA-Data AVP in the AMA, AAAF1 > will use this AVP to recreate the FA-HA key, and replace this AVP > by a MIP-FA-to-HA-Key AVP in the AMA sent to the FA. > > >Requested change: > > This issues supercedes issue#203, which also addresses the > problem of returning an AAAF-Generated FA-HA Key to the FA, but > didn't quite work in the case where there was a 2nd AAAF > involved. > > In section 2.2. Add [HAA-to-AMA-Data] to the AMA ABNF. > > In section 2.4. Add [HAA-to-AMA-Data] to the HAA ABNF. > > In section 6, define the following new AVP: > > 6.x HAA-to-AMA-Data AVP > > The HAA-to-AMA-Data AVP (AVP Code TBD) is of type OctetString and > may be used, when the HA is allocated in the foreign network and > the HA's AAAF generates the FA-HA key, to convey the FA-HA key > information (in some proprietary format and security method which > is agreed-upon by all AAAF servers in the foreign network) back > to the FA's AAAF. > > In section 8.1. Add a row for the new HAA-to-AMA-Data AVP, with these > occurrence rules: AMR 0, AMA 0-1, HAR 0, HAA 0-1. > > Replace section 5.4 by > > If the home agent is in the home realm, then AAAH has to generate > the Foreign-Home session key. Otherwise, it is generated by the > AAAF receiving the HAR. > > If the AAAH generates the Foreign-Home session key, then the AAAH > includes the session key in the MIP-HA-to-FA-Key AVP, and > includes the AVP as part of the HAR message sent to the home > agent. The corresponding session key that is to be sent to the > foreign agent is cached on the AAAH until the HAA is received, at > which time the AAAH adds the MIP-FA-to-HA Key AVP to the AMA, > using the SPI in the MIP-FA-to-HA-SPI. > > Upon receipt of the HAR, the home agent recovers the Foreign-Home > session key, allocates an SPI to be used with the key. The > allocated SPI is included in the HAA's MIP-FA-to-HA SPI AVP. > > If the AAAH doesn't generate the Foreign-Home session key, then > upon receipt of the HAA, the AAAH extracts and passes the > MIP-FA-to-HA-SPI AVP (if present in the HAR) in the AMA, and > extracts and passes the HAA-to-AMA-Data AVP (if present in the > HAR) in the AMA. > > If the AAAF receives an AMA which contains a HAA-to-AMA-Data AVP, > the AAAF will recreate the FA-HA key, generate a MIP-FA-to-HA-Key > AVP, and pass the MIP-FA-to-HA-Key AVP to the FA. > > Alternatively, if the AAAF generates the Foreign-Home session > key, the AAAFs in the foreign network may have a common database > among AAAFs, wherein the HA's AAAF may deposit the FA-HA key, > which is later retrieved by the FA's AAAF, in a proprietary > manner not described in the Diameter documents. From owner-aaa-wg@merit.edu Wed Jan 16 03:31: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 DAA02705 for ; Wed, 16 Jan 2002 03:31:54 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 38B099127F; Wed, 16 Jan 2002 03:31:33 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0872891280; Wed, 16 Jan 2002 03:31: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 EE6AB9127F for ; Wed, 16 Jan 2002 03:31:31 -0500 (EST) Received: by segue.merit.edu (Postfix) id C1CA25DDD3; Wed, 16 Jan 2002 03:31:31 -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 C5AB25DD9A for ; Wed, 16 Jan 2002 03:31:30 -0500 (EST) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0G8VFu15205 for ; Wed, 16 Jan 2002 10:31:16 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 16 Jan 2002 10:31:29 +0200 Received: from esebe014.NOE.Nokia.com ([172.21.138.53]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 16 Jan 2002 10:31:29 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message Subject: [AAA-WG]: One basic question MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Wed, 16 Jan 2002 10:31:29 +0200 Message-ID: <9E3407CE45911B4097632389B77B202306CFF9@esebe014.NOE.Nokia.com> Thread-Topic: One basic question Thread-Index: AcGeaDaGwzV9Dwm5EdatbgAADnz2vQ== From: "Ghadiyaram Venkata (EXT-TataConsultancy/Helsinki)" To: X-OriginalArrivalTime: 16 Jan 2002 08:31:29.0882 (UTC) FILETIME=[322F1BA0:01C19E68] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA02705 Hi, I have one question out of curiosity. What if the AVP header also contains the data type information? 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V M P D r r r r| AVP Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor-ID (opt) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DataType code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data ... +-+-+-+-+-+-+-+-+ DataType code - The code representing the data type. D flag - Tells wheher the data type is vendor specific or not. I feel that this reduces a lot of overhead on the implementations. Any comments... Is this already considered previously. If yes, why is it rejected. Thanks and regards, Kishore From owner-aaa-wg@merit.edu Wed Jan 16 04:20: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 EAA03173 for ; Wed, 16 Jan 2002 04:20:16 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1644191210; Wed, 16 Jan 2002 04:20:05 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DA5F391280; Wed, 16 Jan 2002 04:20:04 -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 C3F1691210 for ; Wed, 16 Jan 2002 04:20:03 -0500 (EST) Received: by segue.merit.edu (Postfix) id 92BE75DDD8; Wed, 16 Jan 2002 04:20:03 -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 D5D2D5DD9A for ; Wed, 16 Jan 2002 04:20:02 -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 g0G9K3908655 for ; Wed, 16 Jan 2002 11:20:03 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 16 Jan 2002 11:20:01 +0200 Received: from beebh001.NOE.Nokia.com ([172.28.19.38]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 16 Jan 2002 11:20:01 +0200 Received: from beebe001.NOE.Nokia.com ([172.28.19.42]) by beebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 16 Jan 2002 17:19:54 +0800 content-class: urn:content-classes:message Subject: RE: [AAA-WG]: One basic question MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Date: Wed, 16 Jan 2002 17:19:54 +0800 Message-ID: <4AE1AC3D692F55488F2D03518907B8AD1D43F2@beebe001.NOE.Nokia.com> Thread-Topic: [AAA-WG]: One basic question Thread-Index: AcGeaD++wl5ZnQpYEdar0gAIx6S5QwABkTwg From: "Li Chunan (Nokia-RD/Beijing)" To: "Ghadiyaram Venkata (EXT-TataConsultancy/Helsinki)" , X-OriginalArrivalTime: 16 Jan 2002 09:19:54.0481 (UTC) FILETIME=[F575BE10:01C19E6E] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id EAA03173 Hi That's a good question. If the AVP data type is known in advance, it will be helpful to save and access the AVP data in real Diameter implementation. B.R. Li ChunAn ---------------------------------------------------- Advanced Internet Technologies Group Communication Systems Laboratory Nokia Research Center No.11, Hepingli Dongjie, Beijing, 100013 Email: chunan.li@nokia.com MP: +86 13601028331 -----Original Message----- From: ext Ghadiyaram Venkata (EXT-TataConsultancy/Helsinki) Sent: Wednesday, January 16, 2002 4:31 PM To: aaa-wg@merit.edu Subject: [AAA-WG]: One basic question Hi, I have one question out of curiosity. What if the AVP header also contains the data type information? 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V M P D r r r r| AVP Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor-ID (opt) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DataType code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data ... +-+-+-+-+-+-+-+-+ DataType code - The code representing the data type. D flag - Tells wheher the data type is vendor specific or not. I feel that this reduces a lot of overhead on the implementations. Any comments... Is this already considered previously. If yes, why is it rejected. Thanks and regards, Kishore From owner-aaa-wg@merit.edu Wed Jan 16 09:26: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 JAA08530 for ; Wed, 16 Jan 2002 09:26:35 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id BA28D91284; Wed, 16 Jan 2002 09:26:24 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8BCF1912B4; Wed, 16 Jan 2002 09:26: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 739D491284 for ; Wed, 16 Jan 2002 09:26:23 -0500 (EST) Received: by segue.merit.edu (Postfix) id 423B35DDEC; Wed, 16 Jan 2002 09:26:23 -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 E9D165DDEA for ; Wed, 16 Jan 2002 09:26:17 -0500 (EST) Received: (qmail 9388 invoked by uid 507); 16 Jan 2002 14:26:07 -0000 Date: Wed, 16 Jan 2002 08:26:05 -0600 From: David Frascone To: "Li Chunan (Nokia-RD/Beijing)" Cc: "Ghadiyaram Venkata (EXT-TataConsultancy/Helsinki)" , aaa-wg@merit.edu Subject: Re: [AAA-WG]: One basic question Message-ID: <20020116142605.GV657@newman.frascone.com> Mail-Followup-To: "Li Chunan (Nokia-RD/Beijing)" , "Ghadiyaram Venkata (EXT-TataConsultancy/Helsinki)" , aaa-wg@merit.edu References: <4AE1AC3D692F55488F2D03518907B8AD1D43F2@beebe001.NOE.Nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4AE1AC3D692F55488F2D03518907B8AD1D43F2@beebe001.NOE.Nokia.com> User-Agent: Mutt/1.3.25i X-encrypt-payload: no X-Virus-Scanned: by AMaViS perl-11 Sender: owner-aaa-wg@merit.edu Precedence: bulk But, then why have a dictionary at all. What could you do with a type that you couldn't do with the AVP code? I mean, let's say you get an unknown AVP, where the data type tells you it's an OctetString. Now what do you have that you didn't have before? I suppose you could have better debugging information i.e.: "Received unknown AVP 0x29485 Value:"qwerty" But, I don't see that it adds any additional functionality to the protocol itself. So, I'm against this change. -Dave On Wednesday, 16 Jan 2002, Li Chunan (Nokia-RD/Beijing) wrote: > Hi > > That's a good question. If the AVP data type is known in advance, it > will be helpful to save and access the AVP data in real Diameter > implementation. > > > B.R. > > Li ChunAn > ---------------------------------------------------- > Advanced Internet Technologies Group > Communication Systems Laboratory > Nokia Research Center > No.11, Hepingli Dongjie, Beijing, 100013 > Email: chunan.li@nokia.com > MP: +86 13601028331 > > > -----Original Message----- > From: ext Ghadiyaram Venkata (EXT-TataConsultancy/Helsinki) > Sent: Wednesday, January 16, 2002 4:31 PM > To: aaa-wg@merit.edu > Subject: [AAA-WG]: One basic question > > > Hi, > > I have one question out of curiosity. > > What if the AVP header also contains the data type information? > > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | AVP Code | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |V M P D r r r r| AVP Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Vendor-ID (opt) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | DataType code | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Data ... > +-+-+-+-+-+-+-+-+ > > DataType code - The code representing the data type. > D flag - Tells wheher the data type is vendor specific or not. > > I feel that this reduces a lot of overhead on the implementations. Any > comments... > > Is this already considered previously. If yes, why is it rejected. > > Thanks and regards, > Kishore > From owner-aaa-wg@merit.edu Wed Jan 16 09:52: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 JAA09677 for ; Wed, 16 Jan 2002 09:52:37 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id ADB7D912BF; Wed, 16 Jan 2002 09:51:23 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7CEC6912BE; Wed, 16 Jan 2002 09:51: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 76E47912B9 for ; Wed, 16 Jan 2002 09:51:19 -0500 (EST) Received: by segue.merit.edu (Postfix) id 441115DE06; Wed, 16 Jan 2002 09:51:19 -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 BB2655DDF6 for ; Wed, 16 Jan 2002 09:51:04 -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 g0GEp5900801 for ; Wed, 16 Jan 2002 16:51:05 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 16 Jan 2002 16:51:03 +0200 Received: from esebe014.NOE.Nokia.com ([172.21.138.53]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 16 Jan 2002 16:51:03 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message Subject: RE: [AAA-WG]: One basic question MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Wed, 16 Jan 2002 16:51:03 +0200 Message-ID: <9E3407CE45911B4097632389B77B202306CFFC@esebe014.NOE.Nokia.com> Thread-Topic: [AAA-WG]: One basic question Thread-Index: AcGemdHlDioosQqNEdaJYgAIx6TWpQAAJgHQ From: "Ghadiyaram Venkata (EXT-TataConsultancy/Helsinki)" To: "'ext David Frascone'" , "Li Chunan (Nokia-RD/Beijing)" Cc: X-OriginalArrivalTime: 16 Jan 2002 14:51:03.0637 (UTC) FILETIME=[38665850:01C19E9D] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA09677 Hi, That was my point. "Why have a AVP Dictionary at all?" Why should the base protocol assume that there is going to be a Dictionary. There are two aspects to this. 1. Parsing the Diameter message. 2. Handling/Serving the Diameter message. If an implementation has to access the AVP dictionary for each AVP that is present in the message in order to parse it and validate it, are we not losing on efficiency. During handling the message the dictionary MAY be required. If it is required the imlementation searches for the descriptors of the AVPs which it is interested in the message rather than ALL the AVPs. "What could you do with a type that you couldn't do with the AVP code?" So I could parse the message without accessing the dictionary. It is not just the question of debugging information but a lot more than that. Regards, Kishore -----Original Message----- From: ext David Frascone [mailto:dave@frascone.com] Sent: 16. January 2002 16:26 To: Li Chunan (Nokia-RD/Beijing) Cc: Ghadiyaram Venkata (EXT-TataConsultancy/Helsinki); aaa-wg@merit.edu Subject: Re: [AAA-WG]: One basic question But, then why have a dictionary at all. What could you do with a type that you couldn't do with the AVP code? I mean, let's say you get an unknown AVP, where the data type tells you it's an OctetString. Now what do you have that you didn't have before? I suppose you could have better debugging information i.e.: "Received unknown AVP 0x29485 Value:"qwerty" But, I don't see that it adds any additional functionality to the protocol itself. So, I'm against this change. -Dave On Wednesday, 16 Jan 2002, Li Chunan (Nokia-RD/Beijing) wrote: > Hi > > That's a good question. If the AVP data type is known in advance, it > will be helpful to save and access the AVP data in real Diameter > implementation. > > > B.R. > > Li ChunAn > ---------------------------------------------------- > Advanced Internet Technologies Group > Communication Systems Laboratory > Nokia Research Center > No.11, Hepingli Dongjie, Beijing, 100013 > Email: chunan.li@nokia.com > MP: +86 13601028331 > > > -----Original Message----- > From: ext Ghadiyaram Venkata (EXT-TataConsultancy/Helsinki) > Sent: Wednesday, January 16, 2002 4:31 PM > To: aaa-wg@merit.edu > Subject: [AAA-WG]: One basic question > > > Hi, > > I have one question out of curiosity. > > What if the AVP header also contains the data type information? > > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | AVP Code | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |V M P D r r r r| AVP Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Vendor-ID (opt) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | DataType code | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Data ... > +-+-+-+-+-+-+-+-+ > > DataType code - The code representing the data type. > D flag - Tells wheher the data type is vendor specific or not. > > I feel that this reduces a lot of overhead on the implementations. Any > comments... > > Is this already considered previously. If yes, why is it rejected. > > Thanks and regards, > Kishore > From owner-aaa-wg@merit.edu Wed Jan 16 10:06: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 KAA10287 for ; Wed, 16 Jan 2002 10:06:11 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D19EF912B6; Wed, 16 Jan 2002 10:05:57 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 951F6912B7; Wed, 16 Jan 2002 10:05: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 8F30D912B6 for ; Wed, 16 Jan 2002 10:05:56 -0500 (EST) Received: by segue.merit.edu (Postfix) id 652675DDFB; Wed, 16 Jan 2002 10:05: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 BE8BF5DDC1 for ; Wed, 16 Jan 2002 10:05:55 -0500 (EST) Received: (qmail 9919 invoked by uid 507); 16 Jan 2002 15:05:55 -0000 Date: Wed, 16 Jan 2002 09:05:53 -0600 From: David Frascone To: "Ghadiyaram Venkata (EXT-TataConsultancy/Helsinki)" Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: One basic question Message-ID: <20020116150553.GW657@newman.frascone.com> Mail-Followup-To: "Ghadiyaram Venkata (EXT-TataConsultancy/Helsinki)" , aaa-wg@merit.edu References: <9E3407CE45911B4097632389B77B202306CFFC@esebe014.NOE.Nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9E3407CE45911B4097632389B77B202306CFFC@esebe014.NOE.Nokia.com> User-Agent: Mutt/1.3.25i X-encrypt-payload: no X-Virus-Scanned: by AMaViS perl-11 Sender: owner-aaa-wg@merit.edu Precedence: bulk > There are two aspects to this. > > 1. Parsing the Diameter message. > 2. Handling/Serving the Diameter message. > > If an implementation has to access the AVP dictionary for each AVP that > is present in the message in order to parse it and validate it, are we > not losing on efficiency. During handling the message the dictionary MAY > be required. If it is required the imlementation searches for the > descriptors of the AVPs which it is interested in the message rather > than ALL the AVPs. > > "What could you do with a type that > you couldn't do with the AVP code?" > > So I could parse the message without accessing the dictionary. It is not > just the question of debugging information but a lot more than that. I disagree. You will know the format of the data's syntax, but not what it means. (Basic Syntatic-vs-Symmantic problem) So, Let's say you do get an OctetString. What is it? Username? Password? Credit Card number? Since you can't know what the data *is*, you have to have a dictionary anyway. So, since symmantic defination has to happen somewhere, there is no need for the overhead of the syntactic definition in the AVP. As far as parsing goes, you already know the length of the data, which is all you need to parse it. Why would you need to know it's type,for anything other than display purposes? -Dave From owner-aaa-wg@merit.edu Wed Jan 16 10:26:07 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 KAA11007 for ; Wed, 16 Jan 2002 10:26:06 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 67937912B9; Wed, 16 Jan 2002 10:25:54 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3941E912BA; Wed, 16 Jan 2002 10:25: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 1AF17912B9 for ; Wed, 16 Jan 2002 10:25:53 -0500 (EST) Received: by segue.merit.edu (Postfix) id E20915DDFE; Wed, 16 Jan 2002 10:25:52 -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 F3FE65DE03 for ; Wed, 16 Jan 2002 10:25: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 g0GFPuk23182 for ; Wed, 16 Jan 2002 17:25:56 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 16 Jan 2002 17:25:50 +0200 Received: from esebe014.NOE.Nokia.com ([172.21.138.53]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 16 Jan 2002 17:25:50 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message Subject: RE: [AAA-WG]: One basic question MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Wed, 16 Jan 2002 17:25:50 +0200 Message-ID: <9E3407CE45911B4097632389B77B202306CFFD@esebe014.NOE.Nokia.com> Thread-Topic: [AAA-WG]: One basic question Thread-Index: AcGen01+AAkr7wqREdar0gAIx6S5QwAADhCQ From: "Ghadiyaram Venkata (EXT-TataConsultancy/Helsinki)" To: "'ext David Frascone'" Cc: X-OriginalArrivalTime: 16 Jan 2002 15:25:50.0731 (UTC) FILETIME=[14679DB0:01C19EA2] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA11007 Hi, During parsing I do not have to know what it means. But I have to know whether the length that I have received is correct or not. For example, if the data type field is present, if a ill-formed Diameter message arrives, with an AVP of data type Integer32 and the length of the AVP as 100, I know immediately what to do with the message according to my policy, and I do not need the dictionary access at all. "So, Let's say you do get an OctetString. What is it? Username? Password? Credit Card number?" The parser do not have to know what it exactly means. The handler knows whether it means a Username etc. For this the handler may use any means and only one of them is maintaining a dictionary. By dictionary if you are referring to the dictionary described in "draft-ietf-aaa-diameter-api-01.txt", teh AVPDescriptor does not contain any extra information from the AVPHeader than the data type. And if the data type is also present in the header the dictionary can be avoided. So the data type field is not for display purposes. Regards, Kishore -----Original Message----- From: ext David Frascone [mailto:dave@frascone.com] Sent: 16. January 2002 17:06 To: Ghadiyaram Venkata (EXT-TataConsultancy/Helsinki) Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: One basic question > There are two aspects to this. > > 1. Parsing the Diameter message. > 2. Handling/Serving the Diameter message. > > If an implementation has to access the AVP dictionary for each AVP that > is present in the message in order to parse it and validate it, are we > not losing on efficiency. During handling the message the dictionary MAY > be required. If it is required the imlementation searches for the > descriptors of the AVPs which it is interested in the message rather > than ALL the AVPs. > > "What could you do with a type that > you couldn't do with the AVP code?" > > So I could parse the message without accessing the dictionary. It is not > just the question of debugging information but a lot more than that. I disagree. You will know the format of the data's syntax, but not what it means. (Basic Syntatic-vs-Symmantic problem) So, Let's say you do get an OctetString. What is it? Username? Password? Credit Card number? Since you can't know what the data *is*, you have to have a dictionary anyway. So, since symmantic defination has to happen somewhere, there is no need for the overhead of the syntactic definition in the AVP. As far as parsing goes, you already know the length of the data, which is all you need to parse it. Why would you need to know it's type,for anything other than display purposes? -Dave From owner-aaa-wg@merit.edu Wed Jan 16 10:37: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 KAA11476 for ; Wed, 16 Jan 2002 10:37:35 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id ABFA9912BB; Wed, 16 Jan 2002 10:37:18 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7B996912BC; Wed, 16 Jan 2002 10:37: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 4F1E5912BB for ; Wed, 16 Jan 2002 10:37:17 -0500 (EST) Received: by segue.merit.edu (Postfix) id 35F195DDFA; Wed, 16 Jan 2002 10:37:17 -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 B0F055DDA5 for ; Wed, 16 Jan 2002 10:37:16 -0500 (EST) Received: (qmail 10337 invoked by uid 507); 16 Jan 2002 15:37:16 -0000 Date: Wed, 16 Jan 2002 09:37:14 -0600 From: David Frascone To: "Ghadiyaram Venkata (EXT-TataConsultancy/Helsinki)" Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: One basic question Message-ID: <20020116153714.GY657@newman.frascone.com> Mail-Followup-To: "Ghadiyaram Venkata (EXT-TataConsultancy/Helsinki)" , aaa-wg@merit.edu References: <9E3407CE45911B4097632389B77B202306CFFD@esebe014.NOE.Nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9E3407CE45911B4097632389B77B202306CFFD@esebe014.NOE.Nokia.com> User-Agent: Mutt/1.3.25i X-encrypt-payload: no X-Virus-Scanned: by AMaViS perl-11 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Wednesday, 16 Jan 2002, Ghadiyaram Venkata (EXT-TataConsultancy/Helsinki) wrote: > Hi, > > During parsing I do not have to know what it means. But I have to know > whether the length that I have received is correct or not. For example, > if the data type field is present, if a ill-formed Diameter message > arrives, with an AVP of data type Integer32 and the length of the AVP as > 100, I know immediately what to do with the message according to my > policy, and I do not need the dictionary access at all. So, you simply want the type there to be able to detect invalid lengths of avps? Is there any other benefit to having it present? > "So, Let's say you do get an OctetString. What is it? Username? > Password? > Credit Card number?" > > The parser do not have to know what it exactly means. The handler knows > whether it means a Username etc. For this the handler may use any means > and only one of them is maintaining a dictionary. By dictionary if you > are referring to the dictionary described in > "draft-ietf-aaa-diameter-api-01.txt", teh AVPDescriptor does not contain > any extra information from the AVPHeader than the data type. And if the > data type is also present in the header the dictionary can be avoided. By dictionary, I mean any internal definition you use to say that AvpCode 2 is a User-Name. In RADIUS, it was called a dictionary. I'm assuming that by "handler" you mean the application that is parsing the message. Since *something* has to maintain a dictionary to parse/handle the message, why do you want to add that redundant information to the protocol on the wire? We could always just transmit the data in XML, and get rid of the dictionary all together. So far, I only see two reasons to add the field: o To try to detect invalid Diameter messages. (The space could probably better used to hold a simple magic number, i.e. 0xdeadbabe) o To add in displaying the data for debugging. I do not think either of these is worth adding redundant information to the protocol on the wire. -Dave From owner-aaa-wg@merit.edu Wed Jan 16 10:58: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 KAA12180 for ; Wed, 16 Jan 2002 10:58:39 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id CD0B5912B7; Wed, 16 Jan 2002 10:58:29 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A0C25912BD; Wed, 16 Jan 2002 10:58: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 9ADCA912B7 for ; Wed, 16 Jan 2002 10:58:28 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6E2C15DDE7; Wed, 16 Jan 2002 10:58:28 -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 E89EA5DDA5 for ; Wed, 16 Jan 2002 10:58:27 -0500 (EST) Received: from ehdb03-home.Germany.Sun.COM ([129.157.142.202]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA24142; Wed, 16 Jan 2002 08:58:24 -0700 (MST) Received: from field (field [129.157.142.146]) by ehdb03-home.Germany.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v2.1p1) with SMTP id QAA20241; Wed, 16 Jan 2002 16:58:22 +0100 (MET) Date: Wed, 16 Jan 2002 16:57:53 +0100 (MET) From: Erik Guttman X-Sender: erikg@field To: aaa-wg@merit.edu Cc: "Li Chunan (Nokia-RD/Beijing)" , "Ghadiyaram Venkata (EXT-TataConsultancy/Helsinki)" Subject: Re: [AAA-WG]: One basic question In-Reply-To: <20020116142605.GV657@newman.frascone.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Kishore, > What if the AVP header also contains the data type information? An AVP is an attribute value pair. The attribute is identified by an ID. If you recognize the ID, you know what type it has. If you do not recognize it, you know the length of the AVP and may skip it. Explicit type fields in protocols yield limited benefit. ASN1 vs. non-ASN1 debates are boring - let's not have one here. Erik From owner-aaa-wg@merit.edu Wed Jan 16 12:24:09 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 MAA14764 for ; Wed, 16 Jan 2002 12:24:08 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 0DC5891286; Wed, 16 Jan 2002 12:23:57 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C2C2C91288; Wed, 16 Jan 2002 12:23: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 A891C91286 for ; Wed, 16 Jan 2002 12:23:55 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7E70C5DE06; Wed, 16 Jan 2002 12:23:55 -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 ED85C5DE05 for ; Wed, 16 Jan 2002 12:23:54 -0500 (EST) Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0GHPNQ18393 for ; Wed, 16 Jan 2002 11:25:23 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 16 Jan 2002 11:23:48 -0600 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 16 Jan 2002 11:23:08 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message Subject: [AAA-WG]: Issue 235 - Enabling efficient accounting record uniqueness checking MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Wed, 16 Jan 2002 11:23:08 -0600 Message-ID: <697DAA22C5004B4596E033803A7CEF444CD482@daebe007.NOE.Nokia.com> Thread-Topic: Issue 235 - Enabling efficient accounting record uniqueness checking Thread-Index: AcGesnlfICf4Ngp4EdaxgQAAhj/HZA== From: "Patil Basavaraj (NET/Dallas)" To: X-OriginalArrivalTime: 16 Jan 2002 17:23:08.0624 (UTC) FILETIME=[7750DD00:01C19EB2] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA14764 Hello, At IETF52, Issue 235 was discussed and postponed in lieu of further clarificaions. Below is a revised version of the issue and the justifications. I will post further clarifications in a followup email. -Basavaraj ---------------------------------------------------------------- Issue 235: Enabling efficient accounting record uniqueness checking Submitter name: Basavaraj Patil Submitter email address: Basavaraj.Patil@nokia.com Date first submitted: November 9, 2001 Reference: Document: Base-08 Comment type: T Priority: 1 Section: 3.0, 9.4 Rationale/Explanation of issue: If a Diameter server does not have any indicator in the received Accounting Requests for the message being potentially duplicated, the Diameter server (or a separate Accounting System) would have to do a vast amount of unnecessary work just for the Accounting Request uniqueness checking. With more and more "hot billing" systems and prepaid billing for packet data becoming prevalent it becomes a requirement for accounting messages (records) to be sent far more frequently and also enabling speedy evaluation for accuracy and uniqueness. For accounting, the section 9.4 (Fault Resilence) defines that duplication detection must be based on the inspection of the Session-Id and Accounting-Record-Number AVP pairs. The current draft text assumes that every accounting message would be cross-checked with these identifiers against the others, to detect duplicate accounting messages. However it is far more efficient to o first check if the Accounting Request sender has flagged the message to be a potential duplicate. (Duplicate messages may be generated in the exceptional cases when a communication link between Diameter peers goes down. This could happen due to the sending node failure or the receiving node failure or the communication link itself failing. e.g. physically damaged. When the sending node is redirecting the traffic to an alternate peer or able to communicate again after a temporary link failure to the primary peer, it may send again messages that have not yet been acknowledged by a recipient node.) Duplicates are generated very seldom. (Typically just a few packets, for eg. after a link failure case.) Therefore duplicate checking all-against-all, by seems a processing intensive work and one that is unnecessary to be performed by accounting servers. (by the Diameter server or a billing system). The 'D' bit would be for all such accounting requests that were pending an application layer ack when the connection went down, whether they are resent on a connection to the same peer or an alternate peer. In failover scenarios, duplicate checking may not necessarily be done in the Diameter Server. It may alternatively be done in a billing engine. In that case the billing engine should get the 'D' bit information from the Diameter header, as delivered together with the payload. (It should be noted that the potentially duplicated accounting message may arrive earlier at the end system than a non-marked original accounting message. This is the case with any duplicate occurrence scenario, but is not a problem as the end system should anyway have some time buffer, e.g. 24h or 12h, for the received accounting records to be checked for duplicates.) The significant benefit achieved here is the decrease of uniqueness checking processing comparisons 1) from e.g. 77 octets to 1 bit and 2) from cross-comparing all accounting messages in the time buffer against each other to comparing just the very few potentially duplicated accounting messages to all other accounting messages in the uniqueness checking time buffer. The End-to-End Identifier could in theory be also utilized by the uniqueness checkings in accounting but has not been defined. Additionally, the End-to-End Identifier has recently been considered to be unique only during a very limited time period, e.g. 4 minutes, which would not always be long enough when e.g. a sending Diameter client node is in temporary isolation due to a network failure for several hours. The scheme proposed here does does not limit the Diameter Server or billing engine to do the uniqueness checking in any other way. (eg. all accounting records checked against each other, by the long AVP pair octet strings). Requested change: ================= In section 3.0 Diameter Header ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R P E r r r r r| Command-Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ would be: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R P E D r r r r| Command-Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ and E(rror) - If set, the message contains a protocol error, and the message will not conform to the ABNF described for this command. Messages with the 'E' bit set is commonly referred to as an error message. This bit MUST NOT be set in request messages. See section 7.2. r(eserved) - these flag bits are reserved for future use, and MUST be set to zero, otherwise an error MUST be sent to the sender. would get one new flag bit 'D': E(rror) - If set, the message contains a protocol error, and the message will not conform to the ABNF described for this command. Messages with the 'E' bit set is commonly referred to as an error message. This bit MUST NOT be set in request messages. See section 7.2. (possibly) D(uplicated) - This bit is defined only for Accounting Requests, sent by a Diameter node or proxy. If set, the message is possibly a duplicate, and must be later checked by a recipient node if it really is a duplicate. If sending a message for first time, this bit MUST be cleared. This bit MUST NOT be set if an answer message (about e.g. a protocol error) has been got for an earlier similar message. It can be used only in cases where no answer has been got from the primary agent for a message and the message is sent again (e.g. due to a failover, to an alternate agent or to a recovered primary peer node). r(eserved) - these flag bits are reserved for future use, and MUST be set to zero, otherwise an error MUST be sent to the sender. and in section 9.4 Fault Resilience ==================================== ... Diameter peers acting as clients MUST implement the use of failover to guard against server failures and certain network failures. Diameter peers acting as agents or related off-line processing systems MUST detect duplicate accounting records caused by the sending of same record to several servers and duplication of messages in transit. This detection MUST be based on the inspection of the Session-Id and Accounting-Record-Number AVP pairs. the above paragraph would get one sentence to its end: The inspection MUST be performed at least for such records that arrived at the Diameter peer specifically in accounting messages which have the 'D' bit set. From owner-aaa-wg@merit.edu Wed Jan 16 12:31: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 MAA15097 for ; Wed, 16 Jan 2002 12:31:28 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3C60491288; Wed, 16 Jan 2002 12:30:37 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 04A2A91289; Wed, 16 Jan 2002 12:30: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 1246E91288 for ; Wed, 16 Jan 2002 12:30:36 -0500 (EST) Received: by segue.merit.edu (Postfix) id 98FE75DE12; Wed, 16 Jan 2002 12:30:34 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by segue.merit.edu (Postfix) with ESMTP id 44C275DDFE for ; Wed, 16 Jan 2002 12:30:34 -0500 (EST) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate.mot.com (motgate 2.1) with ESMTP id KAA21340 for ; Wed, 16 Jan 2002 10:30:30 -0700 (MST)] Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id KAA00298 for ; Wed, 16 Jan 2002 10:30:29 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2654.52) id ; Wed, 16 Jan 2002 11:30:29 -0600 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0437F46A@IL27EXM10.cig.mot.com> From: Cain Brian-BCAIN1 To: aaa-wg@merit.edu Subject: [AAA-WG]: DIAMETER_INVALID_AVP_LENGTH Result-Code Date: Wed, 16 Jan 2002 11:30:29 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain Sender: owner-aaa-wg@merit.edu Precedence: bulk > DIAMETER_INVALID_AVP_LENGTH 5015 > The request contained an AVP with an invalid length. A Diameter > message indicating this error MUST include the offending AVPs > within a Failed-AVP AVP I can think of two cases for which this result code is pertinent. First, a protocol error, a length field is filled in with an incorrect value by the sender (undetectable until an AVP length field, probably due to misalignment, specifies a length that goes beyond the boundary of the command's length). Second, an AVP with code n correlates to an AVP of type m. In this case, m is a fixed-length field. m's length does not match the length field in this AVP's header. Are both of these cases intended to be served by DIAMETER_INVALID_AVP_LENGTH? Would some clarifying text be in order? -Brian From owner-aaa-wg@merit.edu Wed Jan 16 12:35: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 MAA15187 for ; Wed, 16 Jan 2002 12:35:00 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7EC5191289; Wed, 16 Jan 2002 12:34:41 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 464CB9128A; Wed, 16 Jan 2002 12:34: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 467D391289 for ; Wed, 16 Jan 2002 12:34:40 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2B9835DE1C; Wed, 16 Jan 2002 12:34:40 -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 735505DDFE for ; Wed, 16 Jan 2002 12:34:39 -0500 (EST) Received: (qmail 11776 invoked by uid 507); 16 Jan 2002 17:34:38 -0000 Date: Wed, 16 Jan 2002 11:34:36 -0600 From: David Frascone To: Cain Brian-BCAIN1 Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: DIAMETER_INVALID_AVP_LENGTH Result-Code Message-ID: <20020116173436.GC657@newman.frascone.com> Mail-Followup-To: Cain Brian-BCAIN1 , aaa-wg@merit.edu References: <35DBB8B7AC89D4118E98009027B1009B0437F46A@IL27EXM10.cig.mot.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <35DBB8B7AC89D4118E98009027B1009B0437F46A@IL27EXM10.cig.mot.com> User-Agent: Mutt/1.3.25i X-encrypt-payload: no X-Virus-Scanned: by AMaViS perl-11 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Wednesday, 16 Jan 2002, Cain Brian-BCAIN1 wrote: > > DIAMETER_INVALID_AVP_LENGTH 5015 > > The request contained an AVP with an invalid length. A Diameter > > message indicating this error MUST include the offending AVPs > > within a Failed-AVP AVP > > I can think of two cases for which this result code is pertinent. First, a protocol error, a length field is filled in with an incorrect value by the sender (undetectable until an AVP length field, probably due to misalignment, specifies a length that goes beyond the boundary of the command's length). Second, an AVP with code n correlates to an AVP of type m. In this case, m is a fixed-length field. m's length does not match the length field in this AVP's header. > > Are both of these cases intended to be served by DIAMETER_INVALID_AVP_LENGTH? Would some clarifying text be in order? If the length goes beyond the boundry of the command's length, then it is a protocol error, and this error would not be returned. You're probably trying to parse garbage. The connection will/should be dropped, and an error response is optional. So, I think this error would ONLY be returned, say, if a 32 bit integer AVP had other than 4 bytes in it's data field, or an ip address had more than 16, etc. -Dave From owner-aaa-wg@merit.edu Wed Jan 16 15:29: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 PAA20272 for ; Wed, 16 Jan 2002 15:29:44 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2586E91243; Wed, 16 Jan 2002 15:29:32 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E15929126D; Wed, 16 Jan 2002 15:29: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 E571591243 for ; Wed, 16 Jan 2002 15:29:30 -0500 (EST) Received: by segue.merit.edu (Postfix) id C4E225DDD9; Wed, 16 Jan 2002 15:29:30 -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 28C235DDA7 for ; Wed, 16 Jan 2002 15:29:30 -0500 (EST) Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0GKUtQ08605 for ; Wed, 16 Jan 2002 14:30:55 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 16 Jan 2002 14:29:22 -0600 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 16 Jan 2002 14:28:15 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Invoking AAA during every handoff? Date: Wed, 16 Jan 2002 14:28:15 -0600 Message-ID: <697DAA22C5004B4596E033803A7CEF444CD48A@daebe007.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Invoking AAA during every handoff? Thread-Index: AcGdQ2aGlVrTluuSRPWMmH5lNBUSSQBiNzQQ From: "Patil Basavaraj (NET/Dallas)" To: "'ext Judy Fu'" , X-OriginalArrivalTime: 16 Jan 2002 20:28:15.0706 (UTC) FILETIME=[53A713A0:01C19ECC] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA20272 >I need some help to clarify a question. Will AAA infrastructure need to >be invoked to reauthenticate a mobile node during every handoff when >previous authorization is still valid, if so, then a mobile node needs to >include MN-AAA extension in registration request message everytime during >handoff ? It depends on whether the HO to another FA is intra or inter domain. It is also possible that as part of the handoff process, the context associated with the MN at the previous FA would be transferred to the new FA and this would enable the FA to verify the authenticity of the ongoing session and not require the MN to reauthenticate. Context transfer is being worked on in the Seamoby WG. If the MN has to authenticate every time it performs a HO, the performance of HOs becomes questionable. > >Many thanks. >Judy > -Basavaraj From owner-aaa-wg@merit.edu Wed Jan 16 16:01: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 QAA20903 for ; Wed, 16 Jan 2002 16:01:39 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3CB869126D; Wed, 16 Jan 2002 16:01:08 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 045E69126E; Wed, 16 Jan 2002 16:01: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 B79E79126D for ; Wed, 16 Jan 2002 16:01:06 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8E0825DD93; Wed, 16 Jan 2002 16:01:06 -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 C012B5DD8F for ; Wed, 16 Jan 2002 16:01:05 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id MAA94793 for ; Wed, 16 Jan 2002 12:45:39 -0800 (PST) (envelope-from aboba@internaut.com) Date: Wed, 16 Jan 2002 12:45:39 -0800 (PST) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: IETF 52 Materials Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Thanks to La Monte Yarroll and John Vollbrecht for taking notes at the IETF 52 AAA WG meeting. Minutes from IETF 52 are available at: http://www.drizzle.com/~aboba/AAA/IETF52/ietf52-minutes.txt Presentations from IETF 52 are available at: http://www.drizzle.com/~aboba/AAA/IETF52/presentations.zip From owner-aaa-wg@merit.edu Wed Jan 16 17:43: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 RAA22715 for ; Wed, 16 Jan 2002 17:43:50 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id C024591294; Wed, 16 Jan 2002 17:43:30 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 97DB491295; Wed, 16 Jan 2002 17:43: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 A442A91294 for ; Wed, 16 Jan 2002 17:43:29 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7C1E75DD9C; Wed, 16 Jan 2002 17:43:29 -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 B6FFF5DD90 for ; Wed, 16 Jan 2002 17:43:28 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id OAA94947 for ; Wed, 16 Jan 2002 14:28:02 -0800 (PST) (envelope-from aboba@internaut.com) Date: Wed, 16 Jan 2002 14:28:02 -0800 (PST) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: [issue 188-190]: Proposal from Paul Funk? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk In going over the minutes from IETF 52, I noticed that we asked for proposals on how to resolve issues 188-190 (EAP Keying). Paul Funk volunteered to write up an idea and mail it to the list. So consider this a reminder ;) From owner-aaa-wg@merit.edu Wed Jan 16 18:31: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 SAA23617 for ; Wed, 16 Jan 2002 18:31:52 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 38E3E9129A; Wed, 16 Jan 2002 18:31:32 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E46E09129C; Wed, 16 Jan 2002 18:31: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 2E8DC9129A for ; Wed, 16 Jan 2002 18:31:29 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2AB955DD95; Wed, 16 Jan 2002 18:31:17 -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 0902A5DD90 for ; Wed, 16 Jan 2002 18:31:17 -0500 (EST) Received: from hpindsra.cup.hp.com (hpindsra.cup.hp.com [15.13.104.190]) by palrel13.hp.com (Postfix) with ESMTP id 95CFDE003C9 for ; Wed, 16 Jan 2002 15:30:34 -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 PAA17875 for ; Wed, 16 Jan 2002 15:30:56 -0800 (PST) Date: Wed, 16 Jan 2002 15:30:55 -0800 (PST) From: Sivasundar Ramamurthy X-Sender: sramam@hpindsra To: AAA Working Group Subject: [AAA-WG]: AMA for co-located MN Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Hello, I was wondering whether it is viable to make it mandatory for the AAAH to include the MIP-Reg-Req AVP (from the AMR) in the AMA for co-located MN. 1. The HA can process the request without having to store any information while the AMA is pending. With current standards, the HA probably needs to save something in the range of the entire request to a partially formed reply. 2. All the information required to form the registration reply and update the session is available in the AMA, just like the HAR. Processing the AMR and the HAR becomes very similar. 3. HA implementors might find this feature really useful :-) The costs of this feature seem resonable; the AAAH needs just needs to copy over the MIP-Reg-Request AVP in the AMR to the AMA (irrespective of the result code). However, the increased length of the AMA packet due to the addition of the MIP-Reg-Request AVP might be a drawback worth consideration.... thanks! Siva From owner-aaa-wg@merit.edu Wed Jan 16 19:26: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 TAA24447 for ; Wed, 16 Jan 2002 19:26:22 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 41CAF912BD; Wed, 16 Jan 2002 19:26:13 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 15829912BE; Wed, 16 Jan 2002 19:26: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 DB27E912BD for ; Wed, 16 Jan 2002 19:26:11 -0500 (EST) Received: by segue.merit.edu (Postfix) id C2CAC5DDAB; Wed, 16 Jan 2002 19:26:11 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by segue.merit.edu (Postfix) with ESMTP id 6DE315DDA1 for ; Wed, 16 Jan 2002 19:26:11 -0500 (EST) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate2.mot.com (motgate2 2.1) with ESMTP id RAA21772 for ; Wed, 16 Jan 2002 17:26:10 -0700 (MST)] Received: [from m-il06-r4.mot.com (m-il06-r4.mot.com [129.188.137.196]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id RAA17847 for ; Wed, 16 Jan 2002 17:26:09 -0700 (MST)] Received: from pobox.cstl.labs.mot.com by m-il06-r4.mot.com with ESMTP for aaa-wg@merit.edu; Wed, 16 Jan 2002 18:26:09 -0600 Received: from labs.mot.com ([173.23.95.28]) by pobox.cstl.labs.mot.com (Netscape Messaging Server 4.15) with ESMTP id GQ23VK00.GA3; Wed, 16 Jan 2002 18:26:08 -0600 Message-Id: <3C461A20.B4F89C76@labs.mot.com> Date: Wed, 16 Jan 2002 18:26:08 -0600 From: "Judy Fu" X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Patil Basavaraj (NET/Dallas)" Cc: "'ext Judy Fu'" , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Invoking AAA during every handoff? References: <697DAA22C5004B4596E033803A7CEF444CD48A@daebe007.NOE.Nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Thanks for your reply. Then do you think MN has to go through AAA everytime there is a handoff if without context transfer? The AAA round trip delay may not be a big issue since MN has to send binding update to HA everytime it does HO anyway as specified in "Mobility support in IPv6" draft. Unless there is way to eliminate the binding update/ack round trip delay for HO. In "draft-ietf-aaa-diameter-mobileip-08.txt" section 1.3, support for mobile IP handoffs, it says" Many FA do not communicate, which makes it quite difficult for AAA information to be exchanged between these entities. Therefore, it MUST be assumed that a FA is not aware that a registration request from a mobile node has been previously authorized. The first registration request from a mobile node will therefore cause an AMR to be sent to its AAAF". It seems to me it means by default (without context transfer or other enhancement) AAA will be invoked every time there is a handoff. In addition, if without invoking AAA, i.e. there is no path of new FA-AAAF-AAAH, it is not clear how the new FA report accounting data of the MN to AAA infrastructure. I wonder if I understand correctly. Thanks again. Judy "Patil Basavaraj (NET/Dallas)" wrote: > >I need some help to clarify a question. Will AAA infrastructure need to > >be invoked to reauthenticate a mobile node during every handoff when > >previous authorization is still valid, if so, then a mobile node needs > to > >include MN-AAA extension in registration request message everytime > during > >handoff ? > > It depends on whether the HO to another FA is intra or inter > domain. It is also possible that as part of the handoff process, the > context associated with the MN at the previous FA would be transferred > to the new FA and this would enable the FA to verify the authenticity > of the ongoing session and not require the MN to reauthenticate. > Context transfer is being worked on in the Seamoby WG. > > If the MN has to authenticate every time it performs a HO, the > performance of HOs becomes questionable. > > > > >Many thanks. > >Judy > > > > -Basavaraj From owner-aaa-wg@merit.edu Thu Jan 17 16: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 QAA13161 for ; Thu, 17 Jan 2002 16:20:13 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D8BC8912EF; Thu, 17 Jan 2002 16:18:58 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8DC77912F1; Thu, 17 Jan 2002 16:18: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 8201E912EF for ; Thu, 17 Jan 2002 16:18:57 -0500 (EST) Received: by segue.merit.edu (Postfix) id 65C785DDB9; Thu, 17 Jan 2002 16:18: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 522C55DDAA for ; Thu, 17 Jan 2002 16:18:57 -0500 (EST) Received: from phoenix (nat.interlinknetworks.com [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with SMTP id EC7FE7C for ; Thu, 17 Jan 2002 16:18:56 -0500 (EST) From: "Bob Kopacz" To: "aaa-wg" Subject: [AAA-WG]: [issue] Minor corrections/clarifications to draft-mobileip-08 Date: Thu, 17 Jan 2002 16:18:25 -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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Issue : Minor corrections/clarifications to draft-mobileip-08 Submitter name: Bob Kopacz Submitter email address: BKopacz@InterlinkNetworks.com Date first submitted: 01-17-2002 Reference: Document: draft-ietf-aaa-diameter-mobileip-08 Comment type: Editorial Priority: 1 Section: 4.6.1, 6.8 Rationale/Explanation of issue: Minor corrections/clarifications. Requested change: In section 4.6.1, 2nd line of 1st paragraph, change "algorithm" to "algorithm and secret" What follows is the existing 4.6.1 > 4.6.1 MIP-MN-AAA-SPI AVP > > The MIP-MN-AAA-SPI AVP (AVP Code 341) is of type Unsigned32 and > indicates the algorithm by which the targeted AAA server (AAAH) > should attempt to validate the Authenticator computed by the mobile > node over the Registration Request data. In section 6.8, change the name of the 3rd enumerated value from "SHA-1" to "HMAC-SHA-1". What follows is the current 4.6.1: > 6.8 MIP-Algorithm-Type AVP > > 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 [4] > 2 HMAC-MD5 [13] > 3 SHA-1 [17] [The following, taken from "AAA Registration Keys for Mobile IP", (draft-ietf-mobileip-aaa-key-09.txt), refers to "HMAC-SHA-1"] > 3. Dynamic Security Associations > > Mobility Security Associations between Mobile IP entities > (mobile nodes, home agents, foreign agents) contain both the > necessary cryptographic key information, and a way to identify > the cryptographic algorithm which uses the key to produce the > authentication information typically included in the Mobile Home > Authentication extension or the Mobile Foreign Authentication > extension. In order for the mobile node to make use of key material > created by the AAA server, the mobile node also has to be able to > select the appropriate cryptographic algorithm that uses the key > to produce the authentication. The following table contains the > supported algorithm identifiers. > > Algorithm Identifier Name Reference > --------------------- ------------------ ------------ > 1 MD5/prefix+suffix RFC 2002 [11] > 2 HMAC-MD5 RFC 2104 [6] > 3 HMAC-SHA-1 RFC 2104 [6] From owner-aaa-wg@merit.edu Fri Jan 18 16:08:08 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 QAA27170 for ; Fri, 18 Jan 2002 16:08:07 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 0754691324; Fri, 18 Jan 2002 16:04:51 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B470A91327; Fri, 18 Jan 2002 16:04: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 CEF7491324 for ; Fri, 18 Jan 2002 16:04:46 -0500 (EST) Received: by segue.merit.edu (Postfix) id A55C25DD9A; Fri, 18 Jan 2002 16:04:46 -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 1FBEA5DD92 for ; Fri, 18 Jan 2002 16:04:46 -0500 (EST) Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0IL6FQ14000 for ; Fri, 18 Jan 2002 15:06:15 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 18 Jan 2002 15:04:41 -0600 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 18 Jan 2002 15:04:36 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Invoking AAA during every handoff? Date: Fri, 18 Jan 2002 15:04:36 -0600 Message-ID: <697DAA22C5004B4596E033803A7CEF444CD4CD@daebe007.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Invoking AAA during every handoff? Thread-Index: AcGe7ZG5YOrnUgrdEdaJYgAIx6TWpQBddrnQ From: "Patil Basavaraj (NET/Dallas)" To: "'ext Judy Fu'" Cc: X-OriginalArrivalTime: 18 Jan 2002 21:04:36.0938 (UTC) FILETIME=[BC982AA0:01C1A063] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA27170 Judy Fu [Judy_Fu-AZF002@email.mot.com] wrote: >Thanks for your reply. Then do you think MN has to go through AAA everytime >there is a handoff if without context transfer? Having the MN interact with AAA during the process of HO would be quite inefficient. However it depends on the type of service. If you have a RT service ongoing during a HO and if you have to go through AAA, the service would be impacted. However if the application or service is non-RT, delays that will result during the HO because of MN-AAA interaction will be less critical. >The AAA round trip delay may >not be a big issue since MN has to send binding update to HA everytime it >does HO anyway as specified in "Mobility support in IPv6" >draft. Unless With Fast HO (specified in the Mobile IP WG), the need for having a BU sent to the HA immediately after moving is reduced. So with fast HO, the MN will continue to receive packets sent to it even if the BU to the HA is delayed. >there is way to eliminate the binding update/ack round trip delay for HO. > >In "draft-ietf-aaa-diameter-mobileip-08.txt" section 1.3, support for mobile >IP handoffs, it says" Many FA do not communicate, which makes it quite >difficult for AAA information to be exchanged between these entities. >Therefore, it MUST be assumed that a FA is not aware that a registration >request from a mobile node has been previously authorized. The first >registration request from a mobile node will therefore cause an AMR to be >sent to its AAAF". It seems to me it means by default (without context >transfer or other enhancement) AAA will be invoked every time there is a >handoff. In addition, if without invoking AAA, i.e. there is no path of new >FA-AAAF-AAAH, it is not clear how the new FA report accounting data of the >MN to AAA infrastructure. I wonder if I understand correctly. > >Thanks again. >Judy -Basavaraj From owner-aaa-wg@merit.edu Fri Jan 18 19:01: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 TAA01245 for ; Fri, 18 Jan 2002 19:01:56 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 36873912EC; Fri, 18 Jan 2002 19:00:56 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 025669132C; Fri, 18 Jan 2002 19:00: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 C1A81912EC for ; Fri, 18 Jan 2002 19:00:54 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9825B5DD97; Fri, 18 Jan 2002 19:00:54 -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 197C15DD90 for ; Fri, 18 Jan 2002 19:00:54 -0500 (EST) Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0J02PQ07929 for ; Fri, 18 Jan 2002 18:02:25 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 18 Jan 2002 18:00:52 -0600 Received: from daebe005.NOE.Nokia.com ([172.18.242.203]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 18 Jan 2002 18:00:52 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Invoking AAA during every handoff? Date: Fri, 18 Jan 2002 18:00:51 -0600 Message-ID: <82ECD4351A4A9547957C606034A3CB8DBF934C@daebe005.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Invoking AAA during every handoff? Thread-Index: AcGe7ZG5YOrnUgrdEdaJYgAIx6TWpQBddrnQAAYIVKA= From: "Faccin Stefano (NRC/Dallas)" To: "Patil Basavaraj (NET/Dallas)" Cc: X-OriginalArrivalTime: 19 Jan 2002 00:00:52.0130 (UTC) FILETIME=[5BE66820:01C1A07C] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id TAA01245 Raj, I agree with your comments below regarding the inefficiency of having to re-authenticate the MN with the home domain at every HO. However, I would like to add a comment. > Having the MN interact with AAA during the process of HO would be > quite inefficient. > However it depends on the type of service. If you have a RT service > ongoing during a HO and if you have to go through AAA, the service > would be impacted. One could think that, for RT services and the cases where the MN performs an HO to a domain where the new FA cannot talk to the old FA for some reasons, the new FA allows the MN to keep the services for at least the time it takes to re-authenticate the MN. If the authentication succeeds, the service is not impacted. If the authentication fails, the service can be interrupted immediately. Some ISPs may not like the idea, but this could be some type of interim or "special-cases" solution for RT HO in cases where re-authentication is needed and no impact on the RT services is a must. Stefano From owner-aaa-wg@merit.edu Sun Jan 20 00:57: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 AAA28799 for ; Sun, 20 Jan 2002 00:57:50 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 165BF91218; Sun, 20 Jan 2002 00:57:18 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D88E39121A; Sun, 20 Jan 2002 00:57: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 D846491218 for ; Sun, 20 Jan 2002 00:57:16 -0500 (EST) Received: by segue.merit.edu (Postfix) id A88C65DDCC; Sun, 20 Jan 2002 00:56:28 -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 DD0BD5DDC0 for ; Sun, 20 Jan 2002 00:56:27 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id VAA02466 for ; Sat, 19 Jan 2002 21:40:13 -0800 (PST) (envelope-from aboba@internaut.com) Date: Sat, 19 Jan 2002 21:40:13 -0800 (PST) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: Updates issues list available Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk An updated Diameter issues list, reflecting comments during WG last call, is available at: http://www.drizzle.com/~aboba/AAA/issues.html From owner-aaa-wg@merit.edu Sun Jan 20 01:08: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 BAA28882 for ; Sun, 20 Jan 2002 01:08:12 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E335D9121A; Sun, 20 Jan 2002 01:08:01 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B13579121C; Sun, 20 Jan 2002 01:08: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 B50BC9121A for ; Sun, 20 Jan 2002 01:08:00 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8BC945DDCB; Sun, 20 Jan 2002 01:08:00 -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 AE70D5DDC0 for ; Sun, 20 Jan 2002 01:07:59 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id VAA02482 for ; Sat, 19 Jan 2002 21:52:05 -0800 (PST) (envelope-from aboba@internaut.com) Date: Sat, 19 Jan 2002 21:52:05 -0800 (PST) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: Conclusion of AAA WG Last Call 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 the following drafts: http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-08.txt http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-nasreq-08.txt http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-mobileip-08.txt http://www.ietf.org/internet-drafts/draft-ietf-aaa-transport-05.txt http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-cms-sec-03.txt A total of 22 issues were raised in WG last call. The comments are reflected in issues 248-269, included in the Diameter issues list, available at: http://www.drizzle.com/~aboba/AAA/issues.html The breakdown of new issues is as follows: Base: 14 NASREQ: 4 MIP: 5 CMS-Sec: 1 Transport: 3 From owner-aaa-wg@merit.edu Mon Jan 21 12:10: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 MAA17194 for ; Mon, 21 Jan 2002 12:10:10 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E1A7F9122A; Mon, 21 Jan 2002 12:09:57 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AF97B9122B; Mon, 21 Jan 2002 12:09: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 90FB39122A for ; Mon, 21 Jan 2002 12:09:56 -0500 (EST) Received: by segue.merit.edu (Postfix) id 695E35DDA2; Mon, 21 Jan 2002 12:09:56 -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 6239D5DD9A for ; Mon, 21 Jan 2002 12:09:51 -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 g0LH9oh25886 for ; Mon, 21 Jan 2002 11:09:50 -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 g0LH9ot22384 for ; Mon, 21 Jan 2002 11:09:50 -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 LAA25524 for ; Mon, 21 Jan 2002 11:09:49 -0600 (CST) Received: from ericsson.com ([138.85.159.104]) by qpop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id LAA14993 for ; Mon, 21 Jan 2002 11:09:48 -0600 (CST) Message-ID: <3C4C4AEA.AC19E09@ericsson.com> Date: Mon, 21 Jan 2002 09:07: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: aaa-wg@merit.edu Subject: [AAA-WG]: FW:I-D ACTION:draft-johansson-aaa-diameter-mm-app-00.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, A few of us just sent out our first draft that specifies a Diameter application that allows a Diameter server to authenticate, authorize, and collect accounting information for Session Initiation Protocol (SIP) services rendered to a client node, see below. We hope this will be subject for a new working group item as soon as we are done with the current charter. Comments are welcomed, and greatly encouraged. /Tony To: IETF-Announce: ; Subject: I-D ACTION:draft-johansson-aaa-diameter-mm-app-00.txt From: Internet-Drafts@ietf.org Date: Thu, 17 Jan 2002 06:47:58 -0500 CC: aaa-wg@merit.edu Reply-to: Internet-Drafts@ietf.org Sender: nsyracus@cnri.reston.va.us A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Diameter Multimedia Application Author(s) : T. Johansson et al. Filename : draft-johansson-aaa-diameter-mm-app-00.txt Pages : 29 Date : 16-Jan-02 This document specifies a Diameter application that allows a Diameter server to authenticate, authorize, and collect accounting information for Session Initiation Protocol (SIP) services rendered to a client node. This application, combined with the base Diameter protocol and appropriate SIP extensions, allows SIP User Agents (UAs) to obtain services from SIP servers that are connected to a Diameter infrastructure. When combined with the Inter-Domain capability of the base protocol, service may even be obtained from SIP servers that belong to foreign domains, as would be encountered by roaming mobile nodes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-johansson-aaa-diameter-mm-app-00.txt From owner-aaa-wg@merit.edu Tue Jan 22 05:37: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 FAA15187 for ; Tue, 22 Jan 2002 05:37:22 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E957D9124F; Tue, 22 Jan 2002 05:37:10 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BB34691250; Tue, 22 Jan 2002 05:37: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 B31E19124F for ; Tue, 22 Jan 2002 05:37:08 -0500 (EST) Received: by segue.merit.edu (Postfix) id 815D25DDD7; Tue, 22 Jan 2002 05:37:08 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by segue.merit.edu (Postfix) with ESMTP id 96F385DDC8 for ; Tue, 22 Jan 2002 05:37:07 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id g0MAb5w26884; Tue, 22 Jan 2002 11:37:05 +0100 (MET) Received: from lmf.ericsson.se (lmf4ws450.lmf.ericsson.se [131.160.38.50]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g0MAb3r6019581; Tue, 22 Jan 2002 12:37:03 +0200 (EET) Message-ID: <3C4D40CF.FCDCACCD@lmf.ericsson.se> Date: Tue, 22 Jan 2002 12:37:03 +0200 From: Jari Arkko Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Tony Johansson Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]:draft-johansson-aaa-diameter-mm-app-00.txt References: <3C4C4AEA.AC19E09@ericsson.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Thanks for submitting such an extension. We need one! A few comments or questions: - Overall, while the introduction at the beginning is good, as are the detailed AVP etc descriptions, I missed some explanations that fall in between. What goes to what AVPs, and how they are related. - Capability AVPs that use Unsigned32. Given that ls -l *-sip-* | wc -l is 149, I fear the capability space may not be sufficient. And why didn't you use the option-tag scheme present in the SIP Supported etc headers? - I'm not sure I understand why Auth-Data-Item has both Authentication-Challenge/Response and EAP-Payloads. Supposedly because it wants to support EAP within SIP as well as Digest? Well, how does a SIP node know which one is being run? By looking at the scheme parameter in RFC 2617? What if there's a new HTTP Auth scheme that the SIP node doesn't know, but both the client and the AAA server do know? What I'm getting at is whether it makes sense to transport the HTTP Auth headers as such, unchanged, or whether you want or need to understand more of what happens inside the auth headers. - Authentication-Challenge and -Response: do we need two attributes, and how does the SIP node decide which one this is? - 5.11 Authentication-Context needs more detail before implementors know what to do. - The authentication requests, can you say something about the stateful vs. stateless nature of the SIP servers this expects? One way to make this work is to expect that the subsequent SIP request (e.g. response to a digest challenge) will get to the same SIP server which holds some AAA state. Another way to do it would be to allow the SIP server to change in between (as in server farms), but retain the authentication state, if any, in the AAA side. I'd prefer the latter approach. Jari From owner-aaa-wg@merit.edu Tue Jan 22 07:21: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 HAA16183 for ; Tue, 22 Jan 2002 07:21:01 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 617D99120F; Tue, 22 Jan 2002 07:20:47 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3360891251; Tue, 22 Jan 2002 07:20: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 12DCA9120F for ; Tue, 22 Jan 2002 07:20:46 -0500 (EST) Received: by segue.merit.edu (Postfix) id DD45B5DDD7; Tue, 22 Jan 2002 07:20:45 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from alvin.loniis.spb.su (gw1.loniis.spb.su [195.201.37.253]) by segue.merit.edu (Postfix) with ESMTP id B85D45DDA8 for ; Tue, 22 Jan 2002 07:20:44 -0500 (EST) Received: from rts.nio1.loniis (rts.nio1.loniis [192.168.0.143] (may be forged)) by alvin.loniis.spb.su (8.10.0/8.10.0) with ESMTP id g0MCKTL19722; Tue, 22 Jan 2002 15:20:29 +0300 (MSK) Received: from totosha (totosha.rts.nio1.loniis [192.168.100.173]) by rts.nio1.loniis (Postfix) with SMTP id 3CFF08047; Tue, 22 Jan 2002 15:20:28 +0300 (MSK) Message-ID: <000f01c1a33f$a30d27a0$ad64a8c0@rts.nio1.loniis> From: "Zarubin Anton" To: Cc: Subject: Re: [AAA-WG]:draft-johansson-aaa-diameter-mm-app-00.txt Date: Tue, 22 Jan 2002 15:23:45 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hello Tony. Small question. If I correctly have understood, at reception second (9) SIP-REG HSP can receive an information about that to what SSP it to transmit from the message (11) UAA. AAA server will know it from the message (5) MAR. So whether it? Anton A. Zarubin Saint-Petersburg, LONIIS e-mail: totosha@rts.loniis.ru From owner-aaa-wg@merit.edu Tue Jan 22 17:26: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 RAA13247 for ; Tue, 22 Jan 2002 17:26:44 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 8CBC291265; Tue, 22 Jan 2002 17:26:29 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 587A391266; Tue, 22 Jan 2002 17:26: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 66B3891265 for ; Tue, 22 Jan 2002 17:26:28 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4E2885DDA0; Tue, 22 Jan 2002 17:26: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 0B9D55DD9A for ; Tue, 22 Jan 2002 17:26:28 -0500 (EST) Received: (qmail 22451 invoked by uid 500); 22 Jan 2002 22:26:27 -0000 Date: Tue, 22 Jan 2002 16:26:27 -0600 From: David Frascone To: aaa-wg@merit.edu, diameter@frascone.com Subject: [AAA-WG]: Connectathon Test Cases Message-ID: <20020122222626.GE21783@newman.frascone.com> Mail-Followup-To: aaa-wg@merit.edu, diameter@frascone.com 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 I'm going to be putting together a set of test cases for the 2002 Connectathon (http://www.connectathon.org) interoperability event. Please, send me an e-mail (privately) with any test cases you would like to see tested at Connectathon. -Dave From owner-aaa-wg@merit.edu Tue Jan 22 18:33: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 SAA14415 for ; Tue, 22 Jan 2002 18:33:10 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DA44691268; Tue, 22 Jan 2002 18:32:50 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AD00091269; Tue, 22 Jan 2002 18:32: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 441F291268 for ; Tue, 22 Jan 2002 18:32:21 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1B1EB5DDA3; Tue, 22 Jan 2002 18:32:21 -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 B44D55DD8D for ; Tue, 22 Jan 2002 18:32:20 -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 g0MNWCh29671 for ; Tue, 22 Jan 2002 17:32:12 -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 g0MNWCr17240 for ; Tue, 22 Jan 2002 17:32: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 RAA13602; Tue, 22 Jan 2002 17:32:12 -0600 (CST) Received: from ericsson.com (busam54.berkeley.us.am.ericsson.se [138.85.159.204]) by qpop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id RAA21052; Tue, 22 Jan 2002 17:32:10 -0600 (CST) Message-ID: <3C4DF606.9E259DAC@ericsson.com> Date: Tue, 22 Jan 2002 15:30:15 -0800 From: Tony Johansson X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jari Arkko Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]:draft-johansson-aaa-diameter-mm-app-00.txt References: <3C4C4AEA.AC19E09@ericsson.com> <3C4D40CF.FCDCACCD@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hello Jari, Thanks for your comments, please find mine embedded... /Tony Jari Arkko wrote: > Thanks for submitting such an extension. We > need one! > > A few comments or questions: > > - Overall, while the introduction at the beginning > is good, as are the detailed AVP etc descriptions, > I missed some explanations that fall in between. > What goes to what AVPs, and how they are related. Okay, we will work on some text that I hope will cover this issue. > > > - Capability AVPs that use Unsigned32. Given > that ls -l *-sip-* | wc -l is 149, I fear > the capability space may not be sufficient. > And why didn't you use the option-tag scheme > present in the SIP Supported etc headers? > I'm not really sure that I fully understand you. Can you elaborate this a little bit further. > > - I'm not sure I understand why Auth-Data-Item > has both Authentication-Challenge/Response > and EAP-Payloads. Supposedly because it wants > to support EAP within SIP as well as Digest? Correct. > > Well, how does a SIP node know which one is > being run? By looking at the scheme parameter in > RFC 2617? Right, in the case of Digest and Basic, which then would make use of the Authentication-Challenge/Response AVPs, and draft-ieft-torvinen-http-eap-00.txt in the case of EAP-Payloads. I agree, we need to explain this more explicitly. > What if there's a new HTTP Auth > scheme that the SIP node doesn't know, but both > the client and the AAA server do know? What I'm > getting at is whether it makes sense to transport > the HTTP Auth headers as such, unchanged, or > whether you want or need to understand more of > what happens inside the auth headers. First of all, would you really update your client and AAA, and not your SIP node? Furthermore, so lets say that the AAA is handling the HTTP Auth scheme and we transport HTTP Auth headers as such, unchanged, I don't see that the SIP node really have to understand the scheme in it's full detail. The SIP node (SSP) only has to forward the HTTP Auth header created by the client and the AAA, and finally get a successful result code from the AAA, if successfully authenticated . On the other hand, if the SIP node is incharge of authenitication and the SIP node receives an unkown HTTP Auth header you would have do deal with this as in a SIP only case... Unless I have missed some thing, I don't really see that we should change the idea of forwarding the HTTP Auth headers as such. > > > - Authentication-Challenge and -Response: do > we need two attributes, and how does the > SIP node decide which one this is? The idea with two is to make it more explicit. Thus, the Authentication-Challenge AVP is used to carry the challenge and the Authentication-Response is used to carry the digest. I believe this makes it easier especially in the case when a SSP handles authentication and all authentication info has to be distributed by the Diameter server to the SSP. > > > - 5.11 Authentication-Context needs more > detail before implementors know what to do. I agree, we will work on some text. Thanks, Tony From owner-aaa-wg@merit.edu Tue Jan 22 21:01: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 VAA17144 for ; Tue, 22 Jan 2002 21:01:35 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 4748E91206; Tue, 22 Jan 2002 21:01:16 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 043B69126C; Tue, 22 Jan 2002 21:01: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 0D98E91206 for ; Tue, 22 Jan 2002 21:01:10 -0500 (EST) Received: by segue.merit.edu (Postfix) id E07175DDED; Tue, 22 Jan 2002 21:01:09 -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 76D935DD8D for ; Tue, 22 Jan 2002 21:01:09 -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 g0N216S15561; Tue, 22 Jan 2002 20:01:06 -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 g0N215J04425; Tue, 22 Jan 2002 20:01:06 -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 UAA26812; Tue, 22 Jan 2002 20:01:05 -0600 (CST) Received: from ericsson.com (busam54.berkeley.us.am.ericsson.se [138.85.159.204]) by qpop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id UAA23841; Tue, 22 Jan 2002 20:01:04 -0600 (CST) Message-ID: <3C4E18E9.DF7ACE89@ericsson.com> Date: Tue, 22 Jan 2002 17:59:05 -0800 From: Tony Johansson X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Zarubin Anton Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]:draft-johansson-aaa-diameter-mm-app-00.txt References: <000f01c1a33f$a30d27a0$ad64a8c0@rts.nio1.loniis> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Zarubin Anton wrote: > Hello Tony. > > Small question. > If I correctly have understood, at reception second (9) SIP-REG HSP can > receive an information about that to what SSP it to transmit from the > message (11) UAA. AAA server will know it from the message (5) MAR. So > whether it? That is correct. Regards, Tony > > > Anton A. Zarubin > Saint-Petersburg, LONIIS > e-mail: totosha@rts.loniis.ru From owner-aaa-wg@merit.edu Wed Jan 23 08:38: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 IAA07854 for ; Wed, 23 Jan 2002 08:37:58 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A916791276; Wed, 23 Jan 2002 08:37:44 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 78EC191277; Wed, 23 Jan 2002 08:37: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 74E2B91276 for ; Wed, 23 Jan 2002 08:37:43 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4B4CD5DE0B; Wed, 23 Jan 2002 08:37:43 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by segue.merit.edu (Postfix) with ESMTP id A3A9A5DE03 for ; Wed, 23 Jan 2002 08:37:42 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id g0NDbfw03951; Wed, 23 Jan 2002 14:37:41 +0100 (MET) Received: from lmf.ericsson.se (lmf4ws450.lmf.ericsson.se [131.160.38.50]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g0NDbdr6016073; Wed, 23 Jan 2002 15:37:39 +0200 (EET) Message-ID: <3C4EBCA3.3B9A6D56@lmf.ericsson.se> Date: Wed, 23 Jan 2002 15:37:39 +0200 From: Jari Arkko Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Tony Johansson Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]:draft-johansson-aaa-diameter-mm-app-00.txt References: <3C4C4AEA.AC19E09@ericsson.com> <3C4D40CF.FCDCACCD@lmf.ericsson.se> <3C4DF606.9E259DAC@ericsson.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Tony Johansson wrote: > > - Capability AVPs that use Unsigned32. Given > > that ls -l *-sip-* | wc -l is 149, I fear > > the capability space may not be sufficient. > > And why didn't you use the option-tag scheme > > present in the SIP Supported etc headers? > > > > I'm not really sure that I fully understand you. Can you elaborate this > a little bit further. So, for instance, you have a SIP-Server-Capability AVP which is of type Unsigned32. But what are the values? Ok, so you may say that you'll provide some values in the future. But how is this synced to what the SIP WG will do? Will 32 bits be enough? Note that in draft-ietf-sip-rfc2543bis-05.txt, section 21.2 a concept of an "option-tag" is defined. This is a string of a specific format that defines the capabilities of the SIP node. Couldn't we use that? > > What if there's a new HTTP Auth > > scheme that the SIP node doesn't know, but both > > the client and the AAA server do know? What I'm > > getting at is whether it makes sense to transport > > the HTTP Auth headers as such, unchanged, or > > whether you want or need to understand more of > > what happens inside the auth headers. > > First of all, would you really update your client and AAA, and not your > SIP node? > > Furthermore, so lets say that the AAA is handling the HTTP Auth scheme > and we transport HTTP Auth headers as such, unchanged, I don't see that > the SIP node really have to understand the scheme in it's full detail. > The SIP node (SSP) only has to forward the HTTP Auth header created by > the client and the AAA, and finally get a successful result code from > the AAA, if successfully authenticated . > > On the other hand, if the SIP node is incharge of authenitication and > the SIP node receives an unkown HTTP Auth header you would have do deal > with this as in a SIP only case... > > Unless I have missed some thing, I don't really see that we should > change the idea of forwarding the HTTP Auth headers as such. We seem to agree about the goal but perhaps I didn't understand the document well enough to see that this was really the goal. If you transport the HTTP Auth headers as such, where do you need EAP-Payload? Jari From owner-aaa-wg@merit.edu Fri Jan 25 00:33:07 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 AAA16904 for ; Fri, 25 Jan 2002 00:33:05 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 879659128E; Fri, 25 Jan 2002 00:32:41 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5B63B91290; Fri, 25 Jan 2002 00:32: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 681999128E for ; Fri, 25 Jan 2002 00:32:23 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4402A5DDB8; Fri, 25 Jan 2002 00:32:23 -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 79A855DD97 for ; Fri, 25 Jan 2002 00:32:22 -0500 (EST) Received: from knox6039.cisco.com (knox6039.cisco.com [161.44.216.39]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id AAA28295; Fri, 25 Jan 2002 00:32:19 -0500 (EST) Received: (from meklund@localhost) by knox6039.cisco.com (8.9.3+Sun/8.9.3) id AAA01017; Fri, 25 Jan 2002 00:32:17 -0500 (EST) Date: Fri, 25 Jan 2002 00:32:17 -0500 (EST) Message-Id: <200201250532.AAA01017@knox6039.cisco.com> From: Mark Eklund To: "aaa-wg" Subject: [AAA-WG]: Issue 248: Error messages: decimal or hex? Sender: owner-aaa-wg@merit.edu Precedence: bulk I was considering issue #248 which questions if the Result-Code AVP values should be in decimal or hexadecimal. After considering the pros and cons, I think we should leave it as decimal. I see two main reasons to change this to Hexadecimal. 1. This allows for a bitmask to determine what type of error was sent. 2. In doing this we will also expand the range of codes for each result and thus we can have over a 1000 protocol errors. My thoughts are 1. Categorizing these errors in groups of 1000 is mostly a documentation convenience. In essence to an application, the Result-Code AVP is either Success, a few failures that it handles specially and all the other failures. There is little need to distinguish Transient Failures and Permanent Failures. Protocol Errors will be in a packet with the 'E' bit set. So being able to use a bitmask to determin what type of error was sent is of little. 2. We have used less than 50 total Result-Codes. Yes, it is possible that we will have used up an entire 1000 as some time. If that happens, we can simply add another range of 1000 for that type of error. Once again, these categorizations are simply a documentation convenience. 3. This is a personal preference, but when I see a dump of a diameter packet, I typically see the packet broken into information where Unsigned32 values converted to decimal. This is a lame argument, but I had to have one more than the arguments for hexadecimal :) With all that said. If there is a want or push for Hexadecimal, now is the time to fix it. Remember though that if this changes, everyone that working diameter servers will have to go update their enums and dictionaries :( -mark From owner-aaa-wg@merit.edu Fri Jan 25 09:58: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 JAA04292 for ; Fri, 25 Jan 2002 09:58:37 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5F06E91290; Fri, 25 Jan 2002 09:58:16 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2897691292; Fri, 25 Jan 2002 09:58: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 20AD091290 for ; Fri, 25 Jan 2002 09:58:15 -0500 (EST) Received: by segue.merit.edu (Postfix) id F24395DE40; Fri, 25 Jan 2002 09:58:14 -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 5F1DC5DE3A for ; Fri, 25 Jan 2002 09:58:14 -0500 (EST) Received: (qmail 5396 invoked by uid 500); 25 Jan 2002 14:58:13 -0000 Date: Fri, 25 Jan 2002 08:58:13 -0600 From: David Frascone To: Mark Eklund Cc: aaa-wg Subject: Re: [AAA-WG]: Issue 248: Error messages: decimal or hex? Message-ID: <20020125145813.GC5136@newman.frascone.com> Mail-Followup-To: Mark Eklund , aaa-wg References: <200201250532.AAA01017@knox6039.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200201250532.AAA01017@knox6039.cisco.com> User-Agent: Mutt/1.3.25i X-encrypt-payload: no Sender: owner-aaa-wg@merit.edu Precedence: bulk I prefer decimal. HTTP hasn't run out of room yet. -Dave On Friday, 25 Jan 2002, Mark Eklund wrote: > I was considering issue #248 which questions if the Result-Code AVP > values should be in decimal or hexadecimal. After considering the > pros and cons, I think we should leave it as decimal. I see two main > reasons to change this to Hexadecimal. > > 1. This allows for a bitmask to determine what type of error was sent. > > 2. In doing this we will also expand the range of codes for each > result and thus we can have over a 1000 protocol errors. > > My thoughts are > 1. Categorizing these errors in groups of 1000 is mostly a > documentation convenience. In essence to an application, the > Result-Code AVP is either Success, a few failures that it > handles specially and all the other failures. There is little need > to distinguish Transient Failures and Permanent Failures. > Protocol Errors will be in a packet with the 'E' bit set. > So being able to use a bitmask to determin what type of error was > sent is of little. > > 2. We have used less than 50 total Result-Codes. Yes, it is possible > that we will have used up an entire 1000 as some time. If that > happens, we can simply add another range of 1000 for that type of > error. Once again, these categorizations are simply a > documentation convenience. > > 3. This is a personal preference, but when I see a dump of a diameter > packet, I typically see the packet broken into information where > Unsigned32 values converted to decimal. This is a lame argument, > but I had to have one more than the arguments for hexadecimal :) > > With all that said. If there is a want or push for Hexadecimal, now > is the time to fix it. Remember though that if this changes, everyone > that working diameter servers will have to go update their enums and > dictionaries :( > > -mark > > > From owner-aaa-wg@merit.edu Fri Jan 25 14:50: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 OAA12527 for ; Fri, 25 Jan 2002 14:50:09 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 298F99129C; Fri, 25 Jan 2002 14:49:42 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EB5319129D; Fri, 25 Jan 2002 14:49: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 0BAF39129C for ; Fri, 25 Jan 2002 14:49:41 -0500 (EST) Received: by segue.merit.edu (Postfix) id E10995DE47; Fri, 25 Jan 2002 14:49:40 -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 CD14D5DDB4 for ; Fri, 25 Jan 2002 14:49:40 -0500 (EST) Received: from phoenix (nat.interlinknetworks.com [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with SMTP id 7BCDE7B for ; Fri, 25 Jan 2002 14:49:40 -0500 (EST) From: "Bob Kopacz" To: "aaa-wg" Subject: [AAA-WG]: [issue] Proxiable messages MUST contain Axxx-Application-Id AVP Date: Fri, 25 Jan 2002 14:49:03 -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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Issue : Proxiable messages MUST contain Axxx-Application-Id AVP Submitter name: Bob Kopacz Submitter email address: BKopacz@InterlinkNetworks.com Date first submitted: 01-25-2002 Reference: Document: Base Comment type: Technical Priority: 1 Section: [I know last-call is over, but pending issues haven't been resolved yet, and I think this is a bug]. Rationale/Explanation of issue: Accounting messages and application-specific messages have an Axxx-Application-Id AVP which identifies the application (e.g. Mobile IP). The Auth-Application-Id AVP is currently prohibited from being present in the Session-Terminate-Request, Abort-Session-Request, and Re-Auth-Request messages. This creates a routing problem for intermediate proxy or relay servers when receiving an STR/ASR/RAR. The intermediate server's routing table may indicate that, say, Mobile-IP messages route to a different next hop than NASREQ messages. An STR message, however, contains no application-id AVP indicating NASREQ-v-MobileIp, so the intermediate server doesn't know how to route it. Requested change: 1. Require an Auth-Application-Id AVP in Session-Terminate-Request, Abort-Session-Request, and Re-Auth-Request messages. 2. Update occurrence rule tables for the "Auth-Application-Id AVP" row, from "0" to "1", for STR and ASR and RAR. From owner-aaa-wg@merit.edu Fri Jan 25 15:16: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 PAA13086 for ; Fri, 25 Jan 2002 15:16:49 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5E7A79129D; Fri, 25 Jan 2002 15:16:35 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 213F39129E; Fri, 25 Jan 2002 15:16: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 DE2E69129D for ; Fri, 25 Jan 2002 15:16:33 -0500 (EST) Received: by segue.merit.edu (Postfix) id C48275DE4B; Fri, 25 Jan 2002 15:16:33 -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 08AA35DDB4 for ; Fri, 25 Jan 2002 15:16:33 -0500 (EST) Received: from knox6039.cisco.com (knox6039.cisco.com [161.44.216.39]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id PAA15956; Fri, 25 Jan 2002 15:16:31 -0500 (EST) Received: (from meklund@localhost) by knox6039.cisco.com (8.9.3+Sun/8.9.3) id PAA01376; Fri, 25 Jan 2002 15:16:30 -0500 (EST) Date: Fri, 25 Jan 2002 15:16:30 -0500 (EST) Message-Id: <200201252016.PAA01376@knox6039.cisco.com> From: Mark Eklund To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 241: Accounting issues (subissue 1 & 4) Sender: owner-aaa-wg@merit.edu Precedence: bulk Issue 241 brings up four issues. Sub-issues 1 and 4 (paragraph 1 and 4) are minor editorial changes and will be added to the base. Sub-issues 2 and 3 will be discussed in subsequent emails. -mark From owner-aaa-wg@merit.edu Fri Jan 25 15:58: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 PAA14147 for ; Fri, 25 Jan 2002 15:58:32 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2432B9129F; Fri, 25 Jan 2002 15:58:19 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E7FD4912A0; Fri, 25 Jan 2002 15:58: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 D3DC69129F for ; Fri, 25 Jan 2002 15:58:17 -0500 (EST) Received: by segue.merit.edu (Postfix) id B2FE35DE55; Fri, 25 Jan 2002 15:58:17 -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 E5F2C5DDB4 for ; Fri, 25 Jan 2002 15:58:16 -0500 (EST) Received: from knox6039.cisco.com (knox6039.cisco.com [161.44.216.39]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id PAA16909; Fri, 25 Jan 2002 15:58:15 -0500 (EST) Received: (from meklund@localhost) by knox6039.cisco.com (8.9.3+Sun/8.9.3) id PAA01393; Fri, 25 Jan 2002 15:58:14 -0500 (EST) Date: Fri, 25 Jan 2002 15:58:14 -0500 (EST) Message-Id: <200201252058.PAA01393@knox6039.cisco.com> From: Mark Eklund To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 241: Sub-issue 3 Sender: owner-aaa-wg@merit.edu Precedence: bulk Issue 241 paragraph 3 states that a it is not clear what an "accounting stop request" is. It also states that an Abort-Session command is not included in the machine. I think it is clear that an "accounting stop request" is an ACR with an Accounting-Record-Type with a value of STOP_RECORD. Also, this is an accounting state machine that simply keeps track of accounting state. Finally an event of "User service terminated" encompasses the receipt of an Abort-Session command. For these reasons, I vote to reject sub-issue 3 of issue 241. -mark From owner-aaa-wg@merit.edu Fri Jan 25 16:08:09 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 QAA14398 for ; Fri, 25 Jan 2002 16:08:09 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id C85FF9121F; Fri, 25 Jan 2002 16:07:58 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 94579912A0; Fri, 25 Jan 2002 16:07: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 901509121F for ; Fri, 25 Jan 2002 16:07:57 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6F98A5DE54; Fri, 25 Jan 2002 16:07:57 -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 99DB35DDB4 for ; Fri, 25 Jan 2002 16:07:56 -0500 (EST) Received: from knox6039.cisco.com (knox6039.cisco.com [161.44.216.39]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id QAA17105; Fri, 25 Jan 2002 16:07:55 -0500 (EST) Received: (from meklund@localhost) by knox6039.cisco.com (8.9.3+Sun/8.9.3) id QAA01397; Fri, 25 Jan 2002 16:07:53 -0500 (EST) Date: Fri, 25 Jan 2002 16:07:53 -0500 (EST) Message-Id: <200201252107.QAA01397@knox6039.cisco.com> From: Mark Eklund To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 252: Granting Access via Accounting Sender: owner-aaa-wg@merit.edu Precedence: bulk Issue 252 notes that the accounting state machine has an action of "grant access" and since accounting has nothing to do with authentication/authorization, that appears to be an error. I agree and think the "grant access" should be changed to "none". State Event Action New State ------------------------------------------------------------- (text elided) Pending Successful accounting grant Open start answer received access -mark From owner-aaa-wg@merit.edu Sun Jan 27 00:08: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 AAA17164 for ; Sun, 27 Jan 2002 00:08:42 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id BB1EF9121D; Sun, 27 Jan 2002 00:08:28 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8F25B91225; Sun, 27 Jan 2002 00:08: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 406649121D for ; Sun, 27 Jan 2002 00:08:26 -0500 (EST) Received: by segue.merit.edu (Postfix) id 267CC5DDD0; Sun, 27 Jan 2002 00:08:26 -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 5E8055DD8F for ; Sun, 27 Jan 2002 00:08:25 -0500 (EST) Received: from knox6039.cisco.com (knox6039.cisco.com [161.44.216.39]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id AAA21736; Sun, 27 Jan 2002 00:08:24 -0500 (EST) Received: (from meklund@localhost) by knox6039.cisco.com (8.9.3+Sun/8.9.3) id AAA01728; Sun, 27 Jan 2002 00:08:22 -0500 (EST) Date: Sun, 27 Jan 2002 00:08:22 -0500 (EST) Message-Id: <200201270508.AAA01728@knox6039.cisco.com> From: Mark Eklund To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue #254 Sender: owner-aaa-wg@merit.edu Precedence: bulk Issue #254 requests specific information on how IPsec must be used be added. I vote to decline this request. Setting in stone what aspects of IPsec may and may not be used is well beyond what Diameter should specify. Future enhancements of IPsec or discoveries in the failures in the IPsec algorithm may make these specifications worthless. If there is a need to specify what level of security Diameter IPsec conforms to, an RFC entitled something like, "Recommended Minimum IPsec usage for Diameter" should be created. Then you can say you are RFC12345 conformant. If someone comes out with more secure recommendations, another RFC can be created. -mark P.S. I do vote to spell IPsec correctly in the Diameter drafts as this issue also suggests. From owner-aaa-wg@merit.edu Sun Jan 27 00:20: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 AAA17235 for ; Sun, 27 Jan 2002 00:20:00 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id CBC2791225; Sun, 27 Jan 2002 00:19:47 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9BA7291226; Sun, 27 Jan 2002 00:19: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 7F30E91225 for ; Sun, 27 Jan 2002 00:19:46 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5B51F5DE1E; Sun, 27 Jan 2002 00:19:46 -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 8FCBB5DD8F for ; Sun, 27 Jan 2002 00:19:45 -0500 (EST) Received: from knox6039.cisco.com (knox6039.cisco.com [161.44.216.39]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id AAA21937; Sun, 27 Jan 2002 00:19:44 -0500 (EST) Received: (from meklund@localhost) by knox6039.cisco.com (8.9.3+Sun/8.9.3) id AAA01731; Sun, 27 Jan 2002 00:19:44 -0500 (EST) Date: Sun, 27 Jan 2002 00:19:44 -0500 (EST) Message-Id: <200201270519.AAA01731@knox6039.cisco.com> From: Mark Eklund To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 256 Sender: owner-aaa-wg@merit.edu Precedence: bulk Issue 256 suggests the text below. In particular it requires TLS peer authentication. Is there ever a situation where you want to use the TLS encryption capability, but don't care to authenticate your peer? Diameter clients act as TLS clients according to [RFC2246], and Diameter servers act as TLS servers. Diameter clients and servers implementing TLS for security MUST mutually authenticate as part of TLS session establishment. In order to ensure mutual authentication, Diameter servers MUST request certificates from Diameter clients, and the client MUST be prepared to supply a certificate on request." -mark From owner-aaa-wg@merit.edu Sun Jan 27 00:59: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 AAA17607 for ; Sun, 27 Jan 2002 00:59:10 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9AC2491226; Sun, 27 Jan 2002 00:58:58 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 66AA591227; Sun, 27 Jan 2002 00:58: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 667FC91226 for ; Sun, 27 Jan 2002 00:58:57 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4DF435DDC7; Sun, 27 Jan 2002 00:58:57 -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 859495DD8F for ; Sun, 27 Jan 2002 00:58:56 -0500 (EST) Received: from knox6039.cisco.com (knox6039.cisco.com [161.44.216.39]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id AAA22537; Sun, 27 Jan 2002 00:58:55 -0500 (EST) Received: (from meklund@localhost) by knox6039.cisco.com (8.9.3+Sun/8.9.3) id AAA01772; Sun, 27 Jan 2002 00:58:54 -0500 (EST) Date: Sun, 27 Jan 2002 00:58:54 -0500 (EST) Message-Id: <200201270558.AAA01772@knox6039.cisco.com> From: Mark Eklund To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 257 Sender: owner-aaa-wg@merit.edu Precedence: bulk Issue #257 corrects inconsistencies between the base and the transport draft. I vote to accept this issue. -mark From owner-aaa-wg@merit.edu Sun Jan 27 01:21: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 BAA17777 for ; Sun, 27 Jan 2002 01:21:26 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E859291227; Sun, 27 Jan 2002 01:21:04 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B64FE91228; Sun, 27 Jan 2002 01:21:04 -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 A1E2691227 for ; Sun, 27 Jan 2002 01:21:03 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7B9CB5DD95; Sun, 27 Jan 2002 01:21:03 -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 B1DD15DD8F for ; Sun, 27 Jan 2002 01:21:02 -0500 (EST) Received: from knox6039.cisco.com (knox6039.cisco.com [161.44.216.39]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id BAA22895; Sun, 27 Jan 2002 01:21:01 -0500 (EST) Received: (from meklund@localhost) by knox6039.cisco.com (8.9.3+Sun/8.9.3) id BAA01787; Sun, 27 Jan 2002 01:21:01 -0500 (EST) Date: Sun, 27 Jan 2002 01:21:01 -0500 (EST) Message-Id: <200201270621.BAA01787@knox6039.cisco.com> From: Mark Eklund To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 260: SNTP referencing Sender: owner-aaa-wg@merit.edu Precedence: bulk Issue 260 re-words the time format to be more understandable. It also 1. Mandates the extension of the time format to 2104. 2. Changes time to be derived from Unsigned32 to Octetstring. I vote we commit these changes. -mark From owner-aaa-wg@merit.edu Sun Jan 27 01:47: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 BAA17976 for ; Sun, 27 Jan 2002 01:47:56 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3EC5291228; Sun, 27 Jan 2002 01:47:40 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0CB4191229; Sun, 27 Jan 2002 01:47: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 E866B91228 for ; Sun, 27 Jan 2002 01:47:38 -0500 (EST) Received: by segue.merit.edu (Postfix) id BF4825DDC9; Sun, 27 Jan 2002 01:47:38 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from fep02-app.kolumbus.fi (fep02-0.kolumbus.fi [193.229.0.44]) by segue.merit.edu (Postfix) with ESMTP id E631D5DD8F for ; Sun, 27 Jan 2002 01:47:37 -0500 (EST) Received: from jariws1 ([62.248.147.243]) by fep02-app.kolumbus.fi (InterMail vM.5.01.03.15 201-253-122-118-115-20011108) with SMTP id <20020127064736.PKDI16149.fep02-app.kolumbus.fi@jariws1>; Sun, 27 Jan 2002 08:47:36 +0200 Message-ID: <01e101c1a6fe$90f0f8e0$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: "Mark Eklund" , References: <200201270508.AAA01728@knox6039.cisco.com> Subject: Re: [AAA-WG]: Issue #254 Date: Sun, 27 Jan 2002 08:48:02 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > Setting in stone what aspects of IPsec may and may not be used is well > beyond what Diameter should specify. Future enhancements of IPsec or Aren't we doing the same thing already for TLS? Jari From owner-aaa-wg@merit.edu Sun Jan 27 01:50: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 BAA17998 for ; Sun, 27 Jan 2002 01:50:49 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 4CBE091229; Sun, 27 Jan 2002 01:50:37 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 24D349122A; Sun, 27 Jan 2002 01:50: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 20A3E91229 for ; Sun, 27 Jan 2002 01:50:36 -0500 (EST) Received: by segue.merit.edu (Postfix) id 04DB75DDC9; Sun, 27 Jan 2002 01:50:36 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from fep02-app.kolumbus.fi (fep02-0.kolumbus.fi [193.229.0.44]) by segue.merit.edu (Postfix) with ESMTP id 2AF7F5DD8F for ; Sun, 27 Jan 2002 01:50:35 -0500 (EST) Received: from jariws1 ([62.248.147.243]) by fep02-app.kolumbus.fi (InterMail vM.5.01.03.15 201-253-122-118-115-20011108) with SMTP id <20020127065034.PKLP16149.fep02-app.kolumbus.fi@jariws1>; Sun, 27 Jan 2002 08:50:34 +0200 Message-ID: <01e701c1a6fe$fae992c0$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: "Mark Eklund" , References: <200201270519.AAA01731@knox6039.cisco.com> Subject: Re: [AAA-WG]: Issue 256 Date: Sun, 27 Jan 2002 08:51:00 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > Issue 256 suggests the text below. In particular it requires TLS peer > authentication. Is there ever a situation where you want to use the > TLS encryption capability, but don't care to authenticate your peer? I think this issue refers to the use of the regular web TLS model, where the servers have certs and the clients don't. However, that model is inappropriate here because the clients would not get authenticated. You could e.g .send any accounting data to a server. Even in the web side, they had something to handle the other direction (credit card number for ecommerce, simple http auth passwords in other cases). However, I think neither of those fixes are appropriate for DIAMETER. Therefore, I agree with the issue 256. Jari From owner-aaa-wg@merit.edu Sun Jan 27 01:57: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 BAA18063 for ; Sun, 27 Jan 2002 01:57:41 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 854259122A; Sun, 27 Jan 2002 01:57:18 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4F1B69122B; Sun, 27 Jan 2002 01:57: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 121419122A for ; Sun, 27 Jan 2002 01:57:17 -0500 (EST) Received: by segue.merit.edu (Postfix) id AB8415DE6C; Sun, 27 Jan 2002 01:56:51 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from fep02-app.kolumbus.fi (fep02-0.kolumbus.fi [193.229.0.44]) by segue.merit.edu (Postfix) with ESMTP id D21BF5DD8F for ; Sun, 27 Jan 2002 01:56:50 -0500 (EST) Received: from jariws1 ([62.248.147.243]) by fep02-app.kolumbus.fi (InterMail vM.5.01.03.15 201-253-122-118-115-20011108) with SMTP id <20020127065634.PLIH16149.fep02-app.kolumbus.fi@jariws1>; Sun, 27 Jan 2002 08:56:34 +0200 Message-ID: <01ff01c1a6ff$d1dedec0$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: "Jari Arkko" , "Mark Eklund" , References: <200201270508.AAA01728@knox6039.cisco.com> <01e101c1a6fe$90f0f8e0$8a1b6e0a@arenanet.fi> Subject: Re: [AAA-WG]: Issue #254 Date: Sun, 27 Jan 2002 08:57:00 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > > Setting in stone what aspects of IPsec may and may not be used is well > > beyond what Diameter should specify. Future enhancements of IPsec or > > Aren't we doing the same thing already for TLS? And I'm continuing my own comment.... the reason we are doing this in either case is interoperability, ensuring that DIAMETER nodes become interoperable with each other. We can go a little beyond TLS/IPsec interoperability requirements because we know the specific use case for them. I think this is needed. As to further developments, they may indeed occur. However, please remember our recommendation is the *minimum* what must be implemented. We don't necessarily have to re-publish our recommendation in the RFC if something new comes along; smart network managers will deploy it. Only when our recommendation starts to get so old that vendors have trouble find that old stuff any more, then we are going to get complaints and have to re-issue the recommendation for DIAMETERv2... Jari From owner-aaa-wg@merit.edu Sun Jan 27 20:29: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 UAA05573 for ; Sun, 27 Jan 2002 20:29:31 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E915E91230; Sun, 27 Jan 2002 20:29:18 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B900891231; Sun, 27 Jan 2002 20:29: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 69B9F91230 for ; Sun, 27 Jan 2002 20:29:17 -0500 (EST) Received: by segue.merit.edu (Postfix) id 496B45DDE7; Sun, 27 Jan 2002 20:29:17 -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 D86305DDE3 for ; Sun, 27 Jan 2002 20:29:16 -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 g0S1T9S14147; Sun, 27 Jan 2002 19:29:09 -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 g0S1T8q25070; Sun, 27 Jan 2002 19:29:09 -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 TAA16829; Sun, 27 Jan 2002 19:29:08 -0600 (CST) Received: from ericsson.com ([138.85.159.104]) by qpop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id TAA22272; Sun, 27 Jan 2002 19:29:07 -0600 (CST) Message-ID: <3C54A8EB.5B665D87@ericsson.com> Date: Sun, 27 Jan 2002 17:27: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: Bob Kopacz Cc: aaa-wg Subject: [AAA-WG]: Issue 267 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hello Bob, Bob Kopacz wrote: > Issue : Minor corrections/clarifications to draft-mobileip-08 > Submitter name: Bob Kopacz > Submitter email address: BKopacz@InterlinkNetworks.com > Date first submitted: 01-17-2002 > Reference: > Document: draft-ietf-aaa-diameter-mobileip-08 > Comment type: Editorial > Priority: 1 > Section: 4.6.1, 6.8 > Rationale/Explanation of issue: > > Minor corrections/clarifications. > > Requested change: > > In section 4.6.1, 2nd line of 1st paragraph, change "algorithm" > to "algorithm and secret" What follows is the existing 4.6.1 I agree. > > > > 4.6.1 MIP-MN-AAA-SPI AVP > > > > The MIP-MN-AAA-SPI AVP (AVP Code 341) is of type Unsigned32 and > > indicates the algorithm by which the targeted AAA server (AAAH) > > should attempt to validate the Authenticator computed by the mobile > > node over the Registration Request data. > > In section 6.8, change the name of the 3rd enumerated value > from "SHA-1" to "HMAC-SHA-1". Are you sure about this? The latest aaa-key draft I can find is draft-ietf-mobileip-aaa-key-08.txt, which says Algorithm Identifier Name Reference --------------------- ------------------ ------------ 1 MD5/prefix+suffix RFC 2002 [11] 2 HMAC MD5 RFC 2104 [6] 3 SHA-1 FIPS 180-1 [10] Regards, Tony > > > What follows is the current 4.6.1: > > > 6.8 MIP-Algorithm-Type AVP > > > > 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 [4] > > 2 HMAC-MD5 [13] > > 3 SHA-1 [17] > > [The following, taken from "AAA Registration Keys for Mobile IP", > (draft-ietf-mobileip-aaa-key-09.txt), refers to "HMAC-SHA-1"] > > > 3. Dynamic Security Associations > > > > Mobility Security Associations between Mobile IP entities > > (mobile nodes, home agents, foreign agents) contain both the > > necessary cryptographic key information, and a way to identify > > the cryptographic algorithm which uses the key to produce the > > authentication information typically included in the Mobile Home > > Authentication extension or the Mobile Foreign Authentication > > extension. In order for the mobile node to make use of key material > > created by the AAA server, the mobile node also has to be able to > > select the appropriate cryptographic algorithm that uses the key > > to produce the authentication. The following table contains the > > supported algorithm identifiers. > > > > Algorithm Identifier Name Reference > > --------------------- ------------------ ------------ > > 1 MD5/prefix+suffix RFC 2002 [11] > > 2 HMAC-MD5 RFC 2104 [6] > > 3 HMAC-SHA-1 RFC 2104 [6] From owner-aaa-wg@merit.edu Sun Jan 27 21: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 VAA07126 for ; Sun, 27 Jan 2002 21:40:00 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5235091206; Sun, 27 Jan 2002 21:39:45 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 263BB91232; Sun, 27 Jan 2002 21:39: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 F1AA291206 for ; Sun, 27 Jan 2002 21:39:43 -0500 (EST) Received: by segue.merit.edu (Postfix) id D38365DDF1; Sun, 27 Jan 2002 21:39:43 -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 701B25DDCA for ; Sun, 27 Jan 2002 21:39:43 -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 g0S2ddh11927 for ; Sun, 27 Jan 2002 20:39:39 -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 g0S2dda05896 for ; Sun, 27 Jan 2002 20:39:39 -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 UAA22411 for ; Sun, 27 Jan 2002 20:39:38 -0600 (CST) Received: from ericsson.com ([138.85.159.104]) by qpop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id UAA23125 for ; Sun, 27 Jan 2002 20:39:37 -0600 (CST) Message-ID: <3C54B971.4B56BF94@ericsson.com> Date: Sun, 27 Jan 2002 18:37: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: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 265 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 adopt Issue 265, with the proposed text. Thus, change second paragraph in section 2.2 From: "An AMA message with the Result-Code AVP set to DIAMETER_SUCCESS MUST include the MIP-Home-Agent-Address, MIP-Home-Mobile-Node-Address and MIP-Reg-Reply AVPs." To: "An AMA message with the Result-Code AVP set to DIAMETER_SUCCESS MUST include the MIP-Home-Agent-Address AVP, MUST include the MIP-Home-Mobile-Node-Address AVP, and includes the MIP-Reg-Reply AVP if and only if the Co-Located-Mobile-Node bit was not set in the MIP-Feature-Vector AVP." Comments/objections? Regards, /Tony From owner-aaa-wg@merit.edu Sun Jan 27 21:42: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 VAA07172 for ; Sun, 27 Jan 2002 21:42:06 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E4A5291232; Sun, 27 Jan 2002 21:41:47 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B8A4391233; Sun, 27 Jan 2002 21:41: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 8FFAD91232 for ; Sun, 27 Jan 2002 21:41:46 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6F2AF5DDF1; Sun, 27 Jan 2002 21:41:46 -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 3C4615DDCA for ; Sun, 27 Jan 2002 21:41:46 -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 g0S2fjh12156 for ; Sun, 27 Jan 2002 20:41:45 -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 g0S2fjq29220 for ; Sun, 27 Jan 2002 20:41:45 -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 UAA22562 for ; Sun, 27 Jan 2002 20:41:44 -0600 (CST) Received: from ericsson.com ([138.85.159.104]) by qpop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id UAA23155 for ; Sun, 27 Jan 2002 20:41:44 -0600 (CST) Message-ID: <3C54B9F0.45CECB90@ericsson.com> Date: Sun, 27 Jan 2002 18:39:45 -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 Subject: [AAA-WG]: Issue 264 References: 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 adopt Issue 264. Thus, allow the User-Name AVP to appear in AMA and HAA. Here is the proposed the changes; 1. Add "[User-Name]" to ABNF in section 2.2 AA-Mobile-Node-Answer and section 2.4 Home-Agent-MIP-Answer. 2. Change User-Name in section 8.1, to ..... User-Name | 1 | 0-1 | 1 | 0-1 | ------------------------------|-----+-----+-----+-----| Comments/Objections? Regards, Tony From owner-aaa-wg@merit.edu Mon Jan 28 09:34: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 JAA27255 for ; Mon, 28 Jan 2002 09:34:59 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 551709123C; Mon, 28 Jan 2002 09:34:22 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 22FAC9123D; Mon, 28 Jan 2002 09:34: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 14A419123C for ; Mon, 28 Jan 2002 09:34:21 -0500 (EST) Received: by segue.merit.edu (Postfix) id DB9245DDDC; Mon, 28 Jan 2002 09:34:20 -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 99FD05DD9A for ; Mon, 28 Jan 2002 09:34:20 -0500 (EST) Received: from phoenix (nat.interlinknetworks.com [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with SMTP id 3A73B79; Mon, 28 Jan 2002 09:34:20 -0500 (EST) From: "Bob Kopacz" To: "Tony Johansson" Cc: "aaa-wg" Subject: [AAA-WG]: RE: Issue 267 Date: Mon, 28 Jan 2002 09:33:46 -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 Importance: Normal In-Reply-To: <3C54A8EB.5B665D87@ericsson.com> Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Tony, > From: Tony Johansson [tony.johansson@ericsson.com] > Sent: Sunday, January 27, 2002 8:27 PM > To: Bob Kopacz > Cc: aaa-wg > Subject: Issue 267 > > Hello Bob, > > Bob Kopacz wrote: > > > Issue : Minor corrections/clarifications to draft-mobileip-08 > > Submitter name: Bob Kopacz > > Submitter email address: BKopacz@InterlinkNetworks.com > > Date first submitted: 01-17-2002 > > Reference: > > Document: draft-ietf-aaa-diameter-mobileip-08 > > Comment type: Editorial > > Priority: 1 > > Section: 4.6.1, 6.8 > > Rationale/Explanation of issue: > > > > Minor corrections/clarifications. > > > > Requested change: > > > > In section 4.6.1, 2nd line of 1st paragraph, change "algorithm" > > to "algorithm and secret" What follows is the existing 4.6.1 > > I agree. > > > > > > > > 4.6.1 MIP-MN-AAA-SPI AVP > > > > > > The MIP-MN-AAA-SPI AVP (AVP Code 341) is of type Unsigned32 and > > > indicates the algorithm by which the targeted AAA server (AAAH) > > > should attempt to validate the Authenticator computed by the mobile > > > node over the Registration Request data. > > > > In section 6.8, change the name of the 3rd enumerated value > > from "SHA-1" to "HMAC-SHA-1". > > Are you sure about this? The latest aaa-key draft I can find is > draft-ietf-mobileip-aaa-key-08.txt, which says > > Algorithm Identifier Name Reference > --------------------- ------------------ ------------ > 1 MD5/prefix+suffix RFC 2002 [11] > 2 HMAC MD5 RFC 2104 [6] > 3 SHA-1 FIPS 180-1 [10] I'm pretty sure. I have a slightly later draft, draft-ietf-mobileip-aaa-key-09.txt, dated October 2001, in which the 3rd algorithm has been changed to HMAC-SHA-1. I got draft-ietf-mobileip-aaa-key-09 from http://people.nokia.net/charliep/txt/mobilekey/mip-key.txt This was posted by Charles Perkins on the mobile ip mailing list. However it is no longer at that URL, so I will send you a copy separate from this email. The IETF search engine doesn't have key-09. It also looks like key-08 has expired. As I understand things, SHA-1 is like MD5 in that it provides an algorithm to crunch a string of octets into a digest. Where HMAC comes in is to provide a means to drag a secret key into the process. So HMAC-MD5 looks like: MD5(Key XOR opad, MD5(Key XOR ipad, text)) and HMAC-SHA-1 looks like: SHA-1(Key XOR opad, SHA-1(Key XOR ipad, text)) So if the 3rd algorithm is plain old SHA-1, then someone needs to define how to combine the key and the text before feeding into SHA-1. Take care, Bob K. > > Regards, > > Tony > > > > > > > What follows is the current 4.6.1: > > > > > 6.8 MIP-Algorithm-Type AVP > > > > > > 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 [4] > > > 2 HMAC-MD5 [13] > > > 3 SHA-1 [17] > > > > [The following, taken from "AAA Registration Keys for Mobile IP", > > (draft-ietf-mobileip-aaa-key-09.txt), refers to "HMAC-SHA-1"] > > > > > 3. Dynamic Security Associations > > > > > > Mobility Security Associations between Mobile IP entities > > > (mobile nodes, home agents, foreign agents) contain both the > > > necessary cryptographic key information, and a way to identify > > > the cryptographic algorithm which uses the key to produce the > > > authentication information typically included in the Mobile Home > > > Authentication extension or the Mobile Foreign Authentication > > > extension. In order for the mobile node to make use of key material > > > created by the AAA server, the mobile node also has to be able to > > > select the appropriate cryptographic algorithm that uses the key > > > to produce the authentication. The following table contains the > > > supported algorithm identifiers. > > > > > > Algorithm Identifier Name Reference > > > --------------------- ------------------ ------------ > > > 1 MD5/prefix+suffix RFC 2002 [11] > > > 2 HMAC-MD5 RFC 2104 [6] > > > 3 HMAC-SHA-1 RFC 2104 [6] From owner-aaa-wg@merit.edu Mon Jan 28 10:53: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 KAA00251 for ; Mon, 28 Jan 2002 10:53:04 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 914F39123F; Mon, 28 Jan 2002 10:52:40 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5F46B91240; Mon, 28 Jan 2002 10:52: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 44B269123F for ; Mon, 28 Jan 2002 10:52:39 -0500 (EST) Received: by segue.merit.edu (Postfix) id 23CA75DDFF; Mon, 28 Jan 2002 10:52:39 -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 566195DDDC for ; Mon, 28 Jan 2002 10:52:38 -0500 (EST) Received: from knox6039.cisco.com (knox6039.cisco.com [161.44.216.39]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id KAA29144; Mon, 28 Jan 2002 10:52:25 -0500 (EST) Received: (from meklund@localhost) by knox6039.cisco.com (8.9.3+Sun/8.9.3) id KAA02838; Mon, 28 Jan 2002 10:52:23 -0500 (EST) From: Mark Eklund MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15445.29623.534675.135745@gargle.gargle.HOWL> Date: Mon, 28 Jan 2002 10:52:23 -0500 To: "Jari Arkko" Cc: "Mark Eklund" , Subject: Re: [AAA-WG]: Issue #254 In-Reply-To: <01ff01c1a6ff$d1dedec0$8a1b6e0a@arenanet.fi> References: <200201270508.AAA01728@knox6039.cisco.com> <01e101c1a6fe$90f0f8e0$8a1b6e0a@arenanet.fi> <01ff01c1a6ff$d1dedec0$8a1b6e0a@arenanet.fi> X-Mailer: VM 6.93 under Emacs 21.1.1 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Jari, Correct me if I'm wrong, but isn't there a fundamental difference in TLS and IPsec? An application MUST be aware of TLS to make a TLS connection to another peer. As far as I know, the application is ignorant of the IPsec between it and its peer. It just feel that specifying how to configure IPsec is similar to saying that Diameter MUST be run over Gigabit Ethernet. It just seems to me an administrative policy decision. But if you are in favor of giving guidelines to IPsec and feel that you can predict the minimum security level every domain needs for their hop by hop security, I have no problem with guidelines being added. I honestly got lost in the 55 lines of guidelines with 10 MUSTS, 6 SHOULDS and 4 MAYS suggested in issue #254. -mark Jari Arkko writes: > > > > Setting in stone what aspects of IPsec may and may not be used is well > > > beyond what Diameter should specify. Future enhancements of IPsec or > > > > Aren't we doing the same thing already for TLS? > > And I'm continuing my own comment.... the reason we are doing this in > either case is interoperability, ensuring that DIAMETER nodes become > interoperable with each other. We can go a little beyond TLS/IPsec > interoperability requirements because we know the specific use case > for them. I think this is needed. > > As to further developments, they may indeed occur. However, please > remember our recommendation is the *minimum* what must be implemented. > We don't necessarily have to re-publish our recommendation in the RFC > if something new comes along; smart network managers will deploy it. > Only when our recommendation starts to get so old that vendors have trouble > find that old stuff any more, then we are going to get complaints and have > to re-issue the recommendation for DIAMETERv2... > > Jari > > From owner-aaa-wg@merit.edu Mon Jan 28 11:07: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 LAA00844 for ; Mon, 28 Jan 2002 11:07:04 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A316791240; Mon, 28 Jan 2002 11:06:49 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6CC5A91241; Mon, 28 Jan 2002 11:06: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 5066691240 for ; Mon, 28 Jan 2002 11:06:48 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2BDA45DE05; Mon, 28 Jan 2002 11:06:48 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from ws2.piuha.net (ws2.piuha.net [195.165.196.2]) by segue.merit.edu (Postfix) with ESMTP id BD2645DDDC for ; Mon, 28 Jan 2002 11:06:47 -0500 (EST) Received: from kolumbus.fi (ws4.piuha.net [195.165.196.4]) by ws2.piuha.net (Postfix) with ESMTP id 0EA476A904; Mon, 28 Jan 2002 18:06:37 +0200 (EET) Message-ID: <3C557741.1010602@kolumbus.fi> Date: Mon, 28 Jan 2002 18:07:29 +0200 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: Mark Eklund Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue #254 References: <200201270508.AAA01728@knox6039.cisco.com> <01e101c1a6fe$90f0f8e0$8a1b6e0a@arenanet.fi> <01ff01c1a6ff$d1dedec0$8a1b6e0a@arenanet.fi> <15445.29623.534675.135745@gargle.gargle.HOWL> 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 Mark Eklund wrote: > Correct me if I'm wrong, but isn't there a fundamental difference in > TLS and IPsec? An application MUST be aware of TLS to make a TLS > connection to another peer. As far as I know, the application is > ignorant of the IPsec between it and its peer. > > It just feel that specifying how to configure IPsec is similar to > saying that Diameter MUST be run over Gigabit Ethernet. It just seems > to me an administrative policy decision. You are in part right, but I think the crucial issue here is if the Diameter spec is referencing a specific piece of underlying technology, then we need to worry about *how* that is used and how much we expect from it. For instance, we have no need to state that Diameter MUST be run over gigabit ethernet or fast ethernet, but SHOULD NOT be run over regular ethernet. Now, for security we do find a reason to state that you MUST run diameter with either IPsec or TLS. In that sense TLS and IPsec are similar in our context that both are being mandated by us. > But if you are in favor of giving guidelines to IPsec and feel that > you can predict the minimum security level every domain needs for > their hop by hop security, I have no problem with guidelines being > added. I honestly got lost in the 55 lines of guidelines with 10 > MUSTS, 6 SHOULDS and 4 MAYS suggested in issue #254. Very much agree. Perhaps the text is an overkill. I would actually prefer some simpler statement. A long time ago I think I proposed something like MUST implement IPsec architecture [ref] and the ESP protocol [ref], with required support for at least the SHA1 and 3DES algorithms [ref]. MAY implement IKE [ref]. Bernard, do you think we could come up with a shorter statement? Jari From owner-aaa-wg@merit.edu Mon Jan 28 11:42: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 LAA01990 for ; Mon, 28 Jan 2002 11:42:37 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 20CA691241; Mon, 28 Jan 2002 11:42:26 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E6C4391242; Mon, 28 Jan 2002 11:42: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 BA25D91241 for ; Mon, 28 Jan 2002 11:42:24 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9EA165DDDC; Mon, 28 Jan 2002 11:42:24 -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 CE5315DD9B for ; Mon, 28 Jan 2002 11:42:23 -0500 (EST) Received: from knox6039.cisco.com (knox6039.cisco.com [161.44.216.39]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id LAA00368; Mon, 28 Jan 2002 11:42:22 -0500 (EST) Received: (from meklund@localhost) by knox6039.cisco.com (8.9.3+Sun/8.9.3) id LAA02878; Mon, 28 Jan 2002 11:42:20 -0500 (EST) From: Mark Eklund MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15445.32620.857923.623868@gargle.gargle.HOWL> Date: Mon, 28 Jan 2002 11:42:20 -0500 To: Jari Arkko Cc: Mark Eklund , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue #254 In-Reply-To: <3C557741.1010602@kolumbus.fi> References: <200201270508.AAA01728@knox6039.cisco.com> <01e101c1a6fe$90f0f8e0$8a1b6e0a@arenanet.fi> <01ff01c1a6ff$d1dedec0$8a1b6e0a@arenanet.fi> <15445.29623.534675.135745@gargle.gargle.HOWL> <3C557741.1010602@kolumbus.fi> X-Mailer: VM 6.93 under Emacs 21.1.1 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Coming up with a shorter statement sounds good to me. Are there any other drafts that do something similar that we can leverage their wording? -mark Jari Arkko writes: > Mark Eklund wrote: > > > > Correct me if I'm wrong, but isn't there a fundamental difference in > > TLS and IPsec? An application MUST be aware of TLS to make a TLS > > connection to another peer. As far as I know, the application is > > ignorant of the IPsec between it and its peer. > > > > It just feel that specifying how to configure IPsec is similar to > > saying that Diameter MUST be run over Gigabit Ethernet. It just seems > > to me an administrative policy decision. > > > You are in part right, but I think the crucial issue here is if > the Diameter spec is referencing a specific piece of underlying > technology, then we need to worry about *how* that is used and > how much we expect from it. For instance, we have no need to > state that Diameter MUST be run over gigabit ethernet or fast > ethernet, but SHOULD NOT be run over regular ethernet. Now, for > security we do find a reason to state that you MUST run diameter > with either IPsec or TLS. In that sense TLS and IPsec are similar > in our context that both are being mandated by us. > > > > But if you are in favor of giving guidelines to IPsec and feel that > > you can predict the minimum security level every domain needs for > > their hop by hop security, I have no problem with guidelines being > > added. I honestly got lost in the 55 lines of guidelines with 10 > > MUSTS, 6 SHOULDS and 4 MAYS suggested in issue #254. > > Very much agree. Perhaps the text is an overkill. I would actually > prefer some simpler statement. A long time ago I think I proposed > something like MUST implement IPsec architecture [ref] and the ESP protocol > [ref], with required support for at least the SHA1 and 3DES algorithms [ref]. > MAY implement IKE [ref]. Bernard, do you think we could come up with a > shorter statement? > > Jari From owner-aaa-wg@merit.edu Mon Jan 28 12:49: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 MAA03898 for ; Mon, 28 Jan 2002 12:49:42 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 4B38091203; Mon, 28 Jan 2002 12:49:26 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1301091242; Mon, 28 Jan 2002 12:49: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 E27C991203 for ; Mon, 28 Jan 2002 12:49:24 -0500 (EST) Received: by segue.merit.edu (Postfix) id ABBCD5DE07; Mon, 28 Jan 2002 12:49:24 -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 DC8BA5DDEF for ; Mon, 28 Jan 2002 12:49:23 -0500 (EST) Received: from knox6039.cisco.com (knox6039.cisco.com [161.44.216.39]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id MAA01910; Mon, 28 Jan 2002 12:49:22 -0500 (EST) Received: (from meklund@localhost) by knox6039.cisco.com (8.9.3+Sun/8.9.3) id MAA03068; Mon, 28 Jan 2002 12:49:22 -0500 (EST) Date: Mon, 28 Jan 2002 12:49:22 -0500 (EST) Message-Id: <200201281749.MAA03068@knox6039.cisco.com> From: Mark Eklund To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue #253 Sender: owner-aaa-wg@merit.edu Precedence: bulk As long as no one has objections, I plan to commit issue #253 to the base. The changes are the same as the issue listed in http://www.drizzle.com/~aboba/AAA/issues.html#Issue #253. The diffs are listed below. *** ../draft-ietf-aaa-diameter.txt Mon Jan 28 12:34:49 2002 --- 253.txt Mon Jan 28 12:35:25 2002 *************** 5.2 Diameter Peer Discovery *** 2899,2910 **** and only those will be discovered. 3. The Diameter implementation uses DNS to request the SRV RR [33] ! for the '_diameter._sctp' and/or '_diameter._tcp' server in a ! particular realm. The Diameter implementation has to know in ! advance which realm to look for a Diameter agent in. This ! could be deduced, for example, from the 'realm' in a NAI that a ! Diameter implementation needed to perform a Diameter operation ! on. 3.1 If the destination address is a numeric IP address, the requestor contacts the peer at the given address and the --- 2899,2912 ---- and only those will be discovered. 3. The Diameter implementation uses DNS to request the SRV RR [33] ! for the '_diameter-tls._sctp' and/or '_diameter-tls._tcp' in a ! particular realm, as well as the '_diameter._sctp' and/or ! '_diameter._tcp' servers. If records corresponding to the TLS ! ports are found, the Diameter peer is assumed to support TLS. ! The Diameter implementation has to know in advance which realm ! to look for a Diameter agent in. This could be deduced, for ! example, from the 'realm' in a NAI that a Diameter ! implementation needed to perform a Diameter operation on. 3.1 If the destination address is a numeric IP address, the requestor contacts the peer at the given address and the *************** 5.2 Diameter Peer Discovery *** 2923,2948 **** 3.3 If there are no SRV records, the requestor queries the DNS server for address records for the destination address '_diameter._sctp'.realm or '_diameter._tcp'.realm. Address ! records include A RR's, AAAA RR's, A6 RR's or other similar ! records, chosen according to the requestor's network ! protocol capabilities. If the DNS server returns no address records, the requestor gives up. If there are address records, the same rules as in step 3.2 apply. --- 2925,2949 ---- 3.3 If there are no SRV records, the requestor queries the DNS server for address records for the destination address '_diameter._sctp'.realm or '_diameter._tcp'.realm. Address ! records include A RRs, AAAA RRs or other similar records, ! chosen according to the requestor's network protocol ! capabilities. If the DNS server returns no address records, the requestor gives up. If there are address records, the same rules as in step 3.2 apply. -mark From owner-aaa-wg@merit.edu Mon Jan 28 14:26:09 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 OAA06527 for ; Mon, 28 Jan 2002 14:26:08 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A64F591247; Mon, 28 Jan 2002 14:25:53 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7215091248; Mon, 28 Jan 2002 14:25: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 497A491247 for ; Mon, 28 Jan 2002 14:25:52 -0500 (EST) Received: by segue.merit.edu (Postfix) id 22B735DE6B; Mon, 28 Jan 2002 14:25:52 -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 503835DE14 for ; Mon, 28 Jan 2002 14:25:51 -0500 (EST) Received: from knox6039.cisco.com (knox6039.cisco.com [161.44.216.39]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id OAA04513; Mon, 28 Jan 2002 14:25:50 -0500 (EST) Received: (from meklund@localhost) by knox6039.cisco.com (8.9.3+Sun/8.9.3) id OAA03251; Mon, 28 Jan 2002 14:25:49 -0500 (EST) Date: Mon, 28 Jan 2002 14:25:49 -0500 (EST) Message-Id: <200201281925.OAA03251@knox6039.cisco.com> From: Mark Eklund To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 261 Sender: owner-aaa-wg@merit.edu Precedence: bulk Issue 261 proposes that we specify what peer discovery mechanism is required. In particular it requests Indicate in the list under 5.2 that the first option (manual configuration) MUST be supported by all DIAMETER nodes, while the latter two options (SRVLOC and DNS SRV records) MAY be supported. I'm worried that if we do this, someone can't come up with some "plug and play" Diameter client that has absolutely no configuration and has the ability to discover the needed peers. I see no reason to mandate how a certain Diameter implementation discovers its peers. For this reason I vote we reject this issue. -mark From owner-aaa-wg@merit.edu Mon Jan 28 14:32: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 OAA06661 for ; Mon, 28 Jan 2002 14:32:00 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5A7D091248; Mon, 28 Jan 2002 14:31:40 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8D85591249; Mon, 28 Jan 2002 14:31: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 B06DA91248 for ; Mon, 28 Jan 2002 14:31:29 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7D1425DE14; Mon, 28 Jan 2002 14:31:29 -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 717BF5DE70 for ; Mon, 28 Jan 2002 14:31:28 -0500 (EST) Received: from knox6039.cisco.com (knox6039.cisco.com [161.44.216.39]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id OAA04657 for ; Mon, 28 Jan 2002 14:31:27 -0500 (EST) Received: (from meklund@localhost) by knox6039.cisco.com (8.9.3+Sun/8.9.3) id OAA03257; Mon, 28 Jan 2002 14:31:26 -0500 (EST) Message-Id: <200201281931.OAA03257@knox6039.cisco.com> From: Mark Eklund To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue #260 Date: Mon, 28 Jan 2002 12:49:22 -0500 (EST) Sender: owner-aaa-wg@merit.edu Precedence: bulk As long as no one has objections, I plan to commit issue #260 to the base. The changes are the same as the issue listed in http://www.drizzle.com/~aboba/AAA/issues.html#Issue #260. The diffs are listed below. *** ../draft-ietf-aaa-diameter.txt Mon Jan 28 13:53:20 2002 --- 260.txt Mon Jan 28 13:53:57 2002 *************** 4.4 Derived AVP Data Formats *** 1991,2007 **** addresses. Time ! The Time format is derived from the Unsigned32 AVP Base Format. ! This is 32 bit unsigned value containing the four most ! significant octets returned from NTP [18], in network byte ! order. ! This represent the number of seconds since 0h on 1 January 1900 ! with respect to the Coordinated Universal Time (UTC). On 6h 28m 16s UTC, 7 February 2036 the time value will ! overflow. NTP [18] describes a procedure to extend the time to ! 2104. UTF8String The UTF8String format is derived from the OctetString AVP Base --- 1991,2007 ---- addresses. Time ! The Time format is derived from the OctetString AVP Base ! Format. The string MUST contain four octets, in the same format ! as the four first bytes are in the NTP Timestamp Format. The ! NTP Timestamp format is defined in Chapter 3 of reference [18]. ! This represents the number of seconds since 0h on 1 January ! 1900 with respect to the Coordinated Universal Time (UTC). On 6h 28m 16s UTC, 7 February 2036 the time value will ! overflow. SNTP [18] describes a procedure to extend the time to ! 2104. This procedure MUST be used by all DIAMETER nodes. UTF8String The UTF8String format is derived from the OctetString AVP Base -mark From owner-aaa-wg@merit.edu Mon Jan 28 14:48: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 OAA07105 for ; Mon, 28 Jan 2002 14:48:00 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 6799F91249; Mon, 28 Jan 2002 14:47:44 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 315E99124A; Mon, 28 Jan 2002 14:47: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 18F6791249 for ; Mon, 28 Jan 2002 14:47:43 -0500 (EST) Received: by segue.merit.edu (Postfix) id EA3455DE72; Mon, 28 Jan 2002 14:47:42 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from fep06-app.kolumbus.fi (fep06-0.kolumbus.fi [193.229.0.57]) by segue.merit.edu (Postfix) with ESMTP id 1A2CF5DE14 for ; Mon, 28 Jan 2002 14:47:42 -0500 (EST) Received: from jariws1 ([62.248.146.117]) by fep06-app.kolumbus.fi (InterMail vM.5.01.03.15 201-253-122-118-115-20011108) with SMTP id <20020128194735.NOCX7081.fep06-app.kolumbus.fi@jariws1>; Mon, 28 Jan 2002 21:47:35 +0200 Message-ID: <008601c1a834$a36bc7c0$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: "Mark Eklund" , References: <200201281925.OAA03251@knox6039.cisco.com> Subject: Re: [AAA-WG]: Issue 261 Date: Mon, 28 Jan 2002 21:47:37 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > I'm worried that if we do this, someone can't come up with some "plug > and play" Diameter client that has absolutely no configuration and has > the ability to discover the needed peers. I see no reason to mandate > how a certain Diameter implementation discovers its peers. Can you clarify why? I.e. why does this prevent someone coming up with a Diameter client that does that? You can certainly have more stuff in the client than the minimal requirements are? (By the way, we had a discussion since 261 was introduced that indicated that we should separate implementation support in clients and the necessary setups in DNS etc. Therefore, if a particular client does have DNS etc. then he can be assured that he can fetch the information from the infrastructure.) Jari From owner-aaa-wg@merit.edu Mon Jan 28 14:57: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 OAA07293 for ; Mon, 28 Jan 2002 14:57:43 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id CF8039124A; Mon, 28 Jan 2002 14:57:29 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A35D49124B; Mon, 28 Jan 2002 14:57: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 80E129124A for ; Mon, 28 Jan 2002 14:57:28 -0500 (EST) Received: by segue.merit.edu (Postfix) id 50BD05DE7B; Mon, 28 Jan 2002 14:57:28 -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 1D9075DE83 for ; Mon, 28 Jan 2002 14:57:27 -0500 (EST) Received: from knox6039.cisco.com (knox6039.cisco.com [161.44.216.39]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id OAA05359; Mon, 28 Jan 2002 14:56:58 -0500 (EST) Received: (from meklund@localhost) by knox6039.cisco.com (8.9.3+Sun/8.9.3) id OAA03279; Mon, 28 Jan 2002 14:56:56 -0500 (EST) From: Mark Eklund MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15445.44296.686550.914346@gargle.gargle.HOWL> Date: Mon, 28 Jan 2002 14:56:56 -0500 To: "Jari Arkko" Cc: "Mark Eklund" , Subject: Re: [AAA-WG]: Issue 261 In-Reply-To: <008601c1a834$a36bc7c0$8a1b6e0a@arenanet.fi> References: <200201281925.OAA03251@knox6039.cisco.com> <008601c1a834$a36bc7c0$8a1b6e0a@arenanet.fi> X-Mailer: VM 6.93 under Emacs 21.1.1 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Jari Arkko writes: > > I'm worried that if we do this, someone can't come up with some "plug > > and play" Diameter client that has absolutely no configuration and has > > the ability to discover the needed peers. I see no reason to mandate > > how a certain Diameter implementation discovers its peers. > > Can you clarify why? I.e. why does this prevent someone coming > up with a Diameter client that does that? You can certainly have > more stuff in the client than the minimal requirements are? The suggested text says "(manual configuration) MUST be supported". My above example does not support manual configuration and thus is not a Diameter complient server. -mark > > (By the way, we had a discussion since 261 was introduced > that indicated that we should separate implementation support in clients > and the necessary setups in DNS etc. Therefore, if a particular client > does have DNS etc. then he can be assured that he can fetch the > information from the infrastructure.) > > Jari > > From owner-aaa-wg@merit.edu Mon Jan 28 16:57: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 QAA09847 for ; Mon, 28 Jan 2002 16:57:39 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 57BAF9124B; Mon, 28 Jan 2002 16:57:29 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 258089124C; Mon, 28 Jan 2002 16:57: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 95B2B9124B for ; Mon, 28 Jan 2002 16:57:27 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3BD9F5DE7F; Mon, 28 Jan 2002 16:57:27 -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 ECEE05DE7C for ; Mon, 28 Jan 2002 16:57:08 -0500 (EST) Received: by EXCHSRV.stormventures.com with Internet Mail Service (5.5.2653.19) id ; Mon, 28 Jan 2002 13:57:02 -0800 Message-ID: From: "Pat R. Calhoun" To: "'aaa-wg@merit.edu'" Subject: [AAA-WG]: Diameter Spec Editorship Date: Mon, 28 Jan 2002 13:57:01 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1A846.B70D8C20" 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_01C1A846.B70D8C20 Content-Type: text/plain -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 All, I wanted to inform everyone on the list that due to the amount of time my new startup is taking up, I've had to relinquish my editorship responsibilities. Mark Eklund has taken over the base protocol spec, and kindly ask the list members to work with Mark to help get this spec out as soon as possible. Others have signed up for the other specs, but I am waiting to see if they can commit to the rather agressive schedule before making any further announcements. Thanks, PatC -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 7.0.3 for non-commercial use iQA/AwUBPFXJLTN1fXKoxmisEQJragCfc7NYZbfz+ApfuJmerdQsE0nqZeIAn1eC p8+UHTq2xcFjtKpQWdhuykJ5 =pbu9 -----END PGP SIGNATURE----- ------_=_NextPart_001_01C1A846.B70D8C20 Content-Type: text/html Content-Transfer-Encoding: quoted-printable Diameter Spec Editorship

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

All,

I wanted to inform everyone on the list that due to = the amount of
time my new startup is taking up, I've had to = relinquish my
editorship responsibilities. Mark Eklund has taken = over the base
protocol spec, and kindly ask the list members to = work with Mark to
help get this spec out as soon as possible.

Others have signed up for the other specs, but I am = waiting to see if
they can commit to the rather agressive schedule = before making any
further announcements.

Thanks,

PatC

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

iQA/AwUBPFXJLTN1fXKoxmisEQJragCfc7NYZbfz+ApfuJmerdQsE0nqZeIAn1e= C
p8+UHTq2xcFjtKpQWdhuykJ5
=3Dpbu9
-----END PGP SIGNATURE-----

------_=_NextPart_001_01C1A846.B70D8C20-- From owner-aaa-wg@merit.edu Tue Jan 29 00:17: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 AAA17719 for ; Tue, 29 Jan 2002 00:17:39 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1793A9124E; Tue, 29 Jan 2002 00:17:20 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D15F29124F; Tue, 29 Jan 2002 00: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 96C379124E for ; Tue, 29 Jan 2002 00:17:17 -0500 (EST) Received: by segue.merit.edu (Postfix) id 74EF25DDA1; Tue, 29 Jan 2002 00:17:17 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from fep06-app.kolumbus.fi (fep06-0.kolumbus.fi [193.229.0.57]) by segue.merit.edu (Postfix) with ESMTP id 998075DD96 for ; Tue, 29 Jan 2002 00:17:16 -0500 (EST) Received: from jariws1 ([62.248.146.117]) by fep06-app.kolumbus.fi (InterMail vM.5.01.03.15 201-253-122-118-115-20011108) with SMTP id <20020129051715.ZYY1076.fep06-app.kolumbus.fi@jariws1>; Tue, 29 Jan 2002 07:17:15 +0200 Message-ID: <012f01c1a884$3acac040$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: "Mark Eklund" Cc: "Mark Eklund" , References: <200201281925.OAA03251@knox6039.cisco.com><008601c1a834$a36bc7c0$8a1b6e0a@arenanet.fi> <15445.44296.686550.914346@gargle.gargle.HOWL> Subject: Re: [AAA-WG]: Issue 261 Date: Tue, 29 Jan 2002 07:17:21 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > > > I'm worried that if we do this, someone can't come up with some "plug > > > and play" Diameter client that has absolutely no configuration and has > > > the ability to discover the needed peers. I see no reason to mandate > > > how a certain Diameter implementation discovers its peers. > > > > Can you clarify why? I.e. why does this prevent someone coming > > up with a Diameter client that does that? You can certainly have > > more stuff in the client than the minimal requirements are? > > The suggested text says "(manual configuration) MUST be supported". > My above example does not support manual configuration and thus is not > a Diameter complient server. Now I think I see the problem. WHat should do, then? I think I see the following alternatives: 1. Do as proposed in issue 261. If someone wants to make a plug'n'play Diameter client, he can do so but he needs to have some dead code which isn't normally used but *could* be used if the user didn't want to run the automatic mechanism. 2. Make the manual config/dns/svrloc alternatives all MAY, but then have a MUST that says at least one of them must be implemented 3. Leave the spec as is, with no keywords. This is roughly equivalent to alternative #2, except that it may not be so immediately apparent to the reader. I'm not sure myself what to do. Do you or others have a suggestion? Jari From owner-aaa-wg@merit.edu Tue Jan 29 00:52: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 AAA18220 for ; Tue, 29 Jan 2002 00:52:41 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DE84C9124F; Tue, 29 Jan 2002 00:52:29 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AE52591251; Tue, 29 Jan 2002 00:52: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 633EA9124F for ; Tue, 29 Jan 2002 00:52:28 -0500 (EST) Received: by segue.merit.edu (Postfix) id 445215DDAF; Tue, 29 Jan 2002 00:52:28 -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 79E395DD96 for ; Tue, 29 Jan 2002 00:52:27 -0500 (EST) Received: from knox6039.cisco.com (knox6039.cisco.com [161.44.216.39]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id AAA18075; Tue, 29 Jan 2002 00:52:06 -0500 (EST) Received: (from meklund@localhost) by knox6039.cisco.com (8.9.3+Sun/8.9.3) id AAA04515; Tue, 29 Jan 2002 00:52:05 -0500 (EST) From: Mark Eklund MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15446.14469.595405.770187@gargle.gargle.HOWL> Date: Tue, 29 Jan 2002 00:52:05 -0500 To: "Jari Arkko" Cc: "Mark Eklund" , Subject: Re: [AAA-WG]: Issue 261 In-Reply-To: <012f01c1a884$3acac040$8a1b6e0a@arenanet.fi> References: <200201281925.OAA03251@knox6039.cisco.com> <008601c1a834$a36bc7c0$8a1b6e0a@arenanet.fi> <15445.44296.686550.914346@gargle.gargle.HOWL> <012f01c1a884$3acac040$8a1b6e0a@arenanet.fi> X-Mailer: VM 6.93 under Emacs 21.1.1 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Jari, How about option 1.9 (almost option 2)? Add an initial sentence to 5.2: *** ../draft-ietf-aaa-diameter.txt Tue Jan 29 00:44:35 2002 --- 261.txt Tue Jan 29 00:45:12 2002 *************** 5.1 Peer Connections *** 2857,2867 **** 5.2 Diameter Peer Discovery ! Allowing for dynamic Diameter agent discovery will make it possible ! for simpler and more robust deployment of Diameter services. In ! order to promote interoperable implementations of Diameter peer ! discovery, the following mechanisms are described. These are based ! on existing IETF standards. There are two cases where Diameter peer discovery may be performed. The first is when a Diameter client needs to discover a first-hop --- 2857,2870 ---- 5.2 Diameter Peer Discovery ! In order to connect to a peer, the Diameter node MUST support at ! least one of static (manual) configuration, SLPv2 dynamic peer ! discovery, or DNS dynamic peer discovery. Allowing for dynamic ! Diameter agent discovery will make it possible for simpler and more ! robust deployment of Diameter services. In order to promote ! interoperable implementations of Diameter peer discovery, the ! following mechanisms are described. These are based on existing IETF ! standards. There are two cases where Diameter peer discovery may be performed. The first is when a Diameter client needs to discover a first-hop -mark Jari Arkko writes: > > > > I'm worried that if we do this, someone can't come up with some "plug > > > > and play" Diameter client that has absolutely no configuration and has > > > > the ability to discover the needed peers. I see no reason to mandate > > > > how a certain Diameter implementation discovers its peers. > > > > > > Can you clarify why? I.e. why does this prevent someone coming > > > up with a Diameter client that does that? You can certainly have > > > more stuff in the client than the minimal requirements are? > > > > The suggested text says "(manual configuration) MUST be supported". > > My above example does not support manual configuration and thus is not > > a Diameter complient server. > > Now I think I see the problem. WHat should do, then? I think I see the > following alternatives: > > 1. Do as proposed in issue 261. If someone wants to make a plug'n'play > Diameter client, he can do so but he needs to have some dead code > which isn't normally used but *could* be used if the user didn't want to > run the automatic mechanism. > > 2. Make the manual config/dns/svrloc alternatives all MAY, but then > have a MUST that says at least one of them must be implemented > > 3. Leave the spec as is, with no keywords. This is roughly equivalent > to alternative #2, except that it may not be so immediately apparent > to the reader. > > I'm not sure myself what to do. Do you or others have a suggestion? > > Jari > > > > From owner-aaa-wg@merit.edu Tue Jan 29 01:54: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 BAA18693 for ; Tue, 29 Jan 2002 01:54:32 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id CEE9B91251; Tue, 29 Jan 2002 01:54:20 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9698791252; Tue, 29 Jan 2002 01:54: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 8253091251 for ; Tue, 29 Jan 2002 01:54:19 -0500 (EST) Received: by segue.merit.edu (Postfix) id 697925DDA5; Tue, 29 Jan 2002 01:54:19 -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 0DC045DD93 for ; Tue, 29 Jan 2002 01:54:19 -0500 (EST) Received: from gwzpc (tokyo-vpn-client20.cisco.com [10.70.84.20]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id WAA12514; Mon, 28 Jan 2002 22:53:40 -0800 (PST) Reply-To: From: "Glen Zorn" To: "Mark Eklund" , "Bernard Aboba" , Cc: Subject: WG Operation (was RE: [AAA-WG]: Issue #253) Date: Mon, 28 Jan 2002 22:53:38 -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) In-Reply-To: <200201281749.MAA03068@knox6039.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Mark Eklund [mailto:meklund@cisco.com] writes: > As long as no one has objections, I plan to commit issue #253 to the > base. There are a couple of problems with this statement, which I think may have some bearing upon the activity and rather glacial progress of the AAA WG. First of all, I have no idea why the editor of the document is deciding what changes are to be made to it, especially "as long as no one has any objections". My understanding is that in the IETF the WG Chair(s) gauge the _rough consensus_ of the WG & instruct the document editor to modify the WG documents accordingly. AFAIK, rough consensus is _not_ the same as "no objections". Secondly, it seems (correct me if I'm wrong) that issues get added to the issues list with little or no analysis, which results in (sometimes lengthy) debate over "issues" that have been already resolved (sometimes months or years in the past) or are simply features from someone's wish list. So, what I'm saying is that I think that we need much more "leadership" from the chairs, in order to get this work done in this decade... ~gwz Glen Zorn CTO Consulting Engineer Security and Integrity Group Consulting Engineering Cisco Systems PGP Key Fingerprint: 4F41 B93A 007D E2FC 9769 FB97 FBCF 7DA4 9A2D 1963 From owner-aaa-wg@merit.edu Tue Jan 29 02:18: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 CAA27269 for ; Tue, 29 Jan 2002 02:18:46 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7037691252; Tue, 29 Jan 2002 02:18:29 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 37F4591254; Tue, 29 Jan 2002 02:18: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 1367291252 for ; Tue, 29 Jan 2002 02:18:28 -0500 (EST) Received: by segue.merit.edu (Postfix) id E16955DDA1; Tue, 29 Jan 2002 02:18:27 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from fep06-app.kolumbus.fi (fep06-0.kolumbus.fi [193.229.0.57]) by segue.merit.edu (Postfix) with ESMTP id 118A25DD93 for ; Tue, 29 Jan 2002 02:18:27 -0500 (EST) Received: from jariws1 ([62.248.147.36]) by fep06-app.kolumbus.fi (InterMail vM.5.01.03.15 201-253-122-118-115-20011108) with SMTP id <20020129071826.BTBV1076.fep06-app.kolumbus.fi@jariws1>; Tue, 29 Jan 2002 09:18:26 +0200 Message-ID: <000f01c1a895$249ac200$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: "Mark Eklund" Cc: "Mark Eklund" , References: <200201281925.OAA03251@knox6039.cisco.com><008601c1a834$a36bc7c0$8a1b6e0a@arenanet.fi><15445.44296.686550.914346@gargle.gargle.HOWL><012f01c1a884$3acac040$8a1b6e0a@arenanet.fi> <15446.14469.595405.770187@gargle.gargle.HOWL> Subject: Re: [AAA-WG]: Issue 261 Date: Tue, 29 Jan 2002 09:18:25 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > How about option 1.9 (almost option 2)? Add an initial sentence to > 5.2: Works for me. You also need to add language also to require that whatever is being done implementation-wise, folks need to publish the information in svrloc/dns in order for the automatic schemes to work, if some node uses them. Jari From owner-aaa-wg@merit.edu Tue Jan 29 07:33: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 HAA00884 for ; Tue, 29 Jan 2002 07:33:27 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DAF9991205; Tue, 29 Jan 2002 07:33:13 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9CBEC91253; Tue, 29 Jan 2002 07:33: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 7E2E191205 for ; Tue, 29 Jan 2002 07:33:12 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5AB8A5DE86; Tue, 29 Jan 2002 07:33:12 -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 083125DD94 for ; Tue, 29 Jan 2002 07:33:12 -0500 (EST) Received: from ehdb03-home.Germany.Sun.COM ([129.157.142.202]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA16754; Tue, 29 Jan 2002 05:33:10 -0700 (MST) Received: from sun.com (vpn-129-159-0-25.EMEA.Sun.COM [129.159.0.25]) by ehdb03-home.Germany.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v2.1p1) with ESMTP id NAA13189; Tue, 29 Jan 2002 13:33:08 +0100 (MET) Message-ID: <3C56960C.9090409@sun.com> Date: Tue, 29 Jan 2002 13:31:08 +0100 From: Erik Guttman Reply-To: erik.guttman@sun.com Organization: Sun Microsystems, GmbH User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Mark Eklund Cc: Jari Arkko , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 261 References: <200201281925.OAA03251@knox6039.cisco.com> <008601c1a834$a36bc7c0$8a1b6e0a@arenanet.fi> <15445.44296.686550.914346@gargle.gargle.HOWL> 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 Mark, Jari, Mark Eklund wrote: > Jari Arkko writes: > > > I'm worried that if we do this, someone can't come up with some "plug > > > and play" Diameter client that has absolutely no configuration and has > > > the ability to discover the needed peers. I see no reason to mandate > > > how a certain Diameter implementation discovers its peers. 261 supports plug & play as an option since SLP is supported. Proposed change: Indicate in the list under 5.2 that the first option (manual configuration) MUST be supported by all DIAMETER nodes, while the latter two options (SRVLOC and DNS SRV records) MAY be supported. If Diameter servers advertise themselves with SLP (and they SHOULD), Diameter clients can discover them (they MAY). Erik From owner-aaa-wg@merit.edu Tue Jan 29 08:58: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 IAA03239 for ; Tue, 29 Jan 2002 08:58:03 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A2C599125C; Tue, 29 Jan 2002 08:57:36 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 494E791260; Tue, 29 Jan 2002 08:57: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 09A429125C for ; Tue, 29 Jan 2002 08:57:30 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4FA885DDB6; Tue, 29 Jan 2002 08:57:29 -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 8D9A75DDBE for ; Tue, 29 Jan 2002 08:57:27 -0500 (EST) Received: (qmail 16063 invoked by uid 507); 29 Jan 2002 13:57:16 -0000 Date: Tue, 29 Jan 2002 07:57:14 -0600 From: David Frascone To: Erik Guttman Cc: Mark Eklund , Jari Arkko , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 261 Message-ID: <20020129135714.GC13093@newman.frascone.com> Mail-Followup-To: Erik Guttman , Mark Eklund , Jari Arkko , aaa-wg@merit.edu References: <200201281925.OAA03251@knox6039.cisco.com> <008601c1a834$a36bc7c0$8a1b6e0a@arenanet.fi> <15445.44296.686550.914346@gargle.gargle.HOWL> <3C56960C.9090409@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3C56960C.9090409@sun.com> User-Agent: Mutt/1.3.25i X-encrypt-payload: no X-Virus-Scanned: by AMaViS perl-11 Sender: owner-aaa-wg@merit.edu Precedence: bulk This approach works for me. On Tuesday, 29 Jan 2002, Erik Guttman wrote: > Mark, Jari, > > Mark Eklund wrote: > > >Jari Arkko writes: > > > > I'm worried that if we do this, someone can't come up with some "plug > > > > and play" Diameter client that has absolutely no configuration and has > > > > the ability to discover the needed peers. I see no reason to mandate > > > > how a certain Diameter implementation discovers its peers. > > 261 supports plug & play as an option since SLP is supported. > > Proposed change: > > Indicate in the list under 5.2 that the first > option (manual configuration) MUST be supported > by all DIAMETER nodes, while the latter two options > (SRVLOC and DNS SRV records) MAY be supported. > > If Diameter servers advertise themselves with SLP > (and they SHOULD), Diameter clients can discover > them (they MAY). > > Erik > From owner-aaa-wg@merit.edu Tue Jan 29 09:58: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 JAA04938 for ; Tue, 29 Jan 2002 09:58:22 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9DDD891266; Tue, 29 Jan 2002 09:58:10 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6FB2E91267; Tue, 29 Jan 2002 09: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 4B33491266 for ; Tue, 29 Jan 2002 09:58:09 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2FD7B5DDA2; Tue, 29 Jan 2002 09:58:09 -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 CE8545DD9D for ; Tue, 29 Jan 2002 09:58:07 -0500 (EST) Received: from knox6039.cisco.com (knox6039.cisco.com [161.44.216.39]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id JAA27446; Tue, 29 Jan 2002 09:58:00 -0500 (EST) Received: (from meklund@localhost) by knox6039.cisco.com (8.9.3+Sun/8.9.3) id JAA04787; Tue, 29 Jan 2002 09:57:58 -0500 (EST) From: Mark Eklund MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15446.47222.820274.772154@gargle.gargle.HOWL> Date: Tue, 29 Jan 2002 09:57:58 -0500 To: erik.guttman@sun.com Cc: Mark Eklund , Jari Arkko , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 261 In-Reply-To: <3C56960C.9090409@sun.com> References: <200201281925.OAA03251@knox6039.cisco.com> <008601c1a834$a36bc7c0$8a1b6e0a@arenanet.fi> <15445.44296.686550.914346@gargle.gargle.HOWL> <3C56960C.9090409@sun.com> X-Mailer: VM 6.93 under Emacs 21.1.1 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Erik, Erik Guttman writes: > Mark, Jari, > > Mark Eklund wrote: > > > Jari Arkko writes: > > > > I'm worried that if we do this, someone can't come up with some "plug > > > > and play" Diameter client that has absolutely no configuration and has > > > > the ability to discover the needed peers. I see no reason to mandate > > > > how a certain Diameter implementation discovers its peers. > > 261 supports plug & play as an option since SLP is supported. > > Proposed change: > > Indicate in the list under 5.2 that the first > option (manual configuration) MUST be supported Why MUST manual configuration be supported? If I write a server that that only uses SLP, am I in violation of the RFC because I don't support manual configuration? I know, this is a nit, but I am afraid of adding MUSTs that don't seem needed. -mark > by all DIAMETER nodes, while the latter two options > (SRVLOC and DNS SRV records) MAY be supported. > > If Diameter servers advertise themselves with SLP > (and they SHOULD), Diameter clients can discover > them (they MAY). > > Erik From owner-aaa-wg@merit.edu Tue Jan 29 10:01: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 KAA05061 for ; Tue, 29 Jan 2002 10:01:59 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id EFB0091268; Tue, 29 Jan 2002 10:01:28 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A69E19126A; Tue, 29 Jan 2002 10:01: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 698D391268 for ; Tue, 29 Jan 2002 10:01:14 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3C4805DDB0; Tue, 29 Jan 2002 10:01:14 -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 6DE445DD9D for ; Tue, 29 Jan 2002 10:01:13 -0500 (EST) Received: from knox6039.cisco.com (knox6039.cisco.com [161.44.216.39]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id KAA27529; Tue, 29 Jan 2002 10:01:12 -0500 (EST) Received: (from meklund@localhost) by knox6039.cisco.com (8.9.3+Sun/8.9.3) id KAA04790; Tue, 29 Jan 2002 10:01:11 -0500 (EST) From: Mark Eklund MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15446.47414.976013.216335@gargle.gargle.HOWL> Date: Tue, 29 Jan 2002 10:01:10 -0500 To: "Jari Arkko" Cc: "Mark Eklund" , Subject: Re: [AAA-WG]: Issue 261 In-Reply-To: <000f01c1a895$249ac200$8a1b6e0a@arenanet.fi> References: <200201281925.OAA03251@knox6039.cisco.com> <008601c1a834$a36bc7c0$8a1b6e0a@arenanet.fi> <15445.44296.686550.914346@gargle.gargle.HOWL> <012f01c1a884$3acac040$8a1b6e0a@arenanet.fi> <15446.14469.595405.770187@gargle.gargle.HOWL> <000f01c1a895$249ac200$8a1b6e0a@arenanet.fi> X-Mailer: VM 6.93 under Emacs 21.1.1 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Jari, Jari Arkko writes: > > How about option 1.9 (almost option 2)? Add an initial sentence to > > 5.2: > > Works for me. You also need to add language also to require that whatever > is being done implementation-wise, folks need to publish the information > in svrloc/dns in order for the automatic schemes to work, if some node > uses them. Are you saying that we need to add a statement of "If the client uses DNS to discover the server, the server must be registered in DNS?" Do we really need to state something that obvious? -mark > > Jari > > From owner-aaa-wg@merit.edu Tue Jan 29 10:18: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 KAA05662 for ; Tue, 29 Jan 2002 10:18:08 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E049F91207; Tue, 29 Jan 2002 10:17:50 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B04219120E; Tue, 29 Jan 2002 10:17: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 8D9D091207 for ; Tue, 29 Jan 2002 10:17:49 -0500 (EST) Received: by segue.merit.edu (Postfix) id 72E995DD9A; Tue, 29 Jan 2002 10:17:49 -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 EB8D45DD93 for ; Tue, 29 Jan 2002 10:17:48 -0500 (EST) Received: from ehdb03-home.Germany.Sun.COM ([129.157.142.202]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA20542; Tue, 29 Jan 2002 08:17:47 -0700 (MST) Received: from field (field [129.157.142.146]) by ehdb03-home.Germany.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v2.1p1) with SMTP id QAA15817; Tue, 29 Jan 2002 16:17:46 +0100 (MET) Date: Tue, 29 Jan 2002 16:17:15 +0100 (MET) From: Erik Guttman X-Sender: erikg@field To: Mark Eklund Cc: erik.guttman@sun.com, Jari Arkko , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 261 In-Reply-To: <15446.47222.820274.772154@gargle.gargle.HOWL> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk On Tue, 29 Jan 2002, Mark Eklund wrote: > > > > > I'm worried that if we do this, someone can't come up with some "plug > > > > > and play" Diameter client that has absolutely no configuration and has > > > > > the ability to discover the needed peers. I see no reason to mandate > > > > > how a certain Diameter implementation discovers its peers. > > > > 261 supports plug & play as an option since SLP is supported. > > > > Proposed change: > > > > Indicate in the list under 5.2 that the first > > option (manual configuration) MUST be supported > > Why MUST manual configuration be supported? If I write a server that > that only uses SLP, am I in violation of the RFC because I don't > support manual configuration? > > I know, this is a nit, but I am afraid of adding MUSTs that don't seem > needed. Mark, Either a Diameter client MUST support manual config or a Diameter server MUST support SLP. Otherwise, you will have a situation where the client needs to use SLP and the servers don't advertise themselves with SLP, or need to use DNS and find that no DNS SRV RRs exist. Then the operator will be hosed. In practice, don't most RADIUS servers get configured manually? Shouldn't we assume Diameter deployments will follow the same pattern as RADIUS? Please note that just because manual config is supported doesn't mean that it has to be used. One could have a plug and play Diameter client which, optionally, can take manual config. Consider plug and play appliances. You only have to manually configure (ie. to a different voltage) them when you cross an ocean :-) Most of the time you never need to do this, but if you didn't have the switch, you'd be hosed. Erik From owner-aaa-wg@merit.edu Tue Jan 29 10: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 KAA05743 for ; Tue, 29 Jan 2002 10:19:42 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A95089120E; Tue, 29 Jan 2002 10:19:26 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7948091269; Tue, 29 Jan 2002 10:19: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 3E3FD9120E for ; Tue, 29 Jan 2002 10:19:25 -0500 (EST) Received: by segue.merit.edu (Postfix) id 189505DD9A; Tue, 29 Jan 2002 10:19:25 -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 3E0465DD93 for ; Tue, 29 Jan 2002 10:19:24 -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 KAA27982; Tue, 29 Jan 2002 10:19:21 -0500 (EST) Received: (from srich@localhost) by knox6046.cisco.com (8.11.6/8.11.6) id g0TFJKk03316; Tue, 29 Jan 2002 10:19:20 -0500 From: Steve Rich MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15446.48504.748254.722033@knox6046.cisco.com> Date: Tue, 29 Jan 2002 10:19:20 -0500 To: Mark Eklund Cc: "Jari Arkko" , Subject: Re: [AAA-WG]: Issue 261 In-Reply-To: <15446.47414.976013.216335@gargle.gargle.HOWL> References: <200201281925.OAA03251@knox6039.cisco.com> <008601c1a834$a36bc7c0$8a1b6e0a@arenanet.fi> <15445.44296.686550.914346@gargle.gargle.HOWL> <012f01c1a884$3acac040$8a1b6e0a@arenanet.fi> <15446.14469.595405.770187@gargle.gargle.HOWL> <000f01c1a895$249ac200$8a1b6e0a@arenanet.fi> <15446.47414.976013.216335@gargle.gargle.HOWL> X-Mailer: VM 6.97 under Emacs 21.1.1 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Mark Eklund writes: > Jari, > > Jari Arkko writes: > > > How about option 1.9 (almost option 2)? Add an initial sentence to > > > 5.2: > > > > Works for me. You also need to add language also to require that whatever > > is being done implementation-wise, folks need to publish the information > > in svrloc/dns in order for the automatic schemes to work, if some node > > uses them. > > Are you saying that we need to add a statement of "If the client uses > DNS to discover the server, the server must be registered in DNS?" > Do we really need to state something that obvious? Mark, I think it's a good idea to add it. Often times, a little direction can go a long way, especially if the implementor isn't an expert in this area (DNS, etc.). sjr > > -mark > > > > > Jari > > > > > From owner-aaa-wg@merit.edu Tue Jan 29 10:23: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 KAA05850 for ; Tue, 29 Jan 2002 10:23:55 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 107C491269; Tue, 29 Jan 2002 10:23:45 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CC4FA9126A; Tue, 29 Jan 2002 10:23: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 BE24591269 for ; Tue, 29 Jan 2002 10:23:43 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9D67D5DDB0; Tue, 29 Jan 2002 10:23:43 -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 219235DD93 for ; Tue, 29 Jan 2002 10:23:43 -0500 (EST) Received: from ehdb03-home.Germany.Sun.COM ([129.157.142.202]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA24294; Tue, 29 Jan 2002 08:23:37 -0700 (MST) Received: from field (field [129.157.142.146]) by ehdb03-home.Germany.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v2.1p1) with SMTP id QAA15921; Tue, 29 Jan 2002 16:23:36 +0100 (MET) Date: Tue, 29 Jan 2002 16:23:05 +0100 (MET) From: Erik Guttman X-Sender: erikg@field To: Mark Eklund Cc: Jari Arkko , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 261 In-Reply-To: <15446.47414.976013.216335@gargle.gargle.HOWL> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk On Tue, 29 Jan 2002, Mark Eklund wrote: > Jari, > > Jari Arkko writes: > > > How about option 1.9 (almost option 2)? Add an initial sentence to > > > 5.2: > > > > Works for me. You also need to add language also to require that whatever > > is being done implementation-wise, folks need to publish the information > > in svrloc/dns in order for the automatic schemes to work, if some node > > uses them. > > Are you saying that we need to add a statement of "If the client uses > DNS to discover the server, the server must be registered in DNS?" > Do we really need to state something that obvious? I think we should say: Diameter clients MUST be manually configurable. Diameter servers SHOULD advertise themselves via SLP [RFC2608][RFC2614] Diameter servers SHOULD be represented by DNS SRV RR entries in DNS. [RFC2782] Diameter clients MAY use SLP or DNS SRV RRs to obtain the location of Diameter servers. The specifics of how to use DNS or SLP to make service locations available to clients can be left out of the Diameter spec, as it is covered in the cited specifications. Erik From owner-aaa-wg@merit.edu Tue Jan 29 10:26: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 KAA05925 for ; Tue, 29 Jan 2002 10:26:16 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9BD709126A; Tue, 29 Jan 2002 10:25:55 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 659BF9126B; Tue, 29 Jan 2002 10:25: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 534FF9126A for ; Tue, 29 Jan 2002 10:25:54 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3940C5DDB1; Tue, 29 Jan 2002 10:25:54 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from fep01-app.kolumbus.fi (fep01-0.kolumbus.fi [193.229.0.41]) by segue.merit.edu (Postfix) with ESMTP id 5D0255DD93 for ; Tue, 29 Jan 2002 10:25:53 -0500 (EST) Received: from jariws1 ([62.248.150.39]) by fep01-app.kolumbus.fi (InterMail vM.5.01.03.15 201-253-122-118-115-20011108) with SMTP id <20020129152552.UBMP24910.fep01-app.kolumbus.fi@jariws1>; Tue, 29 Jan 2002 17:25:52 +0200 Message-ID: <004701c1a8d9$3d6fef00$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: "Mark Eklund" Cc: "Mark Eklund" , References: <200201281925.OAA03251@knox6039.cisco.com><008601c1a834$a36bc7c0$8a1b6e0a@arenanet.fi><15445.44296.686550.914346@gargle.gargle.HOWL><012f01c1a884$3acac040$8a1b6e0a@arenanet.fi><15446.14469.595405.770187@gargle.gargle.HOWL><000f01c1a895$249ac200$8a1b6e0a@arenanet.fi> <15446.47414.976013.216335@gargle.gargle.HOWL> Subject: Re: [AAA-WG]: Issue 261 Date: Tue, 29 Jan 2002 17:25:53 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > Are you saying that we need to add a statement of "If the client uses > DNS to discover the server, the server must be registered in DNS?" > Do we really need to state something that obvious? I believe this relates to the discussion some weeks or months back, when someone stated that it would be useful to distinguish (a) must implement and (b) must register to foobar. To take your particular example, we could say that you MUST register the server to the DNS regardless of whether you employ DNS discovery mechanism or not. So if I remember correctly we concluded back then that this was a good thing. I'm not sure if that was the right conclusion, but I'm just trying to describe what we wanted to do at that time... Jari From owner-aaa-wg@merit.edu Tue Jan 29 10:28: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 KAA06045 for ; Tue, 29 Jan 2002 10:28:25 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3B27D9126B; Tue, 29 Jan 2002 10:28:06 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 06E659126C; Tue, 29 Jan 2002 10:28: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 B40569126B for ; Tue, 29 Jan 2002 10:28:04 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8A5E75DDB5; Tue, 29 Jan 2002 10:28:04 -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 432B55DD93 for ; Tue, 29 Jan 2002 10:28:04 -0500 (EST) Received: by EXCHSRV.stormventures.com with Internet Mail Service (5.5.2653.19) id ; Tue, 29 Jan 2002 07:28:03 -0800 Message-ID: From: "Pat R. Calhoun" To: "'aaa-wg@merit.edu'" Subject: [AAA-WG]: Diameter draft editorship Date: Tue, 29 Jan 2002 07:28:03 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1A8D9.8AED4660" 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_01C1A8D9.8AED4660 Content-Type: text/plain -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 All, I'd like to retract my statement from yesterday regarding editorship. It appears that in my haste to get my action items completed, I forgot a few steps, such as letting the WG chairs and IESG make a decision on new WG draft editors [based on my recommendation]. It was inappropriate for me to send such an e-mail to the list, and ask that the WG mailing list members ignore my previous e-mail... Thanks and my apologies, PatC -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 7.0.3 for non-commercial use iQA/AwUBPFa/gzN1fXKoxmisEQIOMQCgs/f/kEapMvAKvC3+AeNGpw9vosoAn0YY bdrgkp0lU5w5FIqEbgS2754t =SCQR -----END PGP SIGNATURE----- ------_=_NextPart_001_01C1A8D9.8AED4660 Content-Type: text/html Content-Transfer-Encoding: quoted-printable Diameter draft editorship

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

All,

I'd like to retract my statement from yesterday = regarding editorship.
It appears that in my haste to get my action items = completed, I
forgot a few steps, such as letting the WG chairs = and IESG make a
decision on new WG draft editors [based on my = recommendation].

It was inappropriate for me to send such an e-mail to = the list, and
ask that the WG mailing list members ignore my = previous e-mail...

Thanks and my apologies,

PatC

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

iQA/AwUBPFa/gzN1fXKoxmisEQIOMQCgs/f/kEapMvAKvC3+AeNGpw9vosoAn0Y= Y
bdrgkp0lU5w5FIqEbgS2754t
=3DSCQR
-----END PGP SIGNATURE-----

------_=_NextPart_001_01C1A8D9.8AED4660-- From owner-aaa-wg@merit.edu Tue Jan 29 10:29: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 KAA06110 for ; Tue, 29 Jan 2002 10:29:49 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 087EB9126C; Tue, 29 Jan 2002 10:29:34 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CA7069126D; Tue, 29 Jan 2002 10:29: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 898379126C for ; Tue, 29 Jan 2002 10:29:32 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6FD8B5DDB6; Tue, 29 Jan 2002 10:29: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 280805DD93 for ; Tue, 29 Jan 2002 10:29:32 -0500 (EST) Received: by EXCHSRV.stormventures.com with Internet Mail Service (5.5.2653.19) id ; Tue, 29 Jan 2002 07:29:31 -0800 Message-ID: From: "Pat R. Calhoun" To: "'aaa-wg@merit.edu'" Subject: [AAA-WG]: Diameter draft editorship (this time right format) Date: Tue, 29 Jan 2002 07:29:31 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1A8D9.BF746350" 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_01C1A8D9.BF746350 Content-Type: text/plain -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 [darned mail tools] All, I'd like to retract my statement from yesterday regarding editorship. It appears that in my haste to get my action items completed, I forgot a few steps, such as letting the WG chairs and IESG make a decision on new WG draft editors [based on my recommendation]. It was inappropriate for me to send such an e-mail to the list, and ask that the WG mailing list members ignore my previous e-mail... Thanks and my apologies, PatC -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 7.0.3 for non-commercial use iQA/AwUBPFa/2zN1fXKoxmisEQJ7UgCfarHt2a38L4eeT/yTRZ1eyYMH2vUAoJ+H U1WvvD8mKbmoMZulN0GkewmN =QLgp -----END PGP SIGNATURE----- ------_=_NextPart_001_01C1A8D9.BF746350 Content-Type: text/html Content-Transfer-Encoding: quoted-printable Diameter draft editorship (this time right format)

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

[darned mail tools]

All,

I'd like to retract my statement from yesterday = regarding editorship.
It appears that in my haste to get my action items = completed, I
forgot a few steps, such as letting the WG chairs = and IESG make a
decision on new WG draft editors [based on my = recommendation].

It was inappropriate for me to send such an e-mail to = the list, and
ask that the WG mailing list members ignore my = previous e-mail...

Thanks and my apologies,

PatC

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

iQA/AwUBPFa/2zN1fXKoxmisEQJ7UgCfarHt2a38L4eeT/yTRZ1eyYMH2vUAoJ+= H
U1WvvD8mKbmoMZulN0GkewmN
=3DQLgp
-----END PGP SIGNATURE-----

------_=_NextPart_001_01C1A8D9.BF746350-- From owner-aaa-wg@merit.edu Tue Jan 29 10:33: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 KAA06216 for ; Tue, 29 Jan 2002 10:33:04 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 8E5739120A; Tue, 29 Jan 2002 10:32:49 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 605D591254; Tue, 29 Jan 2002 10:32: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 2F6D09120A for ; Tue, 29 Jan 2002 10:32:48 -0500 (EST) Received: by segue.merit.edu (Postfix) id 162185DD9D; Tue, 29 Jan 2002 10:32:48 -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 47C495DD93 for ; Tue, 29 Jan 2002 10:32:47 -0500 (EST) Received: from knox6039.cisco.com (knox6039.cisco.com [161.44.216.39]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id KAA28315; Tue, 29 Jan 2002 10:32:43 -0500 (EST) Received: (from meklund@localhost) by knox6039.cisco.com (8.9.3+Sun/8.9.3) id KAA04818; Tue, 29 Jan 2002 10:32:42 -0500 (EST) From: Mark Eklund MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15446.49306.254888.693578@gargle.gargle.HOWL> Date: Tue, 29 Jan 2002 10:32:42 -0500 To: Erik Guttman Cc: Mark Eklund , Jari Arkko , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 261 In-Reply-To: References: <15446.47414.976013.216335@gargle.gargle.HOWL> X-Mailer: VM 6.93 under Emacs 21.1.1 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Erik, I know when I'm beat :) Erik Guttman writes: > On Tue, 29 Jan 2002, Mark Eklund wrote: > > > Jari, > > > > Jari Arkko writes: > > > > How about option 1.9 (almost option 2)? Add an initial sentence to > > > > 5.2: > > > > > > Works for me. You also need to add language also to require that whatever > > > is being done implementation-wise, folks need to publish the information > > > in svrloc/dns in order for the automatic schemes to work, if some node > > > uses them. > > > > Are you saying that we need to add a statement of "If the client uses > > DNS to discover the server, the server must be registered in DNS?" > > Do we really need to state something that obvious? > > I think we should say: > Diameter clients MUST be manually configurable. > Diameter servers SHOULD advertise themselves via SLP [RFC2608][RFC2614] > Diameter servers SHOULD be represented by DNS SRV RR entries in DNS. > [RFC2782] > Diameter clients MAY use SLP or DNS SRV RRs to obtain the location > of Diameter servers. If everyone is in agreement with the above, I'll work on the changes and send out the diffs. -mark > > The specifics of how to use DNS or SLP to make service locations > available to clients can be left out of the Diameter spec, as it > is covered in the cited specifications. > > Erik > From owner-aaa-wg@merit.edu Tue Jan 29 11:12: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 LAA07766 for ; Tue, 29 Jan 2002 11:12:31 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A349791256; Tue, 29 Jan 2002 11:12:20 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 772F59126D; Tue, 29 Jan 2002 11:12: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 7529A91256 for ; Tue, 29 Jan 2002 11:12:19 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5998E5DDBA; Tue, 29 Jan 2002 11:12:19 -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 B54BC5DDB9 for ; Tue, 29 Jan 2002 11:12:18 -0500 (EST) Received: (qmail 17894 invoked by uid 507); 29 Jan 2002 16:12:17 -0000 Date: Tue, 29 Jan 2002 10:12:15 -0600 From: David Frascone To: aaa-wg@merit.edu Subject: [AAA-WG]: Supporting TLS? Message-ID: <20020129161215.GK13093@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 X-Virus-Scanned: by AMaViS perl-11 Sender: owner-aaa-wg@merit.edu Precedence: bulk I'm putting together the test specification for Connectathon 2002, and I've got a couple of questions about implementing TLS (I apologize in advance for the ignorance of these questions): o It looks like OpenSSL and similar crypographic libraries that implement TLS always implement SSL on top of it. Am I correct in assuming that SSLv3 == TLSv1? So, setting up a SSL connection via OpenSSL or cryptlib would be an acceptable test/implementation of Diameter over TLS? o If the above is *not* true, is there an EASY way to implement TLS for testing, without implementing the entire TLS RFC. I don't think any vendor will be able to do that before the Connectathon. o No centralized certificate signing authority has been defined for Diameter. I'm assuming that if you have prior knowledge of a peer you're connecting to, you would have it's self signed certificate for identification. And, if you have no prior knowledge of the peer, then you would be susceptable to man-in-the-middle attacks, since you would have no way to authenticate the peer. Are these assumptions correct? Thanks in advance, Dave P.S. At least ipsec is easy :) From owner-aaa-wg@merit.edu Tue Jan 29 11:19: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 LAA08067 for ; Tue, 29 Jan 2002 11:19:55 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id BDD5B9126E; Tue, 29 Jan 2002 11:17:32 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B87899126F; Tue, 29 Jan 2002 11:17: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 B2BEC9126E for ; Tue, 29 Jan 2002 11:17:19 -0500 (EST) Received: by segue.merit.edu (Postfix) id 890285DDBB; Tue, 29 Jan 2002 11:17:19 -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 63BA25DDB9 for ; Tue, 29 Jan 2002 11:17:19 -0500 (EST) Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16Vasx-0004lI-00; Tue, 29 Jan 2002 08:13:27 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Steve Rich Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 261 References: <200201281925.OAA03251@knox6039.cisco.com> <008601c1a834$a36bc7c0$8a1b6e0a@arenanet.fi> <15445.44296.686550.914346@gargle.gargle.HOWL> <012f01c1a884$3acac040$8a1b6e0a@arenanet.fi> <15446.14469.595405.770187@gargle.gargle.HOWL> <000f01c1a895$249ac200$8a1b6e0a@arenanet.fi> <15446.47414.976013.216335@gargle.gargle.HOWL> <15446.48504.748254.722033@knox6046.cisco.com> Message-Id: Date: Tue, 29 Jan 2002 08:13:27 -0800 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit >> Are you saying that we need to add a statement of "If the client uses >> DNS to discover the server, the server must be registered in DNS?" >> Do we really need to state something that obvious? > I think it's a good idea to add it. Often times, a little direction > can go a long way, especially if the implementor isn't an expert in > this area (DNS, etc.). then we should tell them to be sure it's an A or AAAA resource record, recommend TTLs, ...? :-) seems to me that it is best to incorporate by reference, not explicit copy. randy From owner-aaa-wg@merit.edu Tue Jan 29 11:26: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 LAA08281 for ; Tue, 29 Jan 2002 11:26:34 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A630691272; Tue, 29 Jan 2002 11:25:36 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6BD6191275; Tue, 29 Jan 2002 11:25: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 ED7B891272 for ; Tue, 29 Jan 2002 11:25:32 -0500 (EST) Received: by segue.merit.edu (Postfix) id CEBBC5DDBE; Tue, 29 Jan 2002 11:25: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 0B86D5DDC0 for ; Tue, 29 Jan 2002 11:25:32 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id IAA20436; Tue, 29 Jan 2002 08:08:58 -0800 (PST) (envelope-from aboba@internaut.com) Date: Tue, 29 Jan 2002 08:08:58 -0800 (PST) From: Bernard Aboba To: David Frascone Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Supporting TLS? In-Reply-To: <20020129161215.GK13093@newman.frascone.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > o It looks like OpenSSL and similar crypographic libraries that > implement TLS always implement SSL on top of it. Am I correct > in assuming that SSLv3 == TLSv1? So, setting up a SSL connection > via OpenSSL or cryptlib would be an acceptable test/implementation > of Diameter over TLS? No, there are some changes between SSLv3 and TLS. I'd suggest testing both SSLv3 and TLS. > o If the above is *not* true, is there an EASY way to implement > TLS for testing, without implementing the entire TLS RFC. I don't > think any vendor will be able to do that before the Connectathon. As with any RFC, there are MUSTs, SHOULDs and MAYs. So there are levels of compliance. > o No centralized certificate signing authority has been defined for > Diameter. I'm assuming that if you have prior knowledge of a peer > you're connecting to, you would have it's self signed certificate > for identification. And, if you have no prior knowledge of the > peer, then you would be susceptable to man-in-the-middle attacks, > since you would have no way to authenticate the peer. > Are these assumptions correct? A Diameter peer can have a set of root CAs that it trusts. This is one of the areas where the spec is currently not very informative. Self-signed certs can be made secure on all but the first exchange -- so you have to assume that there is no man-in-the-middle operating during that first exchange, so the self-signed cert can be retrieved (and presumably, cached). A self-signed cert tells you "you've conected to the same entity that you spoke with the first time you obtained this cert". It doesn't tell you who that entity is -- typically this requires faith in DNS, IP addresses or other spoofable mechanisms. So using self-signed certs might be a decent way to test things at Connectathon, but we should discuss the circumstances under which this would provide acceptable security. >At least IPsec is easy You'll have the same issues come up if you support certificates with IPsec. I gather you were using pre-shared keys :) From owner-aaa-wg@merit.edu Tue Jan 29 11: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 LAA08606 for ; Tue, 29 Jan 2002 11:37:46 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 6AD7091270; Tue, 29 Jan 2002 11:37:23 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3C93091271; Tue, 29 Jan 2002 11:37: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 324DD91270 for ; Tue, 29 Jan 2002 11:37:22 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1821A5DD8D; Tue, 29 Jan 2002 11:37:22 -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 B92F85DD8C for ; Tue, 29 Jan 2002 11:37:21 -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 g0TGV6111535; Tue, 29 Jan 2002 11:31:06 -0500 Message-ID: <3C56CE49.50AB715B@interlinknetworks.com> Date: Tue, 29 Jan 2002 11:31:05 -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: David Frascone , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Supporting TLS? References: <20020129161215.GK13093@newman.frascone.com> 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 LAA08606 Dave, TLS is an IETF standard protocol based on SSLv3. It is not exactly the same as SSLv3. Toolkits such as OpenSSL can be used to set up either SSL or TLS connections. Certificates used by TLS should be signed by a certificate authority (CA). You can use a utility such as openssl to create CA certificates for an enterprise or you can obtain CA certificates from an existing Certificate Authority. Don David Frascone wrote: > I'm putting together the test specification for Connectathon 2002, and I've > got a couple of questions about implementing TLS (I apologize in advance > for the ignorance of these questions): > > o It looks like OpenSSL and similar crypographic libraries that > implement TLS always implement SSL on top of it. Am I correct > in assuming that SSLv3 == TLSv1? So, setting up a SSL connection > via OpenSSL or cryptlib would be an acceptable test/implementation > of Diameter over TLS? > > o If the above is *not* true, is there an EASY way to implement > TLS for testing, without implementing the entire TLS RFC. I don't > think any vendor will be able to do that before the Connectathon. > > o No centralized certificate signing authority has been defined for > Diameter. I'm assuming that if you have prior knowledge of a peer > you're connecting to, you would have it's self signed certificate > for identification. And, if you have no prior knowledge of the > peer, then you would be susceptable to man-in-the-middle attacks, > since you would have no way to authenticate the peer. > Are these assumptions correct? > > Thanks in advance, > > Dave > > P.S. At least ipsec is easy :) From owner-aaa-wg@merit.edu Tue Jan 29 11:40: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 LAA08774 for ; Tue, 29 Jan 2002 11:40:59 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E3EC591277; Tue, 29 Jan 2002 11:39:51 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A5A0291278; Tue, 29 Jan 2002 11:39: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 72FAD91277 for ; Tue, 29 Jan 2002 11:39:46 -0500 (EST) Received: by segue.merit.edu (Postfix) id 57DAB5DD8D; Tue, 29 Jan 2002 11:39:46 -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 9CD3D5DD8C for ; Tue, 29 Jan 2002 11:39:45 -0500 (EST) Received: (qmail 18211 invoked by uid 507); 29 Jan 2002 16:39:45 -0000 Date: Tue, 29 Jan 2002 10:39:43 -0600 From: David Frascone To: Bernard Aboba Cc: David Frascone , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Supporting TLS? Message-ID: <20020129163943.GL13093@newman.frascone.com> Mail-Followup-To: Bernard Aboba , David Frascone , aaa-wg@merit.edu References: <20020129161215.GK13093@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 X-Virus-Scanned: by AMaViS perl-11 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Tuesday, 29 Jan 2002, Bernard Aboba wrote: > > o It looks like OpenSSL and similar crypographic libraries that > > implement TLS always implement SSL on top of it. Am I correct > > in assuming that SSLv3 == TLSv1? So, setting up a SSL connection > > via OpenSSL or cryptlib would be an acceptable test/implementation > > of Diameter over TLS? > > No, there are some changes between SSLv3 and TLS. I'd suggest testing both > SSLv3 and TLS. Ok. I'll read sparse OpenSSL documents more closely. > >At least IPsec is easy > > You'll have the same issues come up if you support certificates with > IPsec. I gather you were using pre-shared keys :) True, the architectural problems are still there, but at least the diameter implementation itself does not need to be modified. Which means, vendors attending Connectathon might be able to implement it in time. -Dave From owner-aaa-wg@merit.edu Tue Jan 29 11:50: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 LAA09026 for ; Tue, 29 Jan 2002 11:50:37 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2EAB591273; Tue, 29 Jan 2002 11:50:21 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EE8CB91274; Tue, 29 Jan 2002 11:50: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 EA85C91273 for ; Tue, 29 Jan 2002 11:50:19 -0500 (EST) Received: by segue.merit.edu (Postfix) id CF8375DD92; Tue, 29 Jan 2002 11:50:19 -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 89EA45DD8C for ; Tue, 29 Jan 2002 11:50:19 -0500 (EST) Received: (qmail 18418 invoked by uid 507); 29 Jan 2002 16:50:19 -0000 Date: Tue, 29 Jan 2002 10:50:17 -0600 From: David Frascone To: aaa-wg@merit.edu Subject: [AAA-WG]: Major Connectathon Test Items Message-ID: <20020129165017.GP13093@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 X-Virus-Scanned: by AMaViS perl-11 Sender: owner-aaa-wg@merit.edu Precedence: bulk So far, the Connectathon test plan will focus on the following items, in order of priority: o NASREQ o CMS-Sec o TLS o IPSEC o Diameter-Radius gateway functionality Mobile-Ip, Sun Ping, Nasreq, and accounting messages can be sent to test the transport/security items. Anything else? From owner-aaa-wg@merit.edu Tue Jan 29 12:04: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 MAA09426 for ; Tue, 29 Jan 2002 12:04:18 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 6F68391280; Tue, 29 Jan 2002 12:01:49 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2EC9D912AE; Tue, 29 Jan 2002 12:01: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 F009591280 for ; Tue, 29 Jan 2002 12:01:38 -0500 (EST) Received: by segue.merit.edu (Postfix) id C248C5DD90; Tue, 29 Jan 2002 12:01:38 -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 F22BE5DD8C for ; Tue, 29 Jan 2002 12:01:37 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id IAA20504; Tue, 29 Jan 2002 08:45:04 -0800 (PST) (envelope-from aboba@internaut.com) Date: Tue, 29 Jan 2002 08:45:04 -0800 (PST) From: Bernard Aboba To: David Frascone Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Major Connectathon Test Items In-Reply-To: <20020129165017.GP13093@newman.frascone.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Sounds like a good list to me. Diameter-RADIUS gateway functionality is part of NASREQ, no? I'd also be interested in testing of the discovery functionality (DNS SRV, SLPv2, etc.) if anyone has implemented it. On Tue, 29 Jan 2002, David Frascone wrote: > > So far, the Connectathon test plan will focus on the following items, in > order of priority: > > o NASREQ > o CMS-Sec > o TLS > o IPSEC > o Diameter-Radius gateway functionality > > Mobile-Ip, Sun Ping, Nasreq, and accounting messages can be sent to test > the transport/security items. > > > Anything else? > From owner-aaa-wg@merit.edu Tue Jan 29 12: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 MAA09736 for ; Tue, 29 Jan 2002 12:12:24 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 07DD691274; Tue, 29 Jan 2002 12:12:14 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CDCF091275; Tue, 29 Jan 2002 12:12: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 D5F4491274 for ; Tue, 29 Jan 2002 12:12:12 -0500 (EST) Received: by segue.merit.edu (Postfix) id BE6EC5DD93; Tue, 29 Jan 2002 12:12:12 -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 EF4D05DD8C for ; Tue, 29 Jan 2002 12:12:11 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id IAA20527; Tue, 29 Jan 2002 08:51:51 -0800 (PST) (envelope-from aboba@internaut.com) Date: Tue, 29 Jan 2002 08:51:51 -0800 (PST) From: Bernard Aboba To: Jari Arkko Cc: Mark Eklund , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 261 In-Reply-To: <004701c1a8d9$3d6fef00$8a1b6e0a@arenanet.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk There are two distinct issues here. One is what Diameter Servers need to do to register. The other is the discovery sequence for Diameter clients. We have been modelling the Diameter client discovery sequence after the SIP location draft, draft-ietf-sip-srv-0x.txt, since this is already undergoing IESG review. The presumption has been that there will not be any single mandatory registration mechanism for servers, which is part of the reason that the client discovery sequence is so important. From owner-aaa-wg@merit.edu Tue Jan 29 12:28: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 MAA10335 for ; Tue, 29 Jan 2002 12:28:22 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2C5DA91275; Tue, 29 Jan 2002 12:28:13 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F059791278; Tue, 29 Jan 2002 12:28: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 A953091275 for ; Tue, 29 Jan 2002 12:28:11 -0500 (EST) Received: by segue.merit.edu (Postfix) id 914405DDB2; Tue, 29 Jan 2002 12:28:11 -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 63F1F5DDAD for ; Tue, 29 Jan 2002 12:28:11 -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 g0THRnS23442 for ; Tue, 29 Jan 2002 11:27:49 -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 g0THRn020567 for ; Tue, 29 Jan 2002 11:27: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 LAA04156 for ; Tue, 29 Jan 2002 11:27:48 -0600 (CST) Received: from ericsson.com (busam55.berkeley.us.am.ericsson.se [138.85.159.205]) by qpop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id LAA07708 for ; Tue, 29 Jan 2002 11:27:47 -0600 (CST) Message-ID: <3C56DB1B.B41759FB@ericsson.com> Date: Tue, 29 Jan 2002 09:25:48 -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 Subject: [Fwd: Re: [AAA-WG]: [issue] Returning AAAF-Generated FA-HA Key to FA] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit I seems to have some problems with my mail-box, sorry if you receive this twice. /Tony -------- Original Message -------- Subject: Re: [AAA-WG]: [issue] Returning AAAF-Generated FA-HA Key to FA Date: Mon, 28 Jan 2002 15:46:29 -0800 From: Tony Johansson To: Bob Kopacz CC: aaa-wg@merit.edu References: Hello Bob and All, I agree that it could be good to have a way of encrypting the FA-HA Key as you describe below, and even more for the case where you move through a third domain ( i.e. the AAAF1 and AAAF2 belongs to two different networks). However, I really think that we need to find a more interoperability approve approach. I'm not sure that we just can say that the HAA-toAMA-Data AVP is of type OctetString and may be used, to convey the FA-HA key information in some proprietary format and security method which is agreed-upon by all AAAF servers in the foreign network... You mention CMS security below and I agree, couldn't we make use of the CMS security for this case? So, what about the following (I'm not a CMS security expert, so please correct me if this is not really possible or to complex...): Instead, make the HAA-toAMA-Data AVP of type grouped : HAA-toAMA-Data AVP ::= < AVP Header: TBD > { Originating-Foriegn-Home-Key-Distr-Host } { CMS-Encrypted-Data } * [ AVP ] The CMS-Encrypted-Data AVP would contain the FA-HA Key encrypted and the Originating-Foriegn-Home-Key-Distr-Host AVP (lack of better name:) would contain the Host NAI of the AAAF2, see Figure below The message flow would then be the following: (Please view in a fixed-width font such as Courier.) 1.amr-> 1.amr-> FA --------> AAAF1 1------------> AAAH <-6.ama | ^ <-4.ama | | | | ^ | | | | 5.dsar | |5.dsaa 2.har |3.haa | | | | | | V | | | | <-2.har v | <-2.har | HA <-------- AAAF2 <---------------/ 3.haa-> 3.haa-> Thus, the AAAF2 would create the HAA-to-AMA AVP with its Host name and the FA-HA Key encrypted using its digital certificate. Upon receiving the HAA the AAAH would add the HAA-to-AMA AVP into the AMA. Upon receipt of the AMA the AAAF1 would identify the Originating-Foriegn-Home-Key-Distr-Host AVP in the HAA-to-AMA AVP and issue a DSAR to the AAAF2 and request for the digital certificate, which the AAAF1 then would use to decrypt the FA-HA Key.... Could this be a way forward ? Comments please... Tony Bob Kopacz wrote: > Issue : Returning AAAF-Generated FA-HA Key to FA > Submitter name: Bob Kopacz > Submitter email address: BKopacz@InterlinkNetworks.com > Date first submitted: 01-15-2002 > Reference: > Document: mobileip > Comment type: Technical > Priority: 1 > Section: 2.2, 2.4, 5.4, 8.1, Issue#203 > Rationale/Explanation of issue: > > [The following is based on some issue#203-related emails > exchanged with Mark Eklund. The proposal I'm contributing here > is also Mark's, as I understand it] > > When the HA is in the foreign network and a FA-HA key is > requested, the AAAF, rather than the AAAH, generates the key. > > Here's the diagram of the issue: > > amr-> amr-> > FA --------> AAAF1 -------------> AAAH > <-ama <-ama | > | ^ > | | > har | haa > | | > V | > | > <-har <-har | > HA <-------- AAAF2 <---------------/ > haa-> haa-> > > In the above diagram, FA & HA & AAAF1 & AAAF2 are all in the same > visited network. AAAF1 and AAAF2 may be the same server, or may > be different servers. > > In the above diagram, AAAF2 generates the FA-HA key. > > The problem is that this key must somehow be returned to the FA > via AAAF1. The proposal here is to pass the key back to the FA > via the the HAA and AMA messages. AAAF2 may be concerned about > security, so may want the FA-HA key to be passed encrypted so > that AAAH and intervening servers can't figure it out, but AAAF1 > can somehow decrypt it. > > The details are: > > 1. A new HAA-to-AMA-Data AVP, of type octetstring, is created. > The purpose of this AVP is convey information from the HA's AAAF > (AAAF2) to the FA's AAAF (AAAF1). All AAAFs in that foreign > realm MUST have an agreed upon format and security method for > this AVP to be used. (It may be possible to use CMS security > to somehow encrypt this AVP, but it is unclear just how, as it > involves the AAAH copying a secure AVP from the HAA to the AMA, > and the AMA may carry both AAAH-FA and AAAF1-AAAF2 secured > AVPs) > > 2. When the FA-HA key is generated by AAAF2, this key must > somehow be conveyed to AAAF1. There are two ways to do this: > a. Use the MIP-HAA-to-AMA-Data AVP, or > b Have a common database among AAAFs in the foreign network, > wherein AAAF2 may deposit the FA-HA key, which is later retrieved > by AAAF1, in a proprietary manner not described in the Diameter > documents. > > 3. If the HAA-to-AMA-Data AVP is present in the HAA, the AAAH > treats it as opaque data and passes it in the AMA. > > 4, If AAAF1 receives the HAA-to-AMA-Data AVP in the AMA, AAAF1 > will use this AVP to recreate the FA-HA key, and replace this AVP > by a MIP-FA-to-HA-Key AVP in the AMA sent to the FA. > > Requested change: > > This issues supercedes issue#203, which also addresses the > problem of returning an AAAF-Generated FA-HA Key to the FA, but > didn't quite work in the case where there was a 2nd AAAF > involved. > > In section 2.2. Add [HAA-to-AMA-Data] to the AMA ABNF. > > In section 2.4. Add [HAA-to-AMA-Data] to the HAA ABNF. > > In section 6, define the following new AVP: > > 6.x HAA-to-AMA-Data AVP > > The HAA-to-AMA-Data AVP (AVP Code TBD) is of type OctetString and > may be used, when the HA is allocated in the foreign network and > the HA's AAAF generates the FA-HA key, to convey the FA-HA key > information (in some proprietary format and security method which > is agreed-upon by all AAAF servers in the foreign network) back > to the FA's AAAF. > > In section 8.1. Add a row for the new HAA-to-AMA-Data AVP, with these > occurrence rules: AMR 0, AMA 0-1, HAR 0, HAA 0-1. > > Replace section 5.4 by > > If the home agent is in the home realm, then AAAH has to generate > the Foreign-Home session key. Otherwise, it is generated by the > AAAF receiving the HAR. > > If the AAAH generates the Foreign-Home session key, then the AAAH > includes the session key in the MIP-HA-to-FA-Key AVP, and > includes the AVP as part of the HAR message sent to the home > agent. The corresponding session key that is to be sent to the > foreign agent is cached on the AAAH until the HAA is received, at > which time the AAAH adds the MIP-FA-to-HA Key AVP to the AMA, > using the SPI in the MIP-FA-to-HA-SPI. > > Upon receipt of the HAR, the home agent recovers the Foreign-Home > session key, allocates an SPI to be used with the key. The > allocated SPI is included in the HAA's MIP-FA-to-HA SPI AVP. > > If the AAAH doesn't generate the Foreign-Home session key, then > upon receipt of the HAA, the AAAH extracts and passes the > MIP-FA-to-HA-SPI AVP (if present in the HAR) in the AMA, and > extracts and passes the HAA-to-AMA-Data AVP (if present in the > HAR) in the AMA. > > If the AAAF receives an AMA which contains a HAA-to-AMA-Data AVP, > the AAAF will recreate the FA-HA key, generate a MIP-FA-to-HA-Key > AVP, and pass the MIP-FA-to-HA-Key AVP to the FA. > > Alternatively, if the AAAF generates the Foreign-Home session > key, the AAAFs in the foreign network may have a common database > among AAAFs, wherein the HA's AAAF may deposit the FA-HA key, > which is later retrieved by the FA's AAAF, in a proprietary > manner not described in the Diameter documents. From owner-aaa-wg@merit.edu Tue Jan 29 14:42: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 OAA18888 for ; Tue, 29 Jan 2002 14:42:53 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3889B91208; Tue, 29 Jan 2002 14:42:41 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0E98691213; Tue, 29 Jan 2002 14:42: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 E429191208 for ; Tue, 29 Jan 2002 14:42:39 -0500 (EST) Received: by segue.merit.edu (Postfix) id BF1A35DDCF; Tue, 29 Jan 2002 14:42:39 -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 007075DD8C for ; Tue, 29 Jan 2002 14:42:38 -0500 (EST) Received: from knox6039.cisco.com (knox6039.cisco.com [161.44.216.39]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id OAA18576; Tue, 29 Jan 2002 14:42:33 -0500 (EST) Received: (from meklund@localhost) by knox6039.cisco.com (8.9.3+Sun/8.9.3) id OAA05013; Tue, 29 Jan 2002 14:42:32 -0500 (EST) Date: Tue, 29 Jan 2002 14:42:32 -0500 (EST) Message-Id: <200201291942.OAA05013@knox6039.cisco.com> From: Mark Eklund To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue #250, Sub Issue, Unreferenced references Sender: owner-aaa-wg@merit.edu Precedence: bulk When Jari did the work of determining Normative vs Informative, he couldn't find the following references referenced in the body of the base draft. Do we leave them in, or drop them from the base? My vote, drop 4, 5, 6, 14, and 19 from the base (keep in CMS if it makes sense). I have no opinion on 39, and 48. No mention of MD5 in this draft: [4] Rivest, "The MD5 Message-Digest Algorithm", RFC 1321, April 1992. No mention in this draft: [5] Kaufman, Perlman, Speciner, "Network Security: Private Communica- tions in a Public World", Prentice Hall, March 1995, ISBN 0-13-061466-1. A part of the obsolete Integrity-Check-Value AVP [6] Krawczyk, Bellare, Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, January 1997. Older drafts mentioned DIAMETER Message Security requiring a Public Key Infrastructure. [14] Myers, Ankney, Malpani, Galperin, Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol (OCSP)", RFC 2560, June 1999. No mention in this draft. [19] Housley, Ford, Polk, Solo, "Internet X.509 Public Key Infrastruc- ture Certificate and CRL Profile", RFC 2459, January 1999. No mention in the draft. [39] "The Communications of the ACM" Vol.33, No.6 (June 1990), pp. 677-680. No mention in the draft. [48] P. V. Mockapetris, "Domain names - implementation and specifica- tion," RFC 1035, November 1987. -mark From owner-aaa-wg@merit.edu Tue Jan 29 15:31: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 PAA20049 for ; Tue, 29 Jan 2002 15:31:38 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 89E739120D; Tue, 29 Jan 2002 15:31:28 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4829F9127F; Tue, 29 Jan 2002 15:31: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 6681C9120D for ; Tue, 29 Jan 2002 15:31:26 -0500 (EST) Received: by segue.merit.edu (Postfix) id 312AA5DDCC; Tue, 29 Jan 2002 15:31:26 -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 BE2845DD8C for ; Tue, 29 Jan 2002 15:31:25 -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 g0TKVJh00259; Tue, 29 Jan 2002 14:31:19 -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 g0TKVI404965; Tue, 29 Jan 2002 14:31: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 OAA23207; Tue, 29 Jan 2002 14:31:18 -0600 (CST) Received: from ericsson.com ([138.85.159.104]) by qpop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id OAA12287; Tue, 29 Jan 2002 14:31:17 -0600 (CST) Message-ID: <3C57061C.8C40391D@ericsson.com> Date: Tue, 29 Jan 2002 12:29:17 -0800 From: Tony Johansson X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Mark Eklund Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue #250, Sub Issue, Unreferenced references References: <200201291942.OAA05013@knox6039.cisco.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 I agree, I don't see any point in having references listed, which are not referenced in the spec. Furthermore, I went through the same exercise with the Mobile IP spec and found the following: 13.0 References Informative =========== [3] S. Glass, S. Jacobs, C. Perkins, "Mobile IP Authentication, Autho­ rization, and Accounting Requirements". RFC 2977. October 2000. [6] B. Aboba, M. Beadles "The Network Access Identifier." RFC 2486. January 1999. [7] B. Aboba, G. Zorn, "Criteria for Evaluating Roaming Protocols", RFC 2477, January 1999. [8] P. Calhoun, C. Perkins, "Mobile IP Network Address Identifier Extension", RFC 2794, March 2000. [11] S. Bradner, "Key words for use in RFCs to Indicate Requirement Lev­ els", BCP 14, RFC 2119, March 1997. [13] H. Krawczyk, M. Bellare, and R. Cannetti. HMAC: Keyed-Hashing for Message Authentication. RFC 2104, February 1997. [16] T. Hiller and al, "CDMA2000 Wireless Data Requirements for AAA", RFC 3141, June 2001. [17] National Institute of Standards and Technology, "Secure Hash Stan­ dard", Technical Report NIST FIPS PUB 180-1, U.S. Department of Commerce, April 1995. [18] D. Eastlake, 3rd, S. Crocker, and J. Schiller. Randomness Recom­ mendations for Security. Request for Comments (Informational) 1750, Internet Engineering Task Force, December 1994. Normative ========= [1] 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. [2] Narten, Alvestrand,"Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998 [4] C. Perkins, Editor. IP Mobility Support. RFC 2002, October 1996. [5] C. Perkins, P. Calhoun, "Mobile IP Challenge/Response Extensions". RFC 3012. November 2000. [9] P. Calhoun, W. Bulley, S. Farrell, "Diameter CMS Security Applica­ tion", draft-ietf-aaa-diameter-cms-sec-03.txt, IETF work in progress, November 2001. [15] C. Perkins, P. Calhoun, "AAA Registration Keys for Mobile IP", draft-ietf-mobileip-aaa-key-08.txt, IETF work in progress, July 2001. Seem unnecessary (quick search didn't reveal references): ========================================================= [10] Kent, Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998. [12] F. Yergeau, "UTF-8, a transformation format of ISO 10646", RFC2279, January 1998. [14] P. Calhoun, W. Bulley, A. Rubens, J. Haag, "Diameter NASREQ Application", draft-ietf-aaa-diameter-nasreq-08.txt, IETF work in progress, November 2001. /Tony Mark Eklund wrote: > When Jari did the work of determining Normative vs Informative, he > couldn't find the following references referenced in the body of the > base draft. Do we leave them in, or drop them from the base? > > My vote, drop 4, 5, 6, 14, and 19 from the base (keep in CMS if it > makes sense). I have no opinion on 39, and 48. > > No mention of MD5 in this draft: > [4] Rivest, "The MD5 Message-Digest Algorithm", RFC 1321, April 1992. > > No mention in this draft: > [5] Kaufman, Perlman, Speciner, "Network Security: Private Communica- > tions in a Public World", Prentice Hall, March 1995, ISBN > 0-13-061466-1. > > A part of the obsolete Integrity-Check-Value AVP > [6] Krawczyk, Bellare, Canetti, "HMAC: Keyed-Hashing for Message > Authentication", RFC 2104, January 1997. > > Older drafts mentioned DIAMETER Message Security requiring a Public Key > Infrastructure. > [14] Myers, Ankney, Malpani, Galperin, Adams, "X.509 Internet Public Key > Infrastructure Online Certificate Status Protocol (OCSP)", RFC > 2560, June 1999. > > No mention in this draft. > [19] Housley, Ford, Polk, Solo, "Internet X.509 Public Key Infrastruc- > ture Certificate and CRL Profile", RFC 2459, January 1999. > > No mention in the draft. > [39] "The Communications of the ACM" Vol.33, No.6 (June 1990), pp. > 677-680. > > No mention in the draft. > [48] P. V. Mockapetris, "Domain names - implementation and specifica- > tion," RFC 1035, November 1987. > > -mark From owner-aaa-wg@merit.edu Tue Jan 29 22:33: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 WAA29878 for ; Tue, 29 Jan 2002 22:33:06 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D940B9127E; Tue, 29 Jan 2002 22:32:50 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A506A9128A; Tue, 29 Jan 2002 22:32: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 A2F729127E for ; Tue, 29 Jan 2002 22:32:49 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7A4445DDD6; Tue, 29 Jan 2002 22:32:49 -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 B7A415DDC8 for ; Tue, 29 Jan 2002 22:32:48 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id TAA21308 for ; Tue, 29 Jan 2002 19:15:55 -0800 (PST) (envelope-from aboba@internaut.com) Date: Tue, 29 Jan 2002 19:15:55 -0800 (PST) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: Normative vs. Non-normative Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk More information about separation of normative vs. non-normative references (among a few other topics) can be found at: http://www.rfc-editor.org/policy.html Draft editors, please read this. From owner-aaa-wg@merit.edu Wed Jan 30 08:02: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 IAA16917 for ; Wed, 30 Jan 2002 08:02:56 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A5F3F912B5; Wed, 30 Jan 2002 08:02:38 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 75B94912B6; Wed, 30 Jan 2002 08:02: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 A07D6912B5 for ; Wed, 30 Jan 2002 08:02:30 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7E7A95DDE8; Wed, 30 Jan 2002 08:02:30 -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 302915DDE0 for ; Wed, 30 Jan 2002 08:02:30 -0500 (EST) Received: from phoenix (nat.interlinknetworks.com [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with SMTP id 884067B; Wed, 30 Jan 2002 08:02:29 -0500 (EST) From: "Bob Kopacz" To: "Tony Johansson" Cc: "Mark Eklund" , Subject: RE: [AAA-WG]: [issue] Returning AAAF-Generated FA-HA Key to FA Date: Wed, 30 Jan 2002 08:01:53 -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: <3C55E2D5.5C74F160@ericsson.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Tony, > From: Tony Johansson [tony.johansson@ericsson.com] > Sent: Monday, January 28, 2002 6:46 PM > To: Bob Kopacz > Cc: aaa-wg@merit.edu > Subject: Re: [AAA-WG]: [issue] Returning AAAF-Generated FA-HA Key to FA > > Hello Bob and All, > > I agree that it could be good to have a way of encrypting the FA-HA Key as > you describe below, and even more for the case where you move through a > third domain ( i.e. the AAAF1 and AAAF2 belongs to two different networks). > However, I really think that we need to find a more interoperability > approve approach. I'm not sure that we just can say that the HAA-toAMA-Data > AVP is of type OctetString and may be used, to convey the FA-HA key > information in some proprietary format and security method which is > agreed-upon by all AAAF servers in the foreign network... > > You mention CMS security below and I agree, couldn't we make use of the CMS > security for this case? Your idea to use CMS security is probably a better idea. A proprietary solution wouldn't work very well inter-realm. And using CMS is more in the spirit of the mobileip-draft, where its one comment in section 5.0 about securing keys is "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." > So, what about the following (I'm not a CMS security expert, so please > correct me if this is not really possible or to complex...): > > Instead, make the HAA-toAMA-Data AVP of type grouped : > > HAA-toAMA-Data AVP ::= < AVP Header: TBD > > { Originating-Foriegn-Home-Key-Distr-Host } > { CMS-Encrypted-Data } > * [ AVP ] > > The CMS-Encrypted-Data AVP would contain the FA-HA Key encrypted and the > Originating-Foriegn-Home-Key-Distr-Host AVP (lack of better name:) would > contain the Host NAI of the AAAF2, see Figure below > > The message flow would then be the following: > > (Please view in a fixed-width font such as Courier.) > > 1.amr-> 1.amr-> > FA --------> AAAF1 1------------> AAAH > <-6.ama | ^ <-4.ama | > | | | ^ > | | | | > 5.dsar | |5.dsaa 2.har |3.haa > | | | | > | | V | > | | | > <-2.har v | <-2.har | > HA <-------- AAAF2 <---------------/ > 3.haa-> 3.haa-> > > Thus, the AAAF2 would create the HAA-to-AMA AVP with its Host name and the > FA-HA Key encrypted using its digital certificate. Upon receiving the HAA > the AAAH would add the HAA-to-AMA AVP into the AMA. Upon receipt of the AMA > the AAAF1 would identify the Originating-Foriegn-Home-Key-Distr-Host AVP in > the HAA-to-AMA AVP and issue a DSAR to the AAAF2 and request for the > digital certificate, which the AAAF1 then would use to decrypt the FA-HA > Key.... > > Could this be a way forward ? Here's some thoughts, but bear in mind my limited understanding of CMS. (1) Maybe AAAF2 should initiate the security relationship with AAAF1, rather than the other way around. That is, AAAF2 sends the DSAR before responding with the HAA. My thinking here is, in the case where the AAAH wants to secure its generated keys with the FA, it is the sender of the CMS-secured data that initiates the DSAR. (2) The above scheme requires the CMS big gun. In the mobile-ip draft, the AAAH has the option of securing its generated keys via CMS, or sending them in the clear. So maybe CMS should be an option for the AAAF2-generated key. That is, AAAF2 could send the FA-HA-Key secured (per your proposal), or could instead just send a plain old MIP-FA-to-HA-Key AVP if the AAAF2 didn't feel the need to secure the key. (3) In the above HAA-to-AMA-Data AVP, the diameter identity of the AAAF2 is provided. If the AAAF1 wants to send a DSAR to AAAF2, it might also be necessary to include AAAF2's realm in the HAA-to-AMA-Data AVP, so that AAAF1 can fill in both the Destination-Realm and Destination-Host of the DSAR, for routing. (4) "Originating-Foriegn-Home-Key-Distr-Host" is one heck of name. With the thought of minimizing the creation of new AVPs, could we just use the "Origin-Host" and "Origin-Realm" AVPs as members of HAA-to-AMA-Data? The idea is, when "Origin-Host" and "Origin-Realm" are members of a grouped AVP, they represent the originator of that AVP. So AAAF2 could fill in his identity as the Origin-Host member of HAA-to-AMA-Data. (5) Also in the interest of not unnecessarily creating new AVPs, maybe just use the existing MIP-FA-to-HA-Key AVP instead of the new HAA-to-AMA-Data AVP. The idea here is that nowadays Diameter allows grouped AVPs to have variable member AVPs. So the MIP-FA-to-HA-Key AVP could contain different sets of member AVPs that represent either encrypted or non-encrypted FA-HA information. That is, the MIP-FA-to-HA-Key AVP could be something like: MIP-FA-to-HA-Key ::= < AVP Header: 328 > // non-encrypted case { MIP-FA-to-HA-SPI } { MIP-Algorithm-Type } { MIP-Session-Key } * [ AVP ] MIP-FA-to-HA-Key ::= < AVP Header: 328 > // encrypted case { Origin-Realm } // = AAAF2's realm, if necessary { Origin-Host } // = AAAF2's host, if necessary { CMS-Encrypted-Data } //(or {MIP-Session-Key-Material}?) * [ AVP ] (6) If the AAAF2 wanted to send back a CMS-encrypted version of the FA-HA key, then the single AMA sent from the AAAH to AAAF1 could contain two sets of CMS-secured AVPs, with two different sources and destinations. That is, the AMA could contain FA-HA key data, CMS-secured between AAAF2 and AAAF1, and also could contain FA-MN key data, CMS-secured betweeen AAAH and FA. Can CMS/AMAs piggyback stuff this way? > Comments please... > > Tony > > > > Bob Kopacz wrote: > > > Issue : Returning AAAF-Generated FA-HA Key to FA > > Submitter name: Bob Kopacz > > Submitter email address: BKopacz@InterlinkNetworks.com > > Date first submitted: 01-15-2002 > > Reference: > > Document: mobileip > > Comment type: Technical > > Priority: 1 > > Section: 2.2, 2.4, 5.4, 8.1, Issue#203 > > Rationale/Explanation of issue: > > > > [The following is based on some issue#203-related emails > > exchanged with Mark Eklund. The proposal I'm contributing here > > is also Mark's, as I understand it] > > > > When the HA is in the foreign network and a FA-HA key is > > requested, the AAAF, rather than the AAAH, generates the key. > > > > Here's the diagram of the issue: > > > > amr-> amr-> > > FA --------> AAAF1 -------------> AAAH > > <-ama <-ama | > > | ^ > > | | > > har | haa > > | | > > V | > > | > > <-har <-har | > > HA <-------- AAAF2 <---------------/ > > haa-> haa-> > > > > In the above diagram, FA & HA & AAAF1 & AAAF2 are all in the same > > visited network. AAAF1 and AAAF2 may be the same server, or may > > be different servers. > > > > In the above diagram, AAAF2 generates the FA-HA key. > > > > The problem is that this key must somehow be returned to the FA > > via AAAF1. The proposal here is to pass the key back to the FA > > via the the HAA and AMA messages. AAAF2 may be concerned about > > security, so may want the FA-HA key to be passed encrypted so > > that AAAH and intervening servers can't figure it out, but AAAF1 > > can somehow decrypt it. > > > > The details are: > > > > 1. A new HAA-to-AMA-Data AVP, of type octetstring, is created. > > The purpose of this AVP is convey information from the HA's AAAF > > (AAAF2) to the FA's AAAF (AAAF1). All AAAFs in that foreign > > realm MUST have an agreed upon format and security method for > > this AVP to be used. (It may be possible to use CMS security > > to somehow encrypt this AVP, but it is unclear just how, as it > > involves the AAAH copying a secure AVP from the HAA to the AMA, > > and the AMA may carry both AAAH-FA and AAAF1-AAAF2 secured > > AVPs) > > > > 2. When the FA-HA key is generated by AAAF2, this key must > > somehow be conveyed to AAAF1. There are two ways to do this: > > a. Use the MIP-HAA-to-AMA-Data AVP, or > > b Have a common database among AAAFs in the foreign network, > > wherein AAAF2 may deposit the FA-HA key, which is later retrieved > > by AAAF1, in a proprietary manner not described in the Diameter > > documents. > > > > 3. If the HAA-to-AMA-Data AVP is present in the HAA, the AAAH > > treats it as opaque data and passes it in the AMA. > > > > 4, If AAAF1 receives the HAA-to-AMA-Data AVP in the AMA, AAAF1 > > will use this AVP to recreate the FA-HA key, and replace this AVP > > by a MIP-FA-to-HA-Key AVP in the AMA sent to the FA. > > > > Requested change: > > > > This issues supercedes issue#203, which also addresses the > > problem of returning an AAAF-Generated FA-HA Key to the FA, but > > didn't quite work in the case where there was a 2nd AAAF > > involved. > > > > In section 2.2. Add [HAA-to-AMA-Data] to the AMA ABNF. > > > > In section 2.4. Add [HAA-to-AMA-Data] to the HAA ABNF. > > > > In section 6, define the following new AVP: > > > > 6.x HAA-to-AMA-Data AVP > > > > The HAA-to-AMA-Data AVP (AVP Code TBD) is of type OctetString and > > may be used, when the HA is allocated in the foreign network and > > the HA's AAAF generates the FA-HA key, to convey the FA-HA key > > information (in some proprietary format and security method which > > is agreed-upon by all AAAF servers in the foreign network) back > > to the FA's AAAF. > > > > In section 8.1. Add a row for the new HAA-to-AMA-Data AVP, with these > > occurrence rules: AMR 0, AMA 0-1, HAR 0, HAA 0-1. > > > > Replace section 5.4 by > > > > If the home agent is in the home realm, then AAAH has to generate > > the Foreign-Home session key. Otherwise, it is generated by the > > AAAF receiving the HAR. > > > > If the AAAH generates the Foreign-Home session key, then the AAAH > > includes the session key in the MIP-HA-to-FA-Key AVP, and > > includes the AVP as part of the HAR message sent to the home > > agent. The corresponding session key that is to be sent to the > > foreign agent is cached on the AAAH until the HAA is received, at > > which time the AAAH adds the MIP-FA-to-HA Key AVP to the AMA, > > using the SPI in the MIP-FA-to-HA-SPI. > > > > Upon receipt of the HAR, the home agent recovers the Foreign-Home > > session key, allocates an SPI to be used with the key. The > > allocated SPI is included in the HAA's MIP-FA-to-HA SPI AVP. > > > > If the AAAH doesn't generate the Foreign-Home session key, then > > upon receipt of the HAA, the AAAH extracts and passes the > > MIP-FA-to-HA-SPI AVP (if present in the HAR) in the AMA, and > > extracts and passes the HAA-to-AMA-Data AVP (if present in the > > HAR) in the AMA. > > > > If the AAAF receives an AMA which contains a HAA-to-AMA-Data AVP, > > the AAAF will recreate the FA-HA key, generate a MIP-FA-to-HA-Key > > AVP, and pass the MIP-FA-to-HA-Key AVP to the FA. > > > > Alternatively, if the AAAF generates the Foreign-Home session > > key, the AAAFs in the foreign network may have a common database > > among AAAFs, wherein the HA's AAAF may deposit the FA-HA key, > > which is later retrieved by the FA's AAAF, in a proprietary > > manner not described in the Diameter documents. From owner-aaa-wg@merit.edu Wed Jan 30 08:43: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 IAA18109 for ; Wed, 30 Jan 2002 08:43:59 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1A5479121A; Wed, 30 Jan 2002 08:43:44 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DA646912B8; Wed, 30 Jan 2002 08:43: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 91B959121A for ; Wed, 30 Jan 2002 08:43:41 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6C4595DDFA; Wed, 30 Jan 2002 08:43: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 568955DDE0 for ; Wed, 30 Jan 2002 08:43:41 -0500 (EST) Received: from phoenix (nat.interlinknetworks.com [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with SMTP id DDC7D7B; Wed, 30 Jan 2002 08:43:40 -0500 (EST) From: "Bob Kopacz" To: "Mark Eklund" Cc: "aaa-wg" Subject: [AAA-WG]: Error in base-08 state machine ? Date: Wed, 30 Jan 2002 08:43:04 -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) 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 Mark, This is just a preview of what might become an issue. I want to bring this up, but haven't clarified my thoughts enough to propose a solution. There might be a bug in the "Authorization Session State Machine", in section 8.1 of the base draft, in the 1st state machine which represents the case where the server maintains session-state. If in OPEN state, the server wants the session to be be terminated, it sends an ASR and goes into DISCON state. When the ASA is received, the server goes into IDLE state. This seems not quite right for a few reasons. (1) When the server subsequently receives the follow-up STR from the access device, the session will be either non-existent or in IDLE state. (2) The draft indicates that an access device is not required to honor an ASR, i.e. the access device can just reply with "unable to comply" and not terminate the session. In this case the server would have incorrectly terminated the session when receiving the negative ASA. The state machine might look the way it does because it is trying to accommodate the picture where some server other than the AAAH sends the ASR. Some sort of central session manager server. In this case the state machine works ok. What I see as an error is in the case where the AAAH sends his own ASR. Here's a few more partly-baked thoughts: (1) The protocol is asymmetrical; the server sends ASRs, receives auth requrests, receives STRs, sends STAs, etc; while the access device does the opposite. It might be clearer to have two state tables, one for the server and one for the access device. (2) Is the access device allowed to ignore an ASR from the AAAH? It might be that the text indicating that the access device is not required to honor an ASR is so that any old schmuck cannot just terminate a session. But should the access device be REQUIRED to honor the ASR if it comes from the AAAH? (3) This is a very-slightly baked thought: the state machine might want an entry or two about re-auths. Maybe the client's state table needs to differentiate between a "pending" re-auth versus a "pending" initial auth, and to reflect when a re-auth is pending versus hasn't-been-sent-yet. While the re-auth is pending, the service is effectively Opened for continued business, but not so when the initial auth is pending. Also, the client can receive an ASR while a re-auth is pending, but not so when the inital auth is pending. Bob K. From owner-aaa-wg@merit.edu Wed Jan 30 09:13: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 JAA19319 for ; Wed, 30 Jan 2002 09:13:43 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B201391281; Wed, 30 Jan 2002 09:13:20 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 83B0591285; Wed, 30 Jan 2002 09:13: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 6F91B91281 for ; Wed, 30 Jan 2002 09:13:19 -0500 (EST) Received: by segue.merit.edu (Postfix) id 48FCC5DDE0; Wed, 30 Jan 2002 09:13:19 -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 459525DD97 for ; Wed, 30 Jan 2002 09:13:18 -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 PAA14140; Wed, 30 Jan 2002 15:11:13 +0100 Message-ID: <3C580D4F.1000100@ipunplugged.com> Date: Wed, 30 Jan 2002 16:12:15 +0100 From: Johan Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7+) Gecko/20020120 X-Accept-Language: en-us MIME-Version: 1.0 To: Bob Kopacz Cc: Mark Eklund , aaa-wg Subject: Re: [AAA-WG]: Error in base-08 state machine ? 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 Bob Kopacz wrote: >If in OPEN state, the server wants the session to be be terminated, it >sends an ASR and goes into DISCON state. When the ASA is received, >the server goes into IDLE state. This seems not quite right for a few >reasons. > >(1) When the server subsequently receives the follow-up STR from the >access device, the session will be either non-existent or in IDLE >state. > It gets better. There is no specified order between the STR and the ASA, and since they may very well travel different routes specifying and order in the sending of them from the client wouldn't rectify this. If you really want your messages to add up you will need to add an intermediate state and transitions both on received STR and STA from both (well ok there are other possible statemachines but this seems like the smallest). The solution we have adopted for our mobile ip sessions is to simply ignore whichever arrives last. >(2) The draft indicates that an access device is not required to honor >an ASR, i.e. the access device can just reply with "unable to comply" >and not terminate the session. In this case the server would have >incorrectly terminated the session when receiving the negative ASA. > So on a negative ASA you would go back to open and stay there indefinately? Would you do the same thing if the ASR was undeliverable? It could be stated for good reasons that every service you receive after attempting to tear down the session is free. >(1) The protocol is asymmetrical; the server sends ASRs, receives auth >requrests, receives STRs, sends STAs, etc; while the access device >does the opposite. It might be clearer to have two state tables, one >for the server and one for the access device. > It certainly would. I think any reasonable implementation would separate them anyway. >(2) Is the access device allowed to ignore an ASR from the AAAH? It >might be that the text indicating that the access device is not >required to honor an ASR is so that any old schmuck cannot just >terminate a session. But should the access device be REQUIRED to honor >the ASR if it comes from the AAAH? > This brings me back to the question of why ASRs don't have termination causes while STRs do? j From owner-aaa-wg@merit.edu Wed Jan 30 10:16: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 KAA21834 for ; Wed, 30 Jan 2002 10:16:35 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B6D9B91294; Wed, 30 Jan 2002 10:16:13 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 827C4912B8; Wed, 30 Jan 2002 10:16: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 6A3ED91294 for ; Wed, 30 Jan 2002 10:16:12 -0500 (EST) Received: by segue.merit.edu (Postfix) id 535C55DE01; Wed, 30 Jan 2002 10:16:12 -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 A19AF5DD97 for ; Wed, 30 Jan 2002 10:16:11 -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 QAA16090; Wed, 30 Jan 2002 16:14:21 +0100 Message-ID: <3C581C18.6080606@ipunplugged.com> Date: Wed, 30 Jan 2002 17:15:20 +0100 From: Johan Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7+) Gecko/20020120 X-Accept-Language: en-us MIME-Version: 1.0 To: aaa-wg Subject: [AAA-WG]: Mobile IP accounting 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 am somewhat confused about how to do MIP accounting. The only description of accounting beyond avp definitions that I can find in the mip draft is a few statements about Accounting-Multi-Session-Id and the figure reproduced below for your convenience: ACR, Session-Id = foo ACR, Session-Id = bar Accounting-Multi-Session-Id = a Accounting-Multi-Session-Id = a ---------------------> <-------------------- +----+ +------+ +------+ +----+ | FA | | AAAF | | AAAH | | HA | +----+ +------+ +------+ +----+ <--------------------- ---------------------> ACA, Session-Id = foo ACA, Session-Id = bar Figure 4: Accounting messages w/ Mobile IP Application This seems to imply that only *the* accounting server receives any accounting information, which in this particular case also happens to be the AAAH. Let us examine the following network: FA in realm abc.com AAAH in realm isp.com HA in realm def.com Does this mean that only isp.com will receive accounting messages and that abc.com and def.com never interchange information at all and if they want to store accounting information for comparison we say "sure, go ahead" but we don't care how and we provide no support for it? j From owner-aaa-wg@merit.edu Wed Jan 30 10:33: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 KAA22545 for ; Wed, 30 Jan 2002 10:33:51 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id BC046912B8; Wed, 30 Jan 2002 10:33:34 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7F767912B9; Wed, 30 Jan 2002 10:33: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 7D9B1912B8 for ; Wed, 30 Jan 2002 10:33:33 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5EC3A5DE11; Wed, 30 Jan 2002 10:33:33 -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 6D5D45DE04 for ; Wed, 30 Jan 2002 10:33:32 -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 QAA16551; Wed, 30 Jan 2002 16:31:44 +0100 Message-ID: <3C58202D.7030002@ipunplugged.com> Date: Wed, 30 Jan 2002 17:32:45 +0100 From: Johan Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7+) Gecko/20020120 X-Accept-Language: en-us MIME-Version: 1.0 To: aaa-wg Cc: Boris Prochazka Subject: Re: [AAA-WG]: Mobile IP accounting References: <3C581C18.6080606@ipunplugged.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 Am I furthermore correct in assuming that the initial ACR has the realm from the users' nai but no destination host and that subsequent ACRs have the destination host of the initial ACA? Johan Johansson wrote: > I am somewhat confused about how to do MIP accounting. The only > description of accounting beyond avp definitions that I can find in > the mip draft is a few statements about Accounting-Multi-Session-Id > and the figure reproduced below for your convenience: > > ACR, Session-Id = foo ACR, Session-Id = bar > Accounting-Multi-Session-Id = a Accounting-Multi-Session-Id = a > ---------------------> <-------------------- > +----+ +------+ +------+ +----+ > | FA | | AAAF | | AAAH | | HA | > +----+ +------+ +------+ +----+ > <--------------------- ---------------------> > ACA, Session-Id = foo ACA, Session-Id = bar > > Figure 4: Accounting messages w/ Mobile IP Application > > This seems to imply that only *the* accounting server receives any > accounting information, which in this particular case also happens to > be the AAAH. Let us examine the following network: > > FA in realm abc.com > AAAH in realm isp.com > HA in realm def.com > > Does this mean that only isp.com will receive accounting messages and > that abc.com and def.com never interchange information at all and if > they want to store accounting information for comparison we say "sure, > go ahead" but we don't care how and we provide no support for it? > > j > > > From owner-aaa-wg@merit.edu Wed Jan 30 22:20: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 WAA07887 for ; Wed, 30 Jan 2002 22:20:09 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 857E2912A1; Wed, 30 Jan 2002 22:19:54 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4898E912A2; Wed, 30 Jan 2002 22:19: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 8316B912A1 for ; Wed, 30 Jan 2002 22:19:51 -0500 (EST) Received: by segue.merit.edu (Postfix) id 67B5F5DDE5; Wed, 30 Jan 2002 22:19:51 -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 292C75DD99 for ; Wed, 30 Jan 2002 22:19:51 -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 g0V3Jnh11300; Wed, 30 Jan 2002 21:19:49 -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 g0V3Jnq06839; Wed, 30 Jan 2002 21:19: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 VAA15547; Wed, 30 Jan 2002 21:19:49 -0600 (CST) Received: from ericsson.com ([138.85.159.104]) by qpop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id VAA21191; Wed, 30 Jan 2002 21:19:47 -0600 (CST) Message-ID: <3C58B759.B84185CC@ericsson.com> Date: Wed, 30 Jan 2002 19:17: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: Bob Kopacz Cc: Mark Eklund , aaa-wg@merit.edu Subject: Re: [AAA-WG]: [issue] Returning AAAF-Generated FA-HA Key to FA 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, Thanks for your comments I think we are getting somewhere here:) please find my comments embedded... Regards, Tony Bob Kopacz wrote: > Hi Tony, > > > From: Tony Johansson [tony.johansson@ericsson.com] > > Sent: Monday, January 28, 2002 6:46 PM > > To: Bob Kopacz > > Cc: aaa-wg@merit.edu > > Subject: Re: [AAA-WG]: [issue] Returning AAAF-Generated FA-HA Key to FA > > > > Hello Bob and All, > > > > I agree that it could be good to have a way of encrypting the FA-HA Key as > > you describe below, and even more for the case where you move through a > > third domain ( i.e. the AAAF1 and AAAF2 belongs to two different networks). > > However, I really think that we need to find a more interoperability > > approve approach. I'm not sure that we just can say that the HAA-toAMA-Data > > AVP is of type OctetString and may be used, to convey the FA-HA key > > information in some proprietary format and security method which is > > agreed-upon by all AAAF servers in the foreign network... > > > > You mention CMS security below and I agree, couldn't we make use of the CMS > > security for this case? > > Your idea to use CMS security is probably a better idea. A proprietary > solution wouldn't work very well inter-realm. And using CMS is more in > the spirit of the mobileip-draft, > where its one comment in section 5.0 > about securing keys is "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." > > > > So, what about the following (I'm not a CMS security expert, so please > > correct me if this is not really possible or to complex...): > > > > Instead, make the HAA-toAMA-Data AVP of type grouped : > > > > HAA-toAMA-Data AVP ::= < AVP Header: TBD > > > { Originating-Foriegn-Home-Key-Distr-Host } > > { CMS-Encrypted-Data } > > * [ AVP ] > > > > The CMS-Encrypted-Data AVP would contain the FA-HA Key encrypted and the > > Originating-Foriegn-Home-Key-Distr-Host AVP (lack of better name:) would > > contain the Host NAI of the AAAF2, see Figure below > > > > The message flow would then be the following: > > > > (Please view in a fixed-width font such as Courier.) > > > > 1.amr-> 1.amr-> > > FA --------> AAAF1 1------------> AAAH > > <-6.ama | ^ <-4.ama | > > | | | ^ > > | | | | > > 5.dsar | |5.dsaa 2.har |3.haa > > | | | | > > | | V | > > | | | > > <-2.har v | <-2.har | > > HA <-------- AAAF2 <---------------/ > > 3.haa-> 3.haa-> > > > > Thus, the AAAF2 would create the HAA-to-AMA AVP with its Host name and the > > FA-HA Key encrypted using its digital certificate. Upon receiving the HAA > > the AAAH would add the HAA-to-AMA AVP into the AMA. Upon receipt of the AMA > > the AAAF1 would identify the Originating-Foriegn-Home-Key-Distr-Host AVP in > > the HAA-to-AMA AVP and issue a DSAR to the AAAF2 and request for the > > digital certificate, which the AAAF1 then would use to decrypt the FA-HA > > Key.... > > > > Could this be a way forward ? > > Here's some thoughts, but bear in mind my limited understanding of CMS. > > (1) Maybe AAAF2 should initiate the security relationship with AAAF1, > rather than the other way around. That is, AAAF2 sends the DSAR before > responding with the HAA. My thinking here is, in the case where the AAAH > wants to secure its generated keys with the FA, it is the sender of the > CMS-secured data that initiates the DSAR. Right. Since it is the AAAF2 that will create the FA-HA Key and also the one that will decide if the key needs to be encrypted or not. However, there is no way for the AAAF2 to know from which domain this MN is requesting to keep the HA (the only thing the AAAF2 know is that it has no pending AMR for this user from one of its FAs). So, for the AAAF2 to really be able to decide if the FA-HA key needs to be encrypted or not it needs to know the originating domain. So, what about introduce the following new AVP: Originating-Foreign-AAA ::= < AVP Header: YYY > { Origin-Realm } // = AAAF1's realm { Origin-Host } // = AAAF1's host-name The Originating-Foreign-AAA AVP would be added in the AMR by the AAAF1 in the case that the Home-Address-Allocatable-Only-in-Home-Realm flag are set to zero...(i.e. in all cases when the HA is not allocated in the home domain). So, if the Originating-Foreign-AAA AVP is present in the AMR the AAAH must copy it into the HAR. The AAAF2 would then have the necessary info for the above.. > > > (2) The above scheme requires the CMS big gun. In the mobile-ip draft, > the AAAH has the option of securing its generated keys via CMS, or sending > them in the clear. So maybe CMS should be an option for the > AAAF2-generated key. That is, AAAF2 could send the FA-HA-Key secured (per > your proposal), or could instead just send a plain old MIP-FA-to-HA-Key > AVP if the AAAF2 didn't feel the need to secure the key. > > (3) In the above HAA-to-AMA-Data AVP, the diameter identity of the AAAF2 > is provided. If the AAAF1 wants to send a DSAR to AAAF2, it might also be > necessary to include AAAF2's realm in the HAA-to-AMA-Data AVP, so that > AAAF1 can fill in both the Destination-Realm and Destination-Host of the > DSAR, for routing. > > (4) "Originating-Foriegn-Home-Key-Distr-Host" is one heck of name. With > the thought of minimizing the creation of new AVPs, could we just use the > "Origin-Host" and "Origin-Realm" AVPs as members of HAA-to-AMA-Data? The > idea is, when "Origin-Host" and "Origin-Realm" are members of a grouped > AVP, they represent the originator of that AVP. So AAAF2 could fill in > his identity as the Origin-Host member of HAA-to-AMA-Data. > > (5) Also in the interest of not unnecessarily creating new AVPs, maybe > just use the existing MIP-FA-to-HA-Key AVP instead of the new > HAA-to-AMA-Data AVP. The idea here is that nowadays Diameter allows > grouped AVPs to have variable member AVPs. So the MIP-FA-to-HA-Key AVP > could contain different sets of member AVPs that represent either > encrypted or non-encrypted FA-HA information. That is, the > MIP-FA-to-HA-Key AVP could be something like: > > MIP-FA-to-HA-Key ::= < AVP Header: 328 > // non-encrypted case > { MIP-FA-to-HA-SPI } > { MIP-Algorithm-Type } > { MIP-Session-Key } > * [ AVP ] > > MIP-FA-to-HA-Key ::= < AVP Header: 328 > // encrypted case > { Origin-Realm } // = AAAF2's realm, if necessary > { Origin-Host } // = AAAF2's host, if necessary > { CMS-Encrypted-Data } > //(or {MIP-Session-Key-Material}?) > * [ AVP ] > I don't think this would be such a good idea to try to reuse that same AVP. I think we need new grouped AVP for the encryption case since we need a completely new set of mandatory AVPs. So what about the following: MIP-Encrypted-FA-to-HA-Key ::= < AVP Header: YYY> { CMS-Encrypted-Data } * [ AVP ] The FA-HA key would be encrypted in the CMS-Encrypted-Data AVP with AAAF1 SA. The originator info is part of the CMS envelop-data header. So, I don't think we need to add an Origin-Realm AVP and an Origin-Host AVP. Upon receiving the HAA the AAAH only has to copy the MIP-Encrypted-FA-to-HA-Key AVP to the AMA back to the AAAF1 (i.e. in the same fashion as when the FA-HA Key is distributed in clear text, which is describe in the draft today). > > (6) If the AAAF2 wanted to send back a CMS-encrypted version of the FA-HA > key, then the single AMA sent from the AAAH to AAAF1 could contain two > sets of CMS-secured AVPs, with two different sources and destinations. > That is, the AMA could contain FA-HA key data, CMS-secured between AAAF2 > and AAAF1, and also could contain FA-MN key data, CMS-secured betweeen > AAAH and FA. Can CMS/AMAs piggyback stuff this way? > > > Comments please... > > > > Tony > > > > > > > > Bob Kopacz wrote: > > > > > Issue : Returning AAAF-Generated FA-HA Key to FA > > > Submitter name: Bob Kopacz > > > Submitter email address: BKopacz@InterlinkNetworks.com > > > Date first submitted: 01-15-2002 > > > Reference: > > > Document: mobileip > > > Comment type: Technical > > > Priority: 1 > > > Section: 2.2, 2.4, 5.4, 8.1, Issue#203 > > > Rationale/Explanation of issue: > > > > > > [The following is based on some issue#203-related emails > > > exchanged with Mark Eklund. The proposal I'm contributing here > > > is also Mark's, as I understand it] > > > > > > When the HA is in the foreign network and a FA-HA key is > > > requested, the AAAF, rather than the AAAH, generates the key. > > > > > > Here's the diagram of the issue: > > > > > > amr-> amr-> > > > FA --------> AAAF1 -------------> AAAH > > > <-ama <-ama | > > > | ^ > > > | | > > > har | haa > > > | | > > > V | > > > | > > > <-har <-har | > > > HA <-------- AAAF2 <---------------/ > > > haa-> haa-> > > > > > > In the above diagram, FA & HA & AAAF1 & AAAF2 are all in the same > > > visited network. AAAF1 and AAAF2 may be the same server, or may > > > be different servers. > > > > > > In the above diagram, AAAF2 generates the FA-HA key. > > > > > > The problem is that this key must somehow be returned to the FA > > > via AAAF1. The proposal here is to pass the key back to the FA > > > via the the HAA and AMA messages. AAAF2 may be concerned about > > > security, so may want the FA-HA key to be passed encrypted so > > > that AAAH and intervening servers can't figure it out, but AAAF1 > > > can somehow decrypt it. > > > > > > The details are: > > > > > > 1. A new HAA-to-AMA-Data AVP, of type octetstring, is created. > > > The purpose of this AVP is convey information from the HA's AAAF > > > (AAAF2) to the FA's AAAF (AAAF1). All AAAFs in that foreign > > > realm MUST have an agreed upon format and security method for > > > this AVP to be used. (It may be possible to use CMS security > > > to somehow encrypt this AVP, but it is unclear just how, as it > > > involves the AAAH copying a secure AVP from the HAA to the AMA, > > > and the AMA may carry both AAAH-FA and AAAF1-AAAF2 secured > > > AVPs) > > > > > > 2. When the FA-HA key is generated by AAAF2, this key must > > > somehow be conveyed to AAAF1. There are two ways to do this: > > > a. Use the MIP-HAA-to-AMA-Data AVP, or > > > b Have a common database among AAAFs in the foreign network, > > > wherein AAAF2 may deposit the FA-HA key, which is later retrieved > > > by AAAF1, in a proprietary manner not described in the Diameter > > > documents. > > > > > > 3. If the HAA-to-AMA-Data AVP is present in the HAA, the AAAH > > > treats it as opaque data and passes it in the AMA. > > > > > > 4, If AAAF1 receives the HAA-to-AMA-Data AVP in the AMA, AAAF1 > > > will use this AVP to recreate the FA-HA key, and replace this AVP > > > by a MIP-FA-to-HA-Key AVP in the AMA sent to the FA. > > > > > > Requested change: > > > > > > This issues supercedes issue#203, which also addresses the > > > problem of returning an AAAF-Generated FA-HA Key to the FA, but > > > didn't quite work in the case where there was a 2nd AAAF > > > involved. > > > > > > In section 2.2. Add [HAA-to-AMA-Data] to the AMA ABNF. > > > > > > In section 2.4. Add [HAA-to-AMA-Data] to the HAA ABNF. > > > > > > In section 6, define the following new AVP: > > > > > > 6.x HAA-to-AMA-Data AVP > > > > > > The HAA-to-AMA-Data AVP (AVP Code TBD) is of type OctetString and > > > may be used, when the HA is allocated in the foreign network and > > > the HA's AAAF generates the FA-HA key, to convey the FA-HA key > > > information (in some proprietary format and security method which > > > is agreed-upon by all AAAF servers in the foreign network) back > > > to the FA's AAAF. > > > > > > In section 8.1. Add a row for the new HAA-to-AMA-Data AVP, with these > > > occurrence rules: AMR 0, AMA 0-1, HAR 0, HAA 0-1. > > > > > > Replace section 5.4 by > > > > > > If the home agent is in the home realm, then AAAH has to generate > > > the Foreign-Home session key. Otherwise, it is generated by the > > > AAAF receiving the HAR. > > > > > > If the AAAH generates the Foreign-Home session key, then the AAAH > > > includes the session key in the MIP-HA-to-FA-Key AVP, and > > > includes the AVP as part of the HAR message sent to the home > > > agent. The corresponding session key that is to be sent to the > > > foreign agent is cached on the AAAH until the HAA is received, at > > > which time the AAAH adds the MIP-FA-to-HA Key AVP to the AMA, > > > using the SPI in the MIP-FA-to-HA-SPI. > > > > > > Upon receipt of the HAR, the home agent recovers the Foreign-Home > > > session key, allocates an SPI to be used with the key. The > > > allocated SPI is included in the HAA's MIP-FA-to-HA SPI AVP. > > > > > > If the AAAH doesn't generate the Foreign-Home session key, then > > > upon receipt of the HAA, the AAAH extracts and passes the > > > MIP-FA-to-HA-SPI AVP (if present in the HAR) in the AMA, and > > > extracts and passes the HAA-to-AMA-Data AVP (if present in the > > > HAR) in the AMA. > > > > > > If the AAAF receives an AMA which contains a HAA-to-AMA-Data AVP, > > > the AAAF will recreate the FA-HA key, generate a MIP-FA-to-HA-Key > > > AVP, and pass the MIP-FA-to-HA-Key AVP to the FA. > > > > > > Alternatively, if the AAAF generates the Foreign-Home session > > > key, the AAAFs in the foreign network may have a common database > > > among AAAFs, wherein the HA's AAAF may deposit the FA-HA key, > > > which is later retrieved by the FA's AAAF, in a proprietary > > > manner not described in the Diameter documents. From owner-aaa-wg@merit.edu Thu Jan 31 09:37: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 JAA27838 for ; Thu, 31 Jan 2002 09:37:13 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 460BB912A8; Thu, 31 Jan 2002 09:36:58 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0F9C1912A9; Thu, 31 Jan 2002 09:36: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 ED9A9912A8 for ; Thu, 31 Jan 2002 09:36:56 -0500 (EST) Received: by segue.merit.edu (Postfix) id CD6E55DDB8; Thu, 31 Jan 2002 09:36:56 -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 0BE5E5DDAB for ; Thu, 31 Jan 2002 09:36:56 -0500 (EST) Received: from knox6039.cisco.com (knox6039.cisco.com [161.44.216.39]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id JAA10277; Thu, 31 Jan 2002 09:36:54 -0500 (EST) Received: (from meklund@localhost) by knox6039.cisco.com (8.9.3+Sun/8.9.3) id JAA06969; Thu, 31 Jan 2002 09:36:53 -0500 (EST) From: Mark Eklund MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15449.22149.275532.846130@gargle.gargle.HOWL> Date: Thu, 31 Jan 2002 09:36:53 -0500 To: Johan Johansson Cc: aaa-wg Subject: Re: [AAA-WG]: Mobile IP accounting In-Reply-To: <3C581C18.6080606@ipunplugged.com> References: <3C581C18.6080606@ipunplugged.com> X-Mailer: VM 6.93 under Emacs 21.1.1 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Johan, Johan Johansson writes: > I am somewhat confused about how to do MIP accounting. The only > description of accounting beyond avp definitions that I can find in the > mip draft is a few statements about Accounting-Multi-Session-Id and the > figure reproduced below for your convenience: > > ACR, Session-Id = foo ACR, Session-Id = bar > Accounting-Multi-Session-Id = a Accounting-Multi-Session-Id = a > ---------------------> <-------------------- > +----+ +------+ +------+ +----+ > | FA | | AAAF | | AAAH | | HA | > +----+ +------+ +------+ +----+ > <--------------------- ---------------------> > ACA, Session-Id = foo ACA, Session-Id = bar > > Figure 4: Accounting messages w/ Mobile IP Application > > This seems to imply that only *the* accounting server receives any > accounting information, which in this particular case also happens to be > the AAAH. Let us examine the following network: > > FA in realm abc.com > AAAH in realm isp.com > HA in realm def.com > > Does this mean that only isp.com will receive accounting messages and > that abc.com and def.com never interchange information at all and if > they want to store accounting information for comparison we say "sure, > go ahead" but we don't care how and we provide no support for it? I had always assummed that the FA accounting records were the property of the foreign domain and the HA accounting records were property of the home domain. Figure 4 disagrees with my assumptions. Given your argument above, I would say that Figure 4 is wrong. -mark > > j > > From owner-aaa-wg@merit.edu Thu Jan 31 15:04: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 PAA10465 for ; Thu, 31 Jan 2002 15:04:30 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9B7C2912E6; Thu, 31 Jan 2002 15:00:56 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5B62E912E5; Thu, 31 Jan 2002 15:00: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 710AC912DF for ; Thu, 31 Jan 2002 15:00:52 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4E5115DDAE; Thu, 31 Jan 2002 15:00:52 -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 E1BC75DDAB for ; Thu, 31 Jan 2002 15:00:51 -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 g0VK0lS14232; Thu, 31 Jan 2002 14:00:47 -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 g0VK0lC23026; Thu, 31 Jan 2002 14:00:47 -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 OAA21151; Thu, 31 Jan 2002 14:00:46 -0600 (CST) Received: from ericsson.com ([138.85.159.104]) by qpop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id OAA08703; Thu, 31 Jan 2002 14:00:45 -0600 (CST) Message-ID: <3C59A1F3.6EBC91F@ericsson.com> Date: Thu, 31 Jan 2002 11:58:44 -0800 From: Tony Johansson X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Mark Eklund Cc: Johan Johansson , aaa-wg Subject: Re: [AAA-WG]: Mobile IP accounting References: <3C581C18.6080606@ipunplugged.com> <15449.22149.275532.846130@gargle.gargle.HOWL> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Johan and Mark, Mark Eklund wrote: > Johan, > > Johan Johansson writes: > > I am somewhat confused about how to do MIP accounting. The only > > description of accounting beyond avp definitions that I can find in the > > mip draft is a few statements about Accounting-Multi-Session-Id and the > > figure reproduced below for your convenience: > > > > ACR, Session-Id = foo ACR, Session-Id = bar > > Accounting-Multi-Session-Id = a Accounting-Multi-Session-Id = a > > ---------------------> <-------------------- > > +----+ +------+ +------+ +----+ > > | FA | | AAAF | | AAAH | | HA | > > +----+ +------+ +------+ +----+ > > <--------------------- ---------------------> > > ACA, Session-Id = foo ACA, Session-Id = bar > > > > Figure 4: Accounting messages w/ Mobile IP Application > > > > This seems to imply that only *the* accounting server receives any > > accounting information, which in this particular case also happens to be > > the AAAH. Let us examine the following network: > > > > FA in realm abc.com > > AAAH in realm isp.com > > HA in realm def.com > > > > Does this mean that only isp.com will receive accounting messages and > > that abc.com and def.com never interchange information at all and if > > they want to store accounting information for comparison we say "sure, > > go ahead" but we don't care how and we provide no support for it? > > I had always assummed that the FA accounting records were the property > of the foreign domain and the HA accounting records were property of > the home domain. Figure 4 disagrees with my assumptions. Given your > argument above, I would say that Figure 4 is wrong. Well, I thought that we have agree that ACR's MUST be sent to the Home AAA server, see text below from Base section 9.2 "9.2 Protocol Messages A Diameter node that receives a successful authentication and/or authorization messages from the Home AAA Server, MUST collect accounting information for the session. The Accounting-Request message is used to transmit the accounting information to the Home AAA server, which MUST reply with the Accounting-Answer message to confirm reception. The Accounting-Answer message includes the Result-Code AVP, which MAY indicate that an error......" However, there is of course nothing that prevents the foreign domain to collect a copy of the accounting data. Regarding the fact that we only talk about real-time accounting, I really don't see anything wrong with what we have in the spec today. > > > -mark > > > > > j > > > > From owner-aaa-wg@merit.edu Thu Jan 31 19:50: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 TAA16665 for ; Thu, 31 Jan 2002 19:50:36 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2EB33912F9; Thu, 31 Jan 2002 19:50:26 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F2544912FA; Thu, 31 Jan 2002 19:50: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 C60BB912F9 for ; Thu, 31 Jan 2002 19:50:24 -0500 (EST) Received: by segue.merit.edu (Postfix) id A62915DDAB; Thu, 31 Jan 2002 19:50:24 -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 139ED5DD91 for ; Thu, 31 Jan 2002 19:50:24 -0500 (EST) Received: from ipunplugged.com ([213.100.60.208]) by fep01-svc.swip.net with ESMTP id <20020201005023.CELJ17637.fep01-svc.swip.net@ipunplugged.com>; Fri, 1 Feb 2002 01:50:23 +0100 Message-ID: <3C59F1F0.3010404@ipunplugged.com> Date: Fri, 01 Feb 2002 01:40:00 +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: Tony Johansson Cc: Mark Eklund , aaa-wg Subject: Re: [AAA-WG]: Mobile IP accounting References: <3C581C18.6080606@ipunplugged.com> <15449.22149.275532.846130@gargle.gargle.HOWL> <3C59A1F3.6EBC91F@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: >> > FA in realm abc.com >> > AAAH in realm isp.com >> > HA in realm def.com >> > >> > Does this mean that only isp.com will receive accounting messages and >> > that abc.com and def.com never interchange information at all and if >> > they want to store accounting information for comparison we say "sure, >> > go ahead" but we don't care how and we provide no support for it? >> >>I had always assummed that the FA accounting records were the property >>of the foreign domain and the HA accounting records were property of >>the home domain. Figure 4 disagrees with my assumptions. Given your >>argument above, I would say that Figure 4 is wrong. >> > >Well, I thought that we have agree that ACR's MUST be sent to the Home AAA >server, see text below from Base section 9.2 > >"9.2 Protocol Messages > > A Diameter node that receives a successful authentication and/or > authorization messages from the Home AAA Server, MUST collect > accounting information for the session. The Accounting-Request > message is used to transmit the accounting information to the Home > AAA server, which MUST reply with the Accounting-Answer message to > confirm reception. The Accounting-Answer message includes the > Result-Code AVP, which MAY indicate that an error......" > >However, there is of course nothing that prevents the foreign domain to collect >a copy of the accounting data. Regarding the fact that we only talk about >real-time accounting, I really don't see anything wrong with what we have in >the spec today. > I am not necessarily claiming that something is wrong. What I am trying to do is understand the assumptions made when accounting was specified. My present understanding is that accounting is merely a log of what happens and not a control channel in the sense that you will never get an ACA with the result code DIAMETER_INSUFFICIENT_FUNDS. It would be the job of the authorization server to take such a decision. Another assumption is that the AAAH and the HA is operated by the same organization, at least in the case where the HA is not in the foreign realm. Maybe a small company deem it affordable to buy a couple of agents but is unwilling to invest in a home server and the support necessary to administer the users and keep it running and therefore buys this service from an isp? In this scenario it hardly makes sense to send accounting data to someone who is not participating in the actual traffic. Then again accounting could be routed separately from the authorization/authentication traffic. Maybe this is a scenario that we are not even trying to cover? The drafts never explain the purpose of sending accounting data both from the home and foreign realm to the home server. Forcing the foreign agent to send signed accounting data could be useful for nonrepudiation I guess and the home agent's accounting data could be used for online or offline verification that the data is reasonable. Is this the purpose? As you say, there is nothing that stops the foreign realm from storing a copy of the accounting data in case they want to send a bill. There is a certain logic in not specifying the means for doing so since it is after all within the same organization. But why do we then specify how the home organization is to transport its data within its network? j