From mailman-admin@ietf.org Thu May 1 10:41:45 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14413 for ; Thu, 1 May 2003 10:41:45 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41Eln814255 for ; Thu, 1 May 2003 10:47:49 -0400 Date: Thu, 01 May 2003 10:47:49 -0400 Message-ID: <20030501144749.17986.69098.Mailman@www1.ietf.org> Subject: ietf.org mailing list memberships reminder From: mailman-owner@www1.ietf.org To: aaa-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: mailman-admin@ietf.org Errors-To: mailman-admin@ietf.org X-BeenThere: mailman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, aaa-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. *************************************************************************** Note Well All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to * the IETF plenary session, * any IETF working group or portion thereof, * the IESG, or any member thereof on behalf of the IESG, * the IAB or any member thereof on behalf of the IAB, * any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. *************************************************************************** If you have questions, problems, comments, etc, send them to mailman-owner@www1.ietf.org. Thanks! Passwords for aaa-archive@lists.ietf.org: List Password // URL ---- -------- aaa@ietf.org kaithu https://www1.ietf.org/mailman/options/aaa/aaa-archive%40lists.ietf.org From owner-aaa-wg@merit.edu Mon May 5 12:57:24 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07859 for ; Mon, 5 May 2003 12:57:24 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B81B69122F; Mon, 5 May 2003 12:49:22 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 83D2E91230; Mon, 5 May 2003 12:49:22 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 164159122F for ; Mon, 5 May 2003 12:49:21 -0400 (EDT) Received: by segue.merit.edu (Postfix) id F1A4A5E179; Mon, 5 May 2003 12:49:20 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from web41813.mail.yahoo.com (web41813.mail.yahoo.com [66.218.93.147]) by segue.merit.edu (Postfix) with SMTP id 5BBFC5E142 for ; Mon, 5 May 2003 12:49:20 -0400 (EDT) Message-ID: <20030505164919.50438.qmail@web41813.mail.yahoo.com> Received: from [65.213.193.49] by web41813.mail.yahoo.com via HTTP; Mon, 05 May 2003 09:49:19 PDT Date: Mon, 5 May 2003 09:49:19 -0700 (PDT) From: CAITR Reply-To: info@caitr.org Subject: [AAA-WG]: Internetworking 2003: Call for Participation To: aaa-wg@merit.edu MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-2024752007-1052153359=:50316" Sender: owner-aaa-wg@merit.edu Precedence: bulk --0-2024752007-1052153359=:50316 Content-Type: text/plain; charset=us-ascii Internetworking 2003 International Conference Hilton San Jose & Towers Hotel, California June 22-June 24, 2003 http://www.caitr.org/internetworking03/index.htm You are cordially invited to attend the Internetworking 2003 International Conference to be held in San Jose, California, June 22-24, 2003. The 3-day event consists of two-days of highly technical sessions, preceded by four technical tutorials.Registration for the conference is underway. Please visit http://www.caitr.org/internetworking03/registration.htm and follow instructions for registration. The early registration discounts are extremely attractive and are valid till June 1, 2003.Important Dates: --------------------- - Early Registration Rates Cut-Off Date: Sept 30 - Tutorials: Oct 27, 1:00-6:00 pm - Conference sessions: October 28-29 8:30am-6:00pmProgram: ------------- (visit http://www.caitr.org/internetworking03/program.htm for abstracts and speaker details)Sunday June 22 Tutorial-1: MPLS VPNs Tutorial-2: IPv6 Tutorial-3: Mobile Wireless Internet Architecture and Protocols Tutorial-4: Voice over Packet Monday June 23 Welcome and Keynote Session: Network Technology Trends - Forwarding Element and Control Separation - Evolution of Inter-Domain Routing - Network Processing Building Blocks: Enabling the Routers of the Future Session: Network Architecture - An architecture for IPv6 VPNs and IPv6 transport over MPLS/GMPLS multiservice backbones IPv6 - A new routing architecture: Atomised Routing - Internetworking MPLS Layer 2 Transport with an IP Services Network Session: Storage Area Networks - Storage as a Network Node - Object-Based Storage - Design, Implementation, and Performance Analysis of the iSCSI Protocol for SCSI over TCP/IP - SANs Considerations Session: Mobile & Wireless Networks - CertBU: Certificate-based Techniques for Securing Mobile IPv6 Binding Updates IPv6 - Challenges and Roadmap of UMTS Network Deployment - Inter-working Mobile IPv6 with IP Multimedia Subsystem in UMTS - Mobile Authentication and QoS - Mobile Handoff Technologies Tuesday June 24 Session: Inter-Domain Routing - Optimizing Route Convergence - Traceroute and BGP AS Path Incongruities - Domain Constrained Multicast: A New Approach for IP Multicast Routing Session: Applications & Services - Securing the Web with Next Generation Encryption Technologies - Impact of the live radio on the Internet, and the real-time streaming audio, in the ComUNITY cable system from Com21 - A novel EAC semantic for the RTSP protocol - Towards an end-to-end architecture integrating new Transport and IP services in a DiffServ Internet Session: Network Management & Planning - Pseudowire OAM: A Mandatory Yet Often Overlooked Feature - A Multicommodity Flow Formulation for the MPLS Layout Design: Reduced Complexity Layout and Minimum Relayout Probems - Design Of Fast Fault Restoration System For WDM Networks - Cross-domain multimedia service provisioning, the EVOLUTE solution Session: QoS Based Routing - QoS Routing in Networks with Non-Deterministic Information - Active Dynamic Routing - QoS routing for Differentiated Services: simulations and prototype experiments - Probabilistic routing for QoS improvement in GPS networks - Fluid flow network modeling for hop-by-hop feedback control design and analysis We look forward to seeing you at the Conference. Regards, Conference Technical Co-chairs: - Dr. Maurice Gagnaire, ENST, France - Daniel Awduche Technical Program Committee of the Internetworking 2003 Conference: - Roberto Sabella, Erisson - Dr. Moshe Zukerman, Univ. of Melbourne - Nada Golmie, NIST - Dr. Guy Pujolle, LIP6, France - Dr. Samir Tohme, ENST, France - Stefano Trumpy, Italian National Research Council - Dr. Ibrahim Habib, City Univ. of NY - Dr. Marc Lobelle, UCL University, Belgium - Dr. Parviz Yegani, Cisco Systems - Dr. G.S. Kuo - Dr. Abbas Jamalipour, Univ. of Sydney - Dr. Hussein Mouftah, Univ. of Ottawa - James Kempf - Elizabeth Rodriguez - Dr. Ferit Yegenoglu, Isocore - Dr. Ali Zadeh, George Mason University - Dr. Tony Przygienda, Xebeo - Ran Canetti, IBM --0-2024752007-1052153359=:50316 Content-Type: text/html; charset=us-ascii
 

     Internetworking 2003 International Conference
     Hilton San Jose & Towers Hotel, California
              June 22-June 24, 2003
    http://www.caitr.org/internetworking03/index.htm
  
You are cordially invited to attend the Internetworking 2003 International Conference to be held in San Jose, California, June 22-24, 2003. The 3-day event consists of two-days of highly technical sessions, preceded by four technical tutorials.
Registration for the conference is underway. Please visit http://www.caitr.org/internetworking03/registration.htm and follow instructions for registration. The early registration discounts are extremely attractive and are valid till June 1, 2003.
Important Dates:
---------------------
- Early Registration Rates Cut-Off Date: Sept 30
- Tutorials: Oct 27, 1:00-6:00 pm
- Conference sessions: October 28-29 8:30am-6:00pm
Program:
-------------
(visit http://www.caitr.org/internetworking03/program.htm for abstracts and speaker details)
Sunday June 22
    Tutorial-1: MPLS VPNs 
    Tutorial-2: IPv6 
    Tutorial-3: Mobile Wireless Internet Architecture and Protocols
    Tutorial-4: Voice over Packet 
Monday June 23
    Welcome and Keynote 
    Session: Network Technology Trends
      - Forwarding Element and Control Separation
      - Evolution of Inter-Domain Routing
      - Network Processing Building Blocks: Enabling the Routers of the Future
    Session: Network Architecture
      - An architecture for IPv6 VPNs and IPv6 transport over MPLS/GMPLS multiservice backbones IPv6
      - A new routing architecture: Atomised Routing
      - Internetworking MPLS Layer 2 Transport with an IP Services Network
    Session: Storage Area Networks
      - Storage as a Network Node
      - Object-Based Storage
      - Design, Implementation, and Performance Analysis of the iSCSI Protocol for SCSI over TCP/IP
      - SANs Considerations
 
    Session: Mobile & Wireless Networks
      - CertBU: Certificate-based Techniques for Securing Mobile IPv6 Binding Updates IPv6
      - Challenges and Roadmap of UMTS Network Deployment
      - Inter-working Mobile IPv6 with IP Multimedia Subsystem in UMTS 
      - Mobile Authentication and QoS 
      - Mobile Handoff Technologies 
Tuesday June 24
    Session: Inter-Domain Routing
      - Optimizing Route Convergence
      - Traceroute and BGP AS Path Incongruities 
      - Domain Constrained Multicast: A New Approach for IP Multicast Routing
 
    Session: Applications & Services
     -  Securing the Web with Next Generation Encryption Technologies
     - Impact of the live radio on the Internet, and the real-time streaming audio, in the ComUNITY cable system from Com21
     - A novel EAC semantic for the RTSP protocol
     - Towards an end-to-end architecture integrating new Transport and IP services in a DiffServ Internet
 
    Session: Network Management & Planning
     -  Pseudowire OAM: A Mandatory Yet Often Overlooked Feature 
     - A Multicommodity Flow Formulation for the MPLS Layout Design: Reduced Complexity Layout and Minimum Relayout Probems
     - Design Of Fast Fault Restoration System For WDM Networks
     - Cross-domain multimedia service provisioning, the EVOLUTE solution
 
    Session: QoS Based Routing
     - QoS Routing in Networks with Non-Deterministic Information
     - Active Dynamic Routing
     - QoS routing for Differentiated Services: simulations and prototype experiments
     - Probabilistic routing for QoS improvement in GPS networks
     - Fluid flow network modeling for hop-by-hop feedback control design and analysis
 
We look forward to seeing you at the Conference.
Regards,
 Conference Technical Co-chairs:
 - Dr. Maurice Gagnaire, ENST, France
 - Daniel Awduche
 Technical Program Committee of the Internetworking 2003 Conference:
 - Roberto Sabella, Erisson
 - Dr. Moshe Zukerman, Univ. of Melbourne
 - Nada Golmie, NIST
 - Dr. Guy Pujolle, LIP6, France
 - Dr. Samir Tohme, ENST, France
 - Stefano Trumpy, Italian National Research Council
 - Dr. Ibrahim Habib, City Univ. of NY
 - Dr. Marc Lobelle, UCL University, Belgium
 - Dr. Parviz Yegani, Cisco Systems
 - Dr. G.S. Kuo
 - Dr. Abbas Jamalipour, Univ. of Sydney
 - Dr. Hussein Mouftah, Univ. of Ottawa
 - James Kempf
 - Elizabeth Rodriguez
 - Dr. Ferit Yegenoglu, Isocore
 - Dr. Ali Zadeh, George Mason University
 - Dr. Tony Przygienda, Xebeo
 - Ran Canetti, IBM

 
--0-2024752007-1052153359=:50316-- From owner-aaa-wg@merit.edu Sun May 11 01:09:58 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15980 for ; Sun, 11 May 2003 01:09:58 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id AA99591239; Sun, 11 May 2003 01:12:44 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8275B9123A; Sun, 11 May 2003 01:12:44 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7E74491239 for ; Sun, 11 May 2003 01:12:43 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 652F15DE5A; Sun, 11 May 2003 01:12:43 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from c000.snv.cp.net (h008.c000.snv.cp.net [209.228.32.72]) by segue.merit.edu (Postfix) with SMTP id D91E65DE59 for ; Sun, 11 May 2003 01:12:42 -0400 (EDT) Received: (cpmta 16017 invoked from network); 10 May 2003 22:12:41 -0700 Received: from 24.147.218.40 (HELO dmitton.mitton.com) by smtp.mitton.com (209.228.32.72) with SMTP; 10 May 2003 22:12:41 -0700 X-Sent: 11 May 2003 05:12:41 GMT Message-Id: <5.2.1.1.2.20030511010525.02f3d720@mail.attbi.com> X-Sender: david@getmail.mitton.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Sun, 11 May 2003 01:10:31 -0400 To: aaa-wg@merit.edu From: David Mitton Subject: [AAA-WG]: Interim updates for Diameter Nasreq Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk Folks, I have posted an interim update to Diameter Nasreq at the URL below. http://www.circularnetworks.com/draft-ietf-aaa-diameter-nasreq-12a.txt This version deals with many of the issues raised in issues #402, 403, & 404. I will also post detailed responses in seperate messages. http://www.drizzle.com/~aboba/AAA/issues.html There are still some pending issues to be resolved. I will address them soon, but I wanted to get some of the progress and discussion visible. Thanks, Dave. From owner-aaa-wg@merit.edu Sun May 11 01:32:28 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16324 for ; Sun, 11 May 2003 01:32:28 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A8FE09123C; Sun, 11 May 2003 01:35:13 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 627BA9123D; Sun, 11 May 2003 01:35:13 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5B5D79123C for ; Sun, 11 May 2003 01:35:10 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 40ABE5DE68; Sun, 11 May 2003 01:35:10 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from c000.snv.cp.net (h001.c000.snv.cp.net [209.228.32.65]) by segue.merit.edu (Postfix) with SMTP id C58635DE3E for ; Sun, 11 May 2003 01:35:09 -0400 (EDT) Received: (cpmta 15249 invoked from network); 10 May 2003 22:35:08 -0700 Received: from 24.147.218.40 (HELO dmitton.mitton.com) by smtp.mitton.com (209.228.32.65) with SMTP; 10 May 2003 22:35:08 -0700 X-Sent: 11 May 2003 05:35:08 GMT Message-Id: <5.2.1.1.2.20030511012929.031ebaa0@mail.attbi.com> X-Sender: david@getmail.mitton.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Sun, 11 May 2003 01:34:50 -0400 To: aaa-wg@merit.edu From: David Mitton Subject: [AAA-WG]: RE: Issue 404: NASREQ-11 Issues Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk Responses embedded starting with DJM: ---- Issue 404: NASREQ-11 Issues Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: March 11, 2003 Reference: Document: NASREQ-11 Comment type: Technical Priority: S Section: Various Rationale/Explanation of issue: Section 1 " This document describes Diameter applications that are used for AAA in the Network Access Server (NAS) environment." Doesn't the document just describe a single application? Suggested change: "This document describes the Diameter NAS application, which, when combined...." DJM: the word "application" was being overloaded between a Diameter protocol extention, and a computer application program. I've rewritten to be more qualitative. Section 1.2 "1.2. Advertising Application Support Diameter nodes conforming to this specification MAY advertise support by including the value of one (1) in the Auth-Application-Id or the Acct-Application-Id AVP of the Capabilities-Exchange-Request and Capabilities-Exchange-Answer commands [Base]." Isn't advertisement mandatory? Shouldn't the MAY be a MUST? DJM: done - why did no one see this before? Section 2 " Unlike the RADIUS protocol [RADIUS], the Diameter protocol does not require authentication information to be contained in a request from the client. Therefore, it is possible to send a request for authorization only. The type of service depends upon the Auth- Request-Type AVP. This difference MAY cause operational issues in environments that need RADIUS interoperability, and it MAY be necessary that protocol conversion gateways add authentication information when transmitting to a RADIUS server." The RADIUS protocol doesn't require authentication information to be included in a Call-Check, so this isn't accurate. The use of a capital MAY is inappropriate. Adding authentication information in a gateway seems questionable security-wise. Rewrite to: "The Diameter protocol allows authorization-only requests depending on the Auth-Request-Type AVP, where no authentication information is contained in a request from the client. This capability goes beyond the Call Check capabilities described in Section 5.6 of [RADIUS] in that no access decision is requested. As a result, service cannot be started as a result of a response to an authorization-only request without introducing a significant security vulnerability. Since no equivalent capability exists in RADIUS, authorization-only requests from a NAS implementing Diameter may not be easily translated to an equivalent RADIUS message by a Diameter/RADIUS gateway. For example, where a Diameter authorization-only request cannot be translated to a RADIUS Call Check, it would be necessary for the Diameter/RADIUS gateway to add authentication information to the RADIUS Access Request. On receiving the Access-Reply, the Diameter/RADIUS gateway would need to discard the access decision (Accept/Reject). It is not clear that these translations can be accomplished without adding significant security vulnerabilities." DJM: text incorporated Section 2.2 "A Diameter server informs the NAS of the maximum time allowed before re-authentication or re-authorization via the Authorization-Lifetime AVP [Base]. Note, however, that the Authorization-Lifetime AVP SHOULD NOT be used if the AAR message contained a NAS-IP-Address, NAS-IPv6-Address, or NAS- Identifier AVP since this would mean that the NAS is using RADIUS which does not support server-initiated re-authentication or re- authorization." The 2nd sentence is correct, but it doesn't follow from the first. The issue is not that the Diameter server informs the NAS of the maximum time allowed; after all, this is what RADIUS does. The issue is the ability to handle a server-initiated re-authentication or re-authorization. This paragraph confuses the two issues. Rewrite to: "A Diameter server informs the NAS of the maximum time allowed before re-authentication or re-authorization via the Authorization-Lifetime AVP [Base]. A NAS MUST re-authenticate and/or re-authorize after the period provided by the Authorization-Lifetime AVP. Furthermore, it is possible for Diameter servers to issue an unsolicited re-authentication and/or re-authorization requests (e.g. Re-Auth-Request (RAR) message) to the NAS. Upon receipt of such a message, the NAS issues a request to re-authenticate and/or re-authorize the client." See Issue 405 for additional discussion on this. DJM: text incorporated Section 3.1 " It is possible for a single session to be authorized first, then followed by an authentication request." It would help to provide an example of when this would be desirable. Unfortunately, I can't think of any. ; Sun, 11 May 2003 03:34:22 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id ED93D9123B; Sun, 11 May 2003 03:36:47 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BB4119123D; Sun, 11 May 2003 03:36:46 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 94BC69123B for ; Sun, 11 May 2003 03:36:45 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 77A165DEC6; Sun, 11 May 2003 03:36:45 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by segue.merit.edu (Postfix) with ESMTP id 3F1E15DEBB for ; Sun, 11 May 2003 03:36:45 -0400 (EDT) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 16DF96A906; Sun, 11 May 2003 10:36:43 +0300 (EEST) Message-ID: <3EBDFD39.701@kolumbus.fi> Date: Sun, 11 May 2003 10:35:21 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030313 X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Mitton Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: RE: Issue 404: NASREQ-11 Issues References: <5.2.1.1.2.20030511012929.031ebaa0@mail.attbi.com> In-Reply-To: <5.2.1.1.2.20030511012929.031ebaa0@mail.attbi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit David Mitton wrote: > I believe that it would be useful to talk about translation of > unsolicited disconnect > or change of filters messages to their RADIUS equivalents, defined in > [DynAuth]. > > DJM: Groan... Open for now. Isn't DynAUth an Internet-Draft? How stable is it, and how appropriate would it be for us to document in an RFC how convert to draft protocol? I do see this as important, actually. But I'm wondering if we should publish this one separately. Or is it very easy? If it can be done easily, maybe we should do it now. Otherwise, it might make more sense to produce a different document, a companion to DynAuth, that would explain it. --Jari From owner-aaa-wg@merit.edu Sun May 11 09:15:45 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03486 for ; Sun, 11 May 2003 09:15:45 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3ED9391240; Sun, 11 May 2003 09:18:32 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D44C49123E; Sun, 11 May 2003 09:18:31 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6360991240 for ; Sun, 11 May 2003 09:18:23 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 367FF5E02E; Sun, 11 May 2003 09:18:23 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 5F6895E02B for ; Sun, 11 May 2003 09:18:22 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h4BCvKH01543; Sun, 11 May 2003 05:57:20 -0700 Date: Sun, 11 May 2003 05:57:20 -0700 (PDT) From: Bernard Aboba To: Jari Arkko Cc: David Mitton , aaa-wg@merit.edu Subject: Re: [AAA-WG]: RE: Issue 404: NASREQ-11 Issues In-Reply-To: <3EBDFD39.701@kolumbus.fi> Message-ID: References: <5.2.1.1.2.20030511012929.031ebaa0@mail.attbi.com> <3EBDFD39.701@kolumbus.fi> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > Isn't DynAUth an Internet-Draft? How stable is it, and how appropriate > would it be for us to document in an RFC how convert to draft protocol? As I understand it draft-chiba-radius-dynamic-authorization-18.txt has incorporated all IESG comments and is awaiting final approval for publication. So it is stable. However, the conversion between RADIUS and Diameter is tricky as described below. My concern is that we might have to fix NASREQ or draft-chiba to make conversation possible, and if we don't think this through now, there will be a "gotcha" that would make it hard/impossible. > I do see this as important, actually. But I'm wondering if we should > publish this one separately. Or is it very easy? I believe that it's important for deployment of Diameter. draft-chiba is already in widespread use and given the number of NASes that support RADIUS, if Diameter/RADIUS translation is not possible then Diameter will be undeployable wherever draft-chiba is used. Here are the issues that arise: a. Diameter NAS talking to a RADIUS server via a Diameter/RADIUS gateway. The gateway copies the identification attributes from the CoA or Disconnect Request into a Diameter disconnect or reauthorization request. NASREQ should support the same identification attributes as draft-chiba to make this easy -- we need an ABNF for disconnect or reauthorization requests in NASREQ to make this clear. The Diameter NAS then sends a re- authorization or termination request. I'd suggest that the termination request be translated to a Disconnect-ACK in RADIUS, with the Diameter gateway providing a response in Diameter. The re-authorization request should be translated to a CoA-ACK in RADIUS, with the authorization change attributes being inserted into the re-authorization response. The other alternative is to try to translate the Diameter re-authorization request into something like a RADIUS "call check" -- but I think that within draft-chiba it is necessary to receive a CoA-NAK or ACK as a response, not just a "call check" Request. b. RADIUS NAS talking to a Diameter server via a Diameter/RADIUS gateway. Here the Diameter server sends a CoA or disconnect request. The gateway translates a Diameter disconnect request into a RADIUS Disconnect-Request by using the same identification attributes in both. The gateway then receives a Disconnect-ACK from the RADIUS NAS and translates this to a Diameter disconnect request; the Diameter server responds with a disconnect response and the gateway throws this away (doesn't need to be translated). A Diameter CoA request is somewhat trickier, because it only contains identification attributes. I think the gateway needs to reply with a Diameter re-authorization request, without sending any packet to the RADIUS NAS. After receiving the Diameter re-authorization response, the gateway can issue a CoA-Request to the RADIUS NAS by copying both the identification and authorization attributes into the CoA-Request. The gateway then receives a CoA-ACK or CoA-NAK and discards this because it isn't translatable. This is a bit of a problem because the Diameter server will believe that its request was honored while it may not have been. Translation between Diameter and RADIUS is made considerably simpler if We were to support an (optional) sequence more akin to Diameter in draft-chiba. For example, a Request with a Service-Type of "Reauthorization" would be interpretted purely as a identification of a session that needs to be re-authorized, or disconnected. The RADIUS NAS would then respond with a NAK to acknowledge receipt, including an Error-Cause attribute saying "In progress", and would then send an Access-Request. This makes case a) simpler because presumably the RADIUS server would use this sequence when talking to a Diameter NAS. Case b) is also simpler because the Diameter messages now are more easily translated to RADIUS equivalents. > If it can be done easily, maybe we should do it now. It can be done easily *if* we make the above change to draft-chiba. > Otherwise, it might make more > sense to produce a different document, a companion to DynAuth, that > would explain it. If we issue DynAuth now with no changes, translation could prove impractical for the reasons cited above. I don't believe that this is something we can put off. From owner-aaa-wg@merit.edu Sun May 11 12:00:39 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07216 for ; Sun, 11 May 2003 12:00:39 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0E4239121C; Sun, 11 May 2003 12:03:27 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C2C589123D; Sun, 11 May 2003 12:03:16 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E7BCE9121C for ; Sun, 11 May 2003 12:03:04 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C3A395E0F2; Sun, 11 May 2003 12:03:04 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 437555E0F0 for ; Sun, 11 May 2003 12:03:04 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h4BFg1f10723; Sun, 11 May 2003 08:42:02 -0700 Date: Sun, 11 May 2003 08:42:01 -0700 (PDT) From: Bernard Aboba To: Jari Arkko Cc: David Mitton , aaa-wg@merit.edu Subject: Re: [AAA-WG]: RE: Issue 404: NASREQ-11 Issues In-Reply-To: <3EBDFD39.701@kolumbus.fi> Message-ID: References: <5.2.1.1.2.20030511012929.031ebaa0@mail.attbi.com> <3EBDFD39.701@kolumbus.fi> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > Isn't DynAUth an Internet-Draft? How stable is it, and how appropriate > would it be for us to document in an RFC how convert to draft protocol? I've gone through draft-chiba and identified modifications required to enable translation by a Diameter/RADIUS gateway. This requires addition of a Service-Type with value "Authorize Only" to both Disconnect/CoA messages as well as to a RADIUS Access-Request. A version of the draft with the potential changes included is available for inspection here: http://www.drizzle.com/~aboba/IEEE/draft-chiba-radius-dynamic-authorization-19.txt If people think these potential changes represent a useful addition, I can update draft-chiba to include them. From owner-aaa-wg@merit.edu Sun May 11 13:54:41 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09076 for ; Sun, 11 May 2003 13:54:40 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 645A69123E; Sun, 11 May 2003 13:57:16 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 27E139123F; Sun, 11 May 2003 13:57:16 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 098CC9123E for ; Sun, 11 May 2003 13:57:14 -0400 (EDT) Received: by segue.merit.edu (Postfix) id DF1E45E14F; Sun, 11 May 2003 13:57:14 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by segue.merit.edu (Postfix) with ESMTP id A47565E14E for ; Sun, 11 May 2003 13:57:14 -0400 (EDT) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id A41436A904; Sun, 11 May 2003 20:57:13 +0300 (EEST) Message-ID: <3EBE8EA6.30502@kolumbus.fi> Date: Sun, 11 May 2003 20:55:50 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030313 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba Cc: David Mitton , aaa-wg@merit.edu Subject: Re: [AAA-WG]: RE: Issue 404: NASREQ-11 Issues References: <5.2.1.1.2.20030511012929.031ebaa0@mail.attbi.com> <3EBDFD39.701@kolumbus.fi> In-Reply-To: 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 Bernard Aboba wrote: > I believe that it's important for deployment of Diameter. draft-chiba is > already in widespread use and given the number of NASes that support > RADIUS, if Diameter/RADIUS translation is not possible then Diameter will > be undeployable wherever draft-chiba is used. Ok, I'm now convinced we need to do it. > Translation between Diameter and RADIUS is made considerably simpler if > We were to support an (optional) sequence more akin to Diameter in draft-chiba. > For example, a Request with a Service-Type of "Reauthorization" would be > interpretted purely as a identification of a session that needs to be > re-authorized, or disconnected. The RADIUS NAS would then respond with > a NAK to acknowledge receipt, including an Error-Cause attribute > saying "In progress", and would then send an Access-Request. > > This makes case a) simpler because presumably the RADIUS server would use > this sequence when talking to a Diameter NAS. Case b) is also simpler > because the Diameter messages now are more easily translated to RADIUS > equivalents. > > >>If it can be done easily, maybe we should do it now. > > > It can be done easily *if* we make the above change to draft-chiba. We need to talk to the authors of draft-chiba to see if the change is feasible in their opinion. --Jari From owner-aaa-wg@merit.edu Sun May 11 14:00:52 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09182 for ; Sun, 11 May 2003 14:00:52 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 352D69123F; Sun, 11 May 2003 14:03:35 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F106591241; Sun, 11 May 2003 14:03:34 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C0DDD9123F for ; Sun, 11 May 2003 14:02:20 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 996585E14E; Sun, 11 May 2003 14:02:20 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by segue.merit.edu (Postfix) with ESMTP id 531D85DFDA for ; Sun, 11 May 2003 14:02:20 -0400 (EDT) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 5526C6A904; Sun, 11 May 2003 21:02:19 +0300 (EEST) Message-ID: <3EBE8FD8.4080807@kolumbus.fi> Date: Sun, 11 May 2003 21:00:56 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030313 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba Cc: David Mitton , aaa-wg@merit.edu Subject: Re: [AAA-WG]: RE: Issue 404: NASREQ-11 Issues References: <5.2.1.1.2.20030511012929.031ebaa0@mail.attbi.com> <3EBDFD39.701@kolumbus.fi> In-Reply-To: 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 Bernard Aboba wrote: > I've gone through draft-chiba and identified modifications required to > enable translation by a Diameter/RADIUS gateway. This requires addition > of a Service-Type with value "Authorize Only" to both Disconnect/CoA > messages as well as to a RADIUS Access-Request. A version of the draft > with the potential changes included is available for inspection here: > > http://www.drizzle.com/~aboba/IEEE/draft-chiba-radius-dynamic-authorization-19.txt > > If people think these potential changes represent a useful addition, I can > update draft-chiba to include them. Great! I didn't realize it was so easy for you to talk to the authors of draft-chiba ;-) I haven't looked at the modifications yet, but I recall that you said it has been deployed, will there be problems because of this change? --Jari From owner-aaa-wg@merit.edu Sun May 11 14:33:22 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09649 for ; Sun, 11 May 2003 14:33:22 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4601791241; Sun, 11 May 2003 14:36:08 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 19BAE91242; Sun, 11 May 2003 14:36:08 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2A17791241 for ; Sun, 11 May 2003 14:36:07 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 120415E187; Sun, 11 May 2003 14:36:07 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 7F3A35E189 for ; Sun, 11 May 2003 14:36:06 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h4BIF4u19406; Sun, 11 May 2003 11:15:04 -0700 Date: Sun, 11 May 2003 11:15:03 -0700 (PDT) From: Bernard Aboba To: Jari Arkko Cc: David Mitton , aaa-wg@merit.edu Subject: Re: [AAA-WG]: RE: Issue 404: NASREQ-11 Issues In-Reply-To: <3EBE8FD8.4080807@kolumbus.fi> Message-ID: References: <5.2.1.1.2.20030511012929.031ebaa0@mail.attbi.com> <3EBDFD39.701@kolumbus.fi> <3EBE8FD8.4080807@kolumbus.fi> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > I haven't looked at the modifications yet, but I recall that you > said it has been deployed, will there be problems because of this > change? The changes have to be optional. But presumably an operator who really needs Diameter compatibility will demand support from their NAS vendor. My understsanding is that 3GPP2 is looking at requiring draft-chiba, and if they want to be able to transition to Diameter at some future point, then I think that implementing the (optional) changes is a good idea. From owner-aaa-wg@merit.edu Mon May 12 06:15:23 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06983 for ; Mon, 12 May 2003 06:15:23 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8650691248; Mon, 12 May 2003 06:18:07 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 53F2391249; Mon, 12 May 2003 06:18:07 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 318CF91248 for ; Mon, 12 May 2003 06:18:06 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1D9395E273; Mon, 12 May 2003 06:18:06 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by segue.merit.edu (Postfix) with ESMTP id 64A395E25A for ; Mon, 12 May 2003 06:18:05 -0400 (EDT) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h4CAI3D29101 for ; Mon, 12 May 2003 13:18:03 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 12 May 2003 13:18:03 +0300 Received: from esebe008.NOE.Nokia.com ([172.21.138.48]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 12 May 2003 13:18:03 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe008.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 12 May 2003 13:18:02 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: RE: Issue 404: NASREQ-11 Issues Date: Mon, 12 May 2003 13:18:01 +0300 Message-ID: Thread-Topic: [AAA-WG]: RE: Issue 404: NASREQ-11 Issues Thread-Index: AcMX1uXTzyOW53Y1SSGRv7WMHnYmxAAmMqcA From: To: Cc: X-OriginalArrivalTime: 12 May 2003 10:18:02.0882 (UTC) FILETIME=[C5673E20:01C3186F] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA06983 Bernard, > I've gone through draft-chiba and identified modifications required to > enable translation by a Diameter/RADIUS gateway. This requires addition > of a Service-Type with value "Authorize Only" to both Disconnect/CoA > messages as well as to a RADIUS Access-Request. A version of the draft > with the potential changes included is available for inspection here: > > http://www.drizzle.com/~aboba/IEEE/draft-chiba-radius-dynamic-authorization-19.txt > > If people think these potential changes represent a useful > addition, I can update draft-chiba to include them. I think that this would be useful, I support updating the draft to support it. John From owner-aaa-wg@merit.edu Tue May 13 09:41:58 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11810 for ; Tue, 13 May 2003 09:41:58 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 08A4B91280; Tue, 13 May 2003 09:44:47 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BFFAB91281; Tue, 13 May 2003 09:44:46 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C072191280 for ; Tue, 13 May 2003 09:44:45 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A850E5E144; Tue, 13 May 2003 09:44:45 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 39A9C5E124 for ; Tue, 13 May 2003 09:44:45 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h4DDNaq02453 for ; Tue, 13 May 2003 06:23:36 -0700 Date: Tue, 13 May 2003 06:23:36 -0700 (PDT) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: Call for Interest: Diameter EAP and CMS Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Over the last 18 months, we have not made much progress on the Diameter EAP or Diameter CMS documents. I'd therefore like to try to determine whether there is any real interest in implementing these specifications, or whether we should drop them as WG work items. If you are currently working on an implementation of Diameter EAP or CMS, please respond to this message. From owner-aaa-wg@merit.edu Tue May 13 10:01:45 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12487 for ; Tue, 13 May 2003 10:01:45 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id EFC6C91281; Tue, 13 May 2003 10:04:35 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C136891282; Tue, 13 May 2003 10:04:34 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 90EE291281 for ; Tue, 13 May 2003 10:04:33 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 767EA5DD93; Tue, 13 May 2003 10:04:33 -0400 (EDT) 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 C2E5D5DD8F for ; Tue, 13 May 2003 10:04:32 -0400 (EDT) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h4DE4V720977 for ; Tue, 13 May 2003 17:04:31 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 13 May 2003 17:04:31 +0300 Received: from esebe012.NOE.Nokia.com ([172.21.138.51]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 13 May 2003 17:04:31 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe012.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 13 May 2003 17:04:30 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Call for Interest: Diameter EAP and CMS Date: Tue, 13 May 2003 17:04:30 +0300 Message-ID: Thread-Topic: [AAA-WG]: Call for Interest: Diameter EAP and CMS Thread-Index: AcMZVeNTJonvkZNdT7ua031gjmKT9wAAnQ0w From: To: , X-OriginalArrivalTime: 13 May 2003 14:04:30.0921 (UTC) FILETIME=[92EB3390:01C31958] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA12487 Hi Bernard, > I'd therefore like to try to determine whether there is any real interest > in implementing these specifications, or whether we should drop them as WG > work items. > > If you are currently working on an implementation of Diameter EAP or CMS, > please respond to this message. We're working on an EAP implementation - somewhat a low-priority because the spec has been dragging. We are also working on a number of scenarios which would require it. thanks, John From owner-aaa-wg@merit.edu Tue May 13 13:11:00 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20598 for ; Tue, 13 May 2003 13:11:00 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id AFBE79128A; Tue, 13 May 2003 13:13:46 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7D2619128B; Tue, 13 May 2003 13:13:46 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5F1E39128A for ; Tue, 13 May 2003 13:13:45 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 451585DE0B; Tue, 13 May 2003 13:13:45 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by segue.merit.edu (Postfix) with ESMTP id 0B66C5DDE7 for ; Tue, 13 May 2003 13:13:45 -0400 (EDT) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id D46456A901; Tue, 13 May 2003 20:13:42 +0300 (EEST) Message-ID: <3EC12773.4010401@kolumbus.fi> Date: Tue, 13 May 2003 20:12:19 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030313 X-Accept-Language: en-us, en MIME-Version: 1.0 To: john.loughney@nokia.com Cc: aboba@internaut.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: Call for Interest: Diameter EAP and CMS References: In-Reply-To: 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 john.loughney@nokia.com wrote: > We're working on an EAP implementation - somewhat a low-priority because > the spec has been dragging. We are also working on a number of scenarios > which would require it. Same here. --Jari From owner-aaa-wg@merit.edu Tue May 13 13:34:57 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21452 for ; Tue, 13 May 2003 13:34:56 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0E84D9128B; Tue, 13 May 2003 13:37:45 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CE0769128C; Tue, 13 May 2003 13:37:44 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 959CF9128B for ; Tue, 13 May 2003 13:37:43 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6FEAF5DE21; Tue, 13 May 2003 13:37:43 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by segue.merit.edu (Postfix) with ESMTP id D0CBA5DE23 for ; Tue, 13 May 2003 13:37:42 -0400 (EDT) Received: from tari.research.telcordia.com (tari.research.telcordia.com [207.3.232.66]) by thumper.research.telcordia.com (8.12.9/8.12.9) with ESMTP id h4DHb0ej029992; Tue, 13 May 2003 13:37:01 -0400 (EDT) Received: from localhost (tari.research.telcordia.com [207.3.232.66]) by tari.research.telcordia.com (8.8.8/8.8.8) with ESMTP id NAA17954; Tue, 13 May 2003 13:37:22 -0400 (EDT) Date: Tue, 13 May 2003 10:34:34 -0400 To: Bernard Aboba Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Call for Interest: Diameter EAP and CMS Message-ID: <20030513143434.GD1018@catfish> References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.4i From: Yoshihiro Ohba X-Dispatcher: imput version 20030322(IM144) Lines: 15 X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Sender: owner-aaa-wg@merit.edu Precedence: bulk On Tue, May 13, 2003 at 06:23:36AM -0700, Bernard Aboba wrote: > Over the last 18 months, we have not made much progress on the Diameter > EAP or Diameter CMS documents. > > I'd therefore like to try to determine whether there is any real interest > in implementing these specifications, or whether we should drop them as WG > work items. > > If you are currently working on an implementation of Diameter EAP or CMS, > please respond to this message. > We have a plan to implement Diameter EAP application in Open Diameter. Yoshihiro Ohba From owner-aaa-wg@merit.edu Tue May 13 15:03:27 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24831 for ; Tue, 13 May 2003 15:03:27 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 445F791290; Tue, 13 May 2003 15:06:07 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 15CAB91292; Tue, 13 May 2003 15:06:07 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DDB6391290 for ; Tue, 13 May 2003 15:06:05 -0400 (EDT) Received: by segue.merit.edu (Postfix) id CBD625DE63; Tue, 13 May 2003 15:06:05 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from exch01.bridgewatersys.com (bws10.bridgewatersystems.com [216.113.7.10]) by segue.merit.edu (Postfix) with ESMTP id 5C7415DDF4 for ; Tue, 13 May 2003 15:06:05 -0400 (EDT) Received: by exch01.bridgewatersys.com with Internet Mail Service (5.5.2653.19) id ; Tue, 13 May 2003 15:06:04 -0400 Message-ID: From: Avi Lior To: "'aaa-wg@merit.edu'" Subject: [AAA-WG]: RE: draft-chiba compatibility with Diameter review of Chiba 19 Date: Tue, 13 May 2003 15:06:04 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi All, I reviewed Chiba 19 and have one issue relating to routing. The originator, the entity that wants to make the change may not be the same entity that would receive the Authorize only message. State could be used to help the RADIUS route the message to the destination. Otherwise, all looks okay. Avi Bridgewater Systems Hosts a 4-city Wi-Fi Forum for Service Providers May 7-14, 2003 To learn more about the event and to register please visit: http://www.bridgewatersystems.com/forum From owner-aaa-wg@merit.edu Tue May 13 17:02:57 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29026 for ; Tue, 13 May 2003 17:02:56 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 9A5CC91205; Tue, 13 May 2003 17:05:44 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6A1B991207; Tue, 13 May 2003 17:05:44 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 16F9791205 for ; Tue, 13 May 2003 17:05:43 -0400 (EDT) Received: by segue.merit.edu (Postfix) id EE9825DE99; Tue, 13 May 2003 17:05:42 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from exch01.bridgewatersys.com (bws10.bridgewatersystems.com [216.113.7.10]) by segue.merit.edu (Postfix) with ESMTP id 7BBD45DE95 for ; Tue, 13 May 2003 17:05:42 -0400 (EDT) Received: by exch01.bridgewatersys.com with Internet Mail Service (5.5.2653.19) id ; Tue, 13 May 2003 17:05:41 -0400 Message-ID: From: Avi Lior To: "'Murtaza S. Chiba'" , "'Bernard Aboba'" Cc: Avi Lior , "'aaa-wg@merit.edu'" , "'gdommety@cisco.com'" , "'meklund@cisco.com'" , "'david@mitton.com'" , "'iesg@ietf.org'" , "'jari.arkko@piuha.net'" Subject: [AAA-WG]: RE: draft-chiba compatibility with Diameter review of Chiba 19 Date: Tue, 13 May 2003 17:05:41 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-aaa-wg@merit.edu Precedence: bulk The State attribute allows me to tie the two messages together. It is opque outside the home network. But within we can use it to route the message, to the correct server. The question of trust has nothing to do with the State it's a more general issue. The Access Request message will always be routed to the home network based on the username attribute. The Access Accept message should therefore be trusted, no? > -----Original Message----- > From: Murtaza S. Chiba [mailto:mchiba@cisco.com] > Sent: May 13, 2003 4:56 PM > To: Bernard Aboba > Cc: Avi Lior; 'aaa-wg@ietf.org'; 'gdommety@cisco.com'; > 'meklund@cisco.com'; 'david@mitton.com'; 'iesg@ietf.org'; > 'jari.arkko@piuha.net' > Subject: Re: draft-chiba compatibility with Diameter review > of Chiba 19 > > > Bernard Aboba wrote: > >>Hi ALl, > >> If I understand this correctly the Authorize-Only > triggers the NAS to > >>send an Access-Request (after the NAK). Since, username contains > >>domain, this is not enough as a domain could have multiple > servers for > >>redundancy and this request needs to go back to a > particular server(?) > >>and hence we need the State attribute? > > > > > > It is possible that the State Attribute will be needed. Use is > > optional. > > > > > Fair enough, but I am trying to understand the usefulness of > the State > Attribute. What specific problem does its use solve? Also, if the > originator is not the recipient of the Access-Request, then > the security > implications need to be worked out, ie. do you trust the > Access-Accept? > Maybe it SHOULD be restricted to the originator?? > > THanks, > Murtaza > > Bridgewater Systems Hosts a 4-city Wi-Fi Forum for Service Providers May 7-14, 2003 To learn more about the event and to register please visit: http://www.bridgewatersystems.com/forum From owner-aaa-wg@merit.edu Tue May 13 20:15:14 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04813 for ; Tue, 13 May 2003 20:15:14 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E1C4B91207; Tue, 13 May 2003 20:17:58 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AB5D891208; Tue, 13 May 2003 20:17:57 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id EB8D991207 for ; Tue, 13 May 2003 20:17:55 -0400 (EDT) Received: by segue.merit.edu (Postfix) id CEB7B5DF0C; Tue, 13 May 2003 20:17:55 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from cms4.etri.re.kr (cms4.etri.re.kr [129.254.16.14]) by segue.merit.edu (Postfix) with ESMTP id 2C4135DEB6 for ; Tue, 13 May 2003 20:17:50 -0400 (EDT) Received: by cms4.etri.re.kr with Internet Mail Service (5.5.2653.19) id ; Wed, 14 May 2003 09:13:11 +0900 Message-ID: <63CCC1EB21D5D511A2DF00D0B7A8DCBD0A3654@cms4.etri.re.kr> From: dhchoi@etri.re.kr To: aboba@internaut.com, aaa-wg@merit.edu Subject: RE: [AAA-WG]: Call for Interest: Diameter EAP and CMS Date: Wed, 14 May 2003 09:13:09 +0900 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C319AD.99F54310" 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_01C319AD.99F54310 Content-Type: text/plain; charset="iso-2022-kr" -----Original Message----- From: Bernard Aboba [mailto:aboba@internaut.com] Sent: Tuesday, May 13, 2003 10:24 PM To: aaa-wg@merit.edu Subject: [AAA-WG]: Call for Interest: Diameter EAP and CMS Over the last 18 months, we have not made much progress on the Diameter EAP or Diameter CMS documents. I'd therefore like to try to determine whether there is any real interest in implementing these specifications, or whether we should drop them as WG work items. If you are currently working on an implementation of Diameter EAP or CMS, please respond to this message. Hi, We are seriously working on an implementation of Diameter EAP AND CMS... Doo Ho Choi ETRI ------_=_NextPart_001_01C319AD.99F54310 Content-Type: text/html; charset="iso-2022-kr" RE: [AAA-WG]: Call for Interest: Diameter EAP and CMS

-----Original Message-----
From: Bernard Aboba [mailto:aboba@internaut.com]
Sent: Tuesday, May 13, 2003 10:24 PM
To: aaa-wg@merit.edu
Subject: [AAA-WG]: Call for Interest: Diameter EAP and CMS


Over the last 18 months, we have not made much progress on the Diameter
EAP or Diameter CMS documents.

I'd therefore like to try to determine whether there is any real interest
in implementing these specifications, or whether we should drop them as WG
work items.

If you are currently working on an implementation of Diameter EAP or CMS,
please respond to this message.


Hi,
We are seriously working on an implementation of Diameter EAP AND CMS...

Doo Ho Choi
ETRI

------_=_NextPart_001_01C319AD.99F54310-- From owner-aaa-wg@merit.edu Wed May 14 10:08:22 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18812 for ; Wed, 14 May 2003 10:08:22 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5A5EE9129A; Wed, 14 May 2003 10:11:04 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 25B7491299; Wed, 14 May 2003 10:11:04 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E38349129A for ; Wed, 14 May 2003 10:11:02 -0400 (EDT) Received: by segue.merit.edu (Postfix) id CBCE95E0E4; Wed, 14 May 2003 10:11:02 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by segue.merit.edu (Postfix) with ESMTP id 652185E0D7 for ; Wed, 14 May 2003 10:11:02 -0400 (EDT) Received: from mr7.exu.ericsson.se (mr7att.ericy.com [138.85.224.158]) by imr2.ericy.com (8.12.9/8.12.9) with ESMTP id h4EEAwnS026300 for ; Wed, 14 May 2003 09:10:58 -0500 (CDT) Received: from noah.lmc.ericsson.se (noah.lmc.ericsson.se [142.133.1.1]) by mr7.exu.ericsson.se (8.12.9/8.12.9) with ESMTP id h4EEAwev011507 for ; Wed, 14 May 2003 09:10:58 -0500 (CDT) Received: from EAMMLEX034.lmc.ericsson.se (eammlex034.lmc.ericsson.se [142.133.1.134]) by noah.lmc.ericsson.se (8.11.2/8.9.2) with ESMTP id h4EEAwh05752 for ; Wed, 14 May 2003 10:10:58 -0400 (EDT) Received: by eammlex034.lmc.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Wed, 14 May 2003 10:10:57 -0400 Message-ID: <7B2A7784F4B7F0409947481F3F3FEF830A082A34@eammlex037.lmc.ericsson.se> From: "Kevin Purser (LMC)" To: aaa-wg@merit.edu Subject: RE: [AAA-WG]: Call for Interest: Diameter EAP and CMS Date: Wed, 14 May 2003 10:10:55 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk We also have an existing implementation of NASREQ, which we implemented when the spec still included EAP. We do use the EAP functionality in our prototyping activities- just haven't separated it out into it's own app due to lack of time/resources, as well as the pending state of the draft. Kev > -----Original Message----- > From: Bernard Aboba [mailto:aboba@internaut.com] > Sent: Tuesday, May 13, 2003 9:24 AM > To: aaa-wg@merit.edu > Subject: [AAA-WG]: Call for Interest: Diameter EAP and CMS > > > Over the last 18 months, we have not made much progress on > the Diameter > EAP or Diameter CMS documents. > > I'd therefore like to try to determine whether there is any > real interest > in implementing these specifications, or whether we should > drop them as WG > work items. > > If you are currently working on an implementation of Diameter > EAP or CMS, > please respond to this message. > From owner-aaa-wg@merit.edu Thu May 15 15:26:37 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20588 for ; Thu, 15 May 2003 15:26:37 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id F415091231; Thu, 15 May 2003 15:29:27 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C1AE1912C8; Thu, 15 May 2003 15:29:26 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DC47791231 for ; Thu, 15 May 2003 15:29:25 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C52F95E02B; Thu, 15 May 2003 15:29:25 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 5BF9B5E028 for ; Thu, 15 May 2003 15:29:25 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h4FJ83M21432 for ; Thu, 15 May 2003 12:08:03 -0700 Date: Thu, 15 May 2003 12:08:03 -0700 (PDT) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: Re: Call for Interest Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Thanks for responding. It appears that there is interest in proceeding with Diameter EAP, but potentially not sufficient interest to continue work on Diameter CMS. To qualify for continued work, it would be good if we had at least two potential people interested implementing CMS. From owner-aaa-wg@merit.edu Thu May 15 16:28:43 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22206 for ; Thu, 15 May 2003 16:28:42 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8618C91224; Thu, 15 May 2003 16:30:18 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 59B849122F; Thu, 15 May 2003 16:30:18 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9CE7B91224 for ; Thu, 15 May 2003 16:30:16 -0400 (EDT) Received: by segue.merit.edu (Postfix) id AE7725E068; Thu, 15 May 2003 16:30:13 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by segue.merit.edu (Postfix) with ESMTP id 2B0FC5DE2B for ; Thu, 15 May 2003 16:30:13 -0400 (EDT) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 161866A902; Thu, 15 May 2003 23:30:11 +0300 (EEST) Message-ID: <3EC3F87F.7060106@kolumbus.fi> Date: Thu, 15 May 2003 23:28:47 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030313 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Re: Call for Interest References: In-Reply-To: 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 Bernard Aboba wrote: > Thanks for responding. It appears that there is interest in proceeding > with Diameter EAP, but potentially not sufficient interest to continue > work on Diameter CMS. To qualify for continued work, it would be good if > we had at least two potential people interested implementing CMS. The answers to the CMS query might be more interesting if some of the potential relationships between the documents would be highlighted ;-) Do you think key transport over DIAMETER EAP will require CMS? And if someone answered YES for DIAMETER EAP, is that someone going to use his implementation in setting up e.g. link encryption keys for WLAN? --Jari From owner-aaa-wg@merit.edu Thu May 15 17:00:11 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22948 for ; Thu, 15 May 2003 17:00:11 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 97A8F912C9; Thu, 15 May 2003 17:02:21 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E8BA5912CB; Thu, 15 May 2003 17:02:20 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A62B4912C9 for ; Thu, 15 May 2003 17:02:16 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 792B35E065; Thu, 15 May 2003 17:02:16 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 0CA125DEB9 for ; Thu, 15 May 2003 17:02:16 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h4FKeqA05172; Thu, 15 May 2003 13:40:52 -0700 Date: Thu, 15 May 2003 13:40:52 -0700 (PDT) From: Bernard Aboba To: Jari Arkko Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Re: Call for Interest In-Reply-To: <3EC3F87F.7060106@kolumbus.fi> Message-ID: References: <3EC3F87F.7060106@kolumbus.fi> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > Do you think key transport over DIAMETER EAP will require CMS? The relevant requirements are here: http://www.drizzle.com/~aboba/IETF56/AAA/AAA-Key-Mgmt.ppt Do you think that CMS is needed to meet them? From owner-aaa-wg@merit.edu Thu May 15 17:10:10 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23187 for ; Thu, 15 May 2003 17:10:10 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 41350912CB; Thu, 15 May 2003 17:12:58 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DDD8A912CC; Thu, 15 May 2003 17:12:56 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DA67E912CB for ; Thu, 15 May 2003 17:12:55 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C23CE5E07D; Thu, 15 May 2003 17:12:55 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by segue.merit.edu (Postfix) with ESMTP id 8768D5DEB9 for ; Thu, 15 May 2003 17:12:55 -0400 (EDT) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 9C1EA6A905; Fri, 16 May 2003 00:12:54 +0300 (EEST) Message-ID: <3EC40283.5020609@kolumbus.fi> Date: Fri, 16 May 2003 00:11:31 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030313 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Re: Call for Interest References: <3EC3F87F.7060106@kolumbus.fi> In-Reply-To: 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 Bernard Aboba wrote: >>Do you think key transport over DIAMETER EAP will require CMS? > > > The relevant requirements are here: > http://www.drizzle.com/~aboba/IETF56/AAA/AAA-Key-Mgmt.ppt > > Do you think that CMS is needed to meet them? Well, it says "select one end-to-end mechanism to protect the distributed keys" and "maintain confidentiality of session keys". Does this mean something CMS-like, or is hbh security also sufficient? --Jari From owner-aaa-wg@merit.edu Thu May 15 17:13:41 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23331 for ; Thu, 15 May 2003 17:13:41 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 98569912CC; Thu, 15 May 2003 17:15:27 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6999C912CD; Thu, 15 May 2003 17:15:27 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 78625912CC for ; Thu, 15 May 2003 17:15:26 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E18375DEB9; Thu, 15 May 2003 17:15:25 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 091BF5E059 for ; Thu, 15 May 2003 17:15:25 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h4FKs1t05950; Thu, 15 May 2003 13:54:01 -0700 Date: Thu, 15 May 2003 13:54:01 -0700 (PDT) From: Bernard Aboba To: Jari Arkko Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Re: Call for Interest In-Reply-To: <3EC40283.5020609@kolumbus.fi> Message-ID: References: <3EC3F87F.7060106@kolumbus.fi> <3EC40283.5020609@kolumbus.fi> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > Well, it says "select one end-to-end mechanism to protect > the distributed keys" and "maintain confidentiality of > session keys". Does this mean something CMS-like, or > is hbh security also sufficient? I'll answer your question with another question: What if only Diameter redirects were present? Then the connections would always be end-to-end and the distinction would vanish, no? From owner-aaa-wg@merit.edu Thu May 15 17:17:01 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23427 for ; Thu, 15 May 2003 17:17:01 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id CB8ED912CD; Thu, 15 May 2003 17:19:46 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 96BA3912CE; Thu, 15 May 2003 17:19:46 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B6500912CD for ; Thu, 15 May 2003 17:18:34 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8C76A5E078; Thu, 15 May 2003 17:18:34 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by segue.merit.edu (Postfix) with ESMTP id 52A0B5DE5D for ; Thu, 15 May 2003 17:18:34 -0400 (EDT) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 5A9D36A905; Fri, 16 May 2003 00:18:33 +0300 (EEST) Message-ID: <3EC403D5.40808@kolumbus.fi> Date: Fri, 16 May 2003 00:17:09 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030313 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Re: Call for Interest References: <3EC3F87F.7060106@kolumbus.fi> <3EC40283.5020609@kolumbus.fi> In-Reply-To: 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 Bernard Aboba wrote: >>Well, it says "select one end-to-end mechanism to protect >>the distributed keys" and "maintain confidentiality of >>session keys". Does this mean something CMS-like, or >>is hbh security also sufficient? > > > I'll answer your question with another question: > > What if only Diameter redirects were present? Then the connections would > always be end-to-end and the distinction would vanish, no? I agree that this would be sufficient. So this would leave us only with the question of whether someone wants to use the non-redirect model and transport session keys, and if so, whether something else is needed to protect that. Or are we recommending that to transport session keys, you should use redirects? --Jari From owner-aaa-wg@merit.edu Thu May 15 18:07:10 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24801 for ; Thu, 15 May 2003 18:07:10 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 84DD3912D3; Thu, 15 May 2003 18:10:00 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5203B912D4; Thu, 15 May 2003 18:10:00 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 66F0C912D3 for ; Thu, 15 May 2003 18:09:59 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 534175E0AB; Thu, 15 May 2003 18:09:59 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id D80215E0AA for ; Thu, 15 May 2003 18:09:58 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h4FLmbZ09028 for ; Thu, 15 May 2003 14:48:37 -0700 Date: Thu, 15 May 2003 14:48:37 -0700 (PDT) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: Diameter EAP: Are Redirects sufficient? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk As a hypothetical, what if Diameter EAP were to strongly discourage use of proxies, and encourage use of redirects instead. Would any important usage scenarios be compromised by such an approach? The advantage of only using redirects if that the Diameter connections would be end-to-end and therefore keys would not be available to intermediaries. This would simplify the security analysis enormously and would allow us to avoid a dependency on CMS, which seems to lack much interest in the WG. From owner-aaa-wg@merit.edu Thu May 15 18:12:16 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25436 for ; Thu, 15 May 2003 18:12:16 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id BAAE5912D1; Thu, 15 May 2003 17:57:10 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8DE4E912D3; Thu, 15 May 2003 17:57:10 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9ABB6912D1 for ; Thu, 15 May 2003 17:57:09 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 888B95E08B; Thu, 15 May 2003 17:57:09 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 0EF095E079 for ; Thu, 15 May 2003 17:57:09 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h4FLZjd08318; Thu, 15 May 2003 14:35:45 -0700 Date: Thu, 15 May 2003 14:35:45 -0700 (PDT) From: Bernard Aboba To: Jari Arkko Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Re: Call for Interest In-Reply-To: <3EC403D5.40808@kolumbus.fi> Message-ID: References: <3EC3F87F.7060106@kolumbus.fi> <3EC40283.5020609@kolumbus.fi> <3EC403D5.40808@kolumbus.fi> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > > What if only Diameter redirects were present? Then the connections would > > always be end-to-end and the distinction would vanish, no? > > I agree that this would be sufficient. > > So this would leave us only with the question of > whether someone wants to use the non-redirect > model and transport session keys, and if so, > whether something else is needed to protect > that. Yes. I would like to understand the deployment scenarios for Diameter EAP, and whether keys really need to pass through intermediaries, before doing work to protect keys from intermediaries. From owner-aaa-wg@merit.edu Thu May 15 19:35:16 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27393 for ; Thu, 15 May 2003 19:35:16 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8E672912D8; Thu, 15 May 2003 19:38:07 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 536FD912D9; Thu, 15 May 2003 19:38:07 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3DBB6912D8 for ; Thu, 15 May 2003 19:38:06 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2F1025E112; Thu, 15 May 2003 19:38:06 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from web1.merit.edu (web1.merit.edu [198.108.62.192]) by segue.merit.edu (Postfix) with ESMTP id 7248F5E0CC; Thu, 15 May 2003 19:38:01 -0400 (EDT) Received: (from web@localhost) by web1.merit.edu (8.9.3/8.9.1) id TAA10710; Thu, 15 May 2003 19:38:01 -0400 (EDT) Date: Thu, 15 May 2003 19:38:01 -0400 From: William Bulley To: Bernard Aboba Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Diameter EAP: Are Redirects sufficient? Message-ID: <20030515193801.B10602@web1.merit.edu> Mail-Followup-To: Bernard Aboba , aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1us Sender: owner-aaa-wg@merit.edu Precedence: bulk According to Bernard Aboba : > As a hypothetical, what if Diameter EAP were to strongly discourage use of > proxies, and encourage use of redirects instead. Would any important > usage scenarios be compromised by such an approach? The advantage of only > using redirects if that the Diameter connections would be end-to-end and > therefore keys would not be available to intermediaries. This would > simplify the security analysis enormously and would allow us to avoid a > dependency on CMS, which seems to lack much interest in the WG. I may be out of line here, but I believe that discouraging the use of proxies for Diameter EAP would greatly limit the flexibility in which Diameter might be deployed. Admitedly I am thinking with my RADIUS hat on here, but in trying to generalize to Diameter and in a wireless scenario here in Michigan, I wouldn't want to restrict or discourage the use of proxies in Diameter EAP. My $0.02 worth. Regards, web... -- William Bulley Email: web@merit.edu Merit Network Inc. Ann Arbor, Michigan From owner-aaa-wg@merit.edu Thu May 15 19:52:54 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27739 for ; Thu, 15 May 2003 19:52:54 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C3D41912D9; Thu, 15 May 2003 19:55:43 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 930FF912DA; Thu, 15 May 2003 19:55:43 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5F7C0912D9 for ; Thu, 15 May 2003 19:55:41 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 410C55E126; Thu, 15 May 2003 19:55:41 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 88B135E0C7; Thu, 15 May 2003 19:55:40 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h4FNYIM14996; Thu, 15 May 2003 16:34:18 -0700 Date: Thu, 15 May 2003 16:34:18 -0700 (PDT) From: Bernard Aboba To: William Bulley Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Diameter EAP: Are Redirects sufficient? In-Reply-To: <20030515193801.B10602@web1.merit.edu> Message-ID: References: <20030515193801.B10602@web1.merit.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > I may be out of line here, but I believe that discouraging the use > of proxies for Diameter EAP would greatly limit the flexibility in > which Diameter might be deployed. Can you demonstrate a real-life situation in which this would be true? > Admitedly I am thinking with my RADIUS hat on here Diameter isn't RADIUS. One of the reasons that Diameter development was approved to begin with was to be able to handle these scenarios more securely than RADIUS. If it turns out that Diameter in fact offers no advantages beyond RADIUS in terms of security, then in the immortal words of Ronald Reagan -- "we've been flimflammed". > but in trying to generalize to Diameter and in a wireless scenario here > in Michigan, I wouldn't want to restrict or discourage the use of > proxies in Diameter EAP. My $0.02 worth. Are you deploying Diameter in a wireless network now in Michigan? If so, can you share with us the deployment scenario that requires a Diameter proxy? Please don't respond with hypotheticals here -- I'm looking for real deployment plans. To everyone else who is planning deployments of Diameter EAP -- can you live with only Diameter redirects? If not, are you willing to move deploy Diameter CMS? From owner-aaa-wg@merit.edu Fri May 16 01:17:14 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02122 for ; Fri, 16 May 2003 01:17:14 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id CE729912DE; Fri, 16 May 2003 01:20:05 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9FB6A912DF; Fri, 16 May 2003 01:20:05 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3E66D912DE for ; Fri, 16 May 2003 01:20:04 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 26B995DE00; Fri, 16 May 2003 01:20:04 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by segue.merit.edu (Postfix) with ESMTP id E15E85DDFF for ; Fri, 16 May 2003 01:20:03 -0400 (EDT) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id EEB876A905; Fri, 16 May 2003 08:20:02 +0300 (EEST) Message-ID: <3EC474AE.1050602@kolumbus.fi> Date: Fri, 16 May 2003 08:18:38 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030313 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Re: Call for Interest References: <3EC3F87F.7060106@kolumbus.fi> <3EC40283.5020609@kolumbus.fi> <3EC403D5.40808@kolumbus.fi> In-Reply-To: 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 Bernard Aboba wrote: > Yes. I would like to understand the deployment scenarios for Diameter EAP, > and whether keys really need to pass through intermediaries, before > doing work to protect keys from intermediaries. Presumably, Diameter EAP would have to interwork with RADIUS EAP. This creates a number of interesting questions: - If the session uses RFC 2548 attributes for carrying EAP keys (as I think is commonly done today), can DIAMETER EAP interwork with that? Deployment wise, this seems like a requirement. Presumably, procedures outlined for standard RADIUS attributes in draft-ietf-aaa-diameter-nasreq can be employed even for these attributes. - Also, while we could forbid intermediaries for DIAMETER, it seems that for interoperation with DIAMETER, at least one intermediate node may be required. --Jari From owner-aaa-wg@merit.edu Fri May 16 02:48:19 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15216 for ; Fri, 16 May 2003 02:48:19 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 08B59912DF; Fri, 16 May 2003 02:49:23 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3D9149123C; Fri, 16 May 2003 02:49:22 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2B993912DF for ; Fri, 16 May 2003 02:47:58 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 169B25DD9E; Fri, 16 May 2003 02:47:58 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 854DC5DD95 for ; Fri, 16 May 2003 02:47:57 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h4G6QUh05494; Thu, 15 May 2003 23:26:31 -0700 Date: Thu, 15 May 2003 23:26:30 -0700 (PDT) From: Bernard Aboba To: Jari Arkko Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Re: Call for Interest In-Reply-To: <3EC474AE.1050602@kolumbus.fi> Message-ID: References: <3EC3F87F.7060106@kolumbus.fi> <3EC40283.5020609@kolumbus.fi> <3EC403D5.40808@kolumbus.fi> <3EC474AE.1050602@kolumbus.fi> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > Presumably, Diameter EAP would have to interwork with RADIUS EAP. > This creates a number of interesting questions: Most likely, we're talking about a RADIUS NAS (e.g. 802.11 AP) talking to a Diameter server, through a Diameter/RADIUS gateway. > - If the session uses RFC 2548 attributes for carrying EAP keys > (as I think is commonly done today), can DIAMETER EAP interwork > with that? The Diameter/RADIUS gateway specification in NASREQ now supports the ability to translate RADIUS VSAs to Diameter VSAs. However, I don't think it has the ability to translate from standard Diameter attributes to RADIUS VSAs and back. We should file an Issue on that :( > Deployment wise, this seems like a requirement. Yes. > Presumably, procedures outlined for standard RADIUS attributes > in draft-ietf-aaa-diameter-nasreq can be employed even for > these attributes. Unfortunately, I don't think so. > - Also, while we could forbid intermediaries for DIAMETER, it > seems that for interoperation with DIAMETER, at least one > intermediate node may be required. In the case where there is a Diameter server talking to a Diameter/RADIUS gateway, the issue is really untrusted Diameter proxies, not the Diameter/RADIUS gateway, which is likely to be run by the same administration as the NASes. If the keys are always securely transmitted between the Diameter Server and the gateway no matter how many hops there are, it's a big win. From owner-aaa-wg@merit.edu Fri May 16 04:43:16 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16708 for ; Fri, 16 May 2003 04:43:15 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 77CFC9123B; Fri, 16 May 2003 04:45:13 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F10D19123C; Fri, 16 May 2003 04:45:12 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9B3749123B for ; Fri, 16 May 2003 04:45:10 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6A5405DDFA; Fri, 16 May 2003 04:45:10 -0400 (EDT) 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 A55515DDE0 for ; Fri, 16 May 2003 04:45:09 -0400 (EDT) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h4G8j8725839 for ; Fri, 16 May 2003 11:45:08 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 16 May 2003 11:45:08 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 16 May 2003 11:45:08 +0300 Received: from esebe002.NOE.Nokia.com ([172.21.138.17]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 16 May 2003 11:45:07 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 16 May 2003 11:45:07 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Re: Call for Interest Date: Fri, 16 May 2003 11:45:06 +0300 Message-ID: Thread-Topic: [AAA-WG]: Re: Call for Interest Thread-Index: AcMbd5RJC92kRxuJROeSst4YK0+NEwAD401A From: To: , Cc: X-OriginalArrivalTime: 16 May 2003 08:45:07.0301 (UTC) FILETIME=[73C01950:01C31B87] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id EAA16708 Hi Bernard & Jari, > > Presumably, Diameter EAP would have to interwork with RADIUS EAP. > > This creates a number of interesting questions: > > Most likely, we're talking about a RADIUS NAS (e.g. 802.11 > AP) talking to a Diameter server, through a Diameter/RADIUS gateway. That sounds reasonable. > > > - If the session uses RFC 2548 attributes for carrying EAP keys > > (as I think is commonly done today), can DIAMETER EAP interwork > > with that? > > The Diameter/RADIUS gateway specification in NASREQ now > supports the ability to translate RADIUS VSAs to Diameter VSAs. However, I > don't think it has the ability to translate from standard Diameter > attributes to RADIUS VSAs and back. We should file an Issue > on that :( Would this be filed for NASREQ or EAP? > > Deployment wise, this seems like a requirement. > > Yes. > > > Presumably, procedures outlined for standard RADIUS attributes > > in draft-ietf-aaa-diameter-nasreq can be employed even for > > these attributes. > > Unfortunately, I don't think so. This sounds like an issue to be handled in EAP, then. > > - Also, while we could forbid intermediaries for DIAMETER, it > > seems that for interoperation with DIAMETER, at least one > > intermediate node may be required. > > In the case where there is a Diameter server talking to a Diameter/RADIUS > gateway, the issue is really untrusted Diameter proxies, not the > Diameter/RADIUS gateway, which is likely to be run by the same > administration as the NASes. I think that we need to figure out how to forbit 'untrusted' proxies, then. > If the keys are always securely transmitted between the Diameter Server > and the gateway no matter how many hops there are, it's a big win. Agreed. John From owner-aaa-wg@merit.edu Fri May 16 04:52:51 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16863 for ; Fri, 16 May 2003 04:52:51 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8F2CE9123C; Fri, 16 May 2003 04:55:42 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 56C54912E0; Fri, 16 May 2003 04:55:42 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2A35E9123C for ; Fri, 16 May 2003 04:55:41 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 104F65DE13; Fri, 16 May 2003 04:55:41 -0400 (EDT) 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 52C105DE07 for ; Fri, 16 May 2003 04:55:40 -0400 (EDT) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h4G8td706650 for ; Fri, 16 May 2003 11:55:39 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 16 May 2003 11:55:38 +0300 Received: from esebe010.NOE.Nokia.com ([172.21.138.49]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 16 May 2003 11:55:38 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe010.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 16 May 2003 11:55:29 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Re: Call for Interest Date: Fri, 16 May 2003 11:55:23 +0300 Message-ID: Thread-Topic: [AAA-WG]: Re: Call for Interest Thread-Index: AcMbLQGCNmHpzS1NTduGTBf6rtifCQAWoVAw From: To: , Cc: X-OriginalArrivalTime: 16 May 2003 08:55:29.0261 (UTC) FILETIME=[E677A9D0:01C31B88] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id EAA16863 Hi Bernard, > Yes. I would like to understand the deployment scenarios for Diameter EAP, > and whether keys really need to pass through intermediaries, before > doing work to protect keys from intermediaries. I'd probably have to dig through the proposals better, but I think the initial 3GPP scenario is something along the following: +-------+ +---------+ +---------+ +----------+ | | | | | | | | | NAS | | visited | | home | | profile | | |----------| AAA |--------| AAA |....| | | | | server | | server | | server | +-------+ +---------+ +---------+ +----------+ My guess is that all of the connections will be secured. The profile server (probably HLR) can be considered a database where subscriber profiles reside. John From owner-aaa-wg@merit.edu Fri May 16 08:05:12 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20521 for ; Fri, 16 May 2003 08:05:12 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4A607912E3; Fri, 16 May 2003 08:08:04 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 138EA912E4; Fri, 16 May 2003 08:08:04 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0C00D912E3 for ; Fri, 16 May 2003 08:08:03 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E3B5F5DF3E; Fri, 16 May 2003 08:08:02 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 67D825DF3C for ; Fri, 16 May 2003 08:08:02 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h4GBkWp23937; Fri, 16 May 2003 04:46:32 -0700 Date: Fri, 16 May 2003 04:46:32 -0700 (PDT) From: Bernard Aboba To: john.loughney@nokia.com Cc: jari.arkko@kolumbus.fi, aaa-wg@merit.edu Subject: RE: [AAA-WG]: Re: Call for Interest In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > +-------+ +---------+ +---------+ +----------+ > | | | | | | | | > | NAS | | visited | | home | | profile | > | |----------| AAA |--------| AAA |....| | > | | | server | | server | | server | > +-------+ +---------+ +---------+ +----------+ > > My guess is that all of the connections will be secured. The profile > server (probably HLR) can be considered a database where subscriber > profiles reside. In the scenario above there are no untrusted proxies. If the NAS in the diagram is running RADIUS, then there is no way for the visited AAA server to avoid possessing the keys, since it needs to function as a Diameter/RADIUS gateway. CMS would not add any security in such a scenario. From owner-aaa-wg@merit.edu Fri May 16 08:13:59 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20653 for ; Fri, 16 May 2003 08:13:58 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 62F57912E8; Fri, 16 May 2003 08:15:15 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D36BB912EA; Fri, 16 May 2003 08:15:14 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 50F20912E8 for ; Fri, 16 May 2003 08:15:09 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7C2675DF3B; Fri, 16 May 2003 08:15:08 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 9FB415DEC0 for ; Fri, 16 May 2003 08:15:07 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h4GBraf24278; Fri, 16 May 2003 04:53:36 -0700 Date: Fri, 16 May 2003 04:53:36 -0700 (PDT) From: Bernard Aboba To: john.loughney@nokia.com Cc: jari.arkko@kolumbus.fi, aaa-wg@merit.edu Subject: RE: [AAA-WG]: Re: Call for Interest In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > > The Diameter/RADIUS gateway specification in NASREQ now > > supports the ability to translate RADIUS VSAs to Diameter VSAs. However, I > > don't think it has the ability to translate from standard Diameter > > attributes to RADIUS VSAs and back. We should file an Issue > > on that :( > > Would this be filed for NASREQ or EAP? Probably for both. > This sounds like an issue to be handled in EAP, then. Yes. > > In the case where there is a Diameter server talking to a Diameter/RADIUS > > gateway, the issue is really untrusted Diameter proxies, not the > > Diameter/RADIUS gateway, which is likely to be run by the same > > administration as the NASes. > > I think that we need to figure out how to forbid 'untrusted' proxies, > then. We can say that 'untrusted' agents MUST function as redirects so that they don't obtain posession of the keys. During Diameter session setup, if an agent that is expected to act as a redirect does not do so, then the session MUST be torn down. That way, only 'trusted' agents can obtain keys. > > If the keys are always securely transmitted between the Diameter Server > > and the gateway no matter how many hops there are, it's a big win. > > Agreed. In practice, this seems achievable, at least for Diameter EAP. From owner-aaa-wg@merit.edu Fri May 16 08:24:35 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20769 for ; Fri, 16 May 2003 08:24:35 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E051B912E5; Fri, 16 May 2003 08:27:25 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AF8E0912E6; Fri, 16 May 2003 08:27:25 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 99D2E912E5 for ; Fri, 16 May 2003 08:27:24 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7A3195DF4B; Fri, 16 May 2003 08:27:24 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from bsn-mail-01.bstormnetworks.com (mail.bstormnetworks.com [209.11.156.50]) by segue.merit.edu (Postfix) with ESMTP id 2908E5DF4A; Fri, 16 May 2003 08:27:24 -0400 (EDT) Received: from [172.16.8.102] ([172.16.8.102]) by bsn-mail-01.bstormnetworks.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 16 May 2003 05:27:23 -0700 Subject: Re: [AAA-WG]: Diameter EAP: Are Redirects sufficient? From: Pat Calhoun To: Bernard Aboba Cc: William Bulley , aaa-wg@merit.edu In-Reply-To: References: <20030515193801.B10602@web1.merit.edu> Content-Type: text/plain Message-Id: <1053087933.21318.3.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 16 May 2003 05:25:34 -0700 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 May 2003 12:27:23.0818 (UTC) FILETIME=[80EF18A0:01C31BA6] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Thu, 2003-05-15 at 16:34, Bernard Aboba wrote: > > I may be out of line here, but I believe that discouraging the use > > of proxies for Diameter EAP would greatly limit the flexibility in > > which Diameter might be deployed. > > Can you demonstrate a real-life situation in which this would be true? http://www.cometanetworks.com/services.html So if 802.11 goes the way dial-up has, enterprise customers will want their users to authenticate against their own authentication infrastructure. > Are you deploying Diameter in a wireless network now in Michigan? If so, > can you share with us the deployment scenario that requires a Diameter > proxy? Please don't respond with hypotheticals here -- I'm looking for > real deployment plans. I can't state that Cometa will make use of Diameter, in fact their most likely looking at RADIUS since that's all there is out there. However, if security is an issue for them, or their customers, then we need to have something to offer. PatC From owner-aaa-wg@merit.edu Fri May 16 09:48:17 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24589 for ; Fri, 16 May 2003 09:48:16 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 89C4A912EE; Fri, 16 May 2003 09:51:01 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 56DAA912F9; Fri, 16 May 2003 09:51:01 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7498D912EE for ; Fri, 16 May 2003 09:50:59 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5C57F5DFD4; Fri, 16 May 2003 09:50:59 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id BFC365DFD8 for ; Fri, 16 May 2003 09:50:58 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h4GDTWH29580; Fri, 16 May 2003 06:29:32 -0700 Date: Fri, 16 May 2003 06:29:32 -0700 (PDT) From: Bernard Aboba To: Pat Calhoun Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Diameter EAP: Are Redirects sufficient? In-Reply-To: <1053087933.21318.3.camel@localhost.localdomain> Message-ID: References: <20030515193801.B10602@web1.merit.edu> <1053087933.21318.3.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > http://www.cometanetworks.com/services.html My understanding is that Cometa is in the business of being an access wholesaler, no? Wouldn't that scenario be covered by the picture that John provided? > So if 802.11 goes the way dial-up has, enterprise customers will want > their users to authenticate against their own authentication > infrastructure. That doesn't imply use of untrusted proxies. A Diameter/RADIUS gateway at the wholesaler could forward between 802.11 APs running RADIUS and enterprise AAA servers running Diameter. > I can't state that Cometa will make use of Diameter, in fact their most > likely looking at RADIUS since that's all there is out there. However, > if security is an issue for them, or their customers, then we need to > have something to offer. There are quite a few useful features in Diameter Base that could be used to provide improved security beyond what is in RADIUS. This includes things like Redirect support, support for certificate-based authentication, etc. So the question in my mind is why those features cannot be used to solve the problem -- rather than relying on a technology (CMS) which the WG seems to have little interest in developing. Either: 1) the security features of Diameter Base don't improve security sufficiently in key scenarios beyond what is in RADIUS, so that CMS is needed. In this case if we don't do CMS, Diameter will not be more secure than RADIUS in key uses. OR: 2) Diameter Base provides the security features needed to support major deployment scenarios more securely than RADIUS can, so that CMS is not needed in addition, except perhaps in some specialized situations. I'm asking the WG to try #2 on for size, and see if the major deployment scenarios of Diameter EAP can be handled securely based on the functionality in the Diameter Base protocol alone, with no dependencies on CMS. It is quite possible that for #2 to be true that some changes are needed in thinking -- Diameter is not RADIUS, after all. But it seems to me that we're much more likely to succeed if #2 is true than if #1 is closer to reality. From owner-aaa-wg@merit.edu Fri May 16 10:11:33 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26293 for ; Fri, 16 May 2003 10:11:31 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id CE410912F1; Fri, 16 May 2003 10:13:01 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 996BA912F0; Fri, 16 May 2003 10:13:01 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BC104912EA for ; Fri, 16 May 2003 10:12:57 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A03F75DFF4; Fri, 16 May 2003 10:12:57 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 34FDA5DFEA for ; Fri, 16 May 2003 10:12:57 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h4GDpWR30853 for ; Fri, 16 May 2003 06:51:32 -0700 Date: Fri, 16 May 2003 06:51:31 -0700 (PDT) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 407: Diameter Credit Control Review Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: May 9, 2003 Reference: http://www.drizzle.com/~aboba/AAA/draft-ietf-aaa-diameter-cc-00.txt Document: CC-00 Comment type: Technical Priority: S Section: Various Rationale/Explanation of issue: Detailed comments are provided at the referenced URL above. From owner-aaa-wg@merit.edu Fri May 16 10:13:37 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26522 for ; Fri, 16 May 2003 10:13:37 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A2868912EA; Fri, 16 May 2003 10:15:47 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 41102912F0; Fri, 16 May 2003 10:15:47 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id F0FC1912EA for ; Fri, 16 May 2003 10:15:45 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C77EB5DFFA; Fri, 16 May 2003 10:15:45 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from bsn-mail-01.bstormnetworks.com (mail.bstormnetworks.com [209.11.156.50]) by segue.merit.edu (Postfix) with ESMTP id 143DE5DE9A for ; Fri, 16 May 2003 10:15:42 -0400 (EDT) Received: from [172.16.8.102] ([172.16.8.102]) by bsn-mail-01.bstormnetworks.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 16 May 2003 07:15:42 -0700 Subject: Re: [AAA-WG]: Diameter EAP: Are Redirects sufficient? From: Pat Calhoun To: Bernard Aboba Cc: aaa-wg@merit.edu In-Reply-To: References: <20030515193801.B10602@web1.merit.edu> <1053087933.21318.3.camel@localhost.localdomain> Content-Type: text/plain Message-Id: <1053094432.21318.21.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 16 May 2003 07:13:52 -0700 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 May 2003 14:15:42.0615 (UTC) FILETIME=[A284D270:01C31BB5] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > There are quite a few useful features in Diameter Base that could be used > to provide improved security beyond what is in RADIUS. This includes > things like Redirect support, support for certificate-based > authentication, etc. So the question in my mind is why those features > cannot be used to solve the problem -- rather than relying on a technology > (CMS) which the WG seems to have little interest in developing. That wasn't the point I was making. You asked for real-life inter-domain 802.1x deployments. I provided you one. Whether they need proxies, or not, or even whether they deploy Diameter or not, I can't answer. > I'm asking the WG to try #2 on for size, and see if the major deployment > scenarios of Diameter EAP can be handled securely based on the > functionality in the Diameter Base protocol alone, with no dependencies on > CMS. Maybe #2 is sufficient. My understanding was the IESG would not let Diameter out w/o CMS... of course, this is a while ago. PatC From owner-aaa-wg@merit.edu Fri May 16 10:43:26 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27852 for ; Fri, 16 May 2003 10:43:26 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 71A46912F5; Fri, 16 May 2003 10:45:43 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 44F00912F6; Fri, 16 May 2003 10:45:43 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1EF88912F5 for ; Fri, 16 May 2003 10:45:42 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B95955DFAB; Fri, 16 May 2003 10:45:40 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by segue.merit.edu (Postfix) with ESMTP id 23A3A5DDC5 for ; Fri, 16 May 2003 10:45:40 -0400 (EDT) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 1F45C6A909; Fri, 16 May 2003 17:45:39 +0300 (EEST) Message-ID: <3EC4F930.7000207@kolumbus.fi> Date: Fri, 16 May 2003 17:44:00 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030313 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Diameter EAP: Are Redirects sufficient? References: <20030515193801.B10602@web1.merit.edu> <1053087933.21318.3.camel@localhost.localdomain> In-Reply-To: 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 Bernard Aboba wrote: > There are quite a few useful features in Diameter Base that could be used > to provide improved security beyond what is in RADIUS. This includes > things like Redirect support, support for certificate-based > authentication, etc. So the question in my mind is why those features > cannot be used to solve the problem -- rather than relying on a technology > (CMS) which the WG seems to have little interest in developing. Cool. Lets work this out... >>So if 802.11 goes the way dial-up has, enterprise customers will want >>their users to authenticate against their own authentication >>infrastructure. > > > That doesn't imply use of untrusted proxies. A Diameter/RADIUS gateway > at the wholesaler could forward between 802.11 APs running RADIUS and > enterprise AAA servers running Diameter. It would be useful to try to understand how the CAs are setup in this usage. So in your example, the wholesaler would maintain a CA that would sign certs for all of its gateways as well as the enterprise AAA servers (or for the CAs of the enteprises which in turn would sign certs for their servers). So, upon trying to perform EAP over the AAA infrastructure, the gateway would get a Redirect from a proxy, and the session would be directed to the particular enterprise AAA server. A Diameter connection would be setup, protected by TLS using the CA mentioned earlier as the trust root. Looks simple enough, though I worry a bit that we have forgotten something that causes problems in this scenario. But one good thing is that multi-roundtrip EAP methods don't have to pass through a large number of proxies. One issue is that if even the APs are starting to implement DIAMETER, the CA has to sign a lot of nodes. What is, by the way, the status of public domain software for manufacturing certs? Is everyone who has an SSL server implementation running on their unix box capable of generating certs? Also, I guess Redirect-Host-Usage = REALM_AND_APPLICATION so that only EAP stuff gets redirected, and accounting not? --Jari From owner-aaa-wg@merit.edu Fri May 16 10:59:31 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28187 for ; Fri, 16 May 2003 10:59:31 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C6D0E912F6; Fri, 16 May 2003 11:01:41 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5B2D8912F7; Fri, 16 May 2003 11:01:41 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 23CBF912F6 for ; Fri, 16 May 2003 11:01:40 -0400 (EDT) Received: by segue.merit.edu (Postfix) id CCC725E048; Fri, 16 May 2003 11:01:39 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id CC0175E04B for ; Fri, 16 May 2003 11:01:38 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h4GEeBA01139; Fri, 16 May 2003 07:40:11 -0700 Date: Fri, 16 May 2003 07:40:11 -0700 (PDT) From: Bernard Aboba To: Jari Arkko Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Diameter EAP: Are Redirects sufficient? In-Reply-To: <3EC4F930.7000207@kolumbus.fi> Message-ID: References: <20030515193801.B10602@web1.merit.edu> <1053087933.21318.3.camel@localhost.localdomain> <3EC4F930.7000207@kolumbus.fi> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > So, upon trying to perform EAP over the AAA infrastructure, the > gateway would get a Redirect from a proxy, and the session would > be directed to the particular enterprise AAA server. A Diameter > connection would be setup, protected by TLS using the CA mentioned > earlier as the trust root. Exactly. > Looks simple enough, though I worry a bit that we have forgotten > something that causes problems in this scenario. But one good > thing is that multi-roundtrip EAP methods don't have to pass > through a large number of proxies. Yes. This should result in considerably better performance. Also, use of TLS is considerably simpler than IKE would be in that scenario, since the certification authorities for network access are likely to be very different than that of other applications (such as Web service). In TLS it's possible to define a different set of trust anchors for each application. > One issue is that if even the APs are starting to implement DIAMETER, > the CA has to sign a lot of nodes. What is, by the way, the status > of public domain software for manufacturing certs? Is everyone who > has an SSL server implementation running on their unix box capable > of generating certs? I'm not very knowledgeable about this but perhaps someone else can respond. > Also, I guess Redirect-Host-Usage = REALM_AND_APPLICATION so that only > EAP stuff gets redirected, and accounting not? Yes. Accounting data still needs to go the intermediaries. From owner-aaa-wg@merit.edu Fri May 16 11:48:08 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00369 for ; Fri, 16 May 2003 11:48:08 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id AFBC4912F9; Fri, 16 May 2003 11:50:59 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7F08C912FA; Fri, 16 May 2003 11:50:59 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 797E7912F9 for ; Fri, 16 May 2003 11:50:58 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 58B705E0A8; Fri, 16 May 2003 11:50:58 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id D5CD65E0A7 for ; Fri, 16 May 2003 11:50:57 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h4GFTWf03840 for ; Fri, 16 May 2003 08:29:32 -0700 Date: Fri, 16 May 2003 08:29:31 -0700 (PDT) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: AAA WG "pseudo WG last call" on draft-aboba-radius-rfc2869bis-22.txt (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk This is announcing a "pseudo AAA WG last call" on draft-aboba-radius-rfc2869bis-22.txt. This should appear on the IETF archive on Monday, May 19, 2003. Until then it is available for inspection here: http://www.drizzle.com/~aboba/EAP/draft-aboba-radius-rfc2869bis-22.txt The "pseudo AAA WG last call" will last until Monday, June 2, 2003. Please send comments to the mailing list. From owner-aaa-wg@merit.edu Fri May 16 12:36:05 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02086 for ; Fri, 16 May 2003 12:36:05 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id EEFE39121C; Fri, 16 May 2003 12:38:58 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BEAE7912FA; Fri, 16 May 2003 12:38:57 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B4A689121C for ; Fri, 16 May 2003 12:38:56 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A15885E0ED; Fri, 16 May 2003 12:38:56 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from pit.databus.com (p70-227.acedsl.com [66.114.70.227]) by segue.merit.edu (Postfix) with ESMTP id 26D105E0EC for ; Fri, 16 May 2003 12:38:56 -0400 (EDT) Received: from pit.databus.com (localhost [127.0.0.1]) by pit.databus.com (8.12.9/8.12.9) with ESMTP id h4GGcqiK018396; Fri, 16 May 2003 12:38:52 -0400 (EDT) (envelope-from barney@pit.databus.com) Received: (from barney@localhost) by pit.databus.com (8.12.9/8.12.9/Submit) id h4GGcpYq018395; Fri, 16 May 2003 12:38:51 -0400 (EDT) Date: Fri, 16 May 2003 12:38:51 -0400 From: Barney Wolff To: Bernard Aboba Cc: Jari Arkko , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Diameter EAP: Are Redirects sufficient? Message-ID: <20030516163851.GA18100@pit.databus.com> References: <20030515193801.B10602@web1.merit.edu> <1053087933.21318.3.camel@localhost.localdomain> <3EC4F930.7000207@kolumbus.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Scanned-By: MIMEDefang 2.32 (www . roaringpenguin . com / mimedefang) Sender: owner-aaa-wg@merit.edu Precedence: bulk On Fri, May 16, 2003 at 07:40:11AM -0700, Bernard Aboba wrote: > > > One issue is that if even the APs are starting to implement DIAMETER, > > the CA has to sign a lot of nodes. What is, by the way, the status > > of public domain software for manufacturing certs? Is everyone who > > has an SSL server implementation running on their unix box capable > > of generating certs? > > I'm not very knowledgeable about this but perhaps someone else can > respond. Openssl can do this and is widely available. mod_ssl for Apache uses it to generate and sign a cert on installation. That's of course quite different from setting up a fully-secured CA. -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net. From owner-aaa-wg@merit.edu Sun May 18 19:10:21 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20295 for ; Sun, 18 May 2003 19:10:21 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B9FE191205; Sun, 18 May 2003 19:13:11 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8BACC9124C; Sun, 18 May 2003 19:13:11 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3084D91205 for ; Sun, 18 May 2003 19:13:10 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1952B5E79A; Sun, 18 May 2003 19:13:10 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161]) by segue.merit.edu (Postfix) with ESMTP id BEE1F5E799 for ; Sun, 18 May 2003 19:13:09 -0400 (EDT) Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail1.firewall.lucent.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4IND8726003 for ; Sun, 18 May 2003 19:13:08 -0400 (EDT) Received: from lucent.com (tomhiller.lra.lucent.com [192.11.173.60]) by ihmail.ih.lucent.com (8.11.6+Sun/EMS-1.5 sol2) id h4IND4p03232; Sun, 18 May 2003 18:13:04 -0500 (CDT) Message-ID: <3EC81381.A6C5514F@lucent.com> Date: Sun, 18 May 2003 18:13:05 -0500 From: Tom Hiller Organization: Lucent Technologies X-Mailer: Mozilla 4.76 [en]C-CCK-MCD EMS-1.5 (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Diameter EAP: Are Redirects sufficient? 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 am working to understand if there are any problems for 3GPP2 with the redirect proposal. 3GPP2 is initially focussed on MIPv4 and NASREQ applications. From the base protocol we have: > > +------+ > | | > | DRD | > | | > +------+ > ^ | > 2. Request | | 3. Redirection > | | Notification > | v > +------+ ---------> +------+ ---------> +------+ > | | 1. Request | | 4. Request | | > | NAS | | DRL | | HMS | > | | 6. Answer | | 5. Answer | | > +------+ <--------- +------+ <--------- +------+ > example.net example.net example.com > Figure 3: Redirecting a Diameter Message 3GPP2 has a need for the VAAA to possibly override some of the attributes based on local policy, so our VAAA needs to be a proxy and redirect agent. Since "proxy" and "redirect" are logical functions, they can be combined in one agent? thanks, Tom Bernard Aboba wrote: > > > I may be out of line here, but I believe that discouraging the use > > of proxies for Diameter EAP would greatly limit the flexibility in > > which Diameter might be deployed. > > Can you demonstrate a real-life situation in which this would be true? > > > Admitedly I am thinking with my RADIUS hat on here > > Diameter isn't RADIUS. One of the reasons that Diameter development was > approved to begin with was to be able to handle these scenarios more > securely than RADIUS. If it turns out that Diameter in fact offers no > advantages beyond RADIUS in terms of security, then in the immortal words > of Ronald Reagan -- "we've been flimflammed". > > > but in trying to generalize to Diameter and in a wireless scenario here > > in Michigan, I wouldn't want to restrict or discourage the use of > > proxies in Diameter EAP. My $0.02 worth. > > Are you deploying Diameter in a wireless network now in Michigan? If so, > can you share with us the deployment scenario that requires a Diameter > proxy? Please don't respond with hypotheticals here -- I'm looking for > real deployment plans. > > To everyone else who is planning deployments of Diameter EAP -- can you > live with only Diameter redirects? If not, are you willing to move deploy > Diameter CMS? From owner-aaa-wg@merit.edu Mon May 19 07:55:36 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18012 for ; Mon, 19 May 2003 07:55:36 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 45B079124E; Mon, 19 May 2003 07:58:28 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 154AE9124F; Mon, 19 May 2003 07:58:28 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E92E39124E for ; Mon, 19 May 2003 07:58:26 -0400 (EDT) Received: by segue.merit.edu (Postfix) id CC3815E085; Mon, 19 May 2003 07:58:26 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by segue.merit.edu (Postfix) with ESMTP id 91F165E082 for ; Mon, 19 May 2003 07:58:26 -0400 (EDT) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 76FA56A904; Mon, 19 May 2003 14:58:24 +0300 (EEST) Message-ID: <3EC8C687.2020306@kolumbus.fi> Date: Mon, 19 May 2003 14:56:55 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030313 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tom Hiller Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Diameter EAP: Are Redirects sufficient? References: <3EC81381.A6C5514F@lucent.com> In-Reply-To: <3EC81381.A6C5514F@lucent.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 Tom Hiller wrote: > 3GPP2 has a need for the VAAA to possibly override some of the attributes based > on local policy, so our VAAA needs to be a proxy and redirect agent. Since > "proxy" and "redirect" are logical functions, they can be combined in one agent? I'm sure they can be, but the question is whether they can both be done for the same session. Can we do a redirect-based e2e Diameter EAP exchange, followed by a proxy-based Diameter final authz round where the whole sequence gets to agree on the attributes, followed by proxy-based Diameter accounting? This would appear to be possible as long as the EAP exchange and the final authz message exchange are on two different Diameter app numbers. But details would have to be developed. --Jari From owner-aaa-wg@merit.edu Mon May 19 09:41:38 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20653 for ; Mon, 19 May 2003 09:41:36 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3AF2E91211; Mon, 19 May 2003 09:44:30 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0489691212; Mon, 19 May 2003 09:44:29 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 08B6191211 for ; Mon, 19 May 2003 09:44:28 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E2AE55DDCC; Mon, 19 May 2003 09:44:28 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 69C955DDB1 for ; Mon, 19 May 2003 09:44:28 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h4JDMN014985; Mon, 19 May 2003 06:22:24 -0700 Date: Mon, 19 May 2003 06:22:23 -0700 (PDT) From: Bernard Aboba To: Jari Arkko Cc: Tom Hiller , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Diameter EAP: Are Redirects sufficient? In-Reply-To: <3EC8C687.2020306@kolumbus.fi> Message-ID: References: <3EC81381.A6C5514F@lucent.com> <3EC8C687.2020306@kolumbus.fi> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > Can we do a redirect-based e2e Diameter EAP exchange, followed > by a proxy-based Diameter final authz round where the whole > sequence gets to agree on the attributes, followed by proxy-based > Diameter accounting? This would appear to be possible as long as > the EAP exchange and the final authz message exchange are on > two different Diameter app numbers. But details would have to > be developed. Interesting. I'm assuming that the Diameter EAP exchange provides no authorizations other than keys, then? The "autheticate only" exchange including keys is handled via redirects, and is then followed by an "authorize" only" exchange that goes through a proxy. From owner-aaa-wg@merit.edu Wed May 21 09:45:17 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21041 for ; Wed, 21 May 2003 09:45:17 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5BCFE91238; Wed, 21 May 2003 09:44:58 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2767691239; Wed, 21 May 2003 09:44:58 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1341991238 for ; Wed, 21 May 2003 09:44:57 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E34B25DDE7; Wed, 21 May 2003 09:44:56 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 4AE645DDC9 for ; Wed, 21 May 2003 09:44:56 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h4LDN3x29297 for ; Wed, 21 May 2003 06:23:04 -0700 Date: Wed, 21 May 2003 06:23:03 -0700 (PDT) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 408: Another Diameter Credit Control Review Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Submitter name: Avi Lior Submitter email address: avi@bridgewatersystems.com Date first submitted: May 9, 2003 Reference: http://www.drizzle.com/~aboba/AAA/lior-comments.txt Document: CC-00 Comment type: Technical Priority: S Section: Various Rationale/Explanation of issue: General Comments Use of Authentication\Authorization messages. As mentioned before (in various emails) I belive that the correct way (from a philosophical point and technical point) is to use authentication and authorization messages. I belive you have received comments to this effect from other people so I won't bother to repeat myself or others. Protocol Efficiency In many domains where this application will be applicable, the user is authenticated and authorized to use the service. Part of the authorization service is to perform Credit or Prepaid authorization. The problem with the current document is that it *forces* the Credit Authorization or Prepaid Authorization to be performed after the Service Authroization. This creates a problem: First, the credit authorization has to traverse the network again. Since both authorization are done in the Home network, it seems silly to have to traverse the network again. Second and more importantly, the delay in having to perform this operation as a seperate step is not acceptable in many application. This *must* be addressed to have this document acceptable as a generic solution. This is not a specific 3GPP solution right? Types of Credit Control It would be nice if several applicable scenario be presented. For example, its not clear whether the intent of this application is to cover Prepaid Data Services. How are time and volume based applications handled? What about roaming considerations? Applicability in other than 3GPP operating environments This document is intended as a Standard Track therefore, it should work in general operating environments. That is, environments other than 3GPP. There are certain concepts here that work well in the 3GPP but not so well in other environments. For example, the notion that a Credit Control Client can request the user's account balance, or the cost of a service is not appropriate in all conditions. This particular problem was brought up in the past and sadly not addressed in this version. I have no problem if the authors dont want to address these issues. However, they should submit the document as an Informational Document, documenting how 3GPP does things. Redirect In many instances in the text the action to take when a user resources are no longer available is to terminate the session. That is one possible action, the other possible action is to restrict access (or direct the user) to a portal where they can recharge their account etc... Detailed review comments are available below: http://www.drizzle.com/~aboba/AAA/lior-comments.txt From owner-aaa-wg@merit.edu Wed May 21 12:39:41 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27674 for ; Wed, 21 May 2003 12:39:41 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id EF0D79126E; Wed, 21 May 2003 12:39:31 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B88249126F; Wed, 21 May 2003 12:39:30 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B2B239126E for ; Wed, 21 May 2003 12:39:29 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 99B905DECB; Wed, 21 May 2003 12:39:29 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id D58BC5DEC9 for ; Wed, 21 May 2003 12:39:28 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h4LGHY006603 for ; Wed, 21 May 2003 09:17:35 -0700 Date: Wed, 21 May 2003 09:17:34 -0700 (PDT) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: IETF 57 Draft Cutoff Dates Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk NOTE: There are two (2) Internet-Draft Cutoff dates June 23rd: Cutoff for Initial Submissions (new documents) All initial submissions(-00) must be submitted by Monday, June 23rd, at 09:00 ET. Initial submissions received after this time will NOT be made available in the Internet-Drafts directory, and will have to be resubmitted. As before, all initial submissions (-00.txt) with a filename beginning with a draft-ietf MUST be approved by the appropriate WG Chair prior to processing and announcing. WG Chair approval must be received by Monday, June 16th. Please do NOT wait until the last minute to submit. Be advised: NO placeholders. Updates to initial submissions received the week of June 23rd will NOT be accepted. June 30st: FINAL Internet-Draft Cutoff All revised Internet-Draft submissions must be submitted by Monday, June 30st, 2003 at 09:00 ET. Internet-Drafts received after this time will NOT be announced NOR made available in the Internet-Drafts Directories. We will begin accepting Internet-Draft submissions the week of the meeting, though announcements will NOT be sent until the IETF meeting is over. Thank you for your understanding and cooperation. Please do not hesitate to contact us if you have any questions or concenrs. FYI: These and other significant dates can be found at http://www.ietf.org/meetings/cutoff_dates_57.html From owner-aaa-wg@merit.edu Wed May 21 15:27:31 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04969 for ; Wed, 21 May 2003 15:27:29 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 9A3D09123D; Wed, 21 May 2003 15:27:08 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0D0F29123E; Wed, 21 May 2003 15:27:06 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BA4E79123D for ; Wed, 21 May 2003 15:27:05 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A874E5DFD8; Wed, 21 May 2003 15:27:05 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161]) by segue.merit.edu (Postfix) with ESMTP id 53CCE5DFD0 for ; Wed, 21 May 2003 15:27:05 -0400 (EDT) Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail1.firewall.lucent.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4LJR3711284 for ; Wed, 21 May 2003 15:27:04 -0400 (EDT) Received: from lucent.com (tomhiller-1.ih.lucent.com [135.185.210.56]) by ihmail.ih.lucent.com (8.11.6+Sun/EMS-1.5 sol2) id h4LJR3o10070; Wed, 21 May 2003 14:27:03 -0500 (CDT) Message-ID: <3ECBD307.A61C5152@lucent.com> Date: Wed, 21 May 2003 14:27:03 -0500 From: Tom Hiller Organization: Lucent Technologies X-Mailer: Mozilla 4.76 [en]C-CCK-MCD EMS-1.5 (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Diameter EAP: Are Redirects sufficient? References: <3EC81381.A6C5514F@lucent.com> <3EC8C687.2020306@kolumbus.fi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Jari, You wrote the following: > This would appear to be possible as long as the EAP exchange and the > final authz message exchange are on two different Diameter app numbers. > But details would have to be developed. I am interested in the Diameter MIPv4 and NASREQ applications. > +------+ > | | > | DRD | > | | > +------+ > ^ | > 2. Request | | 3. Redirection > | | Notification > | v > +------+ ---------> +------+ ---------> +------+ > | | 1. Request | | 4. Request | | > | NAS | | DRL | | HMS | > | | 6. Answer | | 5. Answer | | > +------+ <--------- +------+ <--------- +------+ > example.net example.net example.com > Figure 3: Redirecting a Diameter Message In the above, DRL would be the AAAF, a proxy, and HMS is the AAAH. To verify, for MIPv4: 1) All messages above have the MIPv4 application id. 2) For MIPv4 or NASREQ to support of key distribution, it is only necessary to add to the MIPv4 application text that the AAAF must have a session protected by TLS with the AAAH, and that it may use redirect to establish a session if it doesn't already have one. There are no further details to develop for NASREQ and MIPv4 applications. Or are there? thanks, Tom Jari Arkko wrote: > > Tom Hiller wrote: > > > 3GPP2 has a need for the VAAA to possibly override some of the attributes based > > on local policy, so our VAAA needs to be a proxy and redirect agent. Since > > "proxy" and "redirect" are logical functions, they can be combined in one agent? > > I'm sure they can be, but the question is whether they can both be done > for the same session. > > Can we do a redirect-based e2e Diameter EAP exchange, followed > by a proxy-based Diameter final authz round where the whole > sequence gets to agree on the attributes, followed by proxy-based > Diameter accounting? This would appear to be possible as long as > the EAP exchange and the final authz message exchange are on > two different Diameter app numbers. But details would have to > be developed. > > --Jari From owner-aaa-wg@merit.edu Thu May 22 00:38:30 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18396 for ; Thu, 22 May 2003 00:38:29 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 9B6B191245; Thu, 22 May 2003 00:38:17 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 64C489126F; Thu, 22 May 2003 00:38:17 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0FE9F91245 for ; Thu, 22 May 2003 00:38:15 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D6D8F5DDCB; Thu, 22 May 2003 00:38:15 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by segue.merit.edu (Postfix) with ESMTP id 8C6715DDC9 for ; Thu, 22 May 2003 00:38:15 -0400 (EDT) Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h4M4c4aY018999; Wed, 21 May 2003 21:38:04 -0700 (PDT) Received: from gwzw2k (sjc-vpn3-856.cisco.com [10.21.67.88]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with ESMTP id VAA19045; Wed, 21 May 2003 21:38:03 -0700 (PDT) Reply-To: From: "Glen Zorn" To: "'Jari Arkko'" , "'Bernard Aboba'" Cc: Subject: RE: [AAA-WG]: Diameter EAP: Are Redirects sufficient? Date: Wed, 21 May 2003 21:37:35 -0700 Organization: Cisco Systems Message-ID: <002401c3201b$ec5fe820$389f4104@amer.cisco.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0025_01C31FE1.40011020" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal In-Reply-To: <3EC4F930.7000207@kolumbus.fi> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0025_01C31FE1.40011020 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Jari Arkko writes: > Bernard Aboba wrote: > >> There are quite a few useful features in Diameter Base that could be >> used to provide improved security beyond what is in RADIUS. This >> includes things like Redirect support, support for certificate-based >> authentication, etc. So the question in my mind is why those >> features cannot be used to solve the problem -- rather than relying >> on a technology (CMS) which the WG seems to have little interest in >> developing. > > Cool. Lets work this out... > > >>So if 802.11 goes the way dial-up has, enterprise customers will > want >>their users to authenticate against their own authentication > >>infrastructure. > > > That doesn't imply use of untrusted > proxies. A Diameter/RADIUS gateway > at the wholesaler could > forward between 802.11 APs running RADIUS and > enterprise AAA > servers running Diameter. > > It would be useful to try to understand how the CAs are setup in this > usage. So in your example, the wholesaler would maintain a CA that > would sign certs for all of its gateways as well as the enterprise > AAA servers (or for the CAs of the enteprises which in turn would > sign certs for their servers). > > So, upon trying to perform EAP over the AAA infrastructure, the > gateway would get a Redirect from a proxy, and the session would be > directed to the particular enterprise AAA server. I'm confused. Where is this proxy? Who owns it? Why is it even necessary? Given the certification scheme you describe above, why are redirects even necessary? > A Diameter > connection would be setup, protected by TLS using the CA mentioned > earlier as the trust root. > > Looks simple enough, though I worry a bit that we have forgotten > something that causes problems in this scenario. In this limited scenario, since the wholesaler and enterprise appear to have a direct trust relationship I don't see any problem at all. OTOH, what about the case where the enterprise has 50 wholesalers? > But one good thing > is that multi-roundtrip EAP methods don't have to pass through a > large number of proxies. > > One issue is that if even the APs are starting to implement DIAMETER, > the CA has to sign a lot of nodes. What is, by the way, the status of > public domain software for manufacturing certs? Is everyone who has > an SSL server implementation running on their unix box capable of > generating certs? > > Also, I guess Redirect-Host-Usage = REALM_AND_APPLICATION so that > only EAP stuff gets redirected, and accounting not? > > --Jari ~gwz "They that can give up essential liberty to obtain a little temporary safety deserve neither..." -- Benjamin Franklin, 1759 I've stopped 25,199 spam messages. You can too! Get your free, safe spam protection at http://www.cloudmark.com/spamnetsig/ ------=_NextPart_000_0025_01C31FE1.40011020 Content-Type: text/x-vcard; name="Glen Zorn.vcf" Content-Disposition: attachment; filename="Glen Zorn.vcf" Content-Transfer-Encoding: quoted-printable BEGIN:VCARD VERSION:2.1 N:Zorn;Glen FN:Glen Zorn ORG:Cisco Systems TITLE:CTO Consulting Engineer NOTE;ENCODING=3DQUOTED-PRINTABLE:PGP Key Fingerprint: 4F41 B93A 007D = E2FC 9769 FB97 FBCF 7DA4 9A2D 1963=3D0D=3D =3D0A=3D0D=3D0A TEL;HOME;VOICE:+1 (425) 513-8512 TEL;CELL;VOICE:+1 (425) 344-8113 TEL;WORK;FAX:+1 (425) 740-0168 ADR;WORK;ENCODING=3DQUOTED-PRINTABLE:;;500 108th Avenue = N.E.=3D0D=3D0ASuite 500;Bellevue;WA;98004;USA LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:500 108th Avenue = N.E.=3D0D=3D0ASuite 500=3D0D=3D0ABellevue, WA 98004=3D0D=3D0AUSA URL;WORK:http://www.cisco.com EMAIL;PREF;INTERNET:gwz@cisco.com REV:20021107T033833Z END:VCARD ------=_NextPart_000_0025_01C31FE1.40011020-- From owner-aaa-wg@merit.edu Thu May 22 04:20:42 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04371 for ; Thu, 22 May 2003 04:20:42 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 230C291205; Thu, 22 May 2003 04:20:28 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E4D5991206; Thu, 22 May 2003 04:20:27 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 837EA91205 for ; Thu, 22 May 2003 04:20:26 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 64A9B5DF8E; Thu, 22 May 2003 04:20:26 -0400 (EDT) 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 83F645DDF3 for ; Thu, 22 May 2003 04:20:25 -0400 (EDT) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h4M8KO724386 for ; Thu, 22 May 2003 11:20:24 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 22 May 2003 11:20:22 +0300 Received: from esebe003.NOE.Nokia.com ([172.21.138.39]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 22 May 2003 11:20:23 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 22 May 2003 11:20:23 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [AAA-WG]: Responses to Bernard's comments on the Credit Control Application Date: Thu, 22 May 2003 11:20:23 +0300 Message-ID: Thread-Topic: [AAA-WG]: Diameter EAP: Are Redirects sufficient? Thread-Index: AcMfzwyxO5W+eMPOR4CS2oAtwMbHAgAaKVbg From: To: X-OriginalArrivalTime: 22 May 2003 08:20:23.0318 (UTC) FILETIME=[FDB4C360:01C3203A] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id EAA04371 Hi all, We have started to update the CCA to address some of the concerns raised; here are some answers, in no particular order. One concern that Bernard has is: [BA] Overall, this section leads me to believe that the purpose of this document is to provide a general solution to the credit control problem. Is that the intent, or are the goals more specific to 3GPP? If it is the latter, then I think we need some more text describing the applicability of this specification. I think the goals are to define a general purpose mechanism that 3GPP can use. So, I think we need to cover the cases that are general but also make sure that 3GPP can use the application as well. We have been working on text to try to cover these cases: [BA] Here "service element" appears to refer to a Diameter proxy or server. Is that correct? What does "can offer service event to the end user" mean? The service element doesn't speak Diameter to the end user, does it? Anyway, it's the NAS that offers the service, no? This statement confuses me. It seems the definition of 'Service Element' is not so clear, so we have updated it. In principle, a service element can be a Diameter element or even an application server or SIP proxy. I think this will allow (with changes reflected in the document) for this application to be used with Diameter elements & NASes but in scenarios for 3GPP as well. Service Element A network element that provides a service to end user. The Service Element may include the Credit-control Client or another entity (e.g. RADIUS AAA server) can act as a Credit-control Client on behalf of the Service Element. In the latter case the interface between the Service Element and the Diameter Credit-control Client is outside the scope of this specification. We also updated the draft to cover the case where the (H)AAA server interacts with the credit control server and acts as a credit control client and provide the following figures: Figure 1 illustrates the typical credit-control architecture, which consist' of a Service Element with embedded Diameter credit-control client, a Diameter credit-control server and a AAA server. The credit-control server and AAA server in this architecture model are logical entities. The real configuration can combine them into a single host. Service Element AAA +------------+ +-----------+ protocol +--------------+ | End |<----->| +-------+ |<------------>| AAA | | User | +-->| | CC | | | Server | | | | | | client| |<-----+ | | +------------+ | | +-------+ | | +--------------+ | +-----------+ | +------------+ | | | End |<--+ | +--------------+ | User | +------>|Credit-control| +------------+ credit-control | Server | protocol +--------------+ Figure 1 Typical credit-control architecture A service element may authenticate and authorize the end user with the AAA server using AAA protocols, e.g. RADIUS or a Diameter base protocol with a possible Diameter application. Other entities, such as RADIUS AAA server, may act as a Diameter credit-control client towards the Diameter credit-control server for service elements that use credit control mechanisms other than Diameter credit control. In this case the AAA server may contact the Diameter credit-control server as part of the authorization process. This architecture alternative is illustrated in Figure 2, the interaction between the Diameter credit-control client and the service element is outside the scope of this specification. AAA +------------+ +-----------+ protocol +--------------+ | End |<----->| Service |<------------>| AAA | | User | | Element | | Server | +------------+ +-->| | | +----------+ | | +-----------+ | |CC client | | | | +----------+ | +------------+ | +-------A------+ | End |<--+ credit-control | | User | protocol | +------------+ +-------V------+ |Credit-control| | Server | +--------------+ Figure 2 Credit-control architecture with Service Element not supporting the credit-control protocol We've also added some messaging sequences as well, as an appendix. Currently, the draft has a lot of changes in it; it might be helpful for us to post an updated version for review. More comments to follow. John From owner-aaa-wg@merit.edu Thu May 22 04:37:01 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04613 for ; Thu, 22 May 2003 04:37:01 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id BE91691206; Thu, 22 May 2003 04:36:48 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8421591208; Thu, 22 May 2003 04:36:48 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2EFD791206 for ; Thu, 22 May 2003 04:36:47 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 144325DF9D; Thu, 22 May 2003 04:36:47 -0400 (EDT) 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 5A2125DF8C for ; Thu, 22 May 2003 04:36:46 -0400 (EDT) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h4M8aj714752 for ; Thu, 22 May 2003 11:36:45 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 22 May 2003 11:36:44 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 22 May 2003 11:36:45 +0300 Received: from esebe014.NOE.Nokia.com ([172.21.138.53]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 22 May 2003 11:36:44 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe014.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 22 May 2003 11:36:44 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Issue 408: Another Diameter Credit Control Review Date: Thu, 22 May 2003 11:36:43 +0300 Message-ID: Thread-Topic: [AAA-WG]: Issue 408: Another Diameter Credit Control Review Thread-Index: AcMfnz5HJwYCwLUnSXubY492rIMrGgAnEZzw From: To: , X-OriginalArrivalTime: 22 May 2003 08:36:44.0434 (UTC) FILETIME=[467F2F20:01C3203D] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id EAA04613 Hi Avri, Couple of non-technical points: > As mentioned before (in various emails) I belive that the correct way > (from a philosophical point and technical point) is to use > authentication and authorization messages. I belive you have received > comments to this effect from other people so I won't bother to repeat > myself or others. I think we should have a discussion on this point, I'll try to start it in a seperate mail. > Protocol Efficiency > > In many domains where this application will be applicable, the user is > authenticated and authorized to use the service. Part of the > authorization service is to perform Credit or Prepaid authorization. The > problem with the current document is that it *forces* the Credit > Authorization or Prepaid Authorization to be performed after the Service > Authroization. This creates a problem: First, the credit authorization > has to traverse the network again. Since both authorization are done in > the Home network, it seems silly to have to traverse the network again. > Second and more importantly, the delay in having to perform this > operation as a seperate step is not acceptable in many application. I think we can discuss the model of forcing the service authorization. As there can be many different types of service - network access; SIP services, VOIP services, etc.; the model should be flexible to allow staged authorizaiton. > This *must* be addressed to have this document acceptable as a generic > solution. This is not a specific 3GPP solution right? Currently, 3GPP has taken the lead for this type of application. We've started with their requirements. It might be help for others to outline what there needs / requirements are, so we can take them into account. > Types of Credit Control > > It would be nice if several applicable scenario be presented. For > example, its not clear whether the intent of this application is to > cover Prepaid Data Services. We have added this. > How are time and volume based applications handled? > > What about roaming considerations? We will consider these - what are the requirements you are thinking need to be met. > Applicability in other than 3GPP operating environments See above (suggestions & models are helpful) > This document is intended as a Standard Track therefore, it should work > in general operating environments. Actually, this is not necessarily the case. There are plenty of existing proposed standards which define solutions that are very specific uses, networks & architectures. > That is, environments other than > 3GPP. There are certain concepts here that work well in the 3GPP but not > so well in other environments. For example, the notion that a Credit > Control Client can request the user's account balance, or the cost of a > service is not appropriate in all conditions. So, in some cases, you are saying, that a Credit Control client may not be authorized to recieve the user's account - is that correct? I think that this functionality useful, but perhaps we need to have a way to deny the account balance inquiry, correct? > Redirect > > In many instances in the text the action to take when a user resources > are no longer available is to terminate the session. That is one > possible action, the other possible action is to restrict access (or > direct the user) to a portal where they can recharge their account > etc... This is potentially doable. How do you envision such functionality to be handled? Would it configurable based upon the service provider? This functionality, though, could be very tricky to get right. For example, you could imaging a scenario where you are using a pre-paid account to view streaming content via a 3rd party. If your account runs out, the stream should be stopped as the 3rd party has no way to be paid for the rest of the content. The user, of course, could add credits to his/her account and re-attach to the streaming server where they left off. This, however, seems very service specific. My gut feeling is that all we should do here is have a way to notify the user when the user is low on credit and terminate when the user runs out. If services want to add more functionality, it is probably best handled at the service level. br John > Detailed review comments are available below: > > http://www.drizzle.com/~aboba/AAA/lior-comments.txt > > > From owner-aaa-wg@merit.edu Thu May 22 06:32:25 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07397 for ; Thu, 22 May 2003 06:32:25 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7C80691208; Thu, 22 May 2003 06:32:07 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 545C291209; Thu, 22 May 2003 06:32:07 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 36AAD91208 for ; Thu, 22 May 2003 06:32:00 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1093B5E031; Thu, 22 May 2003 06:32:00 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by segue.merit.edu (Postfix) with ESMTP id C8C605E02C for ; Thu, 22 May 2003 06:31:59 -0400 (EDT) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id B0F8B6A901; Thu, 22 May 2003 13:31:57 +0300 (EEST) Message-ID: <3ECCA6C5.9000005@kolumbus.fi> Date: Thu, 22 May 2003 13:30:29 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030313 X-Accept-Language: en-us, en MIME-Version: 1.0 To: gwz@cisco.com Cc: "'Bernard Aboba'" , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Diameter EAP: Are Redirects sufficient? References: <002401c3201b$ec5fe820$389f4104@amer.cisco.com> In-Reply-To: <002401c3201b$ec5fe820$389f4104@amer.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Glen Zorn wrote: > Jari Arkko writes: > > >>Bernard Aboba wrote: >> >> >>>There are quite a few useful features in Diameter Base that could be >>>used to provide improved security beyond what is in RADIUS. This >>>includes things like Redirect support, support for certificate-based >>>authentication, etc. So the question in my mind is why those >>>features cannot be used to solve the problem -- rather than relying >>>on a technology (CMS) which the WG seems to have little interest in >>>developing. >> >>Cool. Lets work this out... >> >> >>So if 802.11 goes the way dial-up has, enterprise customers will >>want >>their users to authenticate against their own authentication >> >>>>infrastructure. > > > That doesn't imply use of untrusted >> >>proxies. A Diameter/RADIUS gateway > at the wholesaler could >>forward between 802.11 APs running RADIUS and > enterprise AAA >>servers running Diameter. >> >>It would be useful to try to understand how the CAs are setup in this >>usage. So in your example, the wholesaler would maintain a CA that >>would sign certs for all of its gateways as well as the enterprise >>AAA servers (or for the CAs of the enteprises which in turn would >>sign certs for their servers). >> >>So, upon trying to perform EAP over the AAA infrastructure, the >>gateway would get a Redirect from a proxy, and the session would be >>directed to the particular enterprise AAA server. > > > I'm confused. Where is this proxy? Who owns it? Why is it even > necessary? Given the certification scheme you describe above, why are > redirects even necessary? Lets draw a picture and use different terms. Here are the domains involved: ------------- At least the consortium and service provider have proxies, optionally both the access provider and company have ones as well. (Access provider is likely to have a proxy if it has more than one NAS/AP.) The cert relationships required for redirect are as follows: - access provider trusts all consortium CAs it is a part of - same for company - consortium needs to sign certs for the CAs of the access provider, service provider, and company. The intention with the redirect idea is that the EAP messaging would go directly from the first DIAMETER-capable node in the access provider (perhaps even the AP) to the last DIAMETER-capable node (perhaps the company AAA server). But the rest of the messaging related to authz would still pass through all proxies. > In this limited scenario, since the wholesaler and enterprise appear to > have a direct trust relationship I don't see any problem at all. OTOH, > what about the case where the enterprise has 50 wholesalers? If an enterprise has multiple service providers, then the keys of its NASes must have multiple certs, one from each service provider. I'm not an expert enough in TLS to know if this will cause a problem. --Jari From owner-aaa-wg@merit.edu Thu May 22 06:46:27 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07635 for ; Thu, 22 May 2003 06:46:27 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E1EBF9120A; Thu, 22 May 2003 06:46:08 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 06E0B9120D; Thu, 22 May 2003 06:46:06 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id EB6759120A for ; Thu, 22 May 2003 06:46:02 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C8C975E052; Thu, 22 May 2003 06:46:02 -0400 (EDT) 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 0BCD45DE33 for ; Thu, 22 May 2003 06:46:02 -0400 (EDT) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h4MAk0721918 for ; Thu, 22 May 2003 13:46:00 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 22 May 2003 13:46:00 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 22 May 2003 13:46:00 +0300 Received: from esebe011.NOE.Nokia.com ([172.21.138.50]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 22 May 2003 13:45:59 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe011.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 22 May 2003 13:45:59 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Issue 408: Another Diameter Credit Control Review Date: Thu, 22 May 2003 13:45:58 +0300 Message-ID: Thread-Topic: [AAA-WG]: Issue 408: Another Diameter Credit Control Review Thread-Index: AcMfnz5HJwYCwLUnSXubY492rIMrGgAq7NMg From: To: , X-OriginalArrivalTime: 22 May 2003 10:45:59.0464 (UTC) FILETIME=[54DADA80:01C3204F] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA07635 Hi Avi, > As mentioned before (in various emails) I belive that the correct way > (from a philosophical point and technical point) is to use > authentication and authorization messages. I belive you have received > comments to this effect from other people so I won't bother to repeat > myself or others. So, it depends upon what functionality you are looking at. On one hand, you are authorizing a service. On the other hand, you are debiting / crediting someone's account. I think this is the rub. It is feasible to use authorization, but you still have to perform some accounting. Bernard made this comment: It seems cleaner to me to use a conventional authentication request/response sequence to inform the Diameter server of the requested service, and have the Diameter server do the service rating, and check the user's credit allocation. The Diameter server can then return the allocated resource usage prior to re-authorization. When the Diameter client has expended the allocated resources it will send a re-authorization request (actually you probably want it to send one sooner in case there are delays). The Diameter server can then check the user's credit limit and the service rating again and allocate more resources, or deny the request and force the user off. I think that this may be an interesting way to provide the functionality, so we are looking into how we could integrate it into the current document. One note about 3GPP. 3GPP already has specified a way to do this kind of prepaid service with Diameter (which is partly the basis for the CCA draft). I think a good solution to the problem would be to create the Diameter application that would support both the 3GPP architecture and a more generic architecture. We are trying to clean-up a lot of text in the current document in order to accomplish this. John From owner-aaa-wg@merit.edu Thu May 22 06:56:12 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07849 for ; Thu, 22 May 2003 06:56:12 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3577D9120F; Thu, 22 May 2003 06:55:42 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 052DB91210; Thu, 22 May 2003 06:55:41 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id ABB529120F for ; Thu, 22 May 2003 06:55:39 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8B0665E05E; Thu, 22 May 2003 06:55:39 -0400 (EDT) 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 A11BE5E05B for ; Thu, 22 May 2003 06:55:38 -0400 (EDT) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h4MAtb704540 for ; Thu, 22 May 2003 13:55:37 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 22 May 2003 13:55:37 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 22 May 2003 13:55:37 +0300 Received: from esebe006.NOE.Nokia.com ([172.21.138.46]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 22 May 2003 13:55:36 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe006.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 22 May 2003 13:55:36 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Issue 408: Another Diameter Credit Control Review Date: Thu, 22 May 2003 13:55:35 +0300 Message-ID: Thread-Topic: [AAA-WG]: Issue 408: Another Diameter Credit Control Review Thread-Index: AcMfnz5HJwYCwLUnSXubY492rIMrGgAq7NMgAAEyn1A= From: To: , X-OriginalArrivalTime: 22 May 2003 10:55:36.0221 (UTC) FILETIME=[ACA0FCD0:01C32050] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA07849 Bernard, > It seems cleaner to me to use a conventional authentication > request/response sequence to inform the Diameter server of > the requested service, and have the Diameter server do the > service rating, and check the user's credit allocation. > The Diameter server can then return the allocated resource > usage prior to re-authorization. When the Diameter client > has expended the allocated resources it will send a > re-authorization request (actually you probably want > it to send one sooner in case there are delays). The > Diameter server can then check the user's credit > limit and the service rating again and allocate more > resources, or deny the request and force the user off. Are you suggesting something like this: NAS AAA Server -------auth req-----> a) check user credit b) if OK, deduct amount (if approriate) <------auth ans --- and reply some time goes by -----re-auth req-----> a) check user credit b) if OK, deduct amount (if approriate) <----re-auth ans --- and reply and so on? John From owner-aaa-wg@merit.edu Thu May 22 09:17:47 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12533 for ; Thu, 22 May 2003 09:17:47 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8711091213; Thu, 22 May 2003 09:17:36 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5CDEE91217; Thu, 22 May 2003 09:17:36 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 610BD91213 for ; Thu, 22 May 2003 09:17:35 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 481985E13F; Thu, 22 May 2003 09:17:35 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id B1C725E13D for ; Thu, 22 May 2003 09:17:34 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h4MCtM711098; Thu, 22 May 2003 05:55:22 -0700 Date: Thu, 22 May 2003 05:55:22 -0700 (PDT) From: Bernard Aboba To: Jari Arkko Cc: gwz@cisco.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: Diameter EAP: Are Redirects sufficient? In-Reply-To: <3ECCA6C5.9000005@kolumbus.fi> Message-ID: References: <002401c3201b$ec5fe820$389f4104@amer.cisco.com> <3ECCA6C5.9000005@kolumbus.fi> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > The intention with the redirect idea is that the EAP messaging would > go directly from the first DIAMETER-capable node in the access provider > (perhaps even the AP) to the last DIAMETER-capable node (perhaps the > company AAA server). But the rest of the messaging related to authz > would still pass through all proxies. I'm not sure it is a requirement the EAP packets go directly, since they're presumably protected by the EAP method. Of course, if they do go directly, the latency will be improved considerably and that might be an important benefit in EAP exchanges that can take as much as 20 roundtrips. The thing that needs to go directly (in the absence of CMS) are the keys. > If an enterprise has multiple service providers, then the keys > of its NASes must have multiple certs, one from each service > provider. I'm not an expert enough in TLS to know if this > will cause a problem. Not sure I parse this. The NAS only needs to be configured with trust anchors sufficient for the Diameter peers that it talks to. The TLS server (the AAA server) can communicate which trust anchors it supports via the cert request payload. Presumably the NAS can find a certificate that matches. From owner-aaa-wg@merit.edu Thu May 22 09:30:01 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13188 for ; Thu, 22 May 2003 09:30:01 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0CFF891217; Thu, 22 May 2003 09:29:49 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CCBB791218; Thu, 22 May 2003 09:29:48 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CEE7691217 for ; Thu, 22 May 2003 09:29:47 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B413C5E1A3; Thu, 22 May 2003 09:29:47 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id C27605E1A2 for ; Thu, 22 May 2003 09:29:44 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h4MD7ip11856; Thu, 22 May 2003 06:07:44 -0700 Date: Thu, 22 May 2003 06:07:44 -0700 (PDT) From: Bernard Aboba To: john.loughney@nokia.com Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: Issue 408: Another Diameter Credit Control Review In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > Are you suggesting something like this: > > NAS AAA Server > -------auth req-----> > a) check user credit > b) if OK, deduct amount (if approriate) > <------auth ans --- and reply a) but not b). The auth req/ans sequence does not demonstrate that the service event has actually occurred -- that is what accounting messages do. So while you can check user credit (and place limits on session-time and other resources) via the answer it is probably not appropriate to credit/debit at that time. This can wait until the accounting messages are sent. > some time goes by > > -----re-auth req-----> > a) check user credit > b) if OK, deduct amount (if approriate) > <----re-auth ans --- and reply In this figure, I'm not clear whether we're talking about re-authentication or re-authorization. I hope it's the latter. What we need in the first authentication answer is AVPs which give the time (or other resources) until session re-authorization (NOT re-authentication). The RADIUS Session-Time attribute isn't appropriate for this, since it forces re-authentication when Termination-Action=1 (RADIUS). So you need to define new AVPs, I think. Assuming that this is done, on re-authorization the user credit is checked again, and new time/resources can be allocated to the session. Note that it is also possible to initiate re-authorization from the Diameter/RADIUS server side, via dynamic authorization messages. Thus, the server can check the declining user credit via the interim accounting messages and decide to change the allocated resources/time at any point. From owner-aaa-wg@merit.edu Thu May 22 16:10:46 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27809 for ; Thu, 22 May 2003 16:10:46 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id CBEBE9122C; Thu, 22 May 2003 16:10:31 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 999A69122D; Thu, 22 May 2003 16:10:31 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3E5D79122C for ; Thu, 22 May 2003 16:10:30 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 297C25E031; Thu, 22 May 2003 16:10:30 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from palrel12.hp.com (palrel12.hp.com [156.153.255.237]) by segue.merit.edu (Postfix) with ESMTP id E7E635DFF2 for ; Thu, 22 May 2003 16:10:29 -0400 (EDT) Received: from xparelay2.ptp.hp.com (xparelay2.ptp.hp.com [15.1.28.65]) by palrel12.hp.com (Postfix) with ESMTP id 7666B1C01326; Thu, 22 May 2003 13:10:29 -0700 (PDT) Received: from xpabh2.ptp.hp.com (xpabh2.ptp.hp.com [15.1.28.61]) by xparelay2.ptp.hp.com (Postfix) with ESMTP id D924A1C00ACA; Thu, 22 May 2003 13:10:28 -0700 (PDT) Received: by xpabh2.ptp.hp.com with Internet Mail Service (5.5.2655.55) id ; Thu, 22 May 2003 13:10:28 -0700 Message-ID: <1D3D2C371FCBD947A7897FABBD3533A566BB4A@xsun01.ptp.hp.com> From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" To: "'Bernard Aboba'" , john.loughney@nokia.com Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: Issue 408: Another Diameter Credit Control Review Date: Thu, 22 May 2003 13:10:21 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi, For those willing to look at PowerPoint vs. ASCII art sequence diagrams, on slide #4 I have a diagram of the interaction model for credit control at: http://www.circumference.org/circumference.ppt The AAA server is labled "IPDR Prepay", but it also shows the other likely relevant elements in the flow of information which include a balance manager and a rating system. Note that there is a distinction between debiting the account and reserving the account. Just like when you register at a hotel, they authorize and reserve some monies against your credit card, they don't actually charge you until you check out; the prepay scenario is the same. Also diagrammed is the "InterimAccounting" which is a somewhat hybrid operation because the service element is both indicating that some service was delivered (accounting) and that there is a desire to reserve more balance (authorization). Regards, Jeff Meyer -----Original Message----- From: Bernard Aboba [mailto:aboba@internaut.com] Sent: Thursday, May 22, 2003 6:08 AM To: john.loughney@nokia.com Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: Issue 408: Another Diameter Credit Control Review > Are you suggesting something like this: > > NAS AAA Server > -------auth req-----> > a) check user credit > b) if OK, deduct amount (if approriate) > <------auth ans --- and reply a) but not b). The auth req/ans sequence does not demonstrate that the service event has actually occurred -- that is what accounting messages do. So while you can check user credit (and place limits on session-time and other resources) via the answer it is probably not appropriate to credit/debit at that time. This can wait until the accounting messages are sent. > some time goes by > > -----re-auth req-----> > a) check user credit > b) if OK, deduct amount (if approriate) > <----re-auth ans --- and reply In this figure, I'm not clear whether we're talking about re-authentication or re-authorization. I hope it's the latter. What we need in the first authentication answer is AVPs which give the time (or other resources) until session re-authorization (NOT re-authentication). The RADIUS Session-Time attribute isn't appropriate for this, since it forces re-authentication when Termination-Action=1 (RADIUS). So you need to define new AVPs, I think. Assuming that this is done, on re-authorization the user credit is checked again, and new time/resources can be allocated to the session. Note that it is also possible to initiate re-authorization from the Diameter/RADIUS server side, via dynamic authorization messages. Thus, the server can check the declining user credit via the interim accounting messages and decide to change the allocated resources/time at any point. From owner-aaa-wg@merit.edu Thu May 22 18:40:07 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03157 for ; Thu, 22 May 2003 18:40:07 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 974989122D; Thu, 22 May 2003 18:39:54 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 62F1691231; Thu, 22 May 2003 18:39:54 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B75CC9122D for ; Thu, 22 May 2003 18:39:51 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9B28F5E127; Thu, 22 May 2003 18:39:51 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from exch01.bridgewatersys.com (bws10.bridgewatersystems.com [216.113.7.10]) by segue.merit.edu (Postfix) with ESMTP id 156C15E123 for ; Thu, 22 May 2003 18:39:51 -0400 (EDT) Received: by exch01.bridgewatersys.com with Internet Mail Service (5.5.2653.19) id ; Thu, 22 May 2003 18:39:50 -0400 Message-ID: From: Avi Lior To: "'john.loughney@nokia.com'" , "'aboba@internaut.com'" , "'aaa-wg@merit.edu'" Subject: RE: [AAA-WG]: Issue 408: Another Diameter Credit Control Review Date: Thu, 22 May 2003 18:39:49 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi John, I am on vacation so I can't get to the email as often as I would like ;-) Note that 3GPP2 or is in the process of defining a prepaid solution using radius -- see IS-835C Chapter 6 ( I can get it you if you can't). I also have an IETF I-D that I will update to line up the 3GPP2 solution. So you guys are not the only or the first to do this.(this is to address a comment in a previous email) It would be very good if you can, at least in a prepaid scenario, allocate an initial quota during the authentiction/authorization phase. This will address the latency issue I brought up. Second, use re-authorization messages to re-allocate quotas. This would line up with RADIUS nicely when you have to interoperate. And we will have to interoperate! In 3GPP2 for example and in the all RADIUS WLAN world. In the RADIUS world Accounting messages are just not usable for this type of interaction. Its not a philosophical point (although it does stem from the fact that accounting message in both RADIUS and DIAMETER are meant to report or record an event that happened and not to be used for controlling a session). In RADIUS accounting messages can be stored by intermediaries and forwarded at a later time. More comments inline..... > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: May 22, 2003 6:46 AM > To: aboba@internaut.com; aaa-wg@merit.edu > Subject: RE: [AAA-WG]: Issue 408: Another Diameter Credit > Control Review > > > Hi Avi, > > > As mentioned before (in various emails) I belive that the > correct way > > (from a philosophical point and technical point) is to use > > authentication and authorization messages. I belive you > have received > > comments to this effect from other people so I won't bother > to repeat > > myself or others. > > So, it depends upon what functionality you are looking at. > On one hand, you are authorizing a service. On the other > hand, you are debiting / crediting someone's account. I > think this is the rub. It is feasible to use authorization, > but you still have to perform some accounting. You are really not doing accounting. And certainly you are not doing accouting in the RADIUS/DIAMETER context which view accounting as a recording function and not something you act on. What your application is doing is debiting and crediting a resource (a users account) we debit and credit resources all the time in RADIUS and DIAMETER. For example, when a user logs on we increment a counter, and when he logs off we decriment a counter. This way we can enforce how many concurrent logins a user can have. This is an accounting function right? But you would never do it using accounting records. So just because you are debiting and crediting money from a user's account that doesn't necessarily make it accounting in the RADIUS/DIAMETER context. > Bernard made this comment: > > It seems cleaner to me to use a conventional authentication > request/response sequence to inform the Diameter server of > the requested service, and have the Diameter server do the > service rating, and check the user's credit allocation. The > Diameter server can then return the allocated resource usage > prior to re-authorization. When the Diameter client has > expended the allocated resources it will send a > re-authorization request (actually you probably want it to > send one sooner in case there are delays). The Diameter > server can then check the user's credit limit and the > service rating again and allocate more resources, or deny > the request and force the user off. > > I think that this may be an interesting way to provide the > functionality, so we are looking into how we could integrate > it into the current document. > > One note about 3GPP. 3GPP already has specified a way to do > this kind of prepaid service with Diameter (which is partly > the basis for the CCA draft). I think a good solution to the > problem would be to create > the Diameter application that would support both the 3GPP > architecture and a more generic architecture. We are trying > to clean-up a lot of text in the current document in order to > accomplish this. I look forward to see the next draft. > John > Looking to offer a managed WLAN Service? Download our market report, completed by Telechoice Market Analyst group, to learn more. http://www.bridgewatersystems.com/learnmore From owner-aaa-wg@merit.edu Thu May 22 18:56:23 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03921 for ; Thu, 22 May 2003 18:56:22 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1132391231; Thu, 22 May 2003 18:56:02 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D4FDA91233; Thu, 22 May 2003 18:56:01 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7FE7D91231 for ; Thu, 22 May 2003 18:56:00 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 60EBB5E143; Thu, 22 May 2003 18:56:00 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from exch01.bridgewatersys.com (bws10.bridgewatersystems.com [216.113.7.10]) by segue.merit.edu (Postfix) with ESMTP id D32895E141 for ; Thu, 22 May 2003 18:55:59 -0400 (EDT) Received: by exch01.bridgewatersys.com with Internet Mail Service (5.5.2653.19) id ; Thu, 22 May 2003 18:55:59 -0400 Message-ID: From: Avi Lior To: "'Bernard Aboba'" , "'john.loughney@nokia.com'" Cc: "'aaa-wg@merit.edu'" Subject: RE: [AAA-WG]: Issue 408: Another Diameter Credit Control Review Date: Thu, 22 May 2003 18:55:58 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-aaa-wg@merit.edu Precedence: bulk I have some issues with these scenarios at least from a Prepaid context. See inline. > -----Original Message----- > From: Bernard Aboba [mailto:aboba@internaut.com] > Sent: May 22, 2003 9:08 AM > To: john.loughney@nokia.com > Cc: aaa-wg@merit.edu > Subject: RE: [AAA-WG]: Issue 408: Another Diameter Credit > Control Review > > > > Are you suggesting something like this: > > > > NAS AAA Server > > -------auth req-----> > > a) check user credit > > b) if OK, deduct amount (if approriate) > > <------auth ans --- and reply > > a) but not b). The auth req/ans sequence does not demonstrate > that the service event has actually occurred -- that is what > accounting messages do. So while you can check user credit > (and place limits on session-time and other > resources) via the answer it is probably not appropriate to > credit/debit at that time. This can wait until the accounting > messages are sent. You can debit the users account when the next Prepaid Authorization message comes in. So that when the NAS askes for more resources using the authorization message you can commit the previously allocated amount at that time. This way you don't need accounting messages. One thing is that you want to generate an Authorize only message when the session ends (similar to account stop message). This is what 3GPP2 is doing for prepaid. > > some time goes by > > > > -----re-auth req-----> > > a) check user credit > > b) if OK, deduct amount (if approriate) > > <----re-auth ans --- and reply > > In this figure, I'm not clear whether we're talking about > re-authentication or re-authorization. I hope it's the > latter. What we need in the first authentication answer is > AVPs which give the time (or other resources) until session > re-authorization (NOT re-authentication). The RADIUS > Session-Time attribute isn't appropriate for this, since it > forces re-authentication when Termination-Action=1 (RADIUS). > So you need to define new AVPs, I think. The AVP mentioned above is the PPAQ AVP used in 3GPP2. > Assuming that this is done, on re-authorization the user > credit is checked again, and new time/resources can be > allocated to the session. Note that it is also possible to > initiate re-authorization from the Diameter/RADIUS server > side, via dynamic authorization messages. Thus, the server > can check the declining user credit via the interim > accounting messages and decide to change the allocated > resources/time at any point. I just want to make sure that accounting messages are not needed for these applications at all. If they are available in real-time they can help in tracking a sessions progress. If they are not available in real-time they can be used for post checking (consolidating accounts) and error recovery. You can do everything using Auth and Authz messages. Looking to offer a managed WLAN Service? Download our market report, completed by Telechoice Market Analyst group, to learn more. http://www.bridgewatersystems.com/learnmore From owner-aaa-wg@merit.edu Thu May 22 23:01:00 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09564 for ; Thu, 22 May 2003 23:01:00 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1A66991237; Thu, 22 May 2003 23:00:11 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D1AF291239; Thu, 22 May 2003 23:00:10 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E7A0E91237 for ; Thu, 22 May 2003 23:00:08 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 96A175E278; Thu, 22 May 2003 23:00:07 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by segue.merit.edu (Postfix) with ESMTP id 937B55E261 for ; Thu, 22 May 2003 23:00:06 -0400 (EDT) Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h4N2tu0u023169; Thu, 22 May 2003 19:59:55 -0700 (PDT) Received: from gwzw2k (sjc-vpn3-856.cisco.com [10.21.67.88]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with ESMTP id TAA19102; Thu, 22 May 2003 19:41:44 -0700 (PDT) Reply-To: From: "Glen Zorn" To: "'Jari Arkko'" Cc: "'Bernard Aboba'" , Subject: RE: [AAA-WG]: Diameter EAP: Are Redirects sufficient? Date: Thu, 22 May 2003 19:41:04 -0700 Organization: Cisco Systems Message-ID: <001201c320d4$d5029e20$389f4104@amer.cisco.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0013_01C3209A.28A3C620" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 In-Reply-To: <3ECCA6C5.9000005@kolumbus.fi> Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0013_01C3209A.28A3C620 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Jari Arkko writes: ... >>> >>> So, upon trying to perform EAP over the AAA infrastructure, the >>> gateway would get a Redirect from a proxy, and the session would be >>> directed to the particular enterprise AAA server. >> >> >> I'm confused. Where is this proxy? Who owns it? Why is it even >> necessary? Given the certification scheme you describe above, why >> are redirects even necessary? > > Lets draw a picture and use different terms. Here are the domains > involved: > > ------------- Which of these is The Entity Fomerly Known As Wholesaler? > > At least the consortium and service provider have proxies, optionally > both the access provider and company have ones as well. But Bernard's original note said "As a hypothetical, what if Diameter EAP were to strongly discourage use of proxies, and encourage use of redirects instead." You seem to be saying that proxies are virtually everywhere... > (Access provider is likely to have a proxy if it has more than one NAS/AP.) > > The cert relationships required for redirect are as follows: > - access provider trusts all consortium CAs it is a part of > - same for company > - consortium needs to sign certs for the CAs of the access provider, > service provider, and company. > > The intention with the redirect idea is that the EAP messaging would > go directly from the first DIAMETER-capable node in the access > provider (perhaps even the AP) to the last DIAMETER-capable node > (perhaps the company AAA server). But the rest of the messaging > related to authz would still pass through all proxies. OK, so it sounds like a) redirects are superfluous after the first (for any given node pair) since an NAI -> server mapping can be stored on the NAS/gateway/whatever and b) any and all authorization/accounting data is deemed insufficiently valuable to warrant protection from malicious proxies; a) sounds great, b) sounds very dangerous. > >> In this limited scenario, since the wholesaler and enterprise appear >> to have a direct trust relationship I don't see any problem at all. >> OTOH, what about the case where the enterprise has 50 wholesalers? > > If an enterprise has multiple service providers, then the keys of its > NASes must have multiple certs, one from each service provider. Sorry, can't parse this statement. > I'm not an expert enough in TLS to know if this will cause a problem. > > --Jari ~gwz "They that can give up essential liberty to obtain a little temporary safety deserve neither..." -- Benjamin Franklin, 1759 I've stopped 25,248 spam messages. You can too! Get your free, safe spam protection at http://www.cloudmark.com/spamnetsig/ ------=_NextPart_000_0013_01C3209A.28A3C620 Content-Type: text/x-vcard; name="Glen Zorn.vcf" Content-Disposition: attachment; filename="Glen Zorn.vcf" Content-Transfer-Encoding: quoted-printable BEGIN:VCARD VERSION:2.1 N:Zorn;Glen FN:Glen Zorn ORG:Cisco Systems TITLE:CTO Consulting Engineer NOTE;ENCODING=3DQUOTED-PRINTABLE:PGP Key Fingerprint: 4F41 B93A 007D = E2FC 9769 FB97 FBCF 7DA4 9A2D 1963=3D0D=3D =3D0A=3D0D=3D0A TEL;HOME;VOICE:+1 (425) 513-8512 TEL;CELL;VOICE:+1 (425) 344-8113 TEL;WORK;FAX:+1 (425) 740-0168 ADR;WORK;ENCODING=3DQUOTED-PRINTABLE:;;500 108th Avenue = N.E.=3D0D=3D0ASuite 500;Bellevue;WA;98004;USA LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:500 108th Avenue = N.E.=3D0D=3D0ASuite 500=3D0D=3D0ABellevue, WA 98004=3D0D=3D0AUSA URL;WORK:http://www.cisco.com EMAIL;PREF;INTERNET:gwz@cisco.com REV:20021107T033833Z END:VCARD ------=_NextPart_000_0013_01C3209A.28A3C620-- From owner-aaa-wg@merit.edu Thu May 22 23:26:38 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA10044 for ; Thu, 22 May 2003 23:26:38 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 267F591239; Thu, 22 May 2003 23:26:25 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E84A79123A; Thu, 22 May 2003 23:26:24 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0686C91239 for ; Thu, 22 May 2003 23:26:24 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E9CD85E291; Thu, 22 May 2003 23:26:23 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 78F8A5E1CA for ; Thu, 22 May 2003 23:26:23 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h4N34Mo25505 for ; Thu, 22 May 2003 20:04:22 -0700 Date: Thu, 22 May 2003 20:04:22 -0700 (PDT) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: New Diameter EAP Editorial Team Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Starting immediately, Pasi Eronen will be taking over the editorship of the Diameter EAP specification. The immediate goal is to ready a complete version of the specification by the draft submission deadline for IETF 57. Please welcome Pasi as the new editor of Diameter EAP. Here's his introduction: "Hi everyone! My name is Pasi Eronen, and I'm working at Nokia Research Center in Helsinki, Finland. My work involves various security and standardization related issues. Lately I've been involved in EAP WG, and I'm a co-author of the EAP State Machine draft." From owner-aaa-wg@merit.edu Fri May 23 03:39:46 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27315 for ; Fri, 23 May 2003 03:39:46 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DD2779123A; Fri, 23 May 2003 03:39:32 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9C9799123B; Fri, 23 May 2003 03:39:32 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 374599123A for ; Fri, 23 May 2003 03:39:31 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E83705E3F2; Fri, 23 May 2003 03:39:30 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by segue.merit.edu (Postfix) with ESMTP id C61D15E3B7 for ; Fri, 23 May 2003 03:39:29 -0400 (EDT) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h4N7dLD19797 for ; Fri, 23 May 2003 10:39:26 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 23 May 2003 10:39:14 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 23 May 2003 10:39:13 +0300 Received: from esebe002.NOE.Nokia.com ([172.21.138.17]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 23 May 2003 10:39:12 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 23 May 2003 10:39:06 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Issue 408: Another Diameter Credit Control Review Date: Fri, 23 May 2003 10:38:41 +0300 Message-ID: Thread-Topic: [AAA-WG]: Issue 408: Another Diameter Credit Control Review Thread-Index: AcMgsw+5QIoTlKYcSkK+dpEjr3SdZwASnkNw From: To: , , X-OriginalArrivalTime: 23 May 2003 07:39:06.0516 (UTC) FILETIME=[63D48540:01C320FE] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA27315 Hi Avi, > Note that 3GPP2 or is in the process of defining a prepaid solution using > radius -- see IS-835C Chapter 6 ( I can get it you if you can't). I also > have an IETF I-D that I will update to line up the 3GPP2 solution. So you > guys are not the only or the first to do this.(this is to address a comment > in a previous email) I never suggest that 3GPP was the only one doing this, they already do have a 3GPP standard using Diameter completed. That was more my point. > It would be very good if you can, at least in a prepaid scenario, allocate > an initial quota during the authentiction/authorization phase. This will > address the latency issue I brought up. As I understand, this is what the current 3GPP2 spec proposes. > Second, use re-authorization messages to re-allocate quotas. This would > line up with RADIUS nicely when you have to interoperate. And we will have > to interoperate! In 3GPP2 for example and in the all RADIUS > WLAN world. Well, perhaps I should re-read the proposed 3GPP2 spec, but I was under the assumption that after the initial quota is met, accounting messages are used to report the used quota and request an additional quota. I'll try to dig around and find the spec ... > In the RADIUS world Accounting messages are just not usable for this type of > interaction. Its not a philosophical point (although it does stem from the > fact that accounting message in both RADIUS and DIAMETER are meant to report > or record an event that happened and not to be used for controlling a > session). In RADIUS accounting messages can be stored by intermediaries and > forwarded at a later time. Of course, we are defining a Diameter application, not a RADIUS application. We should consider how to interwork with RADIUS for certain scenarios, but I guess I have not seen a requirement that everything done in Diameter MUST be equally usuable with RADIUS. John From owner-aaa-wg@merit.edu Fri May 23 13:09:07 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13830 for ; Fri, 23 May 2003 13:09:07 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C7A6591245; Fri, 23 May 2003 13:08:53 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9951091246; Fri, 23 May 2003 13:08:53 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 62B0391245 for ; Fri, 23 May 2003 13:08:52 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 46F785E799; Fri, 23 May 2003 13:08:52 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from exch01.bridgewatersys.com (bws10.bridgewatersystems.com [216.113.7.10]) by segue.merit.edu (Postfix) with ESMTP id B90CD5E794 for ; Fri, 23 May 2003 13:08:51 -0400 (EDT) Received: by exch01.bridgewatersys.com with Internet Mail Service (5.5.2653.19) id ; Fri, 23 May 2003 13:08:50 -0400 Message-ID: From: Avi Lior To: "'john.loughney@nokia.com'" , Avi Lior , "'aboba@internaut.com'" , "'aaa-wg@merit.edu'" Subject: RE: [AAA-WG]: Issue 408: Another Diameter Credit Control Review Date: Fri, 23 May 2003 13:08:50 -0400 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 John, > Well, perhaps I should re-read the proposed 3GPP2 spec, but I > was under the assumption that after the initial quota is met, > accounting messages are used to report the used quota and > request an additional quota. I'll try to dig around and find > the spec ... Regarding 3GPP2: during V&V we changed prepaid to work with Access Request messages. On-line Accounting is not used anymore. This will make it easier to work with other RADIUS scenarios such as WLAN. > Of course, we are defining a Diameter application, not a > RADIUS application. We should consider how to interwork with > RADIUS for certain scenarios, but I guess I have not seen a > requirement that everything done in Diameter MUST be equally > usuable with RADIUS. I will leave the "MUST" to the AAA-WG. But IMHO, RADIUS is not going to die any day soon so we SHOULD make sure that Diameter interopperates with RADIUS. For example, recently CHIBA went a "major" change to make sure that it would interoperate with DIAMETER deployments. Avi Looking to offer a managed WLAN Service? Download our market report, completed by Telechoice Market Analyst group, to learn more. http://www.bridgewatersystems.com/learnmore From owner-aaa-wg@merit.edu Thu May 29 06:55:06 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26139 for ; Thu, 29 May 2003 06:55:06 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 82DF29124F; Thu, 29 May 2003 06:54:54 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5499691250; Thu, 29 May 2003 06:54:54 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 302E39124F for ; Thu, 29 May 2003 06:54:53 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1ADB65E2A1; Thu, 29 May 2003 06:54:53 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from polito.it (terra.polito.it [130.192.3.81]) by segue.merit.edu (Postfix) with ESMTP id 9420C5E101 for ; Thu, 29 May 2003 06:54:52 -0400 (EDT) Received: from [130.192.1.21] (HELO polito.it) by polito.it (CommuniGate Pro SMTP 4.1b2) with ESMTP-TLS id 7809923; Thu, 29 May 2003 12:47:59 +0200 Message-ID: <3ED5E6B5.4040301@polito.it> Date: Thu, 29 May 2003 12:53:41 +0200 From: Corrado Derenale Reply-To: derenale@polito.it User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020830 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba , glennz@microsoft.com Cc: aaa-wg@merit.edu Subject: [AAA-WG]: Some questions on RFC2477: 'Evaluating Roaming Protocols' 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 Dear Bernard, the RFC 2477 is a little old, it came from 1999 and so there is no reference to 802.1x, but only to phonebooks and PPP/SLIP protocols as access to the network infrastructure; today, with 802.11 and 802.1x the network arcitecture is changing, or better, is yet changed. In the identification/authentication requirements (paraghraph 2.3) there is a MUST only for the RADIUS support, what about DIAMETER? In the end, the question is: have you already update the RFC 2477 with a new draft, if is so sorry for bothering you. Otherwise are you thinking about update it? Thank You very much, Corrado. From owner-aaa-wg@merit.edu Thu May 29 09:02:46 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01862 for ; Thu, 29 May 2003 09:02:46 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B7DBD9124E; Thu, 29 May 2003 09:02:28 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8378491253; Thu, 29 May 2003 09:02:28 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 87AFF9124E for ; Thu, 29 May 2003 09:02:27 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 666255E2C8; Thu, 29 May 2003 09:02:27 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id EBB215E156 for ; Thu, 29 May 2003 09:02:26 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h4TCc7D22456; Thu, 29 May 2003 05:38:08 -0700 Date: Thu, 29 May 2003 05:38:06 -0700 (PDT) From: Bernard Aboba To: Corrado Derenale Cc: glennz@microsoft.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: Some questions on RFC2477: 'Evaluating Roaming Protocols' In-Reply-To: <3ED5E6B5.4040301@polito.it> Message-ID: References: <3ED5E6B5.4040301@polito.it> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk RFC 2989 collects all the requirements and summarizes them. So at this point it is the appropriate deocument to cite rather than RFC 2477.