Chairs: Paul Krumviede (paul@mci.net), Brian LLoyd (brian@lloyd.com) Minutes: Steve Moulton and Dave Mitton Brian Lloyd introduced the new chairs and started a discussion of purpose of the group as currently chartered. A list of "nots" was presented: - not a protocol development group - not the Diameter WG - not the COPS WG - not the RADIUS WG Want to look at the applications and services that need to use AAA and look at their characteristics and requirements. An initial, non-exclusive list was presented to start with: Remote Access, L2TP VPNs (IPsec and others) Bandwidth Broker VoIP Mobile IP others? Additional suggestions from the floor included: web repositories, information repositories, e-commerce, news servers, management control services, system login, printing. Authentication access to content and administrative data suggested; not clear if this in scope. Someone asked if we should/could work on definitions first, but consensus favored working applications requirements as we were proceeding. Should we define applications that are out-of-scope? like POP/IMAP which have their own mechanisms. While we should try not to overlap other groups efforts, we should stay open to other groups adapting our mechanisms. It was suggested that we should try to fit into applicable current security mechanisms (like GSS-API). There was also a concern that we may end up duplicating other work (e.g., don't re-invent Kerberos). Paul K indicated that he thought the charter too ambitious in some respects and we will have to work on a subset of the general problem. A discussion of authentication started by pointing out the multiple existing techniques for authentication (e.g.: assertion, password, shared secret). We need to define what persistent date is required so that we can figure out what features are required in the protocol(s). It's likely that we will need more than one protocol. It was further suggested that we consider not just algorithms but frameworks too (e.g.: EAP, Xauth, GSS-API). SASL has 13 different techniques in draft status. It was pronounced that this WG isn't currently working with transports, and will not discuss transports issues (e.g., UDP vs. TCP) at this time. Want to see what RUTS/SLUMS does. The discussion of accounting started with enumerating some of the different types of accounting services and practices. transaction vs session oriented services types of services needs for billing needs for resource and allocation, usage and network engineering Brian claimed he believed accounting was a separable problem, unlike authentication and authorization which seem to be intertwined. There was disagreement from the floor, authorization may be dependent on accounting data. Brian explained that state information dependencies should not be tied to accounting services. Just because some RADIUS implementations use accounting to compensate for lack of state, that is not what I mean here. A comment was made that billing doesn't need dollars counts, just usage information. It was explained that this was the intention of the item. That is collecting data for external usage, but the requirements of different users will affect the delivery and dissemination of the information. Accounting definitions get fuzzy, we need to work the sources, but not necessarily all of the uses. It was requested that we will want to address both real-time and batch needs. There will be desires to want to gather information together, and do correlation and trend analysis. The information should hold up to this kind of operation. This led to needs for accounting correlation for the purposes of tracking intrusion detection, yes? Bernard: Needs may be different, but we should explore them. MarkB: Need to separate accounting from monitoring. Not a byte/packet monitor JohnV: Should put in the need for fraud detection system. Should keep that in mind. This framework will generate lots of information for different users; are we going to include mechanisms for customizing the information (views, cuts) ? - PaulK: maybe, but that might be something we deal with later Authorization -least understood - what is the relationship to Policy? they will interact and we will have to define this - Does it require authentication? - Not always... sometimes entities may be talking among themselves - authentication by assertion is sometimes used m: more experience today... ACLs, etc.... policies that are used based on your identity are often very service dependent. Hard to standardize this... should look at common frameworks for authorization models. ACL related: LDAP, IMAP, ACAP.... have these design features. authentication can be implicit example mandatory tunnel setup, sets up tunnel based on your phone number. Denis Pinkas: authorization maybe interested in roles as a dimension of authorization (role-based authentication). CAT is working authentication - BrianL we are overlapping, and not doing protocols m: scope? real -time payment methods - PaulK: not payment per-se, but certainly a discussion topic there are other schemes in this area (e.g.: IOTP) that we could tie into but not try to recreate it ourselves. Will not rule it out, but won't rule it in either. Protocols are referred to in the charter - we are trying to stall that for now, as people are jumping straight into protocol messages and data elements. Eventually we will push protocol issues out to other groups and/or re-charter when we are ready. JohnV - single or multiple authorizing parties; maybe more. Accounting requires an identity not just a authentication, distinct for tracking instances, and unauthenticated users. Also authorization by role. m: Non-repudiation? - PK: not going to devise a protocol, but the accounting data may need this (as may other forms of data, such as requests, approvals or denials, and authorizations). How this is provided is open for discussion. Some authentication methods may not allow non-repudiation. FredB: could be certificates, could be detecting missing data m: non-repudiation could be handled by transactions Marcus: non-repud is a legal problem with soft boundaries, we don't want to go there. Technical problems are difficult to satisfy. Paul: the cost of supporting this is also an issue. PatC: must take brokering into account, RoamOps would make this requirement. Tomorrow: - give presentations from subgroups people to split up into subgroups and pursue initial issues 3:30 pm AAA - groups to produce draft-documents by end of April Strawman architecture diagram presented by Brian Lloyd and discussed - Application AAA Focus Group (Alex, Siggy Maier) Note that in some cases authentication and authorization may be based on payment info rather than identity. - Bandwidth Broker (Sue Hares, Shai Herzog) note the desire to support multicast applications here. includes dynamic allocation of bandwidth resources domain chaining process Basic Operations: Requestor has authentication requirements Grantor performs admission control to domain Updates/Notification - needs may change, availability may change SLAs - diagram of chaining application to campus net to backbone provider(s) to remote lab net wants to account for bandwidth used by connection Question arose as to whether or not denial of service should be considered in AAA. Marcus suggests solving the obvious cases first. - Mobile IP (Stuart Jacobs) Authentication requirements scaleability performance: at most 1 sec, inter-domain; less than 1 sec intra-domain non-repudiation two-way One-way: mobile node to visited network authentication data exchange expedited re-registration authentication Authorization requirements Policy driven QoS;location hiding; Tunneling; Dynamic/non HAs; other Bandwidth broker? Accounting per mobile node reconciliation network port and addresses traffic handled; bytes, packets, tunneled packets NAIs used integrity, accuracy retention time privacy Fraud RoamOps model VoIP (Pat C, Ping Pan, Rosenberg) AAA server is used to centralize the user VoIP profile, call handling features support both user owned SIP client as well as public telephones in public case, the authentication must be done between user and the home server discussions on whether roaming is a suitable topic for discussion here voip may require additional dynamic authorization and authentication to setup fancy call features (3way bridging, etc.) VoIP may involve billing requirements, and certainly inter-domain issues SIP AAA server can return users profile, which can include calling features, speed dial, etc. Successful sequence indicates willingness to pay AAA may/will keep state information about previous calls Accounting; Start and Stop records (some SIP problems here) E-Commerce (Jason Eaton) diagram of Http/ssl exchange to Merchant server Merchant talks SCMP, S/Mime, SSL to E-commerce provider E-commerce provider does fraud detection, payment processing, Fulfillment, address verification Merchant and E-commerce Provider talk to Merchant bank The bank needs to setup trust relationship and authenticate NASreq (Dave Mitton - Nortel) Need to support transition from existing RADIUS services. Authentication (Mark Stevens - Lucent) Examine current authentication technology Outline the authentication requires of a good sample of application correlate various authentication methods with requirements of applications evaluate existing protocols and authentication for fit publish informational document BrianCarp: Do need to know identity of authenticatee before attempting authentication? No, we don't want to go down rathole of distinguished names. How many methods?, performance issues; should be a matter of policy But the design goal should include performance issues, if there are lots of iterations of authentications over the life of the individual sessions. e.g.: Kerberos is considered a good approach because it aids performance (can do local verification of tickets). do we care about the survey?, we have to support existing techniques yes, and some protocols have not chosen yet and may want to use whatever this group may provide Accounting (Nevil Brownlee) references aboba and arkko drafts as pre-existing 19 I-Ds and 8 RFCs concerned with Accounting Examples: - RADIUS Accounting (RFC 2139) - RoamOps ietf-roamops-acctng-05.txt - Atommib (RFC2512) MIB - Atommib (RFC2513) Collection & Storage - ISDN (RFC2573) MIB - RTFM (RFC 2063) Measurement Architecture - RTFM (RFC 2064) Meter MIB work on a generalized form for describe accounting data, maybe a file format Accounting terminology (Bernard) Application usage characteristics and needs: sensitivity to data loss, delay, security needed. Differences between flat-rate billing and usage sensitive or transactional billing used as example to demonstrate different requirements. Scaling and Reliability issues - contributing causes attack the storage issue not the network protocol problems Why not SNMP? polling model is efficient SNMP v3 provides security adequate for intra-domain accounting Issues with inter-domain accounting access rights issues index table by provider, or context use but most MIBs are not structured this way Bob Stewart; SNMP can be used in file transfer mode Bulk transfer issues high volume accounting Push model needed in some cases; high value transactions, fraud detect, sparse contact m: some systems (ex: hotel checkout) will require push, as immediate billing is required mailing list aaa-wg@merit.edu Interim meetings & teleconference: expect to have, will be discussed on list Paul Krumvide Brian Lloyd Authorization Requirements (Pat C presenting) 6 drafts and RFC2477 George Gross discusses diagram of Policy Decision Points, PEPs, PDPs. Notion of attribute certificates as possible approach for authorization. Pat C discusses Inter-Domain AAA